Scenario-Based Cloud Computing Interview Questions With Answers

A scenario-based cloud computing question describes a business situation and asks what you would build or change. The seven scenarios below cover the areas every cloud interview tests: scaling, migration, security, cost, availability, and data storage. A strong answer has three parts: one stated assumption, the design with the class of service named, and the trade-off you accept. Provider names such as AWS, Azure, or GCP are optional. The concept is what is scored.

How to answer a scenario question

State one assumption with a number before you design. "I will assume 10,000 requests per second at peak and a 99.9 percent availability target" gives the interviewer something to correct and gives your design a reason. Then name the parts and end with what the design gives up. Two minutes per scenario is enough in a screening round.

Scaling and availability scenarios

Question 1. A product launch will bring 20 times normal traffic for two hours. How do you prepare?

Put the web tier in an auto scaling group with a target of about 60 percent average CPU, so that new instances start before the existing ones saturate. Place a load balancer in front and a content delivery network (CDN), a set of edge servers that cache static files near users, so that images and scripts never reach the origin. Cache the catalog in Redis with a 60-second time to live. Pre-warm the fleet 30 minutes before launch, because a new instance takes 2 to 5 minutes to become healthy. The trade-off is paying for idle capacity during that window.

Question 2. Design for high availability and disaster recovery for an e-commerce site.

Define two numbers first. The recovery time objective (RTO) is how long the site may be down, and the recovery point objective (RPO) is how much data may be lost. For an RTO of 15 minutes and an RPO of 1 minute, run the application across at least 2 availability zones, which are separate data centers in one region, behind a load balancer with health checks. Use a managed database with a synchronous standby in a second zone and automatic failover, typically 30 to 120 seconds. Replicate backups to a second region for a regional failure, and test the failover every quarter. A second-region standby roughly doubles the cost.

Migration and data scenarios

Question 3. Migrate an on-premises database to the cloud with minimal downtime.

Measure the database first: size, write rate, and the applications that depend on it. Choose a managed database of the same engine to avoid a rewrite. Take a full copy, then run a migration service with change data capture, which reads the source's transaction log and replays each change to the target, until the target is within seconds of the source. Cut over during the lowest-traffic hour by stopping writes, waiting for the lag to reach zero, and repointing the application. Downtime is the length of that final step, usually under 10 minutes.

Question 4. What is the simplest way to choose a cloud database service?

Ask two questions about the data. If the application needs joins and multi-row transactions, use a managed relational database such as PostgreSQL or MySQL. If it reads and writes single items by key at very high rates, use a key-value store such as DynamoDB. If it stores files larger than about 1 MB, use an object store, not a database. Most applications start relational and add one specialized store later.

Security scenarios

Question 5. Secure customer financial data stored in the cloud.

Encrypt data at rest with AES-256 using keys in a managed key service, and encrypt data in transit with TLS 1.2 or later. Apply least privilege through identity and access management (IAM): each service gets a role that allows only the actions it needs, and every human account uses multi-factor authentication. Place databases in private subnets of a virtual private cloud (VPC) with no public address, and reach them only through the application tier. Name the standard that applies, such as PCI DSS for card data, and map each control to it.

Cost scenarios

Question 6. How do you identify underutilized cloud instances?

Pull 14 days of metrics and flag any instance whose average CPU is under 10 percent and whose network traffic is under 5 MB per day on most of those days. That is the rule the cloud providers' own advisors use. Check memory as well, because a database instance can be idle on CPU and full on memory. Right-size the flagged instances one size down, or move them to a schedule that stops them outside working hours, which removes about 65 percent of the hours in a week.

Question 7. Cloud costs have doubled in a year. What do you do without reducing performance?

Tag every resource by team and service so that the bill can be attributed, then reduce the largest three lines. Buy commitments for the steady part of the load, because reserved capacity or savings plans cost up to about 70 percent less than on-demand pricing. Move batch and fault-tolerant work to spot instances, which are cheaper still but can be reclaimed with a 2-minute notice. Add lifecycle rules to object storage so that files move to a colder tier after 30 days and to archive after 90 days.

What each scenario tests

How to Prepare

• Learn the building blocks these answers name. Load balancers, caches, CDNs, replication, and object storage are each explained in Grokking System Design Fundamentals.
• Practice full designs, not only single answers. Grokking the System Design Interview works through complete systems where several of these scenarios appear together.
• Study the named patterns for availability and cost. System Design Patterns covers failover, checkpointing, and rate limiting with diagrams.
• Rehearse aloud with a time limit. A mock interview shows whether you can state the assumption, the design, and the trade-off in two minutes.