SAA-C03: Design Resilient Architectures
Design Resilient Architectures is one of the skill areas tested on the Solutions Architect – Associate (SAA-C03) exam. Below are free SAA-C03 practice questions with worked answers and a concept diagram — each with a plain-language explanation. Practice the first 10 questions of SAA-C03 free, no signup.
The concept, in one picture
3 free SAA-C03 Design Resilient Architectures questions
A veterinary practice management platform ran on one Amazon EC2 instance that saved scanned X-ray files to an attached Amazon EBS volume. To improve availability the team launched a second instance with its own EBS volume in a different Availability Zone and put both behind an Application Load Balancer. Clinics now report that reloading the page shows one half of their scans or the other, never the full set. What should the solutions architect propose?
- Enable sticky sessions on the Application Load Balancer so each clinic is always routed to the instance that holds its scans.
- ✓ Migrate the files from both EBS volumes into an Amazon EFS file system, mount it on both instances, and have the application write new scans there.
- Run a scheduled synchronization job between the two EBS volumes so each one ends up with a full copy of every scan.
- Configure the Application Load Balancer to forward each request to both instances and return whichever response contains the requested scan.
Amazon EFS is a file system that both instances can mount concurrently across Availability Zones, so every request sees one complete set of scans regardless of which target the load balancer chooses. Synchronizing the two EBS volumes only masks the problem — the copies drift again as soon as new uploads land, storage doubles, and simultaneous writes to the same filename race. Sticky sessions pin a clinic to whichever instance holds half its files, so the missing scans stay missing and losing that instance wipes out the clinic's view. An Application Load Balancer forwards a request to exactly one target; it cannot fan a request out and merge the answers.
A video post-production studio is moving its batch rendering platform to AWS. Today a single dispatcher machine hands render jobs to a farm of worker machines, and demand swings sharply around client deadlines. The studio wants the rebuilt system to be as resilient and as scalable as possible. How should the solutions architect design it?
- Keep a dispatcher EC2 instance alongside worker EC2 instances in an Auto Scaling group, publish each job to an Amazon EventBridge event bus, and scale the workers on their average CPU utilization.
- Send each job to an Amazon SQS queue and run the workers as EC2 instances in an Auto Scaling group that scales on the number of instances registered against the queue.
- Keep a dispatcher EC2 instance alongside worker EC2 instances in an Auto Scaling group, record every job through AWS CloudTrail, and scale the workers on the dispatcher's CPU load.
- ✓ Send each job to an Amazon SQS queue and run the workers as EC2 instances in an Auto Scaling group that scales on the approximate number of messages waiting in the queue.
Putting jobs on an Amazon SQS queue eliminates the dispatcher as a single point of failure, absorbs deadline bursts, and keeps a job durable if the worker processing it dies, while scaling the Auto Scaling group on the approximate number of messages waiting sizes the fleet to the actual backlog. Scaling on the count of instances registered against a queue measures the fleet instead of the work, so capacity never tracks demand. Keeping a dispatcher and reacting to CPU utilization leaves that machine as a failure point and responds late, because CPU only climbs after jobs have already backed up. EventBridge routes events without holding a durable backlog for workers to drain, and CloudTrail records API activity for auditing — it was never a job dispatch mechanism.
A concert ticketing platform posts every seat-reservation change to an Amazon API Gateway REST API, which hands it to a backend function that updates seat inventory. Because two customers can claim the same seat within milliseconds, changes for a given event must be processed in exactly the sequence they arrived. What should the solutions architect implement?
- Configure API Gateway to publish each reservation change to an Amazon SNS standard topic that the processing function subscribes to.
- ✓ Configure API Gateway to send each reservation change to an Amazon SQS FIFO queue, using the event ID as the message group ID, and have the processing function poll that queue.
- Configure API Gateway to send each reservation change to an Amazon SQS standard queue that the processing function polls.
- Attach a Lambda authorizer to the API that rejects incoming requests while a reservation change is still being processed.
An SQS FIFO queue preserves the arrival order of messages within a message group and delivers each message exactly once, so grouping by event ID means every reservation for that event is handled in sequence while different events still process in parallel. A standard SQS queue offers only best-effort ordering and can deliver a message more than once, which is precisely what corrupts seat counts under load. An SNS standard topic fans a notification out to subscribers with no ordering guarantee, so concurrent invocations of the processing function can finish out of sequence. A Lambda authorizer decides whether a caller is permitted in; repurposing it to turn traffic away while work is in flight rejects legitimate customers and still orders nothing.
Practice SAA-C03 free
The first 10 questions of every exam are free. No signup, no email wall.
Start practicing →Get a free SAA-C03 study plan by email
A short plan to work through SAA-C03 by skill area, plus a note when we add new questions. Optional — the practice above stays free. No spam, unsubscribe anytime.