Expert
AWS SAA-C03How to Think Through an AWS Architecture Question in 90 Seconds
A step-by-step walkthrough of a real SAA-C03 style scenario question — the four-step elimination process that separates fast, confident answers from slow, uncertain ones.
SAA-C03 questions are not knowledge tests — they are constraint-satisfaction problems. Every question gives you a scenario with 2–4 explicit requirements, and every answer option is architecturally valid for at least one of them. The candidates who pass quickly are those who have a repeatable process for eliminating wrong answers, not more knowledge.
Choose ONE answer.
A company runs a web application on EC2 instances behind an Application Load Balancer. The application stores session data in memory on each EC2 instance. The company wants to scale out the application to handle peak traffic, but users are experiencing session loss when requests are routed to different instances. The solution must minimise operational overhead. Which solution meets these requirements?
[1 mark]
Read the constraints before reading the options
Before looking at answer choices, identify every requirement the question states. This one has three: (1) scale out — so we need more instances, (2) session data must not be lost when requests hit different instances, (3) minimise operational overhead. Write these down mentally or physically. You will use them as a filter.
Identify what the real problem is
The problem is that session state is stored locally on each EC2 instance. When a user's next request goes to a different instance, the session is gone. This is a stateful application running on stateless infrastructure — a classic AWS architecture problem. The fix is always the same: move the session state off the instances into a shared, external store.
Apply your constraints to eliminate options
Now you look at the options and eliminate ruthlessly: • "Enable sticky sessions on the ALB" — this routes each user to the same instance. It does not solve the problem when that instance fails or is terminated during scale-in. It also breaks proper load distribution. Eliminate. • "Use Amazon RDS to store session data" — a relational database for session data is overengineered and slow. Not the right tool. Also higher operational overhead than a cache. Eliminate. • "Use Amazon ElastiCache for Redis to store session data" — in-memory, sub-millisecond, designed for session management. Fully managed (low operational overhead). Survives EC2 instance changes. This satisfies all three constraints. • "Implement a Network Load Balancer instead of ALB" — changes the load balancer type, does nothing to solve session persistence. Eliminate.
Verify the answer satisfies every constraint
ElastiCache for Redis: ✓ enables scale-out (sessions survive across any instance), ✓ no session loss (shared external store), ✓ low operational overhead (fully managed, no cluster management needed). All three constraints satisfied. Confirm and move on.
The underlying pattern
This question tests a pattern that appears in many different forms on the SAA-C03: stateful application on horizontally scaling infrastructure. The answer is always the same shape — move the state to a managed, external service. Session data → ElastiCache. Database state → RDS Multi-AZ. File uploads → S3. Queued work → SQS.
Common mistakes on this question type
- Choosing sticky sessions — it feels like the simplest answer, but it breaks horizontal scaling and creates uneven load. AWS questions penalise "almost right" answers.
- Choosing RDS for session storage — RDS is for relational data with complex queries, not ephemeral key-value session data. Tool-problem mismatch.
- Not reading "minimise operational overhead" — this rules out self-managed Redis on EC2 and makes ElastiCache (fully managed) the clear winner over any self-hosted alternative.
Practice AWS SAA-C03
Exam simulation, graded results, and detailed guidance on every question.