Anatomy of a scenario question
| Part | Example wording | What it tells you |
|---|---|---|
| Context | “A company runs a web application on EC2 instances in two Availability Zones...” | The current architecture. Much of it is background. |
| Hard constraints | “...must not traverse the internet”, “without changing application code”, “RPO of 15 minutes” | Rules that eliminate options outright |
| Soft signals | “The data is accessed rarely”, “traffic is unpredictable”, “a small operations team” | Hints that point to a family of services |
| Qualifier | “Which solution is the MOST cost-effective?” | The tie-breaker among options that work |
| Options | Four architectures described in plain words | Usually one correct answer, one near miss, two clear misfits |
The four-step method (target: 90 seconds)
Step 1: Read the question sentence first (5 seconds)
Before the scenario, read the last line. Note the qualifier and what is being asked for: a single change, a full design, or two steps. That tells you what to look for as you read the scenario.
Step 2: Mark the hard constraints (30 seconds)
Read the scenario and pick out every phrase that rules something out. Write them down in 2–3 words each on your note board for long stems. Common constraints:
- Data and access: “shared file system”, “SMB”, “POSIX”, “key-value”, “graph”, “SQL joins”, “millisecond latency”
- Operations: “without managing servers”, “small team”, “minimal changes to the application”, “existing Kafka / JMS / Kubernetes”
- Recovery: RPO and RTO figures, “survive the loss of an AZ / a Region”
- Security: “must not traverse the internet”, “company-managed keys”, “audit key usage”, “least privilege”
- Time and scale: “processing takes 40 minutes” (too long for Lambda), “10 TB in 3 days over 100 Mbps” (too slow online)
Step 3: Eliminate options that break a constraint (30 seconds)
For each option, name the constraint it breaks. You should be able to say something like “C runs on EC2, and the stem says no servers to manage” or “A uses One Zone-IA, and the data cannot be re-created”. Options you cannot eliminate this way stay in.
Step 4: Apply the qualifier to the survivors (20 seconds)
Usually two options are left. The qualifier decides between them:
| Qualifier | What usually wins | What usually loses |
|---|---|---|
| MOST cost-effective / lowest cost | The cheapest option that still meets every constraint: Spot for interruptible work, S3 lifecycle to colder classes, gateway endpoints, serverless for idle-heavy load | Over-provisioned HA, active-active DR, interface endpoints where a gateway endpoint works |
| LEAST operational overhead | Managed, serverless and native features: Fargate, Aurora, Secrets Manager rotation, S3 lifecycle, AWS Backup | Self-managed software on EC2, custom scripts, cron jobs, anything you must patch |
| MOST secure | Least privilege, private connectivity, temporary credentials, encryption with customer managed keys, deny-by-default | Access keys on instances, public endpoints, broad wildcards |
| Highest availability / fault tolerance | Multi-AZ and Auto Scaling; multi-Region only when a Region-level failure is in scope | Single instance, single AZ, single NAT gateway, single VPN tunnel |
| LEAST latency / best performance | Caches, edge services, read replicas, the right storage type, placement groups | Cross-Region calls, cold storage, undersized volumes |
| Fewest changes / no code changes | Drop-in options: Multi-AZ, RDS Proxy, Auto Scaling, Storage Gateway, rehosting | Refactoring to microservices or rewriting to use DynamoDB |
Distractor families
Wrong options are built from a small set of patterns. Learn to name them and elimination becomes fast:
- Wrong layer: a network ACL for an application-layer attack (use AWS WAF), or a security group rule to deny an IP (security groups cannot deny).
- Wrong scope: an SCP expected to grant access, or a gateway endpoint expected to serve on-premises clients.
- Over-engineered: multi-Region active-active for a 4-hour RTO, or Direct Connect for a one-off transfer.
- Under-delivers: Lambda for a 40-minute job, Standard SQS when order and exactly-once processing are required, or One Zone storage for critical data.
- Self-managed alternative: Kafka on EC2 when MSK exists, or a database on EC2 when RDS fits.
- Real services in an impossible combination: for example, “enable Multi-AZ on the read replica to serve reads from the standby”. Every word in it sounds familiar, but the mechanism does not work that way.
Worked example: multiple choice
Multiple response: “Choose two” and “Choose three”
Multiple response items are effectively all-or-nothing. Handle them differently from single-answer items:
- Find out what kind of set is asked for. Read the question sentence carefully:
- Complementary steps: “Which combination of steps will meet the requirements?” The correct options are parts of one solution. Each one alone is incomplete.
- Independent solutions: “Which solutions will meet the requirements?” Each correct option works on its own.
- Judge each option as true or false against the requirements, not against the other options. Write T, F or ? next to A–E on your note board.
- Check that your picks work together. For complementary steps, the chosen options must not contradict each other. For example, “use sticky sessions” and “store sessions in ElastiCache” solve the same problem two different ways, so they are rarely both correct.
- Pick exactly the requested number. If you have only one clear T, choose the ? that pairs best with it. Never submit with the wrong number of options selected.
Timing and getting unstuck
Budget 60–75 seconds for a short multiple choice item, 2 minutes for a long one with a policy snippet, and 2–3 minutes for multiple response, averaging 1 minute 40 seconds on the first pass. When stuck:
- If two options differ by one detail (gateway vs interface endpoint, SSE-S3 vs SSE-KMS), that detail is the question. Reread the stem for the constraint that decides it.
- Otherwise choose the more managed, simpler survivor, flag it and move on. A fresh look later often settles it in seconds.