DVA-C02
AWS Certified Developer - Associate
AWS Certified Developer - Associate Exam Guide: Skills, Blueprint, and Study Roadmap
AWS Certified Developer - Associate validates the ability to develop, test, deploy, secure, troubleshoot, and optimize cloud applications on AWS. It is designed for people performing a developer role, with AWS recommending at least one year of hands-on experience developing and maintaining applications with AWS services. This guide helps you decide whether your current experience is sufficient, which domains deserve the most study time, how to build practical skills, and when to schedule the DVA-C02 exam.
What does AWS Certified Developer - Associate validate?
The certification tests application-development work rather than broad AWS administration or architecture design. A prepared candidate should be able to use AWS APIs, the AWS CLI, and SDKs; work with application services; package and deploy code through CI/CD workflows; protect code and data; and diagnose application failures.
The official DVA-C02 exam description focuses on developing, testing, deploying, and debugging AWS Cloud-based applications. It also identifies four practical outcomes: developing and optimizing applications on AWS, packaging and deploying through continuous integration and continuous delivery workflows, securing application code and data, and identifying and resolving application issues.
That emphasis matters when choosing study material. A service-by-service memorization plan is weaker than learning how services behave inside an application. For example, study Lambda with event sources, permissions, configuration, deployment, logging, retries, and failure diagnosis rather than treating Lambda as an isolated product name.
The certification is an Associate-level credential. AWS describes Associate certifications as validating technical skills for specific technical roles, and the Developer - Associate role is concerned with developing and maintaining applications on AWS. The exam guide is periodically reviewed, so use the current official guide and service list when finalizing preparation.
Is this the right exam for your background?
This exam is a sensible target if you already write application code and have used AWS services in development or maintenance work. AWS identifies the target candidate as someone performing a developer role and recommends at least one year of hands-on experience developing and maintaining applications with AWS services.
The recommended general knowledge includes proficiency in at least one high-level programming language, application-lifecycle-management knowledge, a basic understanding of cloud-focused applications, the ability to develop functional applications, and experience with development tools. You do not need to be equally strong in every programming language; you do need to reason about application behavior and implementation choices.
AWS also expects candidates to develop and secure applications using AWS service APIs, the AWS CLI, and SDKs, and to use a CI/CD pipeline to deploy applications on AWS. If your experience is limited to clicking through the console, add command-line and SDK practice before relying on practice questions.
A candidate without professional AWS experience can still prepare, but should replace missing workplace exposure with small, complete exercises. Build an application, give it an identity-based permission model, deploy it more than once, inspect its logs, introduce a controlled fault, and remove resources afterward. This creates the decision-making context the blueprint assumes.
The exam guide also names work that is out of scope for the target candidate. It does not expect candidates to design architectures, design and create CI/CD pipelines, administer IAM users and groups, administer servers and operating systems, or design AWS networking infrastructure. These boundaries should prevent you from spending most of your preparation on a different certification’s responsibilities.
How is the DVA-C02 exam structured?
The exam uses multiple-choice and multiple-response questions. AWS lists 65 questions in total, including 50 questions that affect your score and 15 unscored questions. The unscored questions are not identified, so treat every question as a genuine opportunity and manage time consistently from the beginning.
A multiple-choice question has one correct response and three incorrect responses. A multiple-response question has two or more correct responses among five or more options. Unanswered questions are scored as incorrect, and AWS states that there is no penalty for guessing.
You have 130 minutes to complete the exam. That is enough time for deliberate reading, but not for repeatedly rebuilding your answer from scratch. On practice sessions, read the requirement first, identify constraints such as least privilege, deployment safety, latency, or durability, eliminate incompatible choices, and mark uncertain items for later review.
Results are reported as a scaled score of 100–1,000, and the minimum passing score is 720. The exam has a pass-or-fail designation. Do not convert a practice-test percentage directly into an expected AWS score; use practice results to locate weak domains and recurring reasoning errors instead.
AWS includes pretest questions to help keep certifications current. Because those questions are not identified, preparation should cover the complete blueprint rather than attempting to predict which items count. Review the current guide before booking if AWS has published a revision notice.
Which domains carry the most weight?
Prioritize the blueprint in this order: Development with AWS Services, Security, Deployment, then Troubleshooting and Optimization. The first two domains together account for most scored content, but the smaller domains still represent distinct job tasks and should not be abandoned.
Content Domain 1: Development with AWS Services represents 32% of scored content. Study how application code interacts with services, how data and events move through an application, and how to select and configure an appropriate AWS implementation for a stated requirement.
Content Domain 2: Security represents 26% of scored content. Focus on authentication and authorization, IAM policies and roles, application secrets, encryption choices, temporary credentials, and protecting data in transit and at rest. The key habit is matching the security control to the resource and access path described in the scenario.
Content Domain 3: Deployment represents 24% of scored content. Prepare for packaging, configuration, deployment strategies, infrastructure and application changes, and CI/CD workflow behavior. Know what changes between development and deployment, how a release is promoted, and where to look when deployment output does not match the intended version.
Content Domain 4: Troubleshooting and Optimization represents 18% of scored content. Practice using logs, metrics, traces, and service responses to isolate a fault. Include performance, cost, reliability, and operational improvements when comparing otherwise functional designs.
These percentages are domain weightings for scored content, not a promise of a fixed number of questions from each domain. AWS advises caution when interpreting section-level feedback, so use the weighting as a planning signal rather than as a pass threshold for each domain.
What should you study in Development with AWS Services?
Begin with the application path: request or event, compute, permissions, data store, response, and observability. Development questions become easier when you can predict what the code needs at each boundary and distinguish a code defect from a service configuration or authorization defect.
The in-scope list includes AWS Lambda, Amazon EC2, AWS Elastic Beanstalk, Amazon ECS, Amazon EKS, and Amazon ECR for compute and containers. You do not need identical depth across every option, but you should understand the developer-facing differences between managed functions, virtual machines, and container workflows.
For data and storage, the list includes Amazon DynamoDB, Amazon Aurora, Amazon RDS, Amazon ElastiCache, Amazon S3, Amazon EBS, and Amazon EFS. Build comparison notes around access pattern, consistency or transaction needs, object versus file or block storage, scaling behavior, and the permissions required by application code.
Application integration is a major study area. Review Amazon API Gateway, Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Step Functions, and AWS AppSync. For each, ask what initiates the work, whether processing is synchronous or asynchronous, how retries and failures behave, and how the consumer is authorized.
The in-scope services also include Amazon Kinesis, Amazon Athena, and Amazon OpenSearch Service. Study their role in application and event-data workflows without drifting into specialist analytics administration. The exam guide’s service references and task statements should determine how far you go.
Use one small project to connect the concepts. An API can invoke a function, read or write data, publish an event, send a message for asynchronous processing, and expose logs and metrics. The point is not the project’s originality; it is being able to explain each service boundary and test a failure at that boundary.
How should you prepare for Security questions?
Treat security as an implementation constraint in every lab, not as a final chapter. Start with the identity making the request, the resource being accessed, the action being attempted, and the policy or credential mechanism that connects them. This approach is more reliable than memorizing isolated IAM terms.
Practice the difference between application credentials, execution roles, and temporary credentials. Review how an application obtains permission to call another AWS service, how a role is assumed, and why hard-coded long-term credentials are an unsafe implementation choice. Use the AWS CLI or SDK in a controlled account so the permission error is visible and explainable.
Include Amazon Cognito, IAM, AWS KMS, AWS Secrets Manager, AWS Security Token Service, and AWS WAF in your security map. Add Amazon API Gateway and Amazon S3 because application security often depends on the resource policy, request path, encryption setting, or integration configuration rather than on one service alone.
Make least privilege concrete. Give a function only the actions and resources it needs, then test an allowed operation and a denied operation. Inspect the error, identify which identity was evaluated, and revise the policy narrowly. Avoid solving every failure by granting broad permissions; that habit directly undermines the reasoning the exam tests.
Separate authentication from authorization in your notes. Authentication establishes who or what is making a request; authorization determines whether that identity can perform the requested action on the target resource. Then add encryption and secret management as separate controls rather than treating all security features as interchangeable.
A useful review question is: what is the smallest secure change that satisfies the requirement? Apply it to API access, data protection, service-to-service calls, secret rotation, and public exposure. When an answer uses a broad administrator permission, embedded credential, or unnecessary public access, examine it critically.
What deployment knowledge is actually needed?
Deployment preparation should connect source code, build output, configuration, infrastructure, and release behavior. You need to recognize how an application is packaged and moved through a workflow, what can be automated, and which deployment setting controls the risk of releasing a change.
AWS lists AWS CodeArtifact, AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline, AWS Amplify, AWS CloudFormation, AWS CDK, AWS AppConfig, and AWS CloudShell among the in-scope developer tools and management services. Study their roles and handoffs: dependency or artifact management, building, orchestration, deployment, configuration, and infrastructure definition.
Review deployment packaging for the runtime you use and compare it with the packaging needs of containers and static or frontend applications. Check what belongs in the artifact, what should be injected as configuration, and what must remain in a managed secret. A repeatable package is easier to test and troubleshoot than a manually altered production copy.
Use a simple release exercise. Commit a change, build an artifact, deploy it to a test environment, verify the running version, and inspect the pipeline output. Then make the deployment fail deliberately through a controlled configuration or test error. Record whether the failure occurred in source retrieval, build, artifact handling, permissions, deployment, or application startup.
Do not study deployment as if the objective were to design an enterprise pipeline from nothing. The official target description places CI/CD use within scope, while designing and creating CI/CD pipelines is listed as out of scope. Concentrate on understanding pipeline stages, artifacts, permissions, deployment choices, and failure symptoms.
Include configuration management and infrastructure as code in the same mental model. AWS AppConfig, CloudFormation, and CDK can appear in questions where the issue is not the application logic but how a setting or resource change is represented and promoted. Always ask whether the proposed change is reproducible and environment-appropriate.
How do you build troubleshooting and optimization skill?
Troubleshooting questions reward a disciplined diagnostic sequence: establish the symptom, identify the failing boundary, gather the relevant evidence, and change the narrowest likely cause. Do not jump to a replacement service simply because the application is slow or returning an error.
Amazon CloudWatch, AWS CloudTrail, and AWS X-Ray are in scope for observability and investigation. Know what each contributes. Logs can reveal application and integration errors, metrics can expose timing or resource patterns, traces can show where a distributed request spends time, and audit records can help establish which API activity occurred.
Create a fault matrix for your lab. Include an authorization denial, malformed request, missing configuration value, unavailable dependency, throttled request, failed deployment, and delayed asynchronous message. For each fault, write the first evidence source, the likely layer, and the safe corrective action. This turns troubleshooting into a repeatable process rather than a list of guesses.
Optimization is broader than speed. Compare solutions using performance, cost, scalability, reliability, and operational effort. A cache may reduce repeated data retrieval but introduce freshness concerns; asynchronous messaging may improve responsiveness but require retry and idempotency handling; a larger compute option may mask inefficient code while increasing cost.
Study common distributed-application behaviors: retries can duplicate work, queues can accumulate messages, event consumers can fail independently, and a successful invocation does not always mean the complete business operation succeeded. Your notes should state what the developer observes and what action follows.
When reviewing practice questions, do not only record the correct letter. Write why the selected service or configuration solves the stated symptom, why the distractors do not, and what evidence would confirm the diagnosis in a real environment. This is especially important for questions where several options are technically possible but only one addresses the constraint.
Which AWS services belong on your revision map?
Use the official in-scope service list as a boundary, then group services by the application decisions they support. The list is non-exhaustive and subject to change, so it should be checked again during final review rather than copied into a static memorization checklist.
A practical revision map can include these groups: compute and containers; application integration; databases and caching; storage; developer tools; management and observability; networking and content delivery; and security, identity, and compliance. This grouping reflects the official service categories while keeping the focus on relationships between services.
The official list includes Amazon API Gateway, Amazon CloudFront, Elastic Load Balancing, Amazon Route 53, and Amazon VPC under networking and content delivery. For a developer-focused review, concentrate on how an application reaches its endpoint, how traffic is routed or distributed, and which configuration or permission issue could prevent a request from reaching code.
For deployment and operations, include AWS CloudFormation, AWS CDK, AWS CloudWatch, AWS CloudTrail, AWS CLI, AWS Systems Manager, AWS AppConfig, and the Code services named in the official list. Know what problem each solves and what evidence it produces; do not attempt to memorize every console screen.
Amazon Q Developer appears in the official in-scope list. Because AWS exam guides are revised as technologies and practices change, verify the current guide’s treatment and service references close to the exam. Do not infer detailed question coverage from a service’s presence in the list alone.
Build a one-page matrix with columns for purpose, input or trigger, output, identity required, failure signal, and common trade-off. Populate it from official documentation and your labs. This format exposes gaps faster than rereading product descriptions because it forces you to connect each service to application behavior.
What study sequence works for a developer with limited time?
Study in dependency order, not simply in blueprint order. First establish application and AWS fundamentals, then develop a small workload, add security, automate deployment, and finish with troubleshooting and mixed-domain practice. This sequence lets each later topic use an application you already understand.
In the first phase, confirm that you can read code, call an AWS service through an SDK or CLI, interpret a response, and manage configuration without embedding secrets. Review the core service concepts required by your project. If these basics are weak, postpone full practice exams and fix the foundation.
In the second phase, implement the application path. Choose a modest workload using a compute service, an API or event source, a data or storage service, and basic logging. Keep a decision journal: why did you choose synchronous or asynchronous processing, which identity calls which service, and what happens when the dependency fails?
In the third phase, secure and deploy the workload. Replace broad permissions with narrowly scoped access, move sensitive values into an appropriate secret or configuration mechanism, package the application, and use a repeatable build and deployment workflow. Test both a successful release and a release that should be rejected or fail safely.
In the fourth phase, troubleshoot intentionally. Use CloudWatch logs or metrics and, where appropriate, tracing and audit information. Introduce one fault at a time, preserve the symptom, and write the diagnosis. Then optimize one dimension without damaging another—for example, reduce repeated retrieval while considering freshness or improve responsiveness while handling retries.
In the final phase, use mixed practice questions under the official exam conditions. Review by domain and by error type: knowledge gap, misread requirement, confused service boundary, arithmetic or configuration mistake, or rushed selection. Revisit source documentation for the underlying concept rather than memorizing the practice question.
A useful readiness signal is not a single high practice score. You are closer when you can explain an answer without seeing the options, implement the core behavior in a small lab, diagnose a deliberately introduced fault, and identify the security and deployment consequences of your choice.
How should you divide weekly study time?
Allocate the largest share of study effort to Development with AWS Services and Security because those are the two largest scored domains, while reserving regular sessions for Deployment and Troubleshooting and Optimization. Adjust the allocation after diagnostic practice; the blueprint weighting should not override a serious personal weakness.
Use three types of sessions. A concept session reads the official task statements and service references. A build session implements or changes something in AWS. A retrieval session answers questions from memory and explains the reasoning. A week made entirely of videos or reading may feel productive while leaving implementation and diagnosis untested.
At the start of a study week, choose one application capability and one exam task. For example, connect an event source to processing while reviewing retries and permissions, or deploy a versioned artifact while reviewing configuration and rollback behavior. End the week by writing a short summary of what failed, what evidence helped, and what you would change.
Keep an error log with four fields: scenario requirement, chosen answer, actual principle, and next experiment. Add a fifth field for the distractor that most nearly fooled you. Over time, patterns such as confusing resource policies with identity policies or treating asynchronous processing as synchronous will become visible.
Avoid measuring progress by the number of services whose names you can recite. Measure whether you can compare two plausible implementations against explicit constraints. The exam’s distractors are designed to be plausible for someone with incomplete knowledge, so your preparation must include why an attractive alternative is wrong in that scenario.
If you cannot access a suitable AWS environment, use official service documentation and command or SDK examples to reason through requests, permissions, and responses, but recognize the limitation. Reading about deployment failure is not equivalent to seeing an artifact, role, log entry, and application error interact.
What mistakes commonly waste preparation time?
The most costly mistake is studying every AWS service at equal depth. The exam is role-based and blueprint-driven. Start with the official domain tasks, connect relevant services to application workflows, and use the in-scope list to prevent both uncontrolled breadth and premature focus on unrelated administration.
Another mistake is confusing architecture design with developer implementation. The guide lists architecture design, CI/CD pipeline creation, IAM administration, server administration, and network infrastructure design as out of scope for the target candidate. Learn enough surrounding context to make a developer decision, but do not turn this exam into a separate architect or operations curriculum.
Do not grant broad permissions whenever a lab produces an access error. That may make the demonstration work while teaching the wrong lesson. Identify the calling identity, requested action, target resource, and relevant policy. Then make the smallest correction and retest.
Do not memorize product definitions without testing lifecycle behavior. A question may depend on whether work is queued, retried, cached, traced, encrypted, or deployed as an artifact. Build comparison tables around behavior and trade-offs, then verify them through a small implementation or official documentation example.
Do not assume that an answer is correct because it uses a familiar service. A service must satisfy the complete requirement, including security, latency, failure handling, operational control, and deployment constraints. Read for qualifiers such as least privilege, minimal code changes, asynchronous processing, or avoiding hard-coded credentials.
Finally, do not use leaked questions, exam dumps, or memorization as a passing strategy. They do not build the ability to interpret a new scenario, and using unauthorized exam content conflicts with the purpose of certification. Use legitimate practice to test reasoning, then return to the official blueprint and documentation.
Where and how can you take the exam?
AWS lists Pearson VUE testing centers and online-proctored testing as available options for this exam. Choose the format that suits your workspace, connectivity, identification requirements, and ability to follow the provider’s current check-in rules; verify the details in your AWS Certification Account before appointment day.
AWS states that appointments can be scheduled through an AWS Certification Account with Pearson VUE, and that most online-proctored appointments are available 24 hours a day, seven days a week. Availability can vary, so check the live appointment calendar rather than planning around an assumed slot.
The AWS certification page lists the exam price as USD 150 and provides additional pricing information for foreign-exchange rates. Because fees and appointment policies can change, confirm the amount and applicable terms when you schedule. Do not treat a third-party page’s price as authoritative.
AWS lists English, Japanese, Korean, Brazilian Portuguese, Simplified Chinese, and Latin American Spanish as available exam languages. The exam-guides index also identifies Spanish-language availability for DVA-C02. Confirm the language offered for your selected appointment before payment.
Schedule only after you have checked the current DVA-C02 guide, the in-scope service list, and any revision information. AWS says revisions are published at least one month before changes are reflected on the exam. A late review can reveal that your notes or practice material follow an older blueprint.
Use the scheduling page for current delivery instructions and the certification account for appointment details. This guide does not replace the provider’s check-in, identification, rescheduling, or technical requirements, which are operational policies and may change independently of the exam content.
What should you do in the final review?
In the final review, stop expanding your service list and test decision quality. Revisit the four domains, the official task statements, your error log, and the service behaviors that repeatedly caused confusion. Finish with a short mixed practice session and a plan for handling uncertain questions without leaving items unanswered.
Review Development with AWS Services through one end-to-end application flow. Explain the request or event, compute choice, data access, integration behavior, configuration, and observability. Then change one requirement—such as asynchronous processing, a different data access pattern, or stricter permission scope—and explain what must change.
Review Security by tracing every identity and secret. Confirm which principal makes each call, which policy grants access, where sensitive values live, and how data is protected. Review Deployment by tracing source to artifact to environment, including the permissions and configuration required at each step.
Review Troubleshooting and Optimization by reading a symptom before looking at choices. State the likely layer, the evidence you would collect, and the least disruptive correction. If several options could work, select the one that best satisfies the complete requirement rather than the one with the most familiar service name.
Check the current official pages shortly before scheduling and again if AWS communicates a revision. The official in-scope list is non-exhaustive and subject to change, and AWS periodically reviews exam guides. Your final review should therefore confirm the version, domain outline, delivery details, and service references you are using.
On exam day, use the time deliberately. Read the whole scenario, identify the requirement and constraints, eliminate responses that violate them, and flag questions where evidence is incomplete. Return to flagged items with the same method. Answer every question because unanswered questions are scored as incorrect and AWS states there is no penalty for guessing.
What is the best next step after reading this guide?
Take a diagnostic pass through the official domain outline and mark each task as can explain, can implement, or cannot yet do. Then build one small AWS application that crosses development, security, deployment, and troubleshooting. That assessment will tell you whether to schedule soon, extend hands-on practice, or strengthen foundational programming and cloud knowledge first.
Open the DVA-C02 exam guide and read the target candidate description, response types, content outline, domain task pages, service references, and revisions. Open the in-scope service list separately and use it to audit your notes. These official pages are more reliable than an undated checklist or a course summary that does not identify its exam version.
Next, choose a project small enough to finish and complex enough to fail meaningfully. Use an AWS API or SDK, apply a restricted role, deploy a repeatable artifact, capture logs, and test at least one failure path. Keep the project focused on developer decisions rather than building a large production architecture.
After the lab, take mixed practice questions and update your error log. If your errors cluster in one domain, study that domain’s official tasks and repeat a targeted lab. If errors are spread across domains, improve reading discipline and service comparisons before adding more content.
Only then compare your readiness with the practical requirements of your preferred testing option and check current appointment availability. The goal is not to predict an exact score; it is to show that you can apply the developer skills the certification is intended to validate.
Conclusion
A strong DVA-C02 plan combines blueprint awareness with repeated application work. Learn the largest domains first, but keep deployment and troubleshooting active throughout; secure every lab; use logs and service behavior to explain failures; and verify current AWS guidance before scheduling. If you can implement, protect, deploy, and diagnose a small AWS application while explaining the trade-offs, your preparation is aligned with the role the exam measures.