Chapter 5

Architecture Case Studies & Exam Strategy

AWS Certified Solutions Architect – Associate (SAA-C03) Study GuideBased on the official AWS SAA-C03 exam objectives

If you have read Chapters 1 through 4, you already know every individual service the SAA-C03 exam will test. You can recite the difference between GP3 and IO2, you know when to reach for Aurora over RDS, and you can explain S3 storage classes in your sleep. Here is the uncomfortable truth: knowing the services is only about half of what the exam demands. The other half is judgment — looking at a messy, contradictory business scenario and picking the one answer that balances security, resilience, performance, and cost the way AWS wants you to.

That is what this chapter is for. We are going to stop talking about services in isolation and start thinking the way a Solutions Architect thinks: in trade-offs. Every real architecture is a negotiation between competing priorities, and the exam is essentially a test of whether you can run that negotiation correctly, quickly, and under pressure. You will work through full case studies the way an architect would approach a real engagement — constraints first, then decisions, then justification. Along the way, you will learn how to read exam questions the way the test writers wrote them, spot the traps they set for you, and manage your time across the 130 minutes you are given.

By the end of this chapter, scenario questions should stop feeling like walls of text and start feeling like familiar puzzles with a recognizable shape.

Case Study 1: Migrating a Monolithic E-Commerce Site to AWS

The Scenario

Lakeside Home & Garden has been running its online store for eight years on a single LAMP stack: one large physical server at a regional colocation facility running Apache, PHP, and MySQL. The store sells seasonal garden products across North America, and for nine months of the year it hums along fine on that one server. But every spring, the "Spring Planting Sale" brings a flood of traffic that crashes the site — sometimes for hours — costing the company an estimated $180,000 in lost sales last year. The CEO has declared the monolith must go, and the migration has to be complete before the next sale in six months.

The requirements are clear but conflicting. The site must survive 10x traffic spikes without manual intervention. The CFO insists the new architecture cost no more than the current $2,400/month colocation bill during off-peak months. PCI DSS compliance is required for card payments, although the team is open to change. The three developers know PHP and MySQL but have zero AWS experience — anything needing a dedicated DevOps person is effectively impossible.

The Architecture Walkthrough

Step 1 — Containerize and run on a managed platform, not EC2 by hand. The team knows PHP, so the first instinct might be to lift the PHP app onto a few EC2 instances. That recreates the same operational burden on AWS. Instead, the application is containerized with Docker and deployed on Amazon ECS with Fargate. Fargate eliminates the need to manage servers entirely — no patching, no AMI management — which directly addresses the "zero AWS experience" constraint.

Step 2 — Replace self-managed MySQL with Amazon Aurora Serverless v2. The team's MySQL knowledge transfers directly to Aurora (MySQL-compatible), but Aurora adds automatic failover, storage that scales automatically, and — critically — Aurora Serverless v2, which scales compute up and down with traffic. During the nine quiet months, the database scales down to minimal capacity.

Step 3 — Get PCI scope off the servers with a managed payment tokenization service. Processing card data directly means the entire environment falls in PCI scope — a heavy burden for a three-person team. The architecture routes checkout through a PCI-compliant hosted payment page (such as Stripe Checkout) so card numbers never touch Lakeside's infrastructure. Combined with AWS WAF in front of the ALB, the compliance footprint shrinks dramatically.

Step 4 — Serve static content from CloudFront + S3. Product images, CSS, and JavaScript move to S3 behind CloudFront. This cuts origin load during the spring spike — often 60–70% of requests never reach the application tier — improves page loads across North America, and reduces ALB/ECS costs. AWS WAF attaches to the ALB for SQL injection and bot protection, and ACM provides a free TLS certificate.

Step 5 — Session handling without sticky servers. A classic monolith-migration trap is sticky sessions on the load balancer, which break autoscaling. Sessions move to ElastiCache for Redis, so any Fargate task can serve any customer and tasks can be added or removed freely.

Case Study 2: A Global Media Streaming Startup

The Scenario

Streamline is a two-year-old startup about to launch a subscription video service in 40 countries. Their catalog is 12,000 hours of licensed content plus daily uploads of new episodes. Beta testing in three countries revealed two problems: viewers in Southeast Asia and South America experienced constant buffering because the single-region origin could not keep up, and a piracy incident showed that signed URLs were being shared within minutes of release — premium episodes leaked to pirate sites before paying subscribers finished watching them.

The constraints are tight. Launch is in four months and the team is 14 engineers. Investors demand gross margins that only work if per-stream delivery cost stays low at global scale. Content licensing requires geographic restrictions — certain titles may only be served in specific countries. And the anti-piracy requirement is now existential: the next leak could kill licensing deals worth millions.

The Architecture Walkthrough

Step 1 — CloudFront as the global delivery backbone with regional origins. All video segments are delivered through a CloudFront distribution with S3 as the origin. CloudFront's 600+ edge locations solve the buffering problem by caching segments close to viewers in every launch market. Origin failover is configured across two S3 buckets in different regions so a regional S3 issue never takes the catalog offline.

Step 2 — Short-lived signed URLs with token authentication at the edge. The piracy problem gets a layered answer. CloudFront signed URLs expire in minutes, and Lambda@Edge validates a per-session token against the subscriber database on every manifest request. Shared links die almost immediately, and token binding to the subscriber's session means a leaked URL cannot be replayed from another device.

Step 3 — Geographic restriction at the distribution level. CloudFront's built-in geo-restriction enforces the licensing requirement by country, returning 403s for blocked regions before any content is served. This is configured per-distribution, so different catalogs can carry different restriction lists.

Step 4 — Ingest and transcode with event-driven serverless pipelines. Daily uploads land in an S3 ingest bucket, which triggers MediaConvert jobs via EventBridge. Transcoded renditions (1080p, 720p, 480p, audio-only) land in the origin bucket, and a Step Functions workflow tracks each asset's state from upload to published. No transcoding servers to manage, and the team pays only per minute of video processed.

Step 5 — Analytics and cost guardrails. CloudFront real-time logs flow to Kinesis Data Firehose and into S3, where Athena queries power a per-title, per-country cost and engagement dashboard. CloudWatch alarms on 4xx rates catch piracy attempts and misconfigurations early.

Case Study 3: A Financial Services Firm with Strict Compliance Needs

The Scenario

Meridian Trust is a regional bank with $4 billion in assets under management, moving its customer-facing online banking platform to AWS. The regulators are the audience that matters: the bank must demonstrate encryption of data at rest and in transit, complete audit trails of every access to customer data, network isolation of the banking workloads from the public internet, and the ability to prove — on demand — exactly who accessed what and when. A failed audit finding could mean fines and, worse, a consent order that freezes new product launches.

The constraints shape everything. Customer data must remain within the country. The bank's security team requires that no human — not even administrators — can access unencrypted customer data without the access being logged and approved. Backups must be immutable so ransomware cannot destroy them. And the migration cannot tolerate more than four hours of downtime for the core banking database, with recovery measured in minutes, because the bank processes time-critical wire transfers.

The Architecture Walkthrough

Step 1 — Network isolation with private subnets and no internet path for data. The banking application runs in private subnets across three Availability Zones. There is no internet gateway route for the data tier at all; outbound connectivity for patching flows through a NAT gateway in a dedicated egress VPC connected via Transit Gateway, with VPC endpoints (PrivateLink) used for AWS service access so traffic never traverses the public internet. The web tier sits behind an ALB in public subnets, with security groups implementing strict least-privilege ingress.

Step 2 — Encryption everywhere with customer-controlled keys. All EBS volumes, RDS storage, and S3 buckets use SSE with KMS keys the bank controls (customer managed keys), with automatic annual rotation enabled. TLS 1.2+ terminates at the ALB via ACM certificates, and traffic between tiers is also TLS-encrypted. The KMS key policy grants decrypt permission only to the application's IAM role — not to administrators — satisfying the "no human access to unencrypted data" requirement.

Step 3 — Immutable audit trails with CloudTrail, Config, and locked S3. CloudTrail is enabled in all regions with log file validation, writing to an S3 bucket with Object Lock in Compliance mode — logs cannot be deleted or altered by anyone, including the root account. AWS Config records every configuration change and its rules automatically flag non-compliant resources. GuardDuty adds threat detection on top.

Step 4 — Multi-AZ RDS with automated backups and cross-region disaster recovery. The core banking database runs on RDS Multi-AZ (now with two readable standbys), with automated backups retained per policy and copied cross-region with KMS encryption. The four-hour RTO and minutes-level RPO are met by the Multi-AZ failover (typically 60–120 seconds) plus the ability to promote a cross-region read replica if an entire region fails.

Step 5 — Data residency guardrails. SCPs at the AWS Organizations level deny resource creation outside the home region, and guardrails prevent S3 replication or RDS snapshots from leaving the country. This turns the residency requirement from a policy document into an enforced technical control — exactly what auditors want to see.

Case Study 4: A Cost-Crisis Turnaround for an Over-Spending Startup

The Scenario

Pulseboard is a SaaS analytics startup burning $48,000 a month on AWS — nearly triple their budget — with twelve months of runway left at current spend. An emergency cost review found the damage: a fleet of 60 EC2 On-Demand instances running 24/7 at 12% average CPU, three NAT gateways per AZ "for redundancy," 40 TB of S3 data with no lifecycle policies (including seven years of application logs nobody reads), unattached EBS volumes and old snapshots from two years of experiments, and data transfer bills showing massive cross-AZ traffic between chatty microservices.

The constraints are brutal. The CEO has ordered a 50% cost cut within 60 days without degrading the customer-facing SLA (99.9% uptime). The team cannot rewrite the application — whatever is done must be infrastructure-level. And the fix has to be sustainable: the board wants guardrails so spending can never silently triple again.

The Architecture Walkthrough

Step 1 — Right-size compute and commit where usage is stable. The 60 On-Demand instances at 12% CPU are the single biggest line item. Compute Optimizer identifies that the workload fits on far fewer, smaller instances. The steady-state baseline — the portion of capacity that runs 24/7 — moves to Compute Savings Plans (one-year, no upfront), cutting roughly 40% off that portion immediately. The remainder moves to an Auto Scaling group so capacity tracks actual demand instead of idling.

Step 2 — Kill the NAT gateway sprawl and fix cross-AZ chatter. Three NAT gateways per AZ is pure waste — one NAT gateway per AZ is the resilient pattern, and much of the traffic does not need NAT at all: S3 and DynamoDB access moves to gateway VPC endpoints (free), and other AWS service calls move to interface endpoints where the math works. The microservices' cross-AZ traffic is reduced by enabling AZ-aware routing so services prefer endpoints in their own AZ.

Step 3 — Lifecycle policies and storage-class hygiene on the 40 TB. S3 Intelligent-Tiering is enabled on the main buckets so AWS automatically moves objects between frequent and infrequent access tiers. Application logs older than 90 days transition to Glacier Instant Retrieval, and anything older than a year goes to Glacier Deep Archive. A one-time S3 Batch Operations job cleans up the ancient logs nobody reads (after legal confirms retention requirements).

Step 4 — Delete the orphans. Unattached EBS volumes, obsolete snapshots, and unused Elastic IPs are deleted (snapshots first archived to the cheapest tier where retention policy requires).

Step 5 — Guardrails so it never happens again. AWS Budgets with an 80%-of-budget alert and a forecasted-overspend alert go to the whole leadership team. Anomaly Detection flags unusual spend spikes. Tagging enforcement via AWS Config rules means every new resource carries an owner and cost-center tag, and SCPs prevent the most expensive mistakes (like launching large instances in unused regions).

Case Study 5: IoT Data Ingestion at Scale

The Scenario

AgriSense deploys soil sensors across 200,000 farm plots. Each sensor reports temperature, moisture, and pH every 30 seconds — roughly 20,000 messages per second at peak, each under 1 KB. The data must be durably captured (losing a day of readings voids customer SLAs), available for real-time alerting when moisture drops below thresholds, and queryable for seasonal trend analysis going back three years. The ingestion tier must absorb 5x bursts when firmware updates cause sensors to reconnect simultaneously, without data loss and without the team provisioning for peak 24/7.

The Architecture Walkthrough

Step 1 — Decouple ingestion with Kinesis Data Streams. Sensors publish via MQTT to AWS IoT Core, which routes messages into a Kinesis Data Stream. The stream's shards absorb the 5x reconnect bursts, and multiple consumers (real-time alerting, archival, analytics) read independently without impacting each other.

Step 2 — Real-time alerting with Kinesis Data Analytics (Flink). A managed Flink application runs the moisture-threshold logic over the stream in real time, pushing alerts to SNS topics that notify farmers by SMS. No servers, no stream-processing framework to operate.

Step 3 — Durable archival with Firehose to S3. Kinesis Data Firehose delivers every record to S3 with batching and compression, partitioned by date. S3's eleven nines of durability satisfy the no-data-loss SLA, and lifecycle policies age raw data to Glacier after a year while aggregated datasets stay queryable.

Step 4 — Query with Athena and visualize with QuickSight. Seasonal trend analysis runs as Athena SQL directly against the S3 data lake — no warehouse to provision for queries that run a few times a week. QuickSight dashboards give agronomists self-service visualization.

How to Read SAA-C03 Questions

Real exam questions are long — often 150 to 250 words — and most of those words are camouflage. The test writers bury two or three decisive keywords in a paragraph of background, and your job is to find them before you read the answers. Train yourself to read every question twice: first for the keywords, then for the full picture.

The Keyword Hierarchy

Constraint keywords decide the answer. These are the words that eliminate otherwise-correct options:

• "MOST cost-effective" / "lowest cost" — Immediately downgrade any answer with provisioned, always-on, or multi-region-active resources. Look for serverless, lifecycle policies, Intelligent-Tiering, Savings Plans, or Spot (only where interruption-tolerant). If two answers both work technically, the cheaper one wins — but only if it still meets every other constraint.
• "LEAST operational overhead" / "managed" / "no operational overhead" — This phrase is a giant arrow pointing at managed services. EC2-based answers are almost always wrong when this appears. Choose RDS over EC2-hosted databases, Fargate over EC2, Aurora Serverless over provisioned, and managed services over self-built equivalents.
• "Highly available" / "fault tolerant" — Count the Availability Zones. The correct answer spans at least two AZs (Multi-AZ, ALB across AZs, S3's inherent multi-AZ durability). Single-AZ answers are traps.
• "Minimal downtime" / "migrate with least disruption" — Look for AWS DMS, CloudEndure-style replication, or blue/green patterns. Answers requiring application rewrites or extended outages are wrong.
• "Secure" with specifics — "Encrypt at rest" → KMS/SSE. "Private connectivity" → PrivateLink/VPC endpoints. "Audit" → CloudTrail. "Rotate credentials" → Secrets Manager. Match the specific security verb to its service.
• "Global" / "lowest latency worldwide" — CloudFront for content, Route 53 latency/geolocation routing or Global Accelerator for applications, DynamoDB Global Tables or Aurora Global Database for data.

The Two-Pass Method

Pass 1 — Extract. Before looking at the options, note: What is the workload? What are the hard constraints? Which keywords appeared? Predict the answer's shape — "something serverless and multi-AZ."

Pass 2 — Eliminate. Read the options against your extracted constraints. Kill options that violate any hard constraint first — wrong AZ count, violates the budget, requires expertise the scenario says the team lacks. You will usually be left with two plausible answers; the tiebreaker is almost always the strongest keyword in the stem ("MOST cost-effective" picks the cheaper of the two; "LEAST operational overhead" picks the more managed one).

Decoding Distractor Patterns

Wrong answers on the SAA-C03 fall into recognizable families:

1. The technically-works-but-violates-a-constraint answer. EC2-hosted MySQL for a team with no DBAs. Multi-region active-active for a cost-sensitive workload. Always check constraints.
2. The wrong-scale answer. SQS for 20,000 messages/second with five consumers (that's Kinesis). DynamoDB for complex analytical queries (that's Athena/Redshift). Match the service to the scale and access pattern.
3. The outdated-service answer. Classic Load Balancer instead of ALB/NLB. S3 with website hosting instead of CloudFront. The exam tests current best practice.
4. The single-AZ answer. Anything deployed to one AZ when the scenario says "highly available" — instant elimination.

The 10 Most Common Exam Traps

Trap 1 — S3 "consistency" confusion. S3 now provides strong read-after-write consistency for all operations. Any answer claiming you need to "handle eventual consistency" in S3 is outdated and wrong.

Trap 2 — EBS vs. instance store. EBS persists independently of the instance; instance store is ephemeral and dies with the host. "Data must survive instance termination" → EBS (or S3). "Highest IOPS for temporary scratch data" → instance store is fine.

Trap 3 — Security groups vs. NACLs. Security groups are stateful (return traffic allowed automatically) and attach to instances; NACLs are stateless (explicit allow both directions) and attach to subnets. "Block a specific IP" works in both, but the exam loves testing that NACL rules need explicit inbound AND outbound entries.

Trap 4 — NAT gateway vs. VPC endpoints. Traffic to S3/DynamoDB should use gateway endpoints (free); a NAT gateway in that path is wasted money. The exam presents architectures with NAT gateways handling S3 traffic and asks for the cost fix — the answer is endpoints.

Trap 5 — RDS read replicas vs. Multi-AZ standby. Read replicas scale reads and can promote for disaster recovery; the Multi-AZ standby provides automatic failover for high availability but serves no reads. "Offload read traffic" → read replica. "Automatic failover" → Multi-AZ. Mixing these up is one of the most-tested confusions on the exam.

Trap 6 — CloudFront signed URLs vs. signed cookies vs. OAC. Signed URLs/cookies control who can access content (per-user authorization). Origin Access Control controls how CloudFront accesses S3 (blocking direct bucket access). A scenario about piracy needs signed URLs; a scenario about "users bypassing CloudFront to hit S3 directly" needs OAC. They solve different problems and the exam mixes them deliberately.

Trap 7 — Spot Instances for the wrong workload. Spot is for interruption-tolerant work: batch processing, CI fleets, stateless web tiers behind a load balancer. It is never the answer for databases, steady-state production workloads with strict SLAs, or anything that cannot checkpoint and resume.

Trap 8 — "MOST cost-effective" with a hidden availability requirement. The cheapest option that drops an AZ or removes backups fails if the scenario also says "highly available" or mentions RTO/RPO. Cost-effectiveness is always subject to the other constraints — the exam punishes answers that optimize cost alone.

Trap 9 — Decoupling direction: SQS vs. SNS vs. EventBridge. SQS decouples one producer from one consumer (polling). SNS fans out one message to many subscribers (push). EventBridge routes events by pattern to many targets with filtering. "Notify five teams when an upload completes" → SNS. "Buffer orders for a single processing fleet" → SQS. "Route EC2 state changes to different Lambda functions by event type" → EventBridge.

Trap 10 — Backup vs. replication vs. versioning. S3 Versioning protects against accidental overwrite/deletion of objects. Cross-Region Replication protects against regional failure. AWS Backup (or RDS snapshots) provides point-in-time recovery. "Protect against accidental deletion" → versioning (+ MFA Delete for the paranoid). "Survive a region outage" → replication. The exam swaps these constantly.

Time Management for the 130-Minute Exam

You get 65 questions in 130 minutes — exactly two minutes per question on average. That sounds generous until you hit your third consecutive 200-word scenario. Here is the pacing plan that works:

Minutes 0–90: The first pass (about 80 seconds per question). Answer everything you can decide quickly. For scenario questions, run the two-pass method: extract keywords, eliminate, pick. If you cannot eliminate down to one answer within about 90 seconds, flag it and move on. Do not burn five minutes on one question — every minute you overspend is stolen from a question you could have answered.

Minutes 90–115: The flagged questions. Return with fresh eyes — the keyword you missed often jumps out on a second read. Re-read only the stem's final two sentences and the constraints.

Minutes 115–130: Review and sanity check. Verify you answered every question (unanswered questions are guaranteed wrong; a guess has a 25% chance). Check for misread keywords — the classic error is answering the "MOST cost-effective" question with the "LEAST operational overhead" answer because you skimmed.

Guessing strategy. Never leave a question blank. When guessing between two: prefer the managed service, prefer the multi-AZ design, and prefer the answer containing the scenario's strongest keyword. Eliminate options with absolute language like "always" or "never" — AWS architectures rarely deal in absolutes, and neither do correct exam answers.

Energy management. If your eyes glaze over at question 40, take the optional break and reset. A fatigued brain misreads keywords, and misread keywords are how prepared candidates fail.

Final Week Checklist

Seven days out: Take one full timed practice exam. Score it by domain — the exam requires competence across all four, and a domain weakness is more dangerous than a low total. List every question you got wrong and every question you got right by guessing.

Five days out: Re-study your weakest domain using the case-study lens from this chapter. For each service in that domain, write one sentence: what problem does it solve, and what keyword in a question points to it? If you cannot write that sentence, you do not know the service well enough yet.

Three days out: Drill the trap list until you can explain each trap to someone else. Then do 30 scenario questions untimed, forcing yourself to name the decisive keyword before looking at the options. Speed comes from keyword recognition, not from reading faster.

One day out: Light review only — keyword flashcards, the trap list, and the service-to-keyword mappings. No new material; cramming now creates confusion, not knowledge. Prepare your ID, confirm your testing setup, and test your environment if taking the exam remotely.

Exam morning: Eat, hydrate, arrive early. Remember the two-pass method and the pacing plan. You have done the work across five chapters — today is about executing the method, not discovering new knowledge.

You are ready. The Solutions Architect – Associate is a judgment test, and judgment is exactly what you have been training in this chapter. Read the constraints, find the keywords, eliminate ruthlessly, and trust the architectural instincts you have built. Good luck — go design something excellent.

End-of-Chapter Test

1. A regional retailer runs its storefront on two EC2 instances behind an ALB in a single Availability Zone. Traffic triples every holiday season, and last December the site went down for six hours when the AZ had a power event. The company wants a redesign that is highly available and handles seasonal spikes with the LEAST operational overhead. Which architecture should the architect recommend? A) Add two more EC2 instances in the same AZ and configure ALB health checks B) Move the application to ECS with Fargate across three AZs with Application Auto Scaling, and migrate the database to Aurora Serverless v2 C) Purchase Reserved Instances for four EC2 instances split across two AZs D) Migrate the application to a single large EC2 instance with daily AMI backups

2. A video-on-demand startup serves 4K content to viewers on five continents. Viewers far from the single origin region report constant buffering, and the company needs per-user access control so shared links expire quickly. Which combination BEST meets these requirements? A) Deploy EC2 origin servers in each continent and use Route 53 latency routing with long-lived pre-signed S3 URLs B) Serve content through CloudFront with an S3 origin, enable origin failover, and use short-lived CloudFront signed URLs validated at the edge C) Store videos in EFS and mount the file system on EC2 instances in every region D) Use S3 Transfer Acceleration directly to viewers with IAM user credentials embedded in the video player

3. A healthcare company must retain patient-record access logs for seven years and prove to auditors that no one — including administrators — can alter or delete them. Which logging design meets this requirement? A) CloudTrail writing to an S3 bucket with Object Lock in Compliance mode and log file validation enabled B) CloudTrail writing to CloudWatch Logs with a 7-year retention setting C) Application-level logging to an RDS database with daily snapshots D) CloudTrail writing to an S3 bucket with Object Lock in Governance mode

4. A startup's AWS bill tripled in six months. Investigation shows 50 EC2 On-Demand instances averaging 10% CPU, NAT gateways processing 30 TB/month of traffic bound for S3, and 25 TB of application logs in S3 Standard dating back five years. The workload must remain highly available. Which set of actions provides the GREATEST cost reduction without reducing availability? A) Switch all instances to Spot, remove two NAT gateways, and delete the old logs B) Right-size with Compute Optimizer, buy Compute Savings Plans for baseline capacity, replace S3-bound NAT traffic with gateway VPC endpoints, and add S3 lifecycle policies transitioning old logs to Glacier Deep Archive C) Move everything to a single AZ to eliminate cross-AZ data transfer charges D) Purchase three-year All Upfront Reserved Instances for all 50 instances at their current size

5. A bank requires that its customer database fail over automatically within minutes of a primary failure, with no data loss, and that backups exist in a second region for regulatory purposes. The database engine must remain PostgreSQL-compatible and the team wants minimal operational overhead. Which solution fits? A) PostgreSQL on EC2 with streaming replication to a second region, managed by the DBA team B) RDS for PostgreSQL with Multi-AZ deployment and automated cross-region backup copy C) DynamoDB global tables with point-in-time recovery D) Aurora Serverless v1 with backtrack enabled

6. A manufacturing company deploys 500,000 sensors that each send a 500-byte reading every minute. Three independent systems need the data: a real-time dashboard, an anomaly-detection ML pipeline, and a long-term archive. Bursts of 4x normal volume occur during shift changes. Which ingestion design is MOST appropriate? A) Sensors write directly to an RDS database; each consumer polls the database B) IoT Core routes messages to Kinesis Data Streams; Firehose archives to S3 while independent consumers read the stream for the dashboard and ML pipeline C) Sensors send to a single SQS queue consumed by one Lambda function that fans out to all systems D) Sensors upload CSV batches to S3 every hour for Athena queries

7. An exam-style scenario describes a company that wants to "reduce the operational overhead of managing database credentials rotation" for its RDS fleet. Which service should the architect recommend? A) Store credentials in an encrypted S3 bucket and rotate them with a monthly Lambda cron B) AWS Secrets Manager with automatic rotation integrated with RDS C) IAM database authentication for all application connections D) Systems Manager Parameter Store with manually rotated SecureString parameters

8. A media company needs to block users from bypassing CloudFront and downloading video files directly from the S3 origin bucket, while still allowing CloudFront to serve the content. Which configuration achieves this? A) Enable S3 Block Public Access and create short-lived pre-signed URLs for each viewer B) Configure CloudFront Origin Access Control (OAC) and restrict the bucket policy to allow access only from the CloudFront distribution C) Move the videos to EBS volumes attached to the origin servers D) Enable S3 Versioning and MFA Delete on the origin bucket

9. A SaaS company processes customer orders through a fleet of EC2 workers that poll an SQS queue. During flash sales the queue grows faster than workers can drain it, and occasionally a worker crashes mid-processing, losing the order. Which TWO changes together solve both problems with LEAST operational overhead? (Select TWO) A) Enable Auto Scaling on the worker fleet based on the queue's ApproximateNumberOfMessagesVisible metric B) Replace SQS with SNS fan-out to the workers C) Configure a dead-letter queue and ensure workers only delete messages after successful processing (visibility timeout tuned to processing time) D) Move the workers to Spot Instances to reduce cost during flash sales

10. A financial firm's auditors require proof of every configuration change made to production resources over the past year, plus automatic alerts when a resource becomes non-compliant (e.g., an unencrypted EBS volume appears). Which combination meets both needs? A) AWS Config with configuration history and managed rules, plus CloudTrail for the API-level audit trail B) CloudWatch Logs Insights queries run manually each quarter C) AWS Trusted Advisor checks reviewed monthly by the security team D) GuardDuty findings exported to S3 weekly

11. A global e-commerce company wants product images to load quickly for users worldwide, needs to keep delivery costs low at high traffic volumes, and must restrict certain product images to viewers in specific countries due to licensing. Which design meets all three requirements? A) Serve images from ALB-backed EC2 instances in each region with security groups filtering by source IP country ranges B) CloudFront distribution with an S3 origin, price class optimized for the served regions, and CloudFront geo-restriction configured per licensing requirements C) S3 static website hosting with bucket policies denying requests based on the aws:SourceIp condition D) Replicate images to EFS in every region and serve them through regional NLBs

12. A startup runs a stateless web API on EC2 On-Demand instances behind an ALB. Usage is highly variable — near zero overnight, 20x spikes during marketing campaigns — and the team of two developers wants to minimize both cost and operational effort. Which is the MOST cost-effective and lowest-overhead option? A) Keep the EC2 fleet and purchase Reserved Instances for the peak capacity B) Migrate the API to Lambda behind API Gateway with provisioned concurrency only for the baseline, letting it scale to zero overnight C) Move the API to a single large EC2 instance that is stopped and started on a schedule D) Deploy the API on EC2 Spot Instances in a single AZ

Answer Key

1. B — Fargate across three AZs gives multi-AZ high availability and automatic scaling for seasonal spikes with zero server management; Aurora Serverless v2 scales the database with demand. A and D are single-AZ; C keeps operational overhead and wastes money off-peak. 2. B — CloudFront edge caching solves global buffering, origin failover adds resilience, and short-lived signed URLs address link sharing. A rebuilds origins per continent (huge overhead); C misuses EFS; D exposes IAM credentials and has no caching. 3. A — Compliance-mode Object Lock makes logs immutable even for administrators, and log file validation proves integrity to auditors. Governance mode (D) allows privileged deletion; CloudWatch Logs (B) and RDS (C) don't provide tamper-proof immutability. 4. B — Each fix targets a specific waste without touching availability: right-sizing + Savings Plans (idle compute), gateway endpoints (NAT charges for S3 traffic are eliminated, not just reduced), lifecycle policies (aging logs). A uses Spot for a steady workload and deletes logs that may need retention; C destroys availability; D commits to oversized instances. 5. B — Multi-AZ RDS provides automatic failover within minutes with synchronous replication (no data loss), and cross-region backup copy satisfies the regulatory requirement — all managed. A adds operational burden; C changes the engine; D's Serverless v1 lacks the required failover semantics. 6. B — Kinesis Data Streams buffers the 4x bursts and supports multiple independent consumers natively; Firehose handles durable archival to S3. Direct DB writes (A) collapse under bursts; a single SQS queue (C) can't serve three independent consumers well; hourly batches (D) kill real-time needs. 7. B — Secrets Manager provides automatic rotation with native RDS integration — the least-overhead answer. A and D are manual/DIY; C (IAM auth) is valid for some engines but the scenario asks specifically about rotation of stored credentials. 8. B — OAC lets CloudFront access the bucket while the bucket policy denies everyone else, exactly blocking direct S3 access. A confuses viewer authorization (signed URLs) with origin protection; C and D don't address direct bucket access at all. 9. A, C — Queue-depth-based Auto Scaling drains flash-sale backlogs automatically, and proper visibility-timeout handling plus a DLQ prevents message loss on worker crashes. SNS (B) is push fan-out, wrong for worker polling; Spot (D) risks interruptions during the most critical traffic. 10. A — Config records resource configuration history and its rules detect non-compliance automatically; CloudTrail provides the who-did-what API audit trail. B is manual, C is advisory-only, and D covers threats, not configuration compliance. 11. B — CloudFront covers global speed and low per-GB delivery cost, price class trims cost further, and geo-restriction enforces licensing by country. A tries to geo-filter with security groups (wrong tool, huge overhead); C can't reliably geo-filter by IP in bucket policy alone at global scale; D is enormously expensive and complex. 12. B — Lambda scales to zero overnight (no idle cost) and absorbs 20x spikes automatically with no servers to manage — matching both the variable pattern and the two-person team constraint. A over-provisions for peak; C can't react to unpredictable spikes; D risks interruptions and keeps server management.