Cloud Fundamentals
IAM roles and least privilege, VPC and public/private subnets, security groups vs NACLs, autoscaling groups, regions and availability zones, and cost control.
10 questions
JuniorTheoryVery commonWhat is the difference between a cloud region and an availability zone?
What is the difference between a cloud region and an availability zone?
A region is a geographic area; an availability zone (AZ) is an isolated datacenter inside it with its own power, cooling and network. AZs fail independently but share low-latency links, so running across AZs is the baseline high-availability unit. Multi-region costs much more, mainly for disaster recovery.
Common mistakes
- ✗Thinking one region with many instances gives zone-failure protection
- ✗Believing multi-region is the cheap default rather than costly DR
- ✗Treating AZs as sharing one power and network, so failing together
Follow-up questions
- →How many AZs would you spread a service across for production high availability?
- →What extra costs appear when you add a second region for disaster recovery?
SeniorDesignVery commonDesign a highly available web tier in a single cloud region for a stateless HTTP service that must tolerate the loss of an entire availability zone with no downtime. Assume a managed relational database behind it and unpredictable, spiky traffic. Cover how you place compute across zones, how traffic reaches healthy instances, how the tier scales with load, and what happens to in-flight and new requests when one zone goes dark. Be explicit about health checks, the number of zones, the database's own failover, and why simply running more instances is not by itself high availability. State the single points of failure you removed and any you deliberately accepted.
Design a highly available web tier in a single cloud region for a stateless HTTP service that must tolerate the loss of an entire availability zone with no downtime. Assume a managed relational database behind it and unpredictable, spiky traffic. Cover how you place compute across zones, how traffic reaches healthy instances, how the tier scales with load, and what happens to in-flight and new requests when one zone goes dark. Be explicit about health checks, the number of zones, the database's own failover, and why simply running more instances is not by itself high availability. State the single points of failure you removed and any you deliberately accepted.
Spread stateless instances across two — ideally three — availability zones behind a load balancer that health-checks each target and routes only to healthy ones. Put the fleet in an autoscaling group spanning those zones so it grows with load and replaces failed nodes. Run the managed database multi-AZ with failover. Many instances in one zone is not HA.
Common mistakes
- ✗Treating instance count in one zone as high availability
- ✗Relying on round-robin DNS with no load balancer or health checks
- ✗Forgetting the database itself needs multi-AZ failover, not just the web tier
Follow-up questions
- →Why prefer three zones over two for the autoscaling group's capacity math?
- →How do connection draining and health checks handle in-flight requests during failover?
JuniorTheoryCommonWhat is a VPC, and how do public and private subnets differ?
What is a VPC, and how do public and private subnets differ?
A VPC is your own isolated virtual network in the cloud, split into subnets across availability zones. A public subnet routes to an internet gateway, so its instances face the internet; a private subnet has none, so instances stay unreachable from outside and egress via NAT. Security groups add a stateful, per-instance firewall.
Common mistakes
- ✗Swapping the definitions of public and private subnet
- ✗Thinking a VPC is shared across tenants rather than isolated per account
- ✗Calling security groups stateless, needing manual return rules
Follow-up questions
- →Why does a private subnet need a NAT gateway for outbound updates?
- →How do security groups differ from network ACLs at the subnet level?
MiddleDebuggingCommonAn autoscaling group stays its old size under heavy load and never adds instances — diagnose why
An autoscaling group stays its old size under heavy load and never adds instances — diagnose why
Two things block it. First, max equals desired at 4, so the group cannot add instances even if a policy fires — raise max. Second, the policy tracks CPU at 70%, but requests are I/O-bound and CPU sits at 34%, so it never trips; scale on a demand signal like request count or queue depth. Cooldown is not masking activity.
Open full question →Common mistakes
- ✗Missing that max equals desired, leaving no headroom to scale out
- ✗Scaling on CPU when the workload is I/O-bound, so the target never trips
- ✗Assuming desired can exceed max, or that CPU is the only usable metric
Follow-up questions
- →Which metric would you target for a queue-worker fleet instead of CPU?
- →How do cooldown or warm-up windows prevent scaling from oscillating?
MiddleDesignCommonYou inherit a cloud bill that has doubled in a year. The setup: a fixed fleet of large VMs sized for last year's peak and running 24/7 at about 15% average CPU, a database provisioned three tiers above its actual load, terabytes of old logs and backups sitting on the fastest storage class, and a monthly egress line nobody can explain. There is no autoscaling anywhere. Walk through a cost-optimization pass: how you find where the money goes, which levers you pull first, and how you cut spend without hurting reliability or getting paged. Be concrete about right-sizing, scaling, storage tiers and egress, and say what you would measure before and after.
You inherit a cloud bill that has doubled in a year. The setup: a fixed fleet of large VMs sized for last year's peak and running 24/7 at about 15% average CPU, a database provisioned three tiers above its actual load, terabytes of old logs and backups sitting on the fastest storage class, and a monthly egress line nobody can explain. There is no autoscaling anywhere. Walk through a cost-optimization pass: how you find where the money goes, which levers you pull first, and how you cut spend without hurting reliability or getting paged. Be concrete about right-sizing, scaling, storage tiers and egress, and say what you would measure before and after.
Start from the bill and usage metrics to find the big line items, not guesses. Right-size the over-provisioned VMs and database to real load, and put the fixed fleet behind autoscaling so idle capacity scales down off-peak. Move cold logs and backups to cheaper archive tiers via lifecycle rules, chase the unexplained egress, and reserve the steady baseline.
Common mistakes
- ✗Guessing at savings instead of starting from the bill and usage metrics
- ✗Sizing to peak and ignoring low average utilisation
- ✗Cutting blindly (deleting data, shrinking to minimum) and hurting reliability
Follow-up questions
- →How do reservations or savings plans trade flexibility for a discount?
- →Which storage lifecycle rule would you set for logs older than 30 days?
MiddleDesignCommonYour team runs a growing web product on cloud VMs and needs a primary relational database. One camp wants a fully managed database service; the other wants to self-host the same engine on your own instances inside your VPC to save money and avoid lock-in. Traffic is spiky, the team is small with no dedicated DBA, and you need point-in-time recovery, multi-AZ failover and an RPO of minutes. Walk through how you decide between the managed service and self-hosting: what each option puts on your plate operationally, where the real cost and risk sit, and what would push you toward one or the other. State your recommendation and the conditions under which the opposite choice would be right.
Your team runs a growing web product on cloud VMs and needs a primary relational database. One camp wants a fully managed database service; the other wants to self-host the same engine on your own instances inside your VPC to save money and avoid lock-in. Traffic is spiky, the team is small with no dedicated DBA, and you need point-in-time recovery, multi-AZ failover and an RPO of minutes. Walk through how you decide between the managed service and self-hosting: what each option puts on your plate operationally, where the real cost and risk sit, and what would push you toward one or the other. State your recommendation and the conditions under which the opposite choice would be right.
A managed service removes most operational toil — patching, backups, point-in-time recovery, multi-AZ failover and monitoring are built in — at a higher price and some lock-in. Self-hosting is cheaper per hour, but you now own HA, backups, upgrades and on-call, which a small team without a DBA rarely does well. Here, recommend managed.
Common mistakes
- ✗Comparing only the hourly price, ignoring the operational cost of self-hosting
- ✗Believing managed means the provider now owns your data and recovery goals
- ✗Assuming a small team can run HA and PITR by hand as well as a managed service
Follow-up questions
- →What concrete forms of lock-in does a managed database create, and how do you limit them?
- →At what team size or scale would self-hosting start to pay off?
JuniorTheoryOccasionalWhat is elasticity in the cloud, and how does it differ from scalability?
What is elasticity in the cloud, and how does it differ from scalability?
Scalability is handling more load by adding capacity; elasticity is doing it automatically both ways — scaling out as demand rises and back in as it falls, so you pay for use. Horizontal scaling adds instances behind a load balancer; vertical enlarges one. Autoscale on a signal that tracks real demand.
Common mistakes
- ✗Using elasticity and scalability as synonyms, missing the automatic both-way part
- ✗Assuming elastic means vertical only, ignoring horizontal scale-out
- ✗Autoscaling on an idle signal instead of one that tracks real demand
Follow-up questions
- →When would vertical scaling be the right choice over horizontal scale-out?
- →Why can autoscaling on CPU mislead you for an I/O-bound service?
MiddleTheoryOccasionalWhen do you go multi-region instead of just multi-AZ, and what does it cost you?
When do you go multi-region instead of just multi-AZ, and what does it cost you?
Multi-AZ is the everyday HA unit: instances across isolated zones in one region survive a single-datacenter failure with low-latency replication. You go multi-region only for disaster recovery from a whole-region outage, or lower latency. It costs far more — cross-region replication, egress fees, and harder consistency and failover.
Common mistakes
- ✗Treating multi-region as the cheap default rather than costly DR
- ✗Claiming multi-AZ cannot survive the loss of one zone
- ✗Forgetting cross-region replication, egress and consistency costs
Follow-up questions
- →What consistency problems appear once your database spans two regions?
- →How would you test a region-failover plan without a real outage?
SeniorDebuggingOccasionalA production service went fully down when one cloud availability zone failed — diagnose the design flaw
A production service went fully down when one cloud availability zone failed — diagnose the design flaw
Every tier lived in one zone, eu-1a, so when that zone failed the whole stack went down — six instances in one zone is redundancy against instance loss, not zone loss. Fix it by spreading the ASG, load balancer and a multi-AZ database with failover across two or three zones. Then losing a zone cuts capacity, not availability.
Open full question →Common mistakes
- ✗Blaming instance count when the flaw is single-zone placement
- ✗Claiming a region always fails as a whole, so only multi-region helps
- ✗Blaming the load balancer software instead of the single-AZ topology
Follow-up questions
- →What is the smallest change that would have kept the service up during this outage?
- →How would you prove the redesigned service survives a zone loss before it happens?
