Methodology

How we write questions

We never store or publish real exam-dump content. Every question on this site is original — here's exactly how that's enforced, not just claimed.

1. Concept extraction, not copying

We start from a syllabus of AWS concepts and facts — things like "a security group can reference another security group as its source" or "EBS encryption can't be enabled in place on an existing volume." When we look at existing study material to identify what's worth testing, we extract only the underlying concept and the facts it involves. No question text, scenario, or wording is ever carried forward — that source material is discarded the moment the concept is identified.

2. Original generation from the concept alone

A fresh question is generated from just the concept and facts — a brand-new scenario, company, constraint, and set of answer options, invented from scratch. The model writing the question has never seen an existing exam question; it only knows the AWS facts being tested and is instructed to build a realistic "pick the best option" scenario around them, the same style the real exam uses.

3. Automated technical QA

Every generated question is checked by an independent pass that re-derives the correct answer from scratch, without seeing which option was marked correct, and flags anything where it disagrees, isn't confident, or spots a factual problem, an ambiguous premise, or two defensible answers.

4. Human review before anything goes live

Nothing reaches this site automatically. Every question lands in a review queue and is read, fact-checked, and either approved, edited, or rejected by a human before it becomes visible to a single visitor. We also periodically re-audit already-published questions by answering them blind — with no knowledge of the marked answer — to catch anything the process missed.

A note on accuracy

AWS ships new capabilities constantly, and a question built on an outdated “service X can’t do Y” premise can silently become wrong. Our writing process specifically avoids building the correct answer on a capability gap unless that limitation is verified as currently true, and prefers questions that test genuine architectural trade-offs — cost, latency, compliance, operational overhead — instead. If you spot an error anyway, tell us — see the About page for contact details.