AWS Data Engineer Associate: Exam Tips and real life scenarios
Golden Jacket Field Notes . Week 20
Series: Golden Jacket Field Notes (22 articles)
- …
- 21AWS Data Engineer Associate: Exam Tips and real life scenarios This article
I passed the AWS Certified Data Engineer Associate in the second half of last year with one minute left on the clock. Not the standard clock. I sit exams with the ESL (English as a Second Language) accommodation, which gives thirty extra minutes to candidates whose first language isn’t English, so I had a hundred and sixty minutes for sixty five questions and I used a hundred and fifty nine of them. My last memory of that exam is watching the timer while I reread a flagged question and deciding that whatever I’d picked was going to have to be enough.
Six months went into that minute. Five hours a night, most of them past midnight, because that’s when the house is quiet. Video theory to build the map. Practice exams to find out where the map was wrong. Labs, a lot of labs, because reading about a Glue job that dies halfway through a partition rewrite teaches you nothing about what that failure looks like when it happens. And conversations with people who run data platforms for a living, asking what their week actually contains. That last part corrected more of my answers than any course did.
People ask me for tips on this exam more than any other Associate, and my honest answer keeps disappointing them, because the tips that matter aren’t about which services to memorize. They’re about how the questions are built and what they’re really asking. So this week I wrote them down.
The problem
There’s a way of preparing for this certification that feels productive and fails, and I recognize it because it was my first instinct too.
You study it as a service exam. Build the comparison table. Glue against EMR against Lambda for transformation. Kinesis Data Streams against Amazon Managed Streaming for Apache Kafka for ingestion. Redshift against Athena for query. Learn which one is serverless, which one bills per hour, which one has a fifteen minute ceiling. Drill the table until it comes back instantly. Then sit down and get taken apart by a question that hands you a fifteen line scenario about a nightly job that reprocesses records after a retry, and asks what you’d change.
The table doesn’t answer that question. Idempotency answers that question, and idempotency isn’t an AWS service. Neither is partition strategy, schema evolution, or the decision about whether late arriving data updates the original partition or lands somewhere else for correction. The exam is full of those, and they all show up wearing service names.
I did the wrong version of this for about two months. My practice scores were solid on anything that named a service and asked for a property of it, and they fell apart on anything that described a pipeline and asked for a judgment. Strong on the half of the exam that rewards memory. Weak on the half that rewards having built something and watched it break.
What fixed it was breaking things on purpose. Feed a Glue job a file with a changed schema and watch what the Data Catalog does with it. Kill a consumer mid stream and find out what replay actually returns. Run the same Step Functions execution twice and count your rows. Every one of those gave me an intuition that a question later paid for, and none of them came from a slide.
The cost of getting this wrong looks small at first. A failed attempt is the exam fee again plus a fourteen day wait. The expensive version is the person who passes on memorization, joins a team, and inherits a pipeline that quietly double counts revenue for three weeks before anyone downstream notices. That meeting doesn’t end with a debate about which service was chosen. It ends with someone asking whether the team understood what exactly once meant when they built it.
Why this matters beyond the specific case
AWS retired the Data Analytics Specialty on April 9, 2024 and launched the Data Engineer Associate in the same movement.
Sit with that for a second. A specialty credential got replaced by an associate one. Normally that signals a body of knowledge becoming less specialized. Here it signaled the opposite: the job role got common enough that AWS wanted it at the associate tier, where the volume is, and the specialty framing had started getting in the way.
That decision shapes the exam you sit today. It was built against a job role instead of a service portfolio, and you feel the difference in every scenario question. AWS didn’t ask what a data engineer should know about Glue. They asked what a data engineer does on a Tuesday, then wrote questions about that using whatever services fit. Look at the target candidate description and you’ll find two to three years of data engineering experience against one to two years of hands on AWS. Read that ratio again. It’s the entire study strategy in one line. AWS expects you to show up with more data engineering than AWS.
Which is also why the preparation travels so well. Most AWS exams teach you AWS. This one makes you learn partitioning, schema evolution, delivery semantics and data modeling, then checks whether you can say those decisions out loud in AWS vocabulary. Prepare properly for the DEA-C01 and you walk away better at data engineering everywhere, including on platforms that have nothing to do with Amazon. I haven’t found another AWS certification where that’s as true, and I hold all of them.
Technical deep dive
Everything below comes from the published exam guide, from my own preparation, and from watching where my practice scores actually moved. I don’t describe a single real exam question here, and nobody writing about a certification should. The patterns are public. The questions aren’t.
Find the qualifier before you look at the options
This was the highest return habit I built. Nothing else moved my practice scores as much.
Almost every scenario question carries one phrase that decides the answer by itself. Least operational overhead. Most cost effective. Near real time. Minimal changes to existing code. Highest durability. That phrase is the question. Everything in front of it is scenery.
Here’s why it bites so hard on this exam specifically. The distractors were written by people who know the material, so two options are frequently correct as architecture. Both would work. Both would ship on a Monday and still be running on Friday. Only one satisfies the qualifier. Read the options before you’ve locked the qualifier in your head and you’ll recognize a design you like, feel that small chemical hit of recognition, and pick it. You’ll have solved a problem nobody asked about.
The mechanic I settled on: read the last sentence of the stem first, find the qualifier, say it silently, then read the scenario from the top holding that phrase. Costs about eight seconds. Completely changes what you notice on the way through.
Watch especially for qualifiers that are operational instead of technical. Least operational overhead is the most common one in this exam, and it consistently favors managed and serverless options over anything you have to size and tune yourself. When you see it, the right answer usually has fewer moving parts than the thing you’d have built by hand. That stings a little, and it’s correct.
The distractors are usually the right service in the wrong layer
See this once and you can kill two options on most questions without knowing the answer.
Wrong options in this exam are rarely absurd. They’re a legitimate AWS service sitting one layer away from where the scenario needs it. Streaming ingestion where the scenario describes a batch window. A delivery service where the question requires reprocessing history from a point in time. A compute option whose maximum execution duration is shorter than the job being described. A query engine dropped into a transformation problem.
So ask what layer the question lives in before you evaluate anything. Ingestion, storage, transformation, orchestration, query, governance. Then throw out everything belonging to a different layer, no matter how good it looks sitting there. Two options usually die on the spot. And a fifty fifty on an exam with compensatory scoring is a completely different situation from a blind guess among four.
Know these pairs cold. Cold enough to state the boundary in one sentence without pausing to think. Streams against delivery for ingestion. Serverless transformation against managed cluster transformation. Warehouse against lakehouse query. Workflow orchestration against event routing. Get those four and you’ve covered most of the elimination work the exam will ask of you.
Spend your study time where the weight is
The exam guide publishes the weightings. Most candidates read them once and then study evenly anyway.
Domain 1, Data Ingestion and Transformation, is thirty four percent of scored content. Domain 2, Data Store Management, twenty six. Domain 3, Data Operations and Support, twenty two. Domain 4, Data Security and Governance, eighteen.
Domains 1 and 2 are sixty percent of your score between them. Your study time is limited, it always is, and that’s where it goes.
The scoring model makes this safe. The exam is compensatory, so you don’t need to pass each domain individually, only the exam as a whole. A candidate who’s strong in ingestion and transformation and merely competent in governance passes comfortably. A candidate who spread the time evenly and came out merely competent everywhere is sitting much closer to the line than they think.
I’d still study Domain 4 properly, for a different reason. Encryption, access control and lineage questions tend to be the cleanest on the exam, because governance has fewer defensible answers than architecture does. Fast points for the hours you put in.
Learn the concepts that decide questions, because none of them are services
This is the tip I wish somebody had handed me on day one. It’s where I lost two months.
A recurring set of data engineering concepts decides a big share of the scenario questions. Not one of them is an AWS service. You can’t flashcard your way there.
Idempotency and replay. What happens when the same record shows up twice, when a job retries after a partial failure, or when you need to reprocess three days of history without wrecking what’s already sitting in the table. This shows up constantly, and it’s completely invisible to you if you’re studying service properties.
Delivery semantics. At least once against exactly once, what each one costs you, and which one a given design actually delivers regardless of what the team believes it delivers.
Partitioning strategy. How partitions drive query cost and scan volume. What happens when your partition key has low cardinality. What happens when it has such high cardinality that you’ve traded one problem for the small files problem.
Schema evolution. What happens to a catalog and to everything downstream when a column changes type, when a field appears, when a field disappears. Open table formats matter here, and Apache Iceberg entered the guide explicitly in the December 2025 revision.
File format and compression. Columnar against row oriented, and why the answer to a cost question is so often a format change rather than a service change.
Late arriving and out of order data. Does it update the original partition, land in a correction path, or get dropped. Each choice moves the numbers a business user sees, and somebody eventually asks why.
Reason through those six from first principles and the AWS layer becomes vocabulary instead of knowledge. Fail to, and no amount of service memorization saves you, because the exam keeps asking about them in AWS clothing.
Break things in the lab on purpose
Passive labs teach you the happy path. The exam is mostly about what happens when the happy path doesn’t hold.
The labs that changed my answers were the ones where I caused the failure myself. Change the schema of an incoming file and watch what the Glue Data Catalog decides to do about it. Kill a stream consumer mid processing and find out what replay actually returns, and from where. Run the same orchestration twice and count your rows, then go hunting for the duplicates you just created. Write ten thousand tiny files into a partition and query it, so the small files problem arrives as query latency instead of as a sentence in a blog post.
Every one of those bought me an intuition that a question later paid out on, and every one takes under an hour. Keep them cheap and tear them down when you’re finished, because leaving a cluster running while you study is exactly how a certification turns into a line item somebody makes you explain.
Two minutes a question, and a plan for when a scenario runs long
A hundred and thirty minutes for sixty five questions. Two minutes each. Fifty of those questions are scored and fifteen are unscored items AWS uses to evaluate future content, and you can’t tell which is which, so treat every one as scored.
Two minutes is fine for most questions. It isn’t fine for the long ones, and this exam has long ones. Scenarios in Domains 1 and 2 sometimes run a full screen of context before they get to the actual ask. Burn six minutes on one of those and you’ve quietly stolen the time from three questions you knew.
Flag and move. Decide your ceiling before you sit down, mine was around three minutes, and when a question crosses it you mark your best current option, flag it, and go. Unanswered questions score as incorrect and there’s no penalty for guessing, so nothing gets left blank when you move on. Answer first, then flag.
If English isn’t your first language, look into the ESL accommodation before you schedule anything. It adds thirty minutes, which turns two minutes per question into roughly two and a half, and on an exam built out of long scenarios that margin is real. I used it and still finished with one minute on the clock. My understanding is that the request has to go in before you book, and that it’s handled inside your AWS Certification Account, but the process has moved around over the years. Confirm the current flow there rather than trusting any blog post, this one included.
One more thing from the official exam page that catches people at the desk. The exam uses short names for some AWS services, and a list mapping short names to full names sits behind the Help button during the exam. Knowing that button exists before exam day is worth more than it sounds.
Study the current exam guide, because it changed in December 2025
Shortest shelf life of any tip here. Highest cost if you skip it.
The DEA-C01 exam guide moved to version 1.1 on December 12, 2025. AWS publishes revisions roughly a month before they show up on live exams, so my reading is that the new content started appearing around January 2026. I sat the exam under version 1.0 in the second half of last year. Everything I’m about to say about the new material comes from reading the revisions page closely, not from having faced it, and I’d rather tell you that than let you assume field experience I don’t have.
What changed is enough that older study material is now incomplete. The new skills include integrating Large Language Models for data processing, managing open table formats such as Apache Iceberg, describing vector index types such as HNSW (Hierarchical Navigable Small World) and IVF (Inverted File), describing vectorization concepts through Bedrock knowledge bases, creating and managing business data catalogs with Amazon SageMaker Catalog, and using domains, domain units and projects in Amazon SageMaker Unified Studio. The target candidate description now lists general concepts of vectors as expected general IT knowledge, sitting there next to networking, storage and compute.
Services added to the in scope list: Amazon Aurora, Amazon Q, Amazon Bedrock, Amazon Kendra, AWS Data Exchange, Amazon S3 Tables. Services removed: AWS Cloud9, AWS CodeCommit, AWS Schema Conversion Tool.
Practically, a course recorded in 2024 or early 2025 is missing a real slice of the current blueprint, and the missing slice happens to be the part everyone finds most intimidating. That doesn’t make it a machine learning exam. The guide still puts ML training and inference explicitly out of scope for the target candidate, and the new skills are worded as describe and integrate rather than build and tune. My read: know what a vector index is, know why HNSW and IVF sit at different points on the recall against speed tradeoff, know where vectorization fits into a pipeline. You don’t need to implement one.
Let the in scope list decide what you ignore
The exam guide publishes an in scope service list and an out of scope service list. Most candidates never open either one. They’re the cheapest study tool in the entire preparation.
The in scope list is your boundary. Service isn’t on it, service doesn’t get your hours. AWS states the list is non exhaustive and subject to change, so treat it as a strong prior rather than a promise. As a prior it’s excellent.
The out of scope list is more useful than it looks, because it shows you where AWS drew the line for this role. AWS X-Ray is out. CloudWatch, CloudWatch Logs, CloudTrail and AWS Config are in. That’s a statement about what observability means for a data engineer in AWS’s model: pipeline monitoring, audit trails, configuration history, and no distributed application tracing. The questions follow that line.
What the official documentation does not tell you
The compensatory scoring model gets read backwards. Candidates hear that you don’t need to pass each domain and conclude that weakness is fine everywhere. What it actually buys you is permission to be strong somewhere specific. Fifty scored questions across four domains means Domain 4 carries roughly nine of them. Nine. You can hand back most of that domain and still walk out certified, provided you’re genuinely strong in the sixty percent that lives in Domains 1 and 2. Spread yourself evenly and you get the opposite: no domain where you’re recovering points, and a final score that lands wherever the question mix decides to put it.
Fifteen of your sixty five questions are AWS doing research on you. The guide states it plainly and almost nobody adjusts for it. Nearly a quarter of your exam is unscored item development, and you can’t tell which quarter. Here’s the part that matters on the day. When a question arrives that feels off blueprint, oddly worded, or harder than everything around it, there’s a real chance you’re looking at an experimental item that may never become a scored question. Answer it, flag it, leave. Letting one strange question shake your confidence for the next ten is the actual cost, and it’s entirely avoidable once you know the fifteen exist.
The section level feedback on your score report is too noisy to rebuild a study plan on. AWS says to interpret it with caution and then everyone ignores that sentence. Do the arithmetic. A Needs Improvement rating in Domain 4 was calculated from around nine scored items. Miss four of them and you get flagged. Miss four out of nine on a topic you actually know because two were badly worded and two were experimental, and you’ll go rebuild an entire month of study around a signal that was mostly variance. If you fail and retake, weight your own practice exam data above the score report. You have more items in it.
The out of scope job tasks are the sharpest boundary in the whole document, and they sit above the domains where nobody looks. Three lines: the target candidate is not expected to perform ML training and inference, is not expected to know programming language specific syntax, and is not expected to draw business conclusions from data. That third one is worth real points. When an option asks you to interpret what the data means for the business, it’s wrong, every time. That’s an analyst’s job and AWS has said so. The second line saves you weeks of misdirected panic, because candidates keep grinding Python syntax for an exam that has explicitly told them it won’t ask.
The skills name services the in scope list never mentions. Amazon SageMaker Unified Studio appears in three separate skill statements in version 1.1 and doesn’t appear in the service list at all. So don’t treat absence from the list as absence from the exam when a skill calls the service out by name. The list is a filter for what to ignore. It isn’t a complete inventory of what can appear, and the guide admits as much by calling itself non exhaustive.
General concepts of vectors was filed under general IT knowledge, not under AWS knowledge. That placement is the loudest thing in the December revision and it’s a single line in a section most people skim. AWS put vectors next to networking, storage and compute as baseline literacy for the role. Not as an AWS service you should recognize. As something a data engineer is now assumed to understand before the AWS conversation starts. I read the blueprint of the Generative AI Professional exam back in Week 8 and made a similar argument about where that certification was pointing. This one is quieter and says more, because it’s an associate level exam for a role that existed long before any of this.
There’s a window where the guide and the exam disagree with each other. AWS publishes revisions roughly a month before they show up on live exams. Straightforward until you’re the person sitting the exam inside that month, studying a guide that describes content you won’t be tested on, or worse, sitting it a week after the cutover with material built for the old version. Check the revisions page and the publication date before you book. If a revision just dropped, you’re either taking it fast on the old blueprint or waiting and studying the new one properly. Splitting the difference is how you end up preparing for two exams and passing neither.
The bigger picture
Certifications are a lagging indicator, which is exactly why they’re worth reading closely. AWS doesn’t build an exam for a job that might exist. They build it for one that already does, after enough customers hired for it that the pattern is undeniable. So the blueprint tells you what the market did about eighteen months ago, with more precision than any survey.
Read the DEA-C01 that way and it says something uncomfortable for people on both sides of the data fence.
The specialty got retired and the role moved down to associate. That’s AWS saying data engineering stopped being a specialization and became infrastructure. Not less valuable. More common, more expected, more assumed. The same thing happened to networking twenty years ago, and nobody would claim networking got easier. It got baseline.
Then December 2025 pushed vectors, Iceberg and Bedrock into the same exam. Put those two movements next to each other and you get the actual signal: the data engineer is now the person who builds the foundation that GenAI workloads stand on. Every retrieval system I’ve reviewed that failed in production failed on ingestion, chunking, permissions at the source, or a catalog nobody maintained. None of them failed on the model. I wrote most of Week 1 about exactly that.
So the career implication runs against the current advice. People are leaving data engineering for machine learning roles because that’s where the noise is. The blueprint says the value went the other way. AWS just declared that knowing what a vector index does is baseline literacy for a data engineer, and simultaneously declared that training and inference are out of scope for that same person. Read those two together. The job isn’t to build the model. The job is to own everything the model depends on, which is most of what determines whether it works.
That’s a better position than it sounds. Model choice churns every six months. Partition strategy doesn’t.
Takeaway
Find the qualifier before you read the options. Kill the distractors that sit in the wrong layer. Put sixty percent of your hours into Domains 1 and 2 and let the compensatory model carry Domain 4.
Study the concepts, since none of the ones that decide questions are AWS services. Break things in a lab on purpose, because the exam lives in the failure path.
And open the revisions page before you buy a course. The exam changed in December 2025 and a lot of material out there still hasn’t.
I keep coming back to one thing I can’t settle. This certification made me better at data engineering in general, more than any other AWS exam made me better at its subject. I don’t know whether that’s a deliberate design choice by the team who wrote it, or a side effect of building an exam for a role that existed long before AWS did. If you were involved in writing it, or you’ve prepared for both this and a vendor neutral data engineering certification, I’d like to know which one you think it is.
References
- AWS Certified Data Engineer Associate (DEA-C01) Exam Guide , the domain weightings, the scoring model, and the out of scope job tasks that most candidates skip
- Revisions , where version 1.1 and its December 12, 2025 publication date live, with the new skills listed line by line
- In-Scope AWS Services , the filter that decides what you can safely ignore
- Out-of-Scope AWS Services , including the observability boundary for this role
- AWS Certified Data Engineer Associate certification page , exam duration, format, languages, and the short name mapping behind the Help button
- AWS Certification retirements and launches , the Data Analytics Specialty retirement and the reasoning AWS gave for it
About the author
I am an AWS Solutions Architect with almost 15 years in cloud, focused on production ML and GenAI workloads for regulated organizations. I hold every active AWS certification, including the Generative AI Developer Professional as an Early Adopter, the status AWS calls Golden Jacket. I am the sixth Brazilian Golden Jacket holder according to the Awstronauts list, and co-founder of Golden Jackets Brazil.
- Medium: medium.com/@erickmancz
- LinkedIn: linkedin.com/in/erick-mancz
- AWS Builder Center: builder.aws.com/profiles/imancz
- Credly: credly.com/users/erick-mancz.66783c3e
- Golden Jackets Brazil: goldenjacketsbrazil.com
Golden Jacket Field Notes is a weekly practitioner series. No re:Invent recaps. No tutorials. Field notes from workloads where outages, audit gaps, and cost surprises are not tolerated. The full index lives at golden-jacket-field-notes .
Series: Golden Jacket Field Notes (22 articles)
- …
- 21AWS Data Engineer Associate: Exam Tips and real life scenarios This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article