Exam Simulation A: Practice Set and Strategy

Fourteen lessons gave you the content. This one gives you the container: how a DEA-C01 item is actually built, how the 130-minute clock behaves, how AWS writes a distractor, and then Set A: twenty exam-style items you sit under time and grade honestly. Everything before this lesson was domain knowledge; everything here is test craft, and on a compensatory 100 to 1,000 scale with 720 to pass, test craft is worth as much as another hour of revision.

By the end of this lesson you will be able to:

• restate every published logistics number (65 / 50 / 15, 130 minutes, 720/1,000, 150 USD, 3 years, 14 days) without notes;
• run the 120-second pacing math and defend a two-pass plan that never leaves an item blank;
• apply the flag-and-sweep technique inside a two-minute per-item budget;
• read a superlative stem, MOST appropriate, LEAST costly, FIRST step, NOT, and know which option the qualifier is buying;
• run the five-move multiple-response procedure that survives all-or-nothing scoring;
• decode the distractor factories AWS reuses across all four domains;
• sit Set A, grade it by domain rather than by total, and route each miss to the right lesson;
• defend the comparative verdict on free official preparation versus paid training versus cross-cloud and on-premises experience.

---

1. The container: what the 130 minutes actually are

1.1 The logistics you must not re-derive on exam day

Every number below is published by AWS and was retrieved in October 2026. You are allowed to forget service trivia; you are not allowed to re-derive these under a running clock.

• 📚 Did you know? The 15 unscored items look exactly like the 50 scored ones: AWS states they "are not identified on the exam". The rational response is symmetry: a badly answered pretest item costs you nothing, a skipped scored item costs the full marks, so the incentive never once points toward "leave it blank and come back". Flag, guess, move.

The interface you will be given. Knowing the controls before test day is free marks, because the exam gives you no orientation tour:

Two administrative failures cost more than any knowledge gap. At a test centre, administrators are instructed not to allow testing when the name on your government ID does not match your AWS Certification Account; online, arriving more than 15 minutes late or skipping the required system test forfeits the fee. Neither is recoverable with study.

1.2 The pacing plan: 65 items, 130 minutes

AWS publishes no per-question budget. The only official pacing inputs are the 130-minute duration, the on-screen countdown timer, and the Exam Demo's flag-and-review controls. Everything below is arithmetic on published numbers, labelled as such.

Worked example 1: the ceiling.

$$\frac{130 \times 60}{65} = \frac{7{,}800}{65} = 120\ \text{s per item} \quad (\text{exactly } 2.00\ \text{minutes})$$

Worked example 2: the scored-only illusion. Against scored items only, the budget looks like $7{,}800 \div 50 = 156$ s $= 2.60$ minutes. You cannot tell which 50 are scored, so 120 s is the number you plan with and 156 s is a trap you must never budget against.

Worked example 3, what slow averaging actually costs. Cruising at 2.5 minutes per item gives $65 \times 2.5 = 162.5$ minutes, 32.5 minutes past the limit, which is roughly the last 16 items rushed or blank, and a blank is scored incorrect. The clock, not your knowledge, produces that score.

The two-pass split. Run pass one so it ends at t = 90 minutes (about 1.4 minutes per item, which is faster than the 120-second ceiling and therefore leaves slack for the long items). At t = 45 you should be near item 33; at t = 65 near item 50. Everything you cannot settle in one clean read gets a flag and a best guess.

Worked example 4, the ESL accommodation. With the +30-minute extension the budget becomes $160 \div 65 = 2.46$ minutes per item. That is more time per item, not permission to spend 4 minutes on a hard stem, the two-pass structure survives the extension unchanged.

Worked example 5: Set A's own clock. Set A has 20 items, so the live budget scales to $20 \times 120 = 2{,}400$ s $= \mathbf{40}$ minutes. Sit it at 40 minutes to reproduce the real rhythm. If you are short of time, run the compressed form: pass 1 at 75 s per item ($20 \times 75 = 1{,}500$ s $= 25$ minutes) plus a 5-minute sweep = 30 minutes, and re-sit at the full 40 before test day. This lesson's 90 minutes are budgeted as roughly 35 to read, 40 to sit, 15 to grade.

1.3 Flag-and-sweep: the technique, item by item

The exam's own guidance reduces to a sequence you can run in one pass. Train it until it is automatic:

The sweep is the other half of the name. At the review screen you are not re-answering; you are checking three things and nothing else:

1. Blanks. Zero. An unanswered item is scored incorrect and there is no penalty for a wrong guess, so blank is strictly dominated by any guess at all.
2. The asked question. Re-read the constraint clause and confirm you answered it: the classic loss is answering the adjacent, more familiar question.
3. Order of operations. Change an option only if you can state the reason in one clause. "It felt wrong" is not a clause.

1.4 Reading the stem: MOST appropriate, LEAST costly, FIRST

Most DEA-C01 losses are reading losses. The stem's qualifier, not the service name, decides the key, so the first move is always the same: find the qualifier, write down what it demands, then read the options.

Worked example 6: reading a superlative end to end. Take a stem that never appears in Set A: "A nightly Spark job over a 40 GB dataset consistently finishes in about 25 minutes with 12 GB of executor memory. Which service and runtime is the MOST appropriate, fully managed choice?"

1. Underline the qualifiers before looking at any option: nightly · 40 GB · 25 minutes · 12 GB · fully managed.
2. Let the hardest qualifier eliminate. 25 minutes is 1,500 seconds, which is past AWS Lambda's hard ceiling of 900 seconds, so Lambda dies on arithmetic, even though it is the most serverless-looking option and 10,240 MB is inside its memory range. That distractor is built to test which limit binds.
3. Match the runtime to the workload. A Spark DataFrame job is not a single-process script, so the Glue Python shell (0.0625 or 1 DPU, no Spark) dies next.
4. Apply "LEAST operational overhead" to the survivors. A Glue ETL (glueetl) job runs Spark fully managed in DPU units (1 DPU = 4 vCPU + 16 GB); EMR Serverless also works but carries more operational surface than the stem's constraint asks for.
5. Say the trap out loud: the most serverless option failed on a limit, not on a preference. Verify every limit against the current service quotas page before you rely on it.

• 📚 Did you know? The exam guide's single most important style sentence is "The ability to compare AWS services to understand the cost, performance, and functional differences between services." Every tie-break in section 1.4 is an instance of it: when two options both work, the differentiator is cost meter, performance envelope or functional limit: never "which one I have used".

1.5 The multiple-response technique

The exam guide defines the type precisely: multiple response "has two or more correct responses out of five or more response options." Two consequences decide your method:

• All-or-nothing. A partially correct set scores zero. AWS's own exam-prep material prints "No Negative points or Partial credit", so the cost of an under-selection is identical to the cost of a wrong selection, and there is no reason to submit fewer than the stem demands.
• Different rhythm. Multiple-response items take roughly half again as long as multiple choice, which makes them the items most likely to push you past the two-minute mark, and the ones you least want to flag, because re-reading five or six options feels productive. Flag them anyway.

The five-move procedure:

• 📚 Did you know? The exam guide guarantees the two types and the counts of scored and unscored items, but AWS has never published how many multiple-response items appear on a given form, nor the ratio of multiple choice to multiple response among the 50 scored items. Set A's five-of-twenty split is a teaching choice that mirrors the guide's own definitions: never quote it as an AWS figure.

1.6 Domain weights and the Set A blueprint

Only domain percentages are published. The item counts below are arithmetic on 50 scored items: a planning aid, never an AWS figure.

Worked example 7: weights to items. $50 \times 0.34 = 17$, $50 \times 0.26 = 13$, $50 \times 0.22 = 11$, $50 \times 0.18 = 9$; $17 + 13 + 11 + 9 = 50$. Domains 1 and 2 together are 60 % of scored content; which is why Set A gives them 12 of its 20 items, but Domain 4's 9 items are more than enough to fail you alone, because scoring is compensatory and there is no section cut to hide behind.

1.7 Distractor families, and what this lesson will not assert

AWS states that distractors are "generally plausible responses that match the content area." They are not random; the same shapes recur, and each one punishes a specific confusion. They are labelled T1, T7 here so they are never confused with the domain labels D1, D4.

Points this lesson deliberately does not assert. These are flagged rather than taught, because an unverified claim is never a fact:

1. How many multiple-response items a live form carries, and whether every stem states the count: unpublished.
2. The per-form multiple choice to multiple response ratio among the 50 scored items: unpublished.
3. The text of the 20 Official Practice Question Set items. They sit behind Skill Builder sign-in; no style claim in this course is attributed to reading them.
4. The exact date on which guide v1.1 content first appeared on a live form. The guide promises revisions at least one month ahead and delivery rolls across languages. Say "in the current exam guide", not a date.
5. Whether DEA-C01 will adopt the ordering, matching and case-study types AWS announced in July 2024. AWS named AI Practitioner and Machine Learning Engineer: Associate as the first exams for those types, and the current DEA-C01 guide lists only multiple choice and multiple response.
6. A raw-to-scaled conversion. 720 is a scaled cut produced by standard setting and equating; "N of 50 = pass" is arithmetic nobody outside AWS can do.
7. Per-domain pass marks. There are none: the model is compensatory.
8. Same-day or on-screen pass/fail. The official policy text is "within five business days".

---

2026 Updates (as of October 2026)

Six 2025 to 2026 changes decide whether your notes are right or wrong on exam day. Every bullet is sourced to an AWS first-party page retrieved in October 2026; where a claim could not be verified it is labelled as such and must never be memorised as fact.

• 📚 Did you know? AWS moved exam guides from static PDFs to AWS Docs precisely so revisions could ship without a new exam code: a significant change earns a new series code (for example DVA-C01 → DVA-C02), while a less significant change, adding or removing skills and in-scope services, becomes a revision on the same code. That is why DEA-C01 stayed DEA-C01 through v1.1, and why the Revisions page, not a PDF watermark, is the artefact to check before you sit.

---

Real-World Case Studies

AWS never prints a customer's name on an exam item, but the shapes of real pipeline failures leak into stems constantly: one sentence of incident history becomes the stem's condition, and the four options become the four ways candidates mis-read it. The two drills below are drawn from the case material behind this course's question bank and should be run before Set A: each ends with which domain this tests and what the exam would ask.

Two rules govern everything in this section:

1. A number in a stem is a constraint, not decoration. "25 minutes", "1,500 records per second", "3 TB uncompressed" is always the qualifier that selects the key.
2. The domain is chosen by the constraint, not by the story. The same streaming narrative seeds a Domain 1 item (ingestion design), a Domain 3 item (monitoring lag) or a Domain 4 item (who may read the stream) depending on which clause the exam underlines: exactly the section 1.4 reflex.

Case Study 1, the hot partition key: why adding shards does nothing

The story. 800 telemetry records per second at 4 KB each arrive from 12,000 devices, and two consumer applications each need every record. Sizing gives 4 shards (Set A's Q1). Two weeks later one faulty firmware build pins 1,500 records per second onto a single device_id partition key, and that shard throttles at 1,000 records per second no matter how many shards sit beside it.

Which domain does this test? Primarily D1 Data Ingestion and Transformation (34 %): skill 1.1.9 throttling and rate limits, skill 1.1.10 fan-in and fan-out. Secondary hooks: D3 (22 %) if the stem asks what to alarm on (GetRecords.IteratorAgeMilliseconds), D4 (18 %) if it asks who may write to the stream.

What would the exam ask? Three stem shapes:

1. "Which change most directly resolves the throttling?" → redesign the partition key (a two-level or salted key such as device#<bucket>), because one partition key maps to exactly one shard. Increasing the shard count is the most-selected wrong answer: the bottleneck is per-key, not per-stream.
2. "Which metric confirms consumer lag?" → GetRecords.IteratorAgeMilliseconds, whose AWS documentation states that a value of zero indicates the consumer has caught up. Alarm on Max against roughly half the retention window.
3. "Which two limits does a single partition key exceed first?" → 1 MB/s and 1,000 records per second per shard, and note that on-demand mode explicitly does not detect and isolate hot hash keys, so auto-scaling will not save you either.

The trap to say out loud: capacity answers feel like answers. When the stem names a key, the fix is in the key.

Case Study 2, the Athena bill: three numbers that must be read together

The story. A 3 TB uncompressed text dataset sits in Amazon S3 with three equally sized columns. Dashboards query one of the three columns. Every query scans 3 TB and costs 3 × 5.00 USD = 15.00 USD. The team converts to Apache Parquet at 3:1 compression, re-registers the table in the AWS Glue Data Catalog, and the same query now scans about 0.33 TB for roughly 1.65 USD.

Which domain does this test? D3 Data Operations and Support (22 %) first, skill 3.2.3 SQL in Athena, skill 3.1.7 query data, with D2 (26 %) hooks in 2.4.5 (partitioning, compression and other optimization techniques) and D1 (34 %) hooks in 1.2.6 (transform data between formats, for example.csv to Apache Parquet).

What would the exam ask? Three stem shapes:

1. "What is the approximate cost per query before and after?" → 15.00 USD → 1.65 USD (Set A's Q6). The distractors are the most likely slips: applying compression but forgetting column pruning, using the wrong before-cost, or multiplying instead of dividing.
2. "Which change produced the larger share of the saving?" → column pruning, because text cannot skip columns: 3:1 compression alone takes 3 TB to 1 TB (5.00 USD), and reading one of three columns takes that to about 0.33 TB.
3. "Which cost meter does this bill use?" → bytes scanned, at 5.00 USD per TB with a 10 MB minimum per query, rounded up to the nearest MB: with no charge for DDL, partition management or failed queries. The competing option is always Redshift, which bills cluster compute time instead.

The trap to say out loud: two levers, one bill. Compression and column selection are different multipliers, and a stem that quotes only one of them is testing whether you can do the arithmetic in the order it happened.

---

Real-World Case Drills

The two studies above came from this course's question bank; the two drills below come from AWS-published customer case studies: every figure read off an AWS-owned page in October 2026 (digest 16). Run each one exactly as you would a live stem: underline the numbers, name the domain, then write the question the exam would build from it. The story is never the answer; only the constraint buried in it is.

Two rules govern everything in this section:

1. A customer result is never an AWS guarantee. AGCO's −78 % and IAS's "hundreds of permission rules down to precisely two rules" are customer outcomes printed on AWS pages; AWS commits to neither a percentage nor a rule count. Any option phrased "AWS guarantees…" fails before you check the number.
2. Build the stem from the clause, not from the headline. The clause the exam underlines decides everything: throughput makes the same AGCO story a Domain 1 item, screen load 600 ms makes it Domain 3, who may read the raw prefix makes it Domain 4: exactly the section 1.4 reflex, applied to a case instead of a service.

Case Drill 1, AGCO: one streaming story, three domains

The story as AWS publishes it (AWS Architecture Monthly, December 2021, p. 10, and the AWS Industries blog of 2021-03-03; accessed Oct 2026):

Which domain does this test? Primarily D1 Data Ingestion and Transformation (34 %): streaming ingestion, fan-out and format conversion, the KDS → Firehose → S3 shape. Secondary hooks: D3 Data Operations and Support (22 %) if the stem asks which metric proves the 600 ms figure, and D4 Data Security and Governance (18 %) if it asks who may write to, or read, the raw prefix.

What would the exam ask? Three stem shapes, all built from the table above:

1. "Which service in this architecture delivers records to Amazon S3 without the team ever running consumer code?" → Amazon Data Firehose: buffered delivery that flushes on size or interval, whichever first, exposing no consumer API and no consumer-side replay. The baited option is always "replay the last 24 hours from the Firehose delivery" (trap pair F1; Set A's Q2).
2. "Which metric would confirm that consumer lag, not Firehose buffering, is behind a delayed dashboard?" → GetRecords.IteratorAgeMilliseconds on the stream, alarmed on Max, at roughly half the retention window; AWS documents that a value of zero means the consumer has caught up (Set A's Q14).
3. "Which analytics path gives the LEAST operational overhead for this workload?" → the managed stream processor, Amazon Managed Service for Apache Flink, renamed from Kinesis Data Analytics on 2023-08-30, over self-run Kafka or Flink. And never "add shards" when the stem's noun is a key.

The trap to say out loud: −78 % is AGCO's number on AGCO's workload, dated to a January 2020 go-live. A stem that offers it as a property of managed streaming is testing digest 16's first trap: AWS says X % ≠ universal. Date-stamp the story and refuse any option that generalises it.

• 📚 Did you know? The table above uses three names for what candidates still call "Kinesis": Amazon Kinesis Data Streams, Amazon Data Firehose (renamed from Kinesis Data Firehose on 2024-02-09, with endpoints, APIs, CLI, IAM prefixes and CloudWatch metrics all unchanged) and Amazon Managed Service for Apache Flink (renamed from Kinesis Data Analytics on 2023-08-30). The DEA-C01 in-scope list still prints "Amazon Kinesis Data Firehose", so both Firehose names are valid: never "correct" an option that uses the older one.

Case Drill 2, Integral Ad Science: hundreds of permission rules become two

The story as AWS publishes it (AWS Big Data Blog, 2021-09-23; accessed Oct 2026):

Which domain does this test? D4 Data Security and Governance (18 %) first: tag-based access control, fine-grained grants and federated identity. Hooks: D2 Data Store Management (26 %) for the central catalog that the tags hang off, and D3 Data Operations and Support (22 %) if the stem asks what a workgroup actually limits.

What would the exam ask? Three stem shapes:

1. "Which mechanism collapses hundreds of grants into two?" → tag-based access control: grant once on a tag, tag the resources, let inheritance carry the grant to every table and column beneath the database (the mechanism one step past Set A's Q17 and Q18).
2. "(Select TWO.) Which two doors must open before a governed query returns rows?" → IAM, API calls, including lakeformation:GetDataAccess for Amazon Athena, and Lake Formation, which gates the catalog and the S3 data. Both, always; and Lake Formation grants are Region-local.
3. "What stops an analyst reading the raw S3 prefix with a perfectly valid IAM policy?" → the Lake Formation data access role: for a governed table, S3 is reached through Lake Formation, not through an S3 policy alone.

The trap to say out loud: the impressive number (two rules) is the customer's; the examinable part is the mechanism: tags, inheritance, two doors. The counter-trap is scope: a tag grant made in one Region does nothing in another, so any option offering "applies account-wide" dies on contact.

• 📚 Did you know? The same governance pattern at a much larger scale is GoDaddy's data mesh: AWS published more than 2,000 data products holding multiple petabytes across hundreds of accounts, with a central governance account owning Lake Formation and the Glue Data Catalog and sharing outward through AWS RAM. If a stem ever says "one account governs, hundreds consume", that is the picture, and it remains a customer result, not an AWS architecture guarantee.

---

Practice Questions

Set A, 20 items in published weight order: D1 seven, D2 five, D3 four, D4 four. The live exam's dominant format is one correct response and three distractors, and so is Set A; five items are multiple-response style, phrased "Select TWO" or "Select THREE" with the correct statements pre-combined into a single option so each item keeps exactly one key. That is a teaching device, on the live exam you would tick separate checkboxes, all-or-nothing.

How to sit Set A

Pre-flight check: run this in the 60 seconds before you start the timer:

1. Timer set to 40 minutes, notifications off, phone in another room.
2. A blank sheet for the qualifier words (MOST, LEAST, FIRST, NOT, Select TWO): writing the qualifier is the whole technique.
3. Answer sheet or tally ready, so grading takes 30 seconds afterwards.
4. Agreement with yourself: no blanks, and no option change without a one-clause reason.
5. Agreement with yourself: at two minutes the item gets flagged and a guess, whatever your instincts say.
6. Teardowns hidden. If you can see them, you are measuring your reading comprehension, not your recall.

Domain 1: Data Ingestion and Transformation (34 %) · items 1 to 7

Teardown, Q1 · the shard formula. Why it is right: both sides of the formula land on 3.125, and the formula says take the maximum of the two ratios and then round up, $3{,}200 \div 1{,}024 = 3.125$ and $6{,}400 \div 2{,}048 = 3.125$, so $\lceil 3.125 \rceil = 4$. Why the traps lose: A (2) ignores the read side entirely and rounds 3.125 down; B (3) truncates instead of applying ceiling, the single most common arithmetic slip on this item; D (8) applies the 2× read factor and the two-consumer factor, double-counting one of them. Trap: the formula's read divisor is 2,048, not 1,024, so a candidate who "remembers 2×" but forgets where it lives will get 8. Source: digest 15 Q01 and C1/C2 · Kinesis Data Streams how-do-i-size-a-stream.html (formula verbatim), as of Oct 2026.

Teardown: Q2 · stream vs delivery pipeline. Why it is right: two qualifiers: under a second (per-record, consumer-driven) and replay 48 hours (retention plus a consumer API), and only Streams satisfies both. Why the traps lose: A and D are the same service twice: Firehose buffers and flushes on size or interval, whichever first, exposes no consumer API, and therefore offers no consumer-side replay: only S3 backup and error prefixes, which do not help you re-run fixed logic over the last 48 hours; a Lambda transformation inside Firehose does not change that. C is a queue-and-route pattern with no stream-level replay affordance. Trap: Firehose sounds like "the Kinesis one that delivers", and a Lambda in the option makes it look consumer-driven: the qualifiers, not the brand name, decide. Source: digest 15 Q02 and trap pair F1 · aws.amazon.com/compare/data-firehose-and-kinesis-data-streams · Firehose FAQs, as of Oct 2026.

Teardown: Q3 · Select TWO, pre-combined. Why it is right: both halves break bookmark state independently: concurrency breaches the documented "bookmarks don't support concurrent job runs and commits will fail" rule, and a renamed transformation_ctx orphans the stored bookmark so every source looks new. Why the traps lose: B offers the correct DynamicFrame choice plus an irrelevant throughput setting; C and D offer output-layout and permission facts, none of which bookmark state reads. Trap: the stem says the job already uses DynamicFrames and already calls job.commit(), so candidates hunt for what is missing: the answer is what was changed. Live-exam form: two checkboxes, all-or-nothing, no partial credit. Source: digest 15 Q03 · Glue glue-troubleshooting-errors.html and programming-etl-connect-bookmarks.html, as of Oct 2026.

Teardown, Q4 · LEAST operational overhead. Why it is right: the stem's hard constraints are no environment to manage, no charge when idle, dependency-ordered retries, human gate, auditable history, Step Functions Standard satisfies all five, and AWS's own MWAA-versus-Step-Functions guidance assigns serverless operation and out-of-the-box AWS integrations to Step Functions. Why the traps lose: A delivers the human gate and DAG semantics but requires a managed Airflow environment that is billed whether or not it runs, the exact phrase the stem forbids; C gives no dependency graph, no per-step retries with backoff and no single execution history; D orchestrates only Glue jobs and crawlers and has no native human-approval construct. Trap: MWAA is the option candidates know best, and "Airflow" reads as "standard", but the superlative is LEAST overhead, which kills it on contact. Source: digest 15 Q04 and trap pair F2 · Step Functions choosing-workflow-type.html · re:Invent API307 Comparing Amazon MWAA and AWS Step Functions.

Teardown: Q5 · which limit binds. Why it is right: 25 minutes is 1,500 seconds, past the 900-second Lambda ceiling, and the workload is Spark, so Glue ETL is the managed, purpose-built fit. Why the traps lose: A is the designed distractor: 10,240 MB is within Lambda's memory range, so the option looks compliant, but duration is the limit that binds; B is a single-process runtime with no Spark, unable to run a distributed 40 GB DataFrame job; D also works technically but carries more operational surface than "MOST appropriate … fully managed" requires. Trap: candidates compare memory numbers and never convert 25 minutes into seconds: write the unit before comparing (distractor family T6). Source: digest 15 Q05 · Lambda gettingstarted-limits.html and configuration-timeout.html · Glue aws-glue-api-jobs-job.html, as of Oct 2026.

Teardown: Q6 · two levers, one bill. Why it is right: the before-cost is a full-table scan ($3 \times 5.00 = 15.00$ USD) and the after-cost is compression and column pruning together ($3 \text{ TB} \div 3 = 1$ TB, then $1 \div 3 \approx 0.33$ TB scanned, $0.33 \times 5.00 \approx 1.65$ USD); this is the worked example on AWS's own Athena pricing page. Why the traps lose: B applies compression but forgets column pruning (the 3:1 gain only); C uses the wrong before-cost, as if the source were already 1 TB; D multiplies instead of dividing: the classic "compression made it bigger" slip. Trap: the stem gives you three numbers (3 TB, 3 columns, 3:1) and only two of them multiply; decide which lever each number belongs to before you calculate. Source: digest 15 Q07, C12 and case D8 · aws.amazon.com/athena/pricing/ (verbatim worked example), as of Oct 2026.

Teardown, Q7 · wrong mechanism. Why it is right: streaming state is checkpointLocation plus watermarks; bookmark state is batch state keyed by job_name + transformation_ctx, two different mechanisms for two different failure modes. Why the traps lose: A is the single most reliable wrong-answer detector in Domain 1, "enable job bookmarks on the Kinesis job" is always wrong; C invents a mode (bookmark-PAUSE is a batch bookmark mode that holds state without advancing it) that does not apply to streams; D is irrelevant, since watermarking is not sink-specific. Trap: both mechanisms solve "do not reprocess", so the stem's streaming noun is the only discriminator, map noun to mechanism first (trap family T1). Source: digest 15 Q12 and trap pair F12 · Glue programming-etl-connect-streaming.html and monitor-continuations.html.

Domain 2: Data Store Management (26 %) · items 8 to 12

Teardown: Q8 · Select THREE, pre-combined. Why it is right: key/value at single-digit latency is DynamoDB's design point, petabyte columnar analytics is Redshift's, and serverless SQL billed per query over the lake is Athena's: the guide names exactly these services in skills 2.1.1 to 2.1.3. Why the traps lose: B wildly overstates Aurora's OLTP write throughput for a key/value pattern, confuses a stream (24-hour to 365-day retention, ordered, replayable) with a warehouse, and inverts the architecture: S3 holds the data, the Glue Data Catalog holds the metadata; C swaps in the wrong family three times (RDS is relational, EMR is a cluster, a crawler discovers schema rather than serving queries); D offers an in-memory store for a question about scale economics, a BI tool for a query engine, and a graph database for columnar analytics. Trap: every failing option is partly plausible; that is trap family T7, true-but-irrelevant, so judge each pairing independently instead of rating the option as a whole. Source: digest 15 Q15 · exam guide skills 2.1.1 to 2.1.3 · DynamoDB, Redshift and Athena product pages, as of Oct 2026.

Teardown, Q9 · the lifecycle delta. Why it is right: the saving is the price delta times the same bytes, $5{,}120 \times (0.023 - 0.0125) = 5{,}120 \times 0.0105 = \mathbf{53.76}$ USD per month. Why the traps lose: B subtracts a 0.0055 delta, which is One Zone-IA's rate leaked into the subtraction; C is the full Standard cost ($5{,}120 \times 0.023 = 117.76$ USD), not the saving; D uses decimal 5,000 GB and a 0.001 delta, two independent errors, which is how numeric-bait distractors are usually built. Trap: the transition-age gate into Standard-IA was removed on 2026-07-16, so a rule may transition at day 0, but the 30-day minimum storage duration (early-deletion billing) is a different rule and still applies. Source: digest 15 Q16, C13, C14 and trap pair F17 · aws.amazon.com/s3/pricing/ (binary GB-months), as of Oct 2026.

Teardown: Q10 · distribution, not ordering. Why it is right: collocating both sides on the join column removes the shuffle entirely, which is the documented star-schema rule: put the distkey on the largest dimension in the most common join, and mirror it on the fact. Why the traps lose: A leaves dim_customer needing broadcast or redistribution on every join; C copies a 50-million-row dimension onto every node, so storage multiplies by node count: DISTSTYLE ALL is reserved for genuinely small dimensions, which here is dim_product, not the fact table; D addresses scan order and filter skipping, not join collocation. Trap: two levers, two symptoms: DISTKEY fixes data movement, SORTKEY fixes scan skipping, and VACUUM/ANALYZE (the options you may be hoping for) fix unsorted rows and stale statistics, neither of which the plan complains about. Source: digest 15 Q17 and trap pairs F11 · Redshift c_choosing_dist_sort.html and t_designating_distribution_styles.html, as of Oct 2026.

Teardown, Q11 · Select TWO, pre-combined. Why it is right: both halves are published Iceberg capabilities, snapshot-based time travel, and v2 position/equality delete files with v3 deletion vectors and row lineage that simplify CDC-style updates. Why the traps lose: A is false twice, Athena, Spark, Trino and Redshift all read Iceberg, and the Glue Data Catalog is the standard catalog for Iceberg on AWS; B overstates (compaction of small files and delete files is still required) and adds the false ORC-only claim; D smuggles the false ORC-only half into an otherwise true pair, the classic structure of a multiple-response trap. Trap: open table formats became a named skill at guide v1.1 (2.1.7), so Iceberg mechanics such as snapshots, schema evolution and compaction are directly testable now; Parquet is the common choice, ORC is supported, and neither is mandatory. Source: digest 15 Q20 · Athena iceberg.html · exam guide skill 2.1.7, as of Oct 2026.

Teardown: Q12 · stale is allowed, seconds are required. Why it is right: up to 15 minutes stale licenses a precomputed result, and must return in seconds rules out recomputation: a materialized view with AUTO REFRESH YES is exactly that, and Redshift can transparently rewrite the dashboard query to use it. Why the traps lose: A pushes the load onto the operational database on every refresh, the opposite of the intent; C still scans Amazon S3 per query and is billed on bytes scanned, so it changes neither the latency nor the cost profile; D is a logical alias that recomputes every time. Trap: AUTO REFRESH defaults to NO, so the option that says "a materialized view" without the refresh setting is only half an answer, and note what a materialized view is not: a federated query reaches live RDS/Aurora with predicate pushdown and no copy, which is a different tool for a different stem. Source: digest 15 Q18 and trap pair F10 · Redshift materialized-view-overview.html and materialized-view-refresh.html, as of Oct 2026.

Domain 3: Data Operations and Support (22 %) · items 13 to 16

Teardown: Q13 · FIRST means fix the cause. Why it is right: the stem hands you the diagnosis in the logs (a second copy running concurrently), and AWS documents that bookmarks do not support concurrent runs, so the first step is to force serialization with MaxConcurrentRuns = 1. Why the traps lose: A changes throughput, not the concurrency guarantee; C masks the symptom and destroys incremental state, so the next run would reprocess everything: the opposite of the desired behaviour; D is a cost optimisation for non-urgent jobs with no effect on bookmark state. Trap: "reset the bookmark" is the remediation-shaped answer candidates reach for, but the stem's FIRST qualifier asks for the root cause, and a reset would reprocess the whole source. Source: digest 15 Q25 · Glue glue-troubleshooting-errors.html ("Currently AWS Glue bookmarks don't support concurrent job runs and commits will fail"), as of Oct 2026.

Teardown: Q14 · one signal per stage. Why it is right: every stage of this pipeline has exactly one metric that names its own failure: stream lag = GetRecords.IteratorAgeMilliseconds (AWS documents that a value of zero means the consumer has caught up), replication lag = DMS CDCLatencyTarget, concurrency starvation = Lambda Throttles. Why the traps lose: B offers three wrong answers: BucketSizeBytes is a once-a-day storage metric, NumberOfMessagesReceived is not a Glue metric, and Redshift CPUUtilization alone misses the queue-length signals that actually matter for a warehouse; C and D each smuggle one right pairing in with two wrong ones, which is how multiple-response traps are manufactured. Trap: alarm on the lag, not on the size, and note that a metric that exists is not automatically a pipeline-health metric. Live-exam form: three checkboxes, all-or-nothing. Source: digest 15 Q30 · CloudWatch metrics documentation for Kinesis Data Streams, DMS and Lambda, as of Oct 2026.

Teardown: Q15 · DPU-hours, not workers. Why it is right: Glue bills DPU-hours, so convert everything to hours first: $8 \times 0.5 = 4$ DPU-hours per run, $4 \times 0.44 = 1.76$ USD per run, $2 \times 31 = 62$ runs, $62 \times 1.76 = \mathbf{109.12}$ USD. Why the traps lose: B is one run per day ($31 \times 1.76 = 54.56$ USD); C doubles the schedule to four runs per day; D models the job running every hour of the month ($8 \times 0.44 \times 24 \times 31 = 2{,}618.88$ USD), an order-of-magnitude slip in the other direction. Trap: "4 × G.2X" already is 8 DPU (each G.2X is 2 DPU), so a candidate who multiplies by two again pays twice. Date-stamp the rate: $0.44 per DPU-hour was read from the Glue 3.0/4.0 ETL line in us-east-1 as of Oct 2026, and Glue 6.0 introduced a headline 30 % price reduction: verify the current rate card before you rely on any figure. Source: digest 15 Q28 and C7/C8 · aws.amazon.com/glue/pricing/ · Glue aws-glue-api-jobs-job.html, as of Oct 2026.

Teardown, Q16 · name the symptom, then the lever. Why it is right: EXPLAIN has already told you the symptom is data movement, and the lever that removes data movement is distribution, match the distkey on both sides of the join, or replicate a genuinely small dimension with DISTSTYLE ALL. Why the traps lose: A addresses unsorted rows and space reclamation; B refreshes statistics, worth doing, and it can change the plan choice, but it does not change the physical distribution; D speeds scans and filters on event_ts, not the join. Trap: all four options are legitimate Redshift maintenance commands, so this item is decided entirely by which symptom the stem names, DISTKEY fixes movement, SORTKEY fixes skipping, VACUUM fixes unsorted rows, ANALYZE fixes stale stats. Source: digest 15 Q31 and trap pair F11 · Redshift c-analyzing-the-query-plan.html and c_choosing_dist_sort.html, as of Oct 2026.

Domain 4: Data Security and Governance (18 %) · items 17 to 20

Teardown, Q17 · FIRST means close the open door. Why it is right: the default IAMAllowedPrincipals group holds Super on the databases, so the catalog is effectively governed by IAM alone no matter how many fine-grained grants you issue, removing that default (and disabling "Use only IAM access control") is the recommended Method 2 transition. Why the traps lose: B changes who can grant, not who can read; C is the incremental-migration state, not the end state, and does not remove the open access; D grants administration, and notably does not let the holder add further admins, without closing the catalog. Trap: candidates who have just learned Lake Formation grants assume the grants are broken; the grants are fine, the door is propped open. Note also that an IAM AdministratorAccess user is not automatically a data lake administrator, and Lake Formation permissions apply only in the Region where they were granted. Source: digest 15 Q35 and trap pair F7 · Lake Formation access-control-fine-grained.html and lf-permissions-reference.html, as of Oct 2026.

Teardown: Q18 · two doors, both must open. Why it is right: Lake Formation permissions and IAM permissions are two doors, and Amazon Athena documentation states verbatim that anyone querying Lake Formation-registered data must have an IAM policy allowing lakeformation:GetDataAccess: plus the LF grant must sit on the resource the query actually reads. Why the traps lose: B offers an account-level S3 listing permission and a networking control, neither of which is authorization for a cataloged table; C destroys least privilege and still would not substitute for the grant semantics, since an IAM administrator is not automatically a data lake administrator; D adds more S3 data-plane actions and changes engine, which does not open either door. Trap: the stem says the analyst already has athena:* and already has an LF SELECT, so candidates conclude "permissions are fine": the missing action is a third door that only Athena questions test. Source: digest 15 Q34 and C19/C22 · Athena lf-athena-user-permissions.html · Lake Formation lf-permissions-overview.html, as of Oct 2026.

Teardown: Q19 · three constraints, one answer. Why it is right: a key the company controls requires a customer managed KMS key; auditable per principal requires KMS's per-caller CloudTrail records, which SSE-S3 cannot produce; a partner account must read requires a key policy grant, and the S3 Bucket Key trims the per-request KMS charge (up to 99 %) without weakening any of the three. Why the traps lose: A is free and is the default since 2023-01-05 (SSE-S3, AES-256-GCM, no fee) but offers no key control, no key-usage audit trail and no cross-account key policy; C makes the customer hold the key: a forgotten key means permanent data loss, and there is no audit of who used it; D is unmanaged and unauditable at the service layer. Trap: candidates stop at "encrypted at rest" and pick the default; the stem's second and third constraints are what force SSE-KMS with a CMK. Source: digest 15 Q37 and C24 · S3 UsingKMSEncryption.html and bucket-key.html · KMS control-access.html, as of Oct 2026.

Teardown, Q20 · who called it. Why it is right: the question is about an API identity, and CloudTrail is the service that records who called which API on which resource, Glue additionally exposes table-version history, which answers what changed, but the auditor asked for the principal. Why the traps lose: B covers object-level S3 operations, not catalog DDL; C discovers sensitive content and reports findings, it never records catalog API calls, and Macie never remediates; D records network flows, not API identities. Trap: three of the four options are real evidence sources that answer a different question, that is trap family T7, true-but-irrelevant. If the auditor had asked what the table looked like before, the answer would shift to Glue table versioning. Source: digest 15 Q40 and trap pair F8 · Glue cloudwatch-cloudtrail-integration.html · CloudTrail User Guide, as of Oct 2026.

Extension items 21 to 22: built from the Real-World Case Drills

These two do not count toward Set A's 20-item clock. Sit them after you have graded Set A, two minutes each, same rules: no notes, no teardown, one-clause reason for any change. They exist to prove that a published customer story can be converted into a markable stem.

Teardown, Q21 · replay lives in the stream, not the delivery. Why it is right: two qualifiers, replay 24 hours (retention plus a consumer API) and the delivery (Firehose), and only the feeding stream satisfies them: Kinesis Data Streams keeps records 24 hours to 365 days and replays via a new shard iterator. Why the traps lose: A invents a consumer API that Firehose does not have; C confuses the buffer interval, which decides when data lands in S3, with retention, two unrelated meters (trap family T6, wrong unit attached to a true fact); D dresses the same false API in encryption clothing. Trap: Firehose "already holds the data in S3" is true and irrelevant, the S3 copy is a backup you can reprocess with a new job, not a replay affordance that re-runs the consumer's logic (trap family T7). Source: digest 16 case material (AGCO, A7/A8) and trap F2 · digest 18 trap 1 · digest 15 Q02 · Firehose FAQs, as of Oct 2026.

Teardown: Q22 · mechanism beats headline. Why it is right: both halves are published mechanics of the customer build: database-level tags inherited by tables and columns (that inheritance is why the rule count fell to two) and S3 reached only through a Lake Formation data access role (the second door). Why the traps lose: B is wrong twice: Lake Formation permissions are Region-local (an "applies account-wide" grant is a fiction), and IAM alone never opens the catalog-and-data door; C inverts the story (per-table grants are the old pain the tags removed) and hands enforcement to Macie, which discovers and reports content and never remediates; D reverses inheritance and deletes the IAM door, including lakeformation:GetDataAccess, which Amazon Athena explicitly requires. Trap: the stem hands you the customer's impressive outcome, so you hunt for the result: the mark is in the mechanism. Live-exam form: two checkboxes, all-or-nothing, no partial credit. Source: digest 16 case study 9 (IAS, A13) and traps F3/F4/F8 · digest 18 trap 7 · Athena lf-athena-user-permissions.html, as of Oct 2026.

• 📚 Did you know? The Official Practice Question Set that AWS offers for DEA-C01 contains exactly 20 questions, the same count as Set A here, is free, aligns with the current exam guide, and lives on Skill Builder. It is the first thing AWS's own four-step prep plan asks you to take, alongside the free Exam Demo for the interface. If Set A felt long, that is useful information about your pacing; if it felt short, take the official 20 next.

---