Before you go hunting for a familiar service name, turn the scenario into a decision record on paper (or in your head). This is what stops a stray keyword from hijacking your reasoning.

What’s actually running here: web requests, files, containers, relational transactions, events, or analytics?

What outcome does the scenario require: low latency, availability, isolation, cost control, or simpler operations?

What must never happen: public exposure, downtime, data loss, manual scaling, or unnecessary spend?

Which phrase actually narrows the answer, and what trade-off is the question willing to accept to get there?

Which option violates security, reliability, performance, cost, or operational requirements — and is therefore out, no matter how appealing?

Can you state the winning architecture in a single sentence before you even look at the individual services?

The Five-Question Service Lens

For any service worth knowing, ask the same five questions every time: what is it, why does it matter, when should I reach for it, what do I keep confusing it with, and what should I actually look for in a question? Do this consistently and recognition turns into usable exam knowledge instead of trivia.

What: object storage. Why: it decouples durable objects from any single compute instance. Use: files, backups, logs, datasets, and data-lake layers. Confused with: EBS and EFS. Look for: object access, lifecycle rules, durability, or static assets.

What: identity and access control. Why: it limits who or what can actually take an action. Use: users, roles, policies, and workload permissions. Confused with: network-level controls. Look for: least privilege, temporary access, authentication, and authorization.

What: a content delivery network. Why: it serves cacheable content from a location closer to the user. Use: lower-latency delivery for supported content and origins. Confused with: Global Accelerator. Look for: caching, edge delivery, viewer behavior, and origin configuration.

Common AWS Exam Keywords — Treat Them as Signals, Not Answers

• “Least operational overhead” — Points toward managed or serverless options — but still check runtime, integration, and control requirements before you commit.
• “Highly available” — Inspect failure domains, redundancy, health checks, and recovery behavior — not just the product’s marketing label.
• “Cost-effective” — Compare total workload cost and actual suitability. The cheapest individual component isn’t always the best overall solution.
• “Durable” — Think preservation of data specifically. Don’t silently swap this requirement out for an availability requirement — they’re not the same thing.
• “Private subnet” — Inspect routing and controlled egress carefully — a private address doesn’t automatically mean there’s no outbound path at all.
• “Read-heavy” — Evaluate caching, replicas, partitioning, and read access patterns, while still preserving whatever consistency the workload needs.
• “Decouple” — Consider queues, topics, or events — then check ordering, delivery guarantees, retries, and consumer behavior before you finalize.
• “Global users” — Evaluate DNS, edge delivery, routing, latency, and origin architecture together — no single service solves this alone.
• WHY THIS MATTERS — A keyword narrows the search space. It does not automatically select one service for you. The requirement and the unacceptable trade-off are still what decide the final answer.