The AWS Certified Developer – Associate exam tests whether a developer can build, secure, deploy, and diagnose applications that use AWS services. This guide focuses on DVA-C02, the outgoing exam version, and on making a practical decision between finishing that exam and preparing for its successor. It is a preparation plan, not a claim that a certificate guarantees a job or a particular salary.
Exam-version notice, November 1, 2026: Amazon announced that DVA-C02’s last testing date is November 30, 2026. Registration for DVA-C03 opened October 27, and DVA-C03 delivery begins December 1. Candidates already close to DVA-C02 readiness can consider an available test appointment before the deadline; candidates starting from scratch should compare the updated DVA-C03 guide rather than assuming an older study plan covers its new AI-assisted development objectives. Check the exact exam code when booking. The DVA-C02 practice-exam listing is relevant to the outgoing version only.
Make the version decision before making a study calendar
Both versions assess AWS application-development competence, but they are not interchangeable blueprints. The October 27, 2026 AWS announcement describes the updated DVA-C03 guide, including changes in AI-assisted development, security, testing, observability, and optimization. DVA-C02 study notes may still teach valuable Lambda, IAM, data-store, and deployment skills, but they should not be represented as a complete guide to the new exam.
If you already have recent, representative DVA-C02 practice results and hands-on experience, check whether a testing appointment is available by November 30 and whether you can close your specific knowledge gaps safely. If not, switch to the DVA-C03 official guide and map the knowledge you have against its updated task statements. A historical DVA-C02 label should be retained in study notes for the older version, not quietly relabeled as DVA-C03.
The four official DVA-C02 knowledge domains
The AWS DVA-C02 exam guide specifies four scored content domains: Development with AWS Services (32%), Security (26%), Deployment (24%), and Troubleshooting and Optimization (18%). These weights describe the distribution of scored exam content; they are not pass thresholds for individual domains. Start with the official task statements under each domain and use the examples below to build applied competence.
Development with AWS Services includes application integration with AWS SDKs and APIs, event-driven and resilient architectures, Lambda behavior, and using application data stores. Security includes access permissions, authentication, encryption, secure credential management, and protection of data handled by applications. Deployment requires the developer to understand release artifacts and the behavior of deployment methods and automation. Troubleshooting and Optimization covers diagnosis through logs and metrics, recognizing fault patterns, and choosing appropriate performance or reliability changes.
The newer DVA-C03 guide retains a four-domain structure but changes the weights to 30% development, 26% security, 22% testing and deployment, and 22% troubleshooting and optimization. Do not mix those percentages into a DVA-C02 flashcard set or assume the changed names leave every underlying skill identical.
Use a small application as a study backbone
A compact event-driven application can connect many DVA-C02 objectives without turning preparation into memorization. Imagine an API that accepts an order, validates its input, writes a record, and emits an event for background processing. A service using Amazon API Gateway, AWS Lambda, DynamoDB, and an appropriate event or queue mechanism lets you study API errors, invocation modes, idempotency, access policies, throughput, logs, and failure recovery in one coherent system.
Design the lab with an explicit scope and a modest budget. Use a test account or approved sandbox, set cost alerts, avoid production customer data, and clean up resources afterward. A free-tier label is not a promise that every possible configuration is free. Record your architecture, the expected successful path, one deliberately introduced failure, and what evidence should reveal the failure.
Develop resilient Lambda and event-driven code
Study synchronous and asynchronous invocation separately. A synchronous caller normally receives the invocation outcome directly; asynchronous processing adds delivery and retry behavior that belongs to the event source and integration. Queue-triggered functions introduce visibility timeouts, batching, partial failures, and duplicate-delivery risks. A function returning an error is not sufficient evidence that a failed business action will never be repeated.
Practice making a write idempotent. For example, assign each business request an immutable request identifier, use a conditional DynamoDB write to prevent duplicate acceptance, and log whether a retry was accepted or ignored. Then intentionally deliver the same event twice. An explanation that merely says “Lambda scales automatically” misses the developer’s responsibility to manage downstream capacity, concurrency, timeouts, and safe retries.
Compare the expected behavior of API Gateway integrations, EventBridge events, and SQS messages. Choose the service based on delivery semantics, failure recovery, and consumer needs rather than assuming all event-driven products behave the same way. Document which component owns retries and how a failed item is observed or recovered.
Design DynamoDB access patterns rather than memorizing feature names
Begin with the queries the application must serve. A table’s partition key and optional sort key determine its primary access pattern; secondary indexes enable additional queries but have their own cost and consistency considerations. A scan used in a small training dataset can become expensive as data grows. Ask which operation actually needs a Query, GetItem, or a conditional update.
Build two test scenarios: retrieving one order by identifier, and looking up a customer’s recent orders. Design the keys for those operations, then use a conditional expression to reject a conflicting update. Examine the trade-offs between on-demand and provisioned capacity, and observe how a hot partition or excessively broad scan affects the access pattern. DynamoDB Streams and TTL are useful additional concepts, but they should not be mistaken for a general-purpose, immediate deletion guarantee or for a substitute for application-level event handling.
Make IAM and application secrets explicit
For each AWS action in the lab, identify the principal, resource, action, and relevant policy conditions. Separate an IAM execution role from an application’s customer-authentication mechanism. Where a service uses an identity-based policy and another supports resource-based policies, trace the effective authorization instead of assuming that attaching a role is enough to grant every requested operation.
A Lambda function that needs a database credential should not embed it in source code or logs. Use an approved secret store, a least-privileged retrieval policy, and a documented rotation path. The distinction between KMS encryption and Secrets Manager credential management matters: encryption keys, ciphertext, and the lifecycle of the underlying application credential are related but not identical concerns.
Test a negative permission case deliberately. Remove the permission needed to perform one action and confirm that the application fails safely, emits useful but non-sensitive diagnostic information, and does not continue with unexpected privilege. A successful request under an administrator account provides little evidence that the least-privileged runtime role is correct.
Rehearse deployments and controlled rollback
Package a small versioned change and deploy it through a repeatable path. Learn where configuration is stored, how immutable artifacts are identified, how environment-specific values are supplied, and what constitutes a safe rollback when a release fails. Changing the application code and its database schema in the same step can make reverting a deployment unsafe; design backward-compatible transitions when the system requires them.
Explore an appropriate deployment mechanism, such as AWS SAM for a serverless application or a managed AWS deployment pipeline. Create a test that rejects an invalid build before promotion, a smoke test that checks the deployed API, and an operational check that verifies a background event was processed. A deployment console showing green is not sufficient if the application is failing downstream.
The DVA-C02 Deployment domain is about being able to select and operate deployment practices, not merely recognizing service names. Explain the difference between creating a deployment artifact, triggering a pipeline, promoting to an environment, and verifying that real business behavior is still correct.
Troubleshoot from observable symptoms to a bounded fix
Start with a specific failure: requests now time out, a Lambda consumer repeatedly retries, a DynamoDB conditional write fails, or a newly deployed version produces more errors. Use CloudWatch logs and metrics, and tracing where available, to locate the failing boundary. Distinguish permission denials from connectivity failures, malformed input, resource throttling, and downstream exhaustion. Similar error rates can require very different fixes.
Record a concise hypothesis, the metric or log field that could disprove it, the smallest safe change to test, and the expected result. After the change, check that the original failure has stopped and that no adjacent error rate or latency metric worsened. This is closer to an exam scenario’s reasoning task than blindly increasing timeouts, memory, or concurrency every time a process runs slowly.
Build a study plan from evidence, not from a universal deadline
First read the DVA-C02 task statements and annotate each as familiar, uncertain, or new. Assign hands-on exercises to the uncertain tasks, especially areas where a service combination behaves differently from a single service. Keep a short error log with the misconception, the correct AWS behavior, and a source that supports the correction. Review that log repeatedly rather than watching an entire course again whenever one question is missed.
Use practice tests as diagnostic tools. Complete a representative set under timed conditions, review both correct and incorrect answers, explain why the distractors do not fit, and verify consequential claims against AWS documentation. A percentage on one vendor’s practice test is not a validated probability of passing the official exam, and “80% guarantees success” is not an evidence-based rule. Look for consistent reasoning and improvement across different objective areas.
For DVA-C02, the exam format has 65 questions and 130 minutes; AWS reports a scaled score from 100 to 1,000 with 720 as the passing mark. A scaled score of 720 is not the same statement as answering 72% of the questions correctly, because the scale is constructed to compare performance across exam forms. Use domain-level feedback as a diagnostic tool rather than treating each domain as a separate passing requirement.
An illustrative step-by-step preparation success story
Consider a developer who has already built small AWS APIs but still confuses Lambda retry behavior, identity-based policies, and DynamoDB access patterns. This is an illustrative learning scenario, not a real candidate testimonial or a guaranteed passing method. The developer starts by comparing the DVA-C02 objectives against a diagnostic set and records three specific gaps instead of declaring the entire security or development domain weak.
Next, the developer builds a nonproduction order API and deliberately breaks one permission and one queue consumer. They first reproduce each failure, then identify its evidence and fix it with the smallest controlled change. Their notes distinguish an expected conditional write failure from a service outage and an authorization denial from a timeout. They can now explain why several tempting multiple-choice alternatives are wrong.
On a later practice set, the developer does not treat an improved percentage as a promise of exam success. They inspect whether previously missed patterns have become reliable, whether new cases still expose gaps, and whether the selected exam version remains available. With a November testing appointment available, they review the official DVA-C02 guide again. Without one, they transfer the lab evidence into the DVA-C03 objectives and identify the AI-assisted development topics that require new study.
This is what a useful step-by-step success path looks like: a dated exam choice, diagnosed gaps, exercises that reproduce real failure modes, evidence-based review, and a booking decision supported by actual readiness. The story illustrates a method for preparing well; the final exam outcome is never guaranteed.
Practice the exam decision, not a memorized service catalog
For each question, identify the requirement that actually selects the solution: delivery semantics, least privilege, resilience, operational cost, or a deployment constraint. Work from evidence rather than the presence of a familiar AWS product name. If a scenario changes from “at most once” to “can be delivered again,” or from “single record” to “range query,” the appropriate design can change even while the list of services stays the same.
A separate discussion of DVA-C02 preparation offers another perspective on planning, but its exam-version statements should be checked against the same current AWS guide. Choose the exam code first, study what that code actually tests, and then apply practice explanations to a small, controlled application you can debug. The goal is demonstrable development competence, not a promise that one study schedule or commercial test set will produce a passing result.
