Free lesson · AWS Fundamentals

How AWS knowledge is actually tested

Easy5 min read

Three Different Tests

AWS knowledge gets evaluated in three settings, and they reward genuinely different things. Preparing for one and being assessed by another is a common and avoidable failure.

Knowing which room you are in changes what a good answer looks like.

What A Certification Question Looks Like

AWS exam questions share a recognisable structure:

1. A scenario - a company with a situation, usually two or three paragraphs, containing details that matter and details that do not.
2. A qualifier - the phrase that decides the answer. Most cost-effective. Least operational overhead. Highest availability. Minimal code changes. Most secure.
3. Four options, of which typically two are technically wrong and two are technically correct.

The qualifier selects between the two correct ones. This is the entire trick, and it is why people who know AWS well still fail exams: they pick the option they would actually build, when the exam asked for the cheapest one.

Tip: Read the qualifier before you read the options. Then eliminate on technical correctness first, and only then apply the qualifier. Reversing this order - scanning options for something familiar - is how you end up choosing a right answer to a question that was not asked.

Distractors are constructed deliberately. Common patterns: a service that solves the problem but at higher operational cost, a service that solves a similar problem in a different domain, a correct approach with one detail wrong, and an approach that was correct three years ago before a service gained a feature.

What A System Design Interview Question Looks Like

Open-ended, verbal, collaborative. "Design a system that lets users upload and share video." No options, no qualifier, and an interviewer who will push wherever you sound least certain.

The failure mode specific to cloud-experienced candidates:

"I'd put the videos in S3, use CloudFront in front, DynamoDB for metadata, SQS for the transcoding queue, and Lambda for the workers."

Every one of those is a defensible choice. As an answer it is weak, because it names products without demonstrating that the candidate knows what any of them is. The interviewer's next question is going to be "why DynamoDB and not a relational database?" or "what happens when a transcoding job takes longer than the Lambda timeout?", and a candidate who selected services by pattern-matching has nothing to say.

The stronger version reasons about primitives first and names the service second: "Metadata access is mostly key-lookup by video ID with no complex joins, and it needs to scale with catalogue size, so a partitioned key-value store fits - DynamoDB. The tradeoff I'm accepting is that any query pattern I didn't design a key for becomes a scan."

Important: Certifications train you to select services. System design interviews test whether you understand what the service is. These skills overlap but they are not the same, and certification preparation on its own can actively reinforce the habit that loses interviews - reaching for a product name as the answer rather than as the conclusion. Course 6 exists specifically to address this.

What The Job Tests

Neither of the above, exactly. The job asks:

• Can you find the answer when you do not know it? (Module 01 Topic 8 - reading the documentation.)
• Can you debug something you did not build? (Module 08 - observability.)
• Do you notice the cost implication before finance does? (Modules 04 and 13.)
• Can you write down why you chose something, so the next person understands? (Module 06 - Well-Architected.)
• Do you know what you do not know, and say so?

The last one matters more than people expect. Confidently wrong is worse than uncertain and correct about being uncertain. This applies in interviews too - "I'd verify the current limit, but the shape of the constraint is per-partition throughput" is a better answer than a precise figure that turns out to be stale.

Preparing For Each

graph TD
    C[Certification] --> C1[Blueprint map]
    C --> C2[Gap lessons]
    C --> C3[Scenario drills]
    I[Interview] --> I1[Primitives behind products]
    I --> I2[Tradeoff articulation]
    I --> I3[Repeated design practice out loud]
    J[The job] --> J1[Build and tear down]
    J --> J2[Break things deliberately]
    J --> J3[Read the docs, not the blog]

This diagram shows three preparation approaches. Certification preparation involves working the blueprint map, studying gap lessons, and practising scenario drills. Interview preparation involves learning the primitives behind products, practising tradeoff articulation, and repeated design practice spoken out loud. Job preparation involves building and tearing down real infrastructure, breaking things deliberately, and reading official documentation rather than blog posts.

For certifications: work the blueprint map in the Course 7 overlay. Do scenario drills, not flashcards. Train the qualifier-first reading habit.

For interviews: work Course 6. Practise out loud, ideally with another person - the gap between "I understand this" and "I can explain this in real time under mild pressure" is large and only closes with rehearsal.

For the job: build things and tear them down. Break them deliberately and observe what the failure looks like. Read the primary documentation. Nothing in a course substitutes for having once watched a NAT Gateway bill arrive.

Warning: The most common preparation error is optimising for the test you are not taking. Grinding certification practice questions for a role that never asks about certifications. Or reading system design theory when the immediate blocker is an exam in three weeks. Decide which room you are walking into, then prepare for that room. Module 00 Topic 2 exists to make that decision explicit.

A Note On Certification Value

An honest position, because the AWS training industry has a strong incentive to overstate it.

Certifications carry real weight for consultancies and AWS partners with tier requirements, for regulated and government contracting, for passing automated résumé screens at mid-market companies, and for career changers who need a credible signal on a thin résumé. In those contexts they can be decisive.

They carry comparatively little weight in senior engineering loops at large product companies, where the assessment is design reasoning and coding rather than service selection.

Both are true. The mistake is assuming one applies to you because you read it in a marketing page. Find out what your specific target rewards before committing three months.

Course 7 contains a dedicated topic on this, written by an Amazon Principal Engineer and Bar Raiser who has conducted more than 300 interviews. It is free to read, and worth reading before you buy an exam voucher rather than after.

Practice

Exercise: Starter. Find a sample AWS exam question online. Identify the scenario, the qualifier, and which two options are technically correct before you pick one.

Intermediate. Take one design decision you have made - at work or in a project - and write two versions: one naming the services, one reasoning from the primitive to the service. Notice which one you would rather say out loud in an interview.

Advanced. Find three job postings for your target role. Note whether each mentions certifications, and whether the technical screen described is a coding interview, a system design interview, or a practical exercise. Adjust your path accordingly, and write down what you are choosing not to prepare for.

Related Topics

• Module 00 Topic 2 - Choosing your path
• Module 01 Topic 8 - Reading AWS documentation and the service API model
• Course 6 - AWS for System Design Interviews
• Course 7 - Certification Prep

Back to AWS Fundamentals