The AWS Certified Developer - Associate (DVA-C02) validates that you can build, deploy, and debug cloud-native applications on AWS. Where the Solutions Architect exam asks how you would design a system, the Developer exam asks how you would build and ship the code that runs on it. The questions lean heavily on serverless (Lambda, API Gateway, DynamoDB), on security inside application code (IAM roles, Cognito, KMS, secrets management), and on automated deployment (the CI/CD and infrastructure-as-code tooling). The single most effective way to prepare is to build a small serverless application yourself, because the exam consistently tests how the services fit together rather than what they are in isolation. This guide is a full self-study course organised around the four official domains. It explains the concepts, shows where developers most often lose marks, and turns the material into a plan. It is original teaching material only. It contains no real or simulated exam questions, and you should confirm the current weights and rules against AWS’s own Developer Associate exam guide before booking.
Chapter 1: Exam overview and how to use this guide
What the Developer Associate measures
The Developer Associate measures whether you can develop, deploy, and maintain applications on AWS using AWS services and good cloud-native patterns. AWS recommends roughly a year of hands-on experience developing and maintaining AWS applications before attempting it, and that recommendation is a useful signal of the level: this is an intermediate exam that assumes you already write code, not a beginner’s tour. The most important planning fact is the domain split. AWS organises the scored content into four domains with fixed weights: Development with AWS Services at 32%, Security at 26%, Deployment at 24%, and Troubleshooting and Optimization at 18%. Those weights tell you where your hours belong. Development and security together are nearly 60% of the exam, so they deserve the lion’s share of your time, but deployment is close behind and is where many developers are weakest, so do not let it slide.
The exam is 65 questions in 130 minutes, delivered as multiple-choice (one correct answer) and multiple-response (select two or more) questions. Only 50 of the 65 are scored; the other 15 are unscored questions AWS is trialling, and they are not identified, so you answer every question as if it counts. Results are reported as a scaled score from 100 to 1,000, and the pass mark is 720. Because the score is scaled, do not try to translate 720 into a fixed percentage of correct answers; aim instead to be answering confidently across all four domains.
Why hands-on experience is the fastest route
Most questions are scenarios: a short description of an application requirement or a failure, followed by a question about which service, configuration, or pattern fits. That style rewards developers who have actually wired these services together and punishes pure memorisation, because the distinguishing detail is often something you only internalise by building (how a Lambda function gets its permissions, why a queue needs idempotent consumers, which deployment service rolls back on failure). Throughout this course the emphasis is on those connections and the reasoning behind them.
How to use this course
Read the chapters in order. Chapter 2 covers the development domain that anchors everything, Chapter 3 covers security as it applies to running code, Chapter 4 covers deployment and infrastructure as code, and Chapter 5 covers troubleshooting and optimisation. Chapter 6 lays out the one project worth building, Chapter 7 turns the content into a timeline, and Chapter 8 describes final preparation and exam day. The bold terms are a checklist: by the end you should be able to explain each in a sentence and say when you would use it. Short worked examples appear where a concept is easy to misread, but none of them are exam questions.
Chapter 2: Development with AWS Services (32%)
This is the largest domain, and it is the heart of the exam: writing application code that uses AWS services well, with a strong bias toward serverless and event-driven designs. The goal is to understand how the core services behave from a developer’s point of view, including their limits and their failure modes, because that is what the scenarios probe.
Lambda, the centre of gravity
AWS Lambda runs your code in response to events without you managing any servers, and it is the single most important service on this exam. As a developer you need to understand its model rather than just its name. A Lambda function has a handler that receives an event and a context, a configured memory allocation (which also scales CPU), and a timeout after which it is stopped. It is billed for the time it runs, rounded to the millisecond. Two behaviours come up repeatedly. The first is the cold start: when a new execution environment is initialised there is extra latency, which you reduce by keeping initialisation code outside the handler and, where it matters, by using provisioned concurrency. The second is concurrency itself: Lambda scales by running many environments in parallel, and you can set reserved or provisioned concurrency to control that. You should also know how a function gets its permissions, which is through an execution role (an IAM role) rather than embedded keys, and how it reads configuration, typically through environment variables. As a teaching example of the model in action: code that opens a database connection should do so during initialisation, outside the handler, so the connection is reused across invocations on a warm environment rather than re-created on every call.
API Gateway in front of your code
Amazon API Gateway is how you expose your functions and services as HTTP or REST APIs. From a developer’s view, the points that matter are how requests reach your backend (a common pattern is Lambda proxy integration, where the whole request is passed to the function and the function returns the whole response), how you control access (API keys and usage plans for throttling, plus authorizers for authentication), and how you manage versions through stages. You should recognise that API Gateway can handle request validation, throttling, and caching, so not every concern needs to live in your function code.
DynamoDB, known cold
Amazon DynamoDB is the NoSQL database the exam expects you to know in genuine depth, more than any other data store. Start with the key model. Every item has a partition key that determines which physical partition stores it, and optionally a sort key that orders items sharing a partition key; together they form the primary key. Good design spreads data evenly across partition keys to avoid a hot partition. To support queries beyond the primary key you add indexes: a Global Secondary Index (GSI) allows a different partition and sort key and has its own capacity, while a Local Secondary Index (LSI) shares the partition key but allows a different sort key and must be created with the table. For throughput you choose between on-demand capacity (which scales automatically and suits unpredictable load) and provisioned capacity (which you size yourself, optionally with auto scaling, and which can be cheaper for steady load); exceeding provisioned capacity causes throttling, which well-written clients handle with retries. Know also that DynamoDB Streams emit a change log other services can react to, that DAX is an in-memory cache for read-heavy workloads, and that operations come in two flavours: a Query (efficient, uses the key) versus a Scan (reads the whole table and should be avoided at scale). The recurring exam instinct is to design around access patterns and the key schema rather than treating DynamoDB like a relational database.
S3 and the other building blocks
Amazon S3 is the object store you use for assets, uploads, backups, and static content, and developers should know features like presigned URLs (which grant temporary, scoped access so a client can upload or download directly without proxying through your code), event notifications (which can trigger a Lambda function when an object is created), and versioning. Beyond these, the development domain expects fluency with the AWS SDK as the way applications call AWS from code, and with the event-driven and decoupling services: Amazon SQS for message queues, Amazon SNS for publish/subscribe fan-out, and AWS Step Functions for orchestrating multi-step workflows as state machines. The pattern the exam rewards is loose coupling: components communicate through queues, topics, and events so they can fail and scale independently.
Event-driven thinking
Pulling the domain together, the strong developer answer is almost always the event-driven, serverless one. When a scenario describes work that should happen in response to something (a file uploaded, a message received, a record changed), the expected design connects services through events rather than tightly coupling them with synchronous calls. Holding that instinct, plus a solid grasp of Lambda and DynamoDB, carries a large share of this domain.
Chapter 3: Security (26%)
This domain is about securing applications, and it is sizeable. The recurring themes are granting code exactly the permissions it needs and no more, authenticating the users of your application, protecting data with encryption, and storing secrets safely rather than in code. Nearly every security question reduces to one of those four ideas.
IAM for application code
AWS Identity and Access Management (IAM) is the foundation, and the developer-specific point is that code should obtain permissions through IAM roles, which provide temporary, automatically rotated credentials, rather than through long-lived access keys embedded in source or configuration. A Lambda function uses an execution role; code on an EC2 instance uses an instance profile; one service assumes a role to act with another’s permissions. IAM policies define what is allowed, and the principle the exam insists on is least privilege: grant only the specific actions on the specific resources the code actually needs. As a teaching example of the anti-pattern the exam wants you to reject: hard-coding an access key and secret into a deployment package is wrong on two counts, because the credentials are long-lived and because they leak with the code; the correct design attaches a narrowly scoped role instead.
Authenticating users with Cognito
Where IAM governs your own and your services’ access, Amazon Cognito handles the identity of your application’s end users. A user pool is a directory that manages sign-up, sign-in, and tokens for your users, while an identity pool grants those users temporary AWS credentials to access AWS resources directly. The distinction is worth holding clearly: a user pool is about authenticating people into your app, an identity pool is about giving authenticated people scoped access to AWS services. Recognising which one a scenario needs is a common question.
Encryption and key management
The exam expects you to know that data should be encrypted at rest and in transit, and that AWS KMS (Key Management Service) manages the encryption keys. From a developer’s view, the useful concepts are the difference between an AWS managed key and a customer managed key (the latter giving you control over rotation and policy), and the idea of envelope encryption, where KMS protects a data key that in turn encrypts your data, which is how large payloads are encrypted efficiently. You should know that many services integrate with KMS so that enabling encryption is largely a configuration choice, and that the developer’s job is mainly to choose the right key and grant access to it correctly.
Storing secrets, not hard-coding them
Application secrets such as database passwords and API keys must not live in code, and AWS offers two services the exam contrasts. AWS Secrets Manager stores secrets and can rotate them automatically, which suits credentials that should change on a schedule. AWS Systems Manager Parameter Store stores configuration and secrets too, with a free tier for standard parameters, and is often used for general configuration. The simple decision rule the exam rewards: reach for Secrets Manager when automatic rotation of credentials matters, and Parameter Store for general configuration and simpler secret storage. Either way, the code retrieves the value at runtime rather than carrying it in the deployment package.
Chapter 4: Deployment (24%)
This domain is about getting code from a repository into running infrastructure reliably and repeatably, and it is the area where many developers, comfortable with writing code but less so with pipelines, lose the most marks. It splits into two parts: the CI/CD tools that automate build and release, and infrastructure as code that defines the resources themselves.
The CI/CD toolchain
AWS provides a family of developer tools, and the exam expects you to tell them apart by their job in a pipeline. AWS CodeBuild compiles source, runs tests, and produces deployable artifacts, driven by a buildspec file. AWS CodeDeploy deploys those artifacts to compute targets such as EC2, Lambda, or ECS, and it controls how the rollout happens. AWS CodePipeline orchestrates the whole flow, chaining source, build, test, and deploy stages together. (You may also see CodeCommit as a Git repository and CodeArtifact for package management.) The most common confusion the exam exploits is between CodeBuild and CodeDeploy, so anchor it firmly: CodeBuild builds and tests, CodeDeploy deploys, and CodePipeline coordinates the stages.
Deployment strategies
CodeDeploy supports different rollout strategies, and the exam tests when each fits. An in-place deployment updates the existing instances, while a blue/green deployment stands up a new set, shifts traffic to it, and lets you roll back by shifting traffic back, which minimises downtime and risk. For traffic shifting, especially with Lambda and ECS, you should recognise canary (shift a small percentage first, then the rest) and linear (shift in equal increments over time) as ways to limit the blast radius of a bad release, with all-at-once being the fastest but riskiest. As a teaching example of matching strategy to requirement: a scenario that demands the ability to roll back instantly with no downtime points toward blue/green, whereas one that wants to expose a new version to a little real traffic before committing points toward a canary shift.
Infrastructure as code: SAM and CloudFormation
AWS CloudFormation defines AWS resources declaratively in a template, so an entire environment can be created, updated, and deleted reproducibly as a stack. AWS SAM (Serverless Application Model) is an extension of CloudFormation tailored to serverless applications, with shorthand syntax for functions, APIs, and tables, plus a local testing and packaging workflow through the SAM CLI. The point the exam rewards is understanding that these tools make deployments repeatable and version-controlled, and that SAM is the serverless-focused, more concise way to express the same idea. You should recognise core CloudFormation mechanics at a high level, such as parameters for inputs, outputs for exported values, and change sets for previewing updates, without needing to author complex templates from memory. AWS Elastic Beanstalk also appears as a higher-level option that handles provisioning and scaling for you, suited to developers who want to deploy an application without managing the underlying infrastructure directly.
Chapter 5: Troubleshooting and Optimization (18%)
This is the smallest domain, but it is where careful reading pays off, because the questions hinge on a specific failure or inefficiency and the precise mechanism that addresses it. It covers observability, error handling and resilience patterns, and tuning applications for performance and cost.
Observability with CloudWatch and X-Ray
Amazon CloudWatch is the core observability service: it collects metrics, stores logs (your Lambda function’s output lands in CloudWatch Logs automatically), and raises alarms when a metric crosses a threshold. Amazon CloudWatch Logs Insights lets you query logs to find the cause of a problem. AWS X-Ray complements this by tracing a request as it flows through multiple services, so you can see where latency or errors arise in a distributed application. The developer instinct the exam rewards is to instrument code and read the traces and logs to locate a fault, rather than guessing; a scenario about diagnosing where time is being spent across several services points squarely at X-Ray.
Error handling, retries, and idempotency
Distributed systems fail in partial, transient ways, and the exam expects you to know the standard responses. Retries with exponential backoff and jitter handle throttling and transient errors gracefully, spacing out attempts so a struggling service is not overwhelmed; the AWS SDKs implement this, and you should recognise it as the right pattern when a call is being throttled. Idempotency, designing an operation so that performing it more than once has the same effect as performing it once, is essential when messages may be delivered more than once, as they can be with at-least-once queues. A dead-letter queue (DLQ) captures messages that repeatedly fail processing so they can be inspected rather than lost or retried forever. As a teaching example tying these together: a payment that might be triggered twice by a redelivered message should be made idempotent (for instance, keyed on a unique transaction identifier) so the second delivery does not charge the customer again, with a DLQ catching anything that cannot be processed at all.
Performance and cost optimisation
The optimisation half of the domain is about tuning what you have built. On performance, recognise caching as a recurring lever: ElastiCache in front of a database, DAX in front of DynamoDB, or CloudFront in front of content all reduce latency and load. On cost, the developer-relevant ideas include right-sizing a Lambda function’s memory (since more memory means more CPU and sometimes shorter, cheaper runs), choosing DynamoDB on-demand versus provisioned capacity to match the traffic pattern, and avoiding expensive operations like full table scans. The exam’s instinct is the same as elsewhere on AWS: match the configuration to the actual workload rather than over-provisioning by default.
Chapter 6: Build one project that touches everything
The most efficient single piece of preparation for this exam is to build one small serverless application end to end, because it exercises three of the four domains at once and makes the connections concrete in a way reading cannot. A good target is an API Gateway endpoint that triggers a Lambda function which reads and writes a DynamoDB table, with the function’s access controlled by an IAM execution role, secrets pulled from Secrets Manager or Parameter Store at runtime, and the whole thing defined in a SAM template and released through CodePipeline. Add CloudWatch logs and an X-Ray trace and you have touched troubleshooting as well.
Building this once teaches more than re-reading the service list, because every design decision the exam likes to test shows up in practice: how the function gets its permissions, why you would not hard-code a database password, what happens when you exceed DynamoDB capacity, how a deployment rolls back, and where to look when a request fails. If you have time for a second iteration, add a queue between two components and make the consumer idempotent, which brings the decoupling and resilience patterns to life. Keep it in a free-tier account and keep it small; the aim is to connect the services, not to ship a product.
Chapter 7: Study plan and timeline
With the domains understood, the work is pacing them so that deployment and troubleshooting, the areas developers most often underweight, get real attention rather than a final-weekend skim.
Let the weights and your background set the plan
Spend your hours roughly in proportion to the weights: the most on Development (32%) and Security (26%), a solid block on Deployment (24%) because it is both heavily weighted and commonly weak, and a focused pass on Troubleshooting and Optimization (18%). Carry the build project through the whole plan rather than treating it as a separate task, because it reinforces every domain as you go.
Choose a timeline
A balanced default is around eight to nine weeks at six to eight hours a week for a developer with some AWS exposure. A workable sequence is: weeks one to three on the development domain, building the serverless project as you learn Lambda, API Gateway, and DynamoDB; weeks four to five on security, adding IAM roles, Cognito, KMS, and secrets to the project; weeks six to seven on deployment, defining the project in SAM and releasing it through a pipeline; and weeks eight to nine on troubleshooting and optimisation followed by full-length timed practice. A working AWS developer can compress this to a four-week intensive at around fifteen hours a week, focusing on serverless, deployment, and security and building as they go. Someone newer to AWS should stretch to a twelve-week steady plan at around five hours a week, learning the core services before the developer-specific tooling. To turn whichever timeline you pick into dated weeks for your own start date, use the free study-plan generator. If you are still choosing between this and the architecture track, the Developer Associate vs Solutions Architect Associate comparison lays out the difference.
Practise scenarios, not trivia
Move from reading to scenario questions as soon as you have covered a domain. The exam rewards reasoning about which service or pattern fits a described situation, so practise that reasoning rather than memorising feature lists, and after each question articulate why the best answer beats the plausible wrong ones. Pay particular attention to the deployment and troubleshooting scenarios, where the wording often turns on a single detail (a rollback requirement, a retry pattern, an idempotency need, a permissions gap).
Chapter 8: Final preparation, exam day, and format
Final preparation
In the last week or two, shift from learning new services to consolidating and sitting full-length, timed practice exams. Treat each as a diagnosis rather than a score: for every question you miss, go back to why the right answer was right and why your choice failed, and watch the deployment and troubleshooting domains in particular, since they are where careful reading and the precise mechanism matter most. Revisit the serverless patterns, the IAM-role-not-keys principle, the CodeBuild-versus-CodeDeploy distinction, and the resilience patterns (backoff, idempotency, dead-letter queues). Aim to be scoring comfortably above 720 on fresh material before you book, and resist adding new topics once you are there.
Exam day and format
On the day, the exam is 65 questions in 130 minutes, taken at a Pearson VUE test centre or through online proctoring, with valid government-issued identification required. The questions are multiple-choice (one correct answer) and multiple-response (select the number stated), and you can flag questions and return to them, so do not stall on a hard one. Remember that 15 of the 65 questions are unscored and unmarked, so answer everything normally. Pace yourself, since 130 minutes for 65 scenario questions is workable but not luxurious, and apply the instincts you built: prefer the event-driven, serverless design, grant least-privilege access through roles, match the deployment strategy to the rollback and downtime requirement, and read each troubleshooting scenario for the specific failure it describes. Having built a real project and practised at full length, the format will feel familiar, which is exactly the advantage the weeks of hands-on preparation are meant to give you.