Preparation

Tiered Practice Arena

Test your architectural intuition. Choose your difficulty, think of your answer, then expand to reveal the truth.

1. Storage Standoff

Scenario: A startup needs to store user profile photos (10KB–5MB each). 50K users now, 5M in 2 years. CTO: "Database or file system?"

Answer: S3. Never store binary files in a database — it's 10-50x more expensive per GB and bloats query performance. Store the image in S3, store the S3 URL in the database.

Key Rule: Binary files → S3. Metadata about those files → Database.
2. The Serverless Question

Scenario: E-commerce site sends a "Thank you" email per order. 500 orders/day. EC2 t3.micro sits idle 99% of the day costing $8/month.

Answer: Replace with Lambda. At 500 invocations/day Lambda costs effectively $0.00 (within free tier). Lambda triggered by SQS message or direct invocation.

Key Rule: Short, infrequent, event-driven functions → Lambda. Always-on stateful servers → EC2.
3. Database Dilemma

Scenario: Mobile gaming, 2M active players, queries are always "Get player X score" or "Update achievement." Must respond under 10ms.

Answer: DynamoDB. Single-digit millisecond at any scale. Access pattern is perfect key-value. RDS struggles with millions of concurrent mobile connections.

Key Rule: Simple key-value at massive scale → DynamoDB. Complex relational joins → RDS.
4. The Content Bottleneck

Scenario: News site, 10M page views/day, mostly static articles changed once/day. Origin in us-east-1 overloaded. Asian and European users get 4–8 second load times.

Answer: CloudFront CDN. 450+ edge locations cache the static content. Reduces Asia/EU latency to under 500ms. Reduces origin server load 80–90%.

Key Rule: Static/cacheable content + global users + high load → CloudFront.
5. The Queue Question

Scenario: Food delivery app: if notification service is down, the entire order fails (synchronous call). CTO wants to decouple.

Answer: SQS. Order placed in queue (never fails). Notification service polls and processes independently. Queue retains messages 14 days.

Key Rule: Decouple services, absorb failure → SQS.
1. The Auto-Scaling Crisis

Scenario: Retail flash sale: ASG adds 10 EC2 instances, still slow. DB CPU at 100%. Adding more EC2 makes it worse.

Answer: The bottleneck is the database, not compute. Fix: Add RDS Read Replica for read queries + ElastiCache Redis to cache hot product data (reduces DB load 70-90%) + RDS Proxy to handle connection pool explosion from ASG. Adding compute to a DB bottleneck is like adding checkout lanes when the stock room is empty.

Key Rule: DB bottleneck ≠ more compute.
2. The Compliance Encryption Audit

Scenario: Healthcare: 3 S3 buckets and 1 RDS unencrypted. CISO demands fix in 48hrs.

Answer: S3: Enable SSE-KMS (one API call, S3 Batch Operations re-encrypts existing objects). RDS: CANNOT encrypt in-place. Procedure: snapshot → restore with encryption → test → update connection string → delete old instance. Takes 2-4 hours.

Key Rule: S3 encryption = toggle. RDS encryption = snapshot, restore, cutover.
3. The Multi-Region Decision

Scenario: Mammoth Capital: if us-east-1 goes down, want auto-failover to eu-west-1 in under 60 seconds. 100K API calls/minute.

Answer: Active-Active Multi-Region. Same stack in both regions. Route 53 Latency-Based Routing splits traffic normally. Route 53 Health Checks trigger automatic DNS failover (~60s with low TTL). DynamoDB Global Tables replicates data across regions. S3 Cross-Region Replication for assets.

Key Rule: True multi-region failover = Route 53 health checks + DynamoDB Global Tables.
4. The Lambda Cold Start Problem

Scenario: Trading dashboard, Lambda price calculations. At 9:30 AM market open, first wave of users gets 3-5 second delays. SLA: under 200ms for all users.

Answer: Provisioned Concurrency — pre-warms Lambda execution environments. Schedule: enable at 9:00 AM, disable at 4:30 PM (market hours only, minimizes cost).

Key Rule: Lambda cold starts on latency-sensitive paths → Provisioned Concurrency. Schedule it for peak windows.
5. The Credential Leak

Scenario: Dev committed AWS access key to public GitHub at 2:15 PM. By 2:47 PM, 87 EC2 instances launched in ap-southeast-1. It is now 3:00 PM.

Answer: Step 1 is ALWAYS deactivate the compromised IAM key immediately (10 seconds in IAM console). Then: terminate 87 unauthorized instances, audit all regions for other resources, enable GuardDuty, set Budget alerts, rotate all other keys. Step 1 is kill the credential — stopping instances first is useless if the key is still active.

Key Rule: Compromised credential → kill key first, everything else second.
1. The Cost Optimization Audit

Scenario: AWS bill jumped $12K to $47K last month. 24 hours to find and fix.

Answer: Cost Explorer by service → top 3 drivers. Look for: NAT Gateway data transfer ($0.045/GB — often #1 surprise), EC2 in unused regions, unattached EBS volumes, S3 data transfer out. Check dev/test instances running 24/7 (stopping overnight saves 65%). Dev RDS on Multi-AZ (wasteful — use single AZ for non-prod). Enable AWS Budgets with daily alerts.

Key Rule: NAT Gateway is almost always the surprise cost. Always check it first.
2. The Architecture Review

Scenario: Series B fintech, monolith on one EC2 + one RDS PostgreSQL, 500K users, $3M ARR. CTO wants to "go serverless and use DynamoDB" because of a blog post.

Answer: This is a high-risk rewrite with no guaranteed benefit at this scale. The architecture is undersized, not broken. Fix: Add Read Replicas + ElastiCache + ALB + ASG first. THEN evaluate which components benefit from serverless. Migrating an entire PostgreSQL business to DynamoDB means rewriting all queries, losing ACID transactions on financial data, and likely introducing critical bugs. Evolutionary architecture beats big-bang rewrites.

Key Rule: Rewrite only when the current architecture is genuinely insufficient.
3. The Disaster that Actually Happened

Scenario: Multi-AZ RDS failed at 2 AM. Failover took 4 minutes (not the advertised 60-120s). 2,400 transactions lost because app didn't handle connection retries.

Answer: Root cause: no connection retry logic. Fix: Implement exponential backoff retry in DB connection layer. Use RDS Proxy — maintains connection pool, handles failover transparently, app sees no interruption. Implement idempotency keys for financial transactions. Test failover quarterly using "Reboot with failover" in RDS console. Multi-AZ prevents data loss — RDS Proxy prevents application disruption.

Key Rule: Multi-AZ = data safety. RDS Proxy + retry logic = application continuity during failover.
4. The Compliance vs. Performance War

Scenario: Healthcare ML: patient data must stay in eu-west-1 (GDPR). ML training runs in us-east-1. Transferring patient data to US violates GDPR.

Answer: Bring compute to data, not data to compute. Options: 1) Move ML training to eu-west-1 (P3/P4 GPU instances available). 2) Use SageMaker in eu-west-1. 3) Federated Learning (model trained on data that never leaves its region). 4) De-identify data using Macie before any cross-region transfer.

Key Rule: Data sovereignty → bring compute to data. Architecture serves compliance, not the ML team's convenience.
5. The Infinite Scaling Problem

Scenario: Social media app goes viral: 10K users at midnight, 800K by 6 AM. Single AZ EC2, single RDS, no CDN. Site is down. 6 AM emergency call.

Answer: Emergency (6 hours): 1) Vertically scale EC2 + RDS immediately. 2) Add CloudFront in front of origin (static asset caching cuts origin load 70%). 3) Add RDS Read Replica, route reads there. Recovery (24 hours): 4) ALB + AMI + Auto Scaling Group across 2 AZs. 5) ElastiCache Redis for sessions and hot data. 30-day: 6) Multi-AZ RDS, Aurora evaluation, load testing.

Key Rule: Emergency order: vertical scale → CloudFront → Read Replica. Horizontal HA comes after the fire is out.
Certification

Full Exam Gauntlet

Up to 65 questions, weighted toward the ones you've missed before. Passing bar matches each real exam's own cut score.