Chapter 2

Design Resilient Architectures

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

Imagine your application as a building. Most architects spend their energy on making the building beautiful and functional — the floor plan, the finishes, the lobby. But a great architect also thinks about what happens when things go wrong: the fire exits, the sprinkler system, the backup generator. In cloud architecture, that second part is called resilience, and it is what this entire chapter is about.

Resilience is the ability of a workload to recover from infrastructure or service disruptions, keep serving customers during those disruptions, and adjust capacity as demand changes. The AWS Well-Architected Framework treats it as a first-class design concern, and the SAA-C03 exam devotes roughly a quarter of its questions to it — more than any other domain. The scenarios you will meet on exam day almost always present a workload that must survive failures: an Availability Zone outage, a database primary crashing, a traffic spike, a whole region going dark. Your job is to pick the combination of services and patterns that keeps the workload alive.

This chapter builds your resilience toolkit from the ground up. We start with the physical foundation — Availability Zones and regions — then add elastic compute and intelligent traffic routing, durable storage and database replication, formal disaster recovery strategies, and finally the decoupling patterns that stop one component's failure from cascading into a total outage. By the end, you will be able to read an exam scenario, identify its recovery-time and data-loss constraints, and select the right architecture with confidence.

2.1 Availability Zones, Regions, and the Meaning of "High Availability"

Every AWS region is a geographic area containing multiple Availability Zones, and every AZ is one or more physically separate data centers with its own power, cooling, and networking. AZs within a region are connected by high-bandwidth, low-latency links, but they are isolated from each other's failures: a power cut, flood, or fiber cut that takes down one AZ should not affect the others. Most regions have at least three AZs, which matters because many resilient designs need an odd number of failure domains to maintain a quorum or a majority.

When architects say "highly available," they mean the workload keeps running when individual components fail. The standard way to measure this is the availability percentage, and it is worth internalizing what each "nine" costs you in real downtime. Availability is measured over a year (8,760 hours), so the math is simple: multiply the allowed failure fraction by the minutes in a year (525,600). A workload at 99.9% ("three nines") can be down about 8 hours and 46 minutes per year. At 99.95% that drops to roughly 4 hours and 23 minutes. At 99.99% ("four nines") you get about 52 minutes and 36 seconds. Each additional nine divides your downtime budget by ten — and roughly multiplies the engineering effort and cost by a similar factor. That is why the exam loves to probe whether a design is appropriately resilient rather than maximally resilient: a marketing blog does not need four nines.

Multi-AZ: Surviving the Loss of a Data Center

The single most common resilience pattern in AWS is also the simplest: run everything in at least two Availability Zones. A Multi-AZ architecture places redundant copies of each tier across AZs so that the loss of any one AZ leaves a working copy behind. In practice this means web servers spread across two or more AZs behind a load balancer, a database with a synchronous standby in another AZ, and shared state (sessions, files) stored in services that are themselves multi-AZ by default, like S3 or DynamoDB.

Notice what multi-AZ protects against: the failure of one physical facility or its local infrastructure. It does not protect against a region-wide event — a major natural disaster, a region-level control-plane problem, or a misconfiguration you replicate everywhere yourself. It also does not protect against application bugs, because the same buggy code runs in every AZ. Those gaps are why multi-region exists.

Multi-Region: Surviving the Loss of a Region

A multi-region architecture runs the workload in two or more AWS regions. It is the answer when the threat model includes the loss of an entire region, when users are spread across continents and need low latency everywhere, or when regulations require data to live in specific jurisdictions. Because regions are fully independent — separate control planes, separate power grids, often thousands of kilometers apart — a multi-region design survives anything short of a global AWS event.

The price of that protection is complexity and cost. You now replicate data between regions, route users to the nearest healthy region, and handle the reality that cross-region replication is never instantaneous. A multi-region design must also decide whether regions are active-active (both serve traffic) or active-passive (one idles as a standby). Active-active gives better latency and utilization but forces you to solve hard problems like write conflicts and session affinity; active-passive is simpler but you pay for idle capacity. Section 2.7 will put numbers on these trade-offs with formal disaster recovery strategies.

2.2 Elastic Compute: Auto Scaling and Load Balancing

Resilience is not only about surviving failures — it is about surviving success. A workload that collapses under a traffic spike is just as unavailable as one whose data center burned down. AWS solves this with two cooperating services: Auto Scaling, which adjusts how many servers you have, and Elastic Load Balancing, which spreads incoming traffic across them.

Auto Scaling Groups: The Right Number of Servers, Automatically

An Auto Scaling group (ASG) maintains a fleet of EC2 instances between a minimum and maximum size you define. You give it a launch template — a versioned blueprint specifying the AMI, instance type, security groups, user data, and everything else an instance needs — and the group launches, replaces, and terminates instances to hold the fleet at the size your policies demand. Launch templates are versioned, so you can roll out a new AMI by creating a new template version and updating the group, with rollback as simple as pointing back at the old version.

The group keeps its fleet healthy through health checks. By default it uses EC2 status checks (is the VM itself alive?), but the exam-relevant move is to enable ELB health checks as well, so the group also replaces instances that fail the load balancer's application-level probes — an instance whose web server crashed but whose VM is fine. After launching an instance, the group waits out the health check grace period before judging it, so a slow-booting application is not killed before it finishes starting.

Scaling Policies: Dynamic, Scheduled, and Predictive

A scaling policy decides when the group grows or shrinks. There are three families, and the exam expects you to match each to its scenario.

Dynamic scaling reacts to real-time metrics. The simplest and most-used form is target tracking: you pick a metric and a target value — say, average CPU at 50% — and Auto Scaling continuously adds or removes instances to hold that target. It is the "set it and forget it" option. Step scaling responds to the size of the breach: add two instances if CPU is a little high, add five if it is far over the threshold. Simple scaling waits for a cooldown after each action and is mostly legacy — if you see it as an exam option alongside target tracking, target tracking is usually the better answer.

Scheduled scaling acts on the clock. If traffic reliably spikes every weekday at 9 AM, you schedule the group to grow at 8:45 and shrink at 6 PM. It is perfect for predictable patterns and costs nothing extra.

Predictive scaling uses machine learning on your historical CloudWatch data to forecast load up to 48 hours ahead and pre-provision capacity before the spike arrives. It shines for workloads with daily or weekly cycles where even a few minutes of under-provisioning hurts — but it needs a couple of weeks of history to learn from, and the exam often tests that prerequisite.

Load Balancers: ALB, NLB, and GWLB

An Elastic Load Balancer sits in front of your fleet and distributes traffic only to healthy targets. But there are three distinct types, operating at different network layers, and choosing correctly is one of the exam's favorite tests.

The Application Load Balancer (ALB) works at Layer 7 — it understands HTTP and HTTPS. That lets it make smart routing decisions: send /api/ to one target group and /images/ to another (path-based routing), route by hostname (host-based routing), or by HTTP headers and query strings. Its targets can be EC2 instances, IP addresses, containers, and even Lambda functions. Use the ALB whenever the traffic is web traffic and you need content-aware routing.

The Network Load Balancer (NLB) works at Layer 4 — TCP, UDP, and TLS. It does not inspect HTTP; it just forwards connections at extreme speed, handling millions of requests per second with ultra-low latency. Its superpowers are a static IP address (or Elastic IP) per AZ, which matters when clients or firewalls whitelist your IP, and preservation of the client source IP. Use the NLB for non-HTTP protocols (gaming, VoIP, MQTT), for extreme performance, or when you need fixed IPs.

The Gateway Load Balancer (GWLB) is the specialist: it routes traffic through fleets of third-party virtual appliances — firewalls, intrusion detection systems, deep packet inspection — using GENEVE encapsulation on port 6081. You will reach for it exactly when a scenario mentions inspecting traffic with security appliances at scale.

All three are themselves multi-AZ and highly available by design; you never build "a load balancer in each AZ" yourself.

2.3 DNS Routing with Route 53

DNS is the front door of almost every internet workload, and Route 53 is AWS's front door service. Beyond simply translating names to IP addresses, Route 53 can decide which door each visitor gets — routing users to the nearest region, splitting traffic between versions, or steering everyone away from a failed site. That decision-making is what makes it a resilience tool rather than just a phone book.

Health Checks: The Eyes of the System

Every intelligent routing decision depends on knowing what is healthy. A Route 53 health check periodically probes an endpoint — an HTTP/HTTPS URL, a TCP port, or the status of a CloudWatch alarm — and marks it healthy or unhealthy. You can even build calculated health checks that combine several child checks with AND/OR logic, so a region counts as healthy only if, say, both its web tier and its database tier pass.

Two details matter for the exam. First, Route 53 health checkers live outside your VPC, on the public internet, so they can only directly monitor endpoints reachable from the internet (for private resources, you publish a CloudWatch alarm and let the health check watch the alarm instead). Second, health checks have a configurable interval and failure threshold, which together determine how fast Route 53 notices an outage — typically well under a minute with aggressive settings.

Routing Policies: Six Ways to Aim Traffic

This is pure exam gold: six routing policies, each with a distinct purpose. Learn the one-line job of each, and most Route 53 questions answer themselves.

Simple routing sends every query to the same value. No health checks, no intelligence — fine for a single server or a non-critical record, and the only policy that cannot use health checks. If a question offers simple routing for a highly available design, it is a distractor.

Failover routing is active-passive: a primary record and a secondary record, each with a health check. All traffic goes to the primary while it is healthy; the moment it fails, Route 53 flips everything to the secondary. This is the textbook answer for "route users to the backup site when the main site fails."

Weighted routing splits traffic by proportions you assign — 90% to the new version, 10% to the old, for example. It is the tool for blue-green deployments, canary releases, and A/B testing. Weights can be combined with health checks so failed endpoints automatically drop out of the rotation.

Latency-based routing sends each user to the region that gives them the lowest latency, measured from their location. When the same application runs in multiple regions and you want every user on the fastest one, this is the policy. Note the subtlety: it optimizes latency, not geographic closeness — a user in Berlin might be routed to Ireland rather than Frankfurt if the measured latency is lower.

Geolocation routing routes by the user's geographic location according to rules you write: "users in France go to the Paris endpoint, everyone else goes to the default." It is about policy — data sovereignty, licensing restrictions, localized content — not performance. You must always provide a default record for locations you do not explicitly list.

Geoproximity routing (configured through Route 53 Traffic Flow) routes by geographic distance but lets you apply a bias to shift traffic: give the Ireland region a positive bias and it "pulls" users from farther away, useful for gradually migrating traffic or compensating for a region with more capacity. Think of it as geolocation with a volume knob.

Multivalue answer routing returns up to eight healthy records in response to each query and lets the client pick — a cheap, DNS-level form of load balancing without a load balancer. It is not a substitute for an ELB (no session stickiness, no path routing), but it is simple and works for any protocol.

2.4 Content Delivery and Edge Resilience with CloudFront

CloudFront is AWS's content delivery network: a global mesh of edge locations that cache your content close to users. For resilience, caching is a superpower in disguise — a cached response can be served even when the origin is down. CloudFront therefore does double duty: it makes the fast path faster and the failure path survivable.

Origin Failover: A Backup Origin on Standby

A CloudFront distribution normally pulls content from a single origin (an S3 bucket, an ALB, an EC2 instance). With origin failover, you configure an origin group containing a primary and a secondary origin. If the primary returns specific HTTP error codes (which you choose — typically 500-series errors), CloudFront automatically retries the request against the secondary origin. The classic pattern is a primary S3 bucket in one region with a replicated backup bucket in another, or a primary ALB with a static-maintenance S3 website as the secondary. Users may never notice the primary died.

Origin Access Control: Keeping S3 Private Behind CloudFront

When S3 is your origin, you do not want users bypassing CloudFront and hitting the bucket directly — that would dodge your caching, your HTTPS, and any signed-URL protection. Origin Access Control (OAC) solves this: CloudFront signs its requests to S3 with short-lived credentials, and the bucket policy grants access only to the CloudFront distribution. The modern exam answer is OAC; its predecessor, Origin Access Identity (OAI), still works but is legacy — if both appear as options, choose OAC.

2.5 Data Resilience in Storage

Compute can be replaced; data cannot. Every resilient architecture therefore treats storage durability — the probability that a stored object survives intact — as sacred. AWS storage services build durability in by replicating your data automatically, but you still choose how many copies, where they live, and how you recover from deletion or corruption.

Amazon S3: Eleven Nines of Durability

S3 stores each object redundantly across a minimum of three Availability Zones within the region, which is how it achieves its famous 99.999999999% (eleven nines) durability — the statistical expectation of losing one object in ten million every ten thousand years, roughly. Note the distinction the exam loves: durability (will my data survive?) is eleven nines, but availability (can I reach it right now?) for S3 Standard is 99.99%. Data can be perfectly safe yet temporarily unreachable during an AZ event — durability and availability are different promises.

Durability protects against hardware failure, but not against you: accidental deletion, an overwritten object, or ransomware encrypting your files. That is what versioning is for. With versioning enabled, every overwrite or delete creates a new version instead of destroying the old one — a "delete" just places a delete marker on top, and you can remove the marker to resurrect the object. Once enabled, versioning can be suspended but never fully disabled, and it is the prerequisite for replication.

Replication copies objects to another bucket automatically. Cross-Region Replication (CRR) sends copies to a different region — your defense against regional loss and your tool for data sovereignty and global low-latency access. Same-Region Replication (SRR) keeps copies in the same region, typically to aggregate logs from many buckets into one or to satisfy compliance rules requiring a second copy. Both require versioning on source and destination. For tight recovery objectives, Replication Time Control (RTC) adds a 15-minute replication SLA backed by CloudWatch metrics.

Object Lock is the last line of defense: it makes objects immutable for a retention period you set. In governance mode, privileged users can still override (protection against accidents); in compliance mode, nobody — not even the root account — can delete or alter the object until retention expires (protection against ransomware and malicious insiders). Object Lock requires versioning and is the exam's answer whenever a scenario demands WORM (write-once-read-many) storage or regulatory immutability.

EBS Snapshots: Point-in-Time Recovery for Block Storage

EBS volumes live in a single AZ — if that AZ is lost, the volume is gone with it. Snapshots are the escape hatch: point-in-time backups of a volume stored redundantly in S3. The first snapshot copies the full volume; every later snapshot is incremental, storing only changed blocks, which makes frequent snapshots cheap. From a snapshot you can create a new volume in any AZ, copy it to another region, or build a custom AMI.

Because snapshots are incremental, your recovery point is simply "the time of the last snapshot" — snapshot hourly and your worst data loss is an hour. The exam frequently pairs snapshots with automation: a Data Lifecycle Manager policy taking daily snapshots with cross-region copy is the standard answer for "back up these EC2 volumes with minimal effort."

AWS Backup: One Policy for Everything

When an architecture spans EBS volumes, RDS databases, DynamoDB tables, EFS file systems, and more, managing each service's native backup separately becomes error-prone. AWS Backup centralizes it: you define backup plans (how often, how long to retain, which vault) and assign resources by tags, and AWS Backup orchestrates the native snapshot mechanisms of each service. Backup vaults organize the recovery points, and cross-region copy bakes your DR strategy right into the plan. On the exam, "centrally manage and automate backups across multiple AWS services" is always AWS Backup — not a fleet of custom scripts.

2.6 Database Resilience

Databases are the hardest tier to make resilient because they hold state: you cannot simply launch a fresh copy like a web server. Every database service in AWS therefore offers its own replication story, and the exam tests whether you know which one fits the failure you are protecting against.

RDS: Multi-AZ Standby vs Read Replicas

Amazon RDS gives you two different replication tools that solve two different problems — confusing them is one of the most common exam mistakes.

A Multi-AZ deployment keeps a synchronous standby copy of your database in a different AZ. Every write is confirmed on both copies before it is acknowledged, so the standby is an exact, up-to-date mirror. If the primary fails, RDS automatically fails over to the standby — typically within a minute or two — and the database endpoint's DNS record flips to point at it, so your application reconnects without configuration changes. The standby serves no read traffic; it exists purely for failover. Choose Multi-AZ when the goal is availability: surviving a database crash or an AZ outage with minimal data loss.

Read replicas are a different animal: asynchronous copies that do serve read traffic. You create up to five per source (more with Aurora, below), offload reporting and analytics queries to them, and even place them in other regions for global reads. Because replication is asynchronous, a replica can lag seconds behind the primary — and because it is a separate endpoint, your application must explicitly send read queries to it. A read replica can be promoted to a standalone primary, which makes cross-region replicas a handy DR tool, but promotion involves some data loss and manual steps, so it is not automatic failover.

Aurora: Built for Resilience from the Storage Up

Amazon Aurora rethinks the database from the storage layer: instead of one primary with attached storage, Aurora's storage is a distributed system that keeps six copies of your data across three Availability Zones and continuously backs up to S3. A single AZ failure is invisible; even two copies can be lost without data loss. On top of that storage, Aurora runs one writer instance and up to 15 read replicas, with failover to a replica typically completing in under 30 seconds.

Three Aurora features deserve special attention. Aurora Global Database spans a primary region and up to five secondary regions with typical replication lag under one second: secondaries serve local reads worldwide, and in a disaster you promote a secondary to primary with a recovery point objective of about one second and recovery time under a minute — the closest thing to multi-region active-passive with a button press. Backtrack lets you rewind a database cluster to a point in the last 72 hours without restoring from backup — the answer to "an application bug corrupted data ten minutes ago" when you need the database back fast and cannot afford a restore window. Cloning creates a copy-on-write clone of a cluster in minutes regardless of size, because only changed pages consume new storage — perfect for testing risky migrations against production-scale data.

DynamoDB Global Tables and ElastiCache Global Datastore

DynamoDB Global Tables turn DynamoDB into a multi-region, active-active database: you write to any replica region and DynamoDB replicates the change everywhere else, typically within a second. Every region accepts reads and writes, so users worldwide get single-digit-millisecond latency. The trade-off is conflict resolution — if two regions update the same item simultaneously, last-writer-wins decides, so global tables fit workloads where concurrent cross-region writes to the same item are rare. On the exam, "multi-region NoSQL with active-active writes" is Global Tables, full stop.

For caching, ElastiCache Global Datastore (Redis only — Memcached has no equivalent) replicates a primary cluster to a secondary region with typical lag under a second. The secondary serves local reads, and promotion to primary takes about a minute, giving you a cross-region Redis DR story with a recovery point measured in seconds. If a scenario's session store or cache must survive a region failure, this is the feature to name.

2.7 Disaster Recovery: Strategies, RTO, and RPO

Everything so far has been about surviving the failure of components. Disaster recovery is about surviving the failure of everything at once — a region-wide outage, a catastrophic data corruption, a ransomware attack that encrypts your primary and your backups alike. Formal DR starts with two numbers that every exam scenario revolves around.

RTO (Recovery Time Objective) is how long you can afford to be down: the maximum acceptable time between the disaster and the workload serving users again. RPO (Recovery Point Objective) is how much data you can afford to lose: the maximum acceptable age of the data you recover — effectively, how far back your last good backup or replica may be. An RPO of one hour means backups or replication must run at least hourly; an RPO of zero means you need synchronous replication, because any async lag is data loss.

The Four DR Strategies

AWS describes DR as a spectrum of four strategies. Cost rises and RTO/RPO shrink as you move down the list; the exam wants you to place each scenario on this spectrum.

Backup and restore is the cheapest: in normal operation you keep nothing running in the DR region except your backups (S3 cross-region replication, snapshot copies, database backups). When disaster strikes, you rebuild the infrastructure — ideally from Infrastructure as Code templates — and restore the data. RTO is measured in hours, RPO in however often you back up. Choose it when the workload tolerates hours of downtime and the budget is tight.

Pilot light keeps a minimal core of the system always running in the DR region — the database replicated, the AMIs ready, the load balancer configured — but no active servers. On failure you "turn up the flame": scale out the compute around the already-warm core. RTO drops to tens of minutes because the hardest part (data and images) is already there. The classic exam example: an RDS cross-region read replica idling as the pilot light, promoted to primary during DR.

Warm standby runs a scaled-down but fully functional copy of the workload in the DR region at all times — same architecture, fewer/smaller instances, live data replication. Failover means scaling up and flipping DNS. RTO is minutes; cost is significant but far below full duplication. Use it for business-critical workloads that cannot wait for a rebuild.

Multi-site active-active (sometimes called active/active) runs full capacity in two or more regions, all serving traffic. There is no "failover" — if one region dies, the others simply absorb its load. RTO and RPO approach zero, and so does your tolerance for complexity: you must solve data consistency, request routing, and deployment synchronization across regions. Reserve it for the workloads where minutes of downtime cost more than a second full deployment.

2.8 Decoupling: Stopping Failures from Cascading

There is a subtle killer that redundancy alone cannot fix: coupling. When Service A calls Service B synchronously and B slows down, A's threads pile up waiting, and soon A is down too — the failure cascades. Decoupling breaks these chains by placing a buffer between components so each side can fail, scale, and deploy independently. AWS offers four decoupling tools, each with a distinct shape.

SQS: The Buffer Between Components

Amazon SQS is a fully managed message queue: producers drop messages in, consumers pull them out at their own pace. If the consumer crashes, messages simply wait — no data lost, no producer blocked. Two queue types serve different needs.

Standard queues offer nearly unlimited throughput with at-least-once delivery and best-effort ordering. "At-least-once" means a message might occasionally be delivered twice, so consumers must be idempotent — able to process the same message twice without harm (e.g., checking a transaction ID before charging a card). Use standard queues for maximum scale where duplicates are harmless.

FIFO queues guarantee exactly-once processing and strict ordering within a message group ID. Throughput is lower — 300 messages per second by default, up to 3,000 with batching — and duplicates are suppressed via deduplication IDs (or content-based deduplication) over a 5-minute window. Use FIFO when order matters: financial transactions, inventory updates, anything where processing event #2 before event #1 corrupts state.

Two mechanics appear constantly on the exam. The visibility timeout (default 30 seconds, up to 12 hours) hides a message from other consumers while one consumer processes it; if the consumer crashes without deleting the message, the timeout expires and the message becomes visible again — automatic retry with no code. Set it longer than your processing time or messages get processed twice. The dead-letter queue (DLQ) catches poison messages: after a configurable number of failed receives, the message moves to the DLQ instead of cycling forever, where you can inspect it, fix the bug, and replay it. "Messages are being processed repeatedly and never succeed" is the exam's cue for a DLQ.

SNS: Fan-Out to Many Subscribers

Where SQS is point-to-point, Amazon SNS is publish-subscribe: one message published to a topic is delivered to all subscribers — SQS queues, Lambda functions, HTTP endpoints, email addresses, SMS numbers. The flagship pattern is fan-out: publish once to SNS, and SNS pushes copies to several SQS queues, letting independent microservices each process the same event in parallel without knowing about each other. SNS also offers FIFO topics (pairing with FIFO queues for ordered fan-out) and message filtering, so subscribers receive only messages matching attributes they care about.

The exam's classic comparison: use SQS when one consumer (or a pool of identical workers) should process each message; use SNS when multiple different consumers each need the same message.

EventBridge: The Event Bus

Amazon EventBridge is the evolution of CloudWatch Events into a serverless event bus. AWS services, your own applications, and even SaaS providers (Zendesk, Shopify, PagerDuty) publish events to the bus; rules match events by pattern and route them to targets like Lambda, Step Functions, or SQS. Two features make it special: archive and replay, which lets you store events and re-send them later — invaluable for recovering from a downstream outage or testing a new consumer against real history — and scheduling (one-time and recurring) that replaces cron glue. On the exam, "route events from many sources to many targets based on content" is EventBridge; "react to an S3 upload / EC2 state change" is an EventBridge rule.

Step Functions: Orchestrating the Workflow

Queues and topics move messages; Step Functions coordinates workflows. You define a state machine — a sequence of steps with branches, retries, and error handling — and Step Functions executes it reliably, calling Lambda functions, starting ECS tasks, or waiting for human approval between steps. Standard workflows run up to a year with exactly-once execution for long, auditable processes like order fulfillment; Express workflows run up to five minutes with at-least-once execution for high-volume, short tasks like stream processing. The exam signal is unmistakable: whenever a scenario describes a multi-step process with error handling, retries, and "if this fails, do that instead" logic, the answer is Step Functions, not a Lambda function full of spaghetti retry code.

End-of-Chapter Test

1. A company runs a web application on EC2 instances in a single Availability Zone. The application must remain available if an entire AZ fails. Which change meets this requirement with the least operational effort? A) Add more EC2 instances in the same AZ behind an Application Load Balancer B) Deploy the application across an Auto Scaling group spanning at least two AZs behind an Application Load Balancer C) Take hourly EBS snapshots of the instances D) Enable S3 Cross-Region Replication for the application's assets

2. An application experiences predictable traffic spikes every weekday between 8 AM and 10 AM. The operations team wants capacity in place before the spike arrives without paying for idle servers overnight. Which Auto Scaling approach is MOST appropriate? A) Target tracking scaling on average CPU utilization B) Scheduled scaling to increase desired capacity before 8 AM and decrease it after 10 AM C) Predictive scaling based on machine-learning forecasts D) Simple scaling with a 300-second cooldown

3. A workload requires a fixed IP address for firewall whitelisting, handles millions of TCP connections per second with ultra-low latency, and does not use HTTP. Which load balancer should be used? A) Application Load Balancer B) Network Load Balancer C) Gateway Load Balancer D) Route 53 multivalue answer routing

4. A company runs its application in two regions. European users must be served from the EU region to satisfy data-residency regulations, while all other users should go to the US region. Which Route 53 routing policy meets this requirement? A) Latency-based routing B) Weighted routing C) Geolocation routing D) Failover routing

5. A CloudFront distribution serves a website from an S3 bucket origin. The company wants to ensure users cannot bypass CloudFront and access the S3 bucket directly. What should be implemented? A) Make the S3 bucket public and restrict access with a bucket policy B) Configure Origin Access Control (OAC) and a bucket policy allowing only the CloudFront distribution C) Enable S3 Cross-Region Replication to a second bucket D) Configure CloudFront origin failover with an origin group

6. A financial services company must retain transaction records for 7 years. Regulations require that no one — including administrators — can delete or modify the records during the retention period. Which S3 feature meets this requirement? A) S3 Versioning with MFA Delete B) S3 Object Lock in compliance mode C) S3 Cross-Region Replication with Replication Time Control D) S3 Lifecycle policies transitioning objects to Glacier Deep Archive

7. A database workload on Amazon RDS for MySQL is experiencing heavy read traffic that is overwhelming the primary instance. The application can tolerate a few seconds of replication lag on reads, and automatic failover for the primary is already handled by Multi-AZ. What should be added? A) Convert the Multi-AZ standby into a read replica B) Add RDS read replicas and direct read queries to the replica endpoints C) Enable RDS Performance Insights on the primary D) Deploy a second Multi-AZ standby in another region

8. An application was corrupted by a faulty deployment 20 minutes ago. The database is Amazon Aurora MySQL, and the team needs the data restored to its state just before the deployment as quickly as possible, without a lengthy restore operation. Which Aurora feature should be used? A) Aurora Global Database switchover B) Aurora Backtrack C) Aurora cloning D) Restoring from the most recent automated snapshot

9. A business requires a disaster recovery strategy for a critical application with an RTO of 15 minutes and an RPO of 1 minute. Cost is a secondary concern. Which strategy is MOST appropriate? A) Backup and restore B) Pilot light C) Warm standby D) Multi-site active-active

10. A payment processing system uses an SQS standard queue. Messages are occasionally processed twice, causing duplicate charges. Which change ensures each payment is processed exactly once and in order? A) Increase the visibility timeout to 12 hours B) Migrate to an SQS FIFO queue with message group IDs and deduplication IDs C) Add a dead-letter queue to the standard queue D) Enable long polling on the standard queue

11. A company wants a single order event to trigger three independent microservices — inventory, billing, and notifications — each processing the event at its own pace without knowing about the others. Which architecture is BEST? A) Send the event to one SQS standard queue consumed by all three services B) Publish the event to an SNS topic fanned out to three separate SQS queues, one per service C) Write the event to a DynamoDB table polled by each service D) Use Step Functions Express workflows to call each service sequentially

12. An e-commerce checkout involves five sequential steps: validate cart, charge payment, reserve inventory, schedule shipment, and send confirmation. If any step fails, the workflow must retry it and, after repeated failures, execute a compensation step. Which service is designed for this orchestration? A) Amazon EventBridge with archive and replay B) AWS Step Functions with Standard workflows C) Amazon SNS FIFO topics D) An SQS FIFO queue with a dead-letter queue

Answer Key

1. B — Spreading instances across multiple AZs behind a load balancer is the standard high-availability pattern; adding instances in one AZ (A) does not survive an AZ failure. 2. B — The pattern is fully predictable on a timetable, which is exactly what scheduled scaling is for; predictive scaling (C) needs ML history and target tracking (A) reacts after the spike begins. 3. B — The NLB operates at Layer 4, supports static/Elastic IPs, preserves source IP, and handles millions of TCP connections with ultra-low latency — all stated requirements. 4. C — Geolocation routing applies rules based on the user's geographic location (with a default record for everyone else); latency-based routing (A) optimizes for speed, not regulatory boundaries. 5. B — OAC lets CloudFront authenticate to S3 while the bucket policy denies all other access; OAI is the legacy predecessor and a public bucket (A) defeats the purpose. 6. B — Object Lock in compliance mode makes objects immutable for the retention period with no override possible, even by administrators; governance mode (unlike compliance) allows privileged overrides. 7. B — Read replicas offload read traffic and tolerate async lag; the Multi-AZ standby (A/D) serves no read traffic and exists only for failover. 8. B — Backtrack rewinds an Aurora cluster to a point within the last 72 hours without a restore; snapshot restore (D) is slower and cloning (C) copies rather than rewinds. 9. D — A 15-minute RTO with a 1-minute RPO and cost as a secondary concern points to active-active, where all regions serve traffic and failover is near-instantaneous. 10. B — FIFO queues provide exactly-once processing and ordering via message group IDs, with deduplication IDs suppressing duplicates; standard queues are at-least-once by design. 11. B — SNS fan-out delivers one published event to multiple independent SQS queues so each microservice processes it separately; a single shared queue (A) would let one service steal another's messages. 12. B — Step Functions Standard workflows orchestrate multi-step processes with retries, branching, and error/compensation handling; queues and topics move messages but do not orchestrate workflows.