Cloud Architecture and Solution Design
What to know
Design questions test trade-offs, not product trivia. Core concepts: high availability through multi-zone (multi-AZ) deployment and load balancing; elasticity via Auto Scaling and serverless; decoupling with message queues (MQ) and asynchronous processing; caching with Redis or CDN to cut latency; and security layering with VPC isolation, security groups, RAM least privilege, and WAF/Anti-DDoS at the edge. Know the shared-responsibility idea: the provider secures the platform, the customer secures data, identities, and configuration.
Traps to watch
Many options are technically valid but one is best for the stated constraint. Watch for: single-zone designs offered as "highly available" (they are not); putting a database directly on the public internet; using a single large ECS instance when the requirement says "handle traffic spikes" (Auto Scaling fits better); and ignoring statefulness when recommending stateless horizontal scaling. Also beware of over-engineering: a small internal tool rarely needs multi-region active-active. Read the constraint words-cost, latency, compliance, RPO/RTO-because they decide the answer.
Rule of thumb
Design in layers and eliminate single points of failure: DNS/CDN → SLB across zones → stateless app tier behind Auto Scaling → managed database with replicas/backups. If a requirement mentions recovery objectives, map RPO to backup/replication frequency and RTO to failover speed.
Worked example
"An app must survive a zone outage and scale during promotions." Answer: deploy ECS in at least two zones under an SLB, enable Auto Scaling with health checks, use a multi-zone managed database with read replicas, and cache hot data in Redis.