DVA-C02
AWS Certified Developer - Associate
AWS Certified Developer - Associate Exam Guide: What to Study, How to Prepare, and When to Schedule
AWS Certified Developer - Associate validates practical ability to develop, test, deploy, and debug applications running on AWS. It is aimed at people performing a developer role, especially candidates who already work with application code, AWS APIs, SDKs, the AWS CLI, and CI/CD delivery. This guide helps you decide whether your experience is ready for the exam, which domains deserve the most study time, how to build useful hands-on practice, and when to verify the current guide before booking.
What the certification actually validates
The exam tests application-focused AWS skills rather than broad infrastructure design. AWS describes the certification as validating proficiency in developing, testing, deploying, and debugging AWS Cloud-based applications, including developing and optimizing applications, packaging and deploying through CI/CD workflows, securing code and data, and resolving application issues. See the [AWS exam guide](https://docs.aws.amazon.com/aws-certification/latest/developer-associate-02/developer-associate-02.md).
That distinction should shape your preparation. You are not preparing to design an entire enterprise architecture or administer every AWS platform component. You are preparing to select and use AWS services appropriately while writing, securing, delivering, observing, and troubleshooting application workloads.
A scenario may therefore test the interaction between services rather than a single service definition. For example, useful preparation connects an application with an API endpoint, an identity mechanism, a data store, a deployment workflow, and logs or traces. The question is not merely what a service does; it is whether the proposed implementation satisfies the stated application requirement.
The role behind the exam
AWS identifies the target candidate as an individual who performs a developer role. The target candidate description recommends at least one year of hands-on experience developing and maintaining applications with AWS services. That recommendation is a readiness signal, not a substitute for reviewing the exam content outline. Candidates with less experience should compensate with deliberate labs rather than relying on memorized service summaries.
What is deliberately outside the target
The detailed guide places several activities outside the target candidate’s expected responsibilities: designing distributed architectures, designing and creating CI/CD pipelines, administering IAM users and groups, administering servers and operating systems, and designing AWS networking infrastructure. These boundaries do not mean the related services are irrelevant. They mean your study should emphasize developer use of those capabilities instead of treating the exam as an administrator or solutions architect exam.
Check the exam version before you commit
Use the detailed exam guide and the AWS exam-guide index together before scheduling. The supplied detailed documentation identifies the assessment as DVA-C02, while the AWS exam-guide index also lists AWS Certified Developer - Associate as DVA-C03 and describes newer scope. Because AWS periodically reviews and revises guides, confirm the version, content outline, and revision information in the official sources immediately before booking. See the [exam-guide index](https://docs.aws.amazon.com/aws-certification/latest/examguides/aws-certification-exam-guides.html).
This is a practical scheduling decision. Do not build a long study plan from an old domain outline and assume that a similarly named exam has identical coverage. Start with the guide associated with the appointment you intend to take. Compare its target candidate description, domains, service references, and revisions with your notes.
The rest of this article uses the supplied DVA-C02 facts, including its four domains and their weightings. Those details should be treated as the working scope for this guide, not as a reason to ignore a newer official guide. If AWS presents a different version when you register, follow the version attached to your appointment.
A simple version-control habit
Save the official guide URL, the in-scope service-list URL, and the exam-guide index URL in your study notes. At the start of preparation, record the exam identifier and the date you checked the documents. Recheck them when you are ready to schedule and again if AWS announces a revision. AWS says exam-guide revisions are published at least one month before changes are reflected on an exam, but the official revision information remains the authority for your decision.
How the scored content is distributed
The supplied DVA-C02 outline divides scored content across four domains: Development with AWS Services (32% of scored content), Security (26% of scored content), Deployment (24% of scored content), and Troubleshooting and Optimization (18% of scored content). Use these labels whenever you plan study time; a percentage without its domain name is not a useful planning signal.
Development with AWS Services carries the largest stated share, but the other domains are not optional. Security and Deployment together represent a substantial part of the scored outline, while Troubleshooting and Optimization tests whether you can diagnose the consequences of implementation choices. The weighting should influence sequence and revision time, not encourage you to skip smaller domains.
The official guide includes tasks and additional context for each task. Read those task descriptions as capability statements. Turn each one into an observable activity, such as choosing a suitable integration, applying a permission boundary to application access, selecting a deployment behavior, or interpreting an application symptom from available telemetry.
Domain 1: Development with AWS Services
Study this domain through application behavior. Work with service APIs, SDKs, and the AWS CLI, then connect the result to the application’s requirements. The in-scope list includes services such as AWS Lambda, Amazon DynamoDB, Amazon S3, Amazon API Gateway, Amazon ECS, Amazon EKS, AWS AppSync, Amazon EventBridge, Amazon SNS, Amazon SQS, and AWS Step Functions.
Do not make the mistake of learning each service in isolation. Compare the decisions an application developer makes: synchronous versus asynchronous integration, object storage versus a database, a function-based workload versus containers, or a queue versus a notification fanout. For every comparison, write down the trigger, input and output shape, failure behavior, permissions, and operational signal you would expect.
A productive lab can be small. Build one application endpoint, persist a record, publish an event, and consume it with a second component. Then change one requirement—such as delayed processing, idempotent handling, or a different data-access pattern—and explain which service behavior becomes relevant. The purpose is reasoning about implementation choices, not building a production system.
Domain 2: Security
Security preparation should focus on how application code obtains and uses access, secrets, tokens, and encrypted data. The in-scope service list includes IAM, Amazon Cognito, AWS KMS, AWS Secrets Manager, AWS STS, and AWS WAF, alongside services that need permissions such as S3, DynamoDB, Lambda, and API Gateway.
For each application action, identify the principal, the requested resource, the relevant action, and the credential or token path. Practise distinguishing an application role from a human identity, a temporary credential from a long-lived secret, and authentication from authorization. Then consider where data is encrypted, how a secret is retrieved, and what an exposed credential would allow.
A common preparation error is reading policy syntax without testing access decisions. Use a controlled account or sandbox to create a narrow application role, retrieve a secret, call an AWS API, and inspect the resulting failure when a permission is removed. Record why access succeeds or fails. This builds the diagnostic habit the exam expects without depending on recalled question wording.
Domain 3: Deployment
Deployment study should connect source code, packaging, infrastructure configuration, and release automation. AWS lists services including AWS CodeBuild, AWS CodeDeploy, AWS CodePipeline, AWS CodeArtifact, AWS CloudFormation, AWS CDK, AWS Amplify, Amazon ECR, Amazon ECS, Amazon EKS, and AWS Elastic Beanstalk within the in-scope services for the supplied guide.
The target candidate is expected to use a CI/CD pipeline to deploy applications on AWS, but the detailed guide distinguishes that from designing and creating CI/CD pipelines, which is out of scope for the target role. Prepare to recognize the purpose and behavior of pipeline components, deployment configurations, artifacts, build environments, container images, and application settings. Do not spend your entire study period architecting an enterprise delivery platform.
Package the same small application in more than one way. For example, identify what belongs in a build artifact, what belongs in an environment configuration, and what must be supplied securely at runtime. Trace the artifact from source through build and deployment, then deliberately introduce a missing dependency or incorrect setting. The exercise makes deployment failures concrete and gives you material for troubleshooting revision.
Domain 4: Troubleshooting and Optimization
Troubleshooting and Optimization requires a chain of reasoning from symptom to evidence to corrective action. The relevant in-scope services include Amazon CloudWatch, AWS X-Ray, AWS CloudTrail, AWS Systems Manager, and AWS AppConfig, as well as the application services producing logs, metrics, events, and errors.
Build a troubleshooting matrix for the failures you create in labs. Include an authorization error, a malformed request, a timeout, a failed deployment, an unavailable dependency, an incorrect environment variable, and a data-access problem. For each, note which evidence would confirm the hypothesis and which change could fix the issue without creating a new security or reliability problem.
Optimization is not simply choosing the cheapest service. Examine the trade-off stated in the scenario: latency, throughput, resilience, operational effort, security, or cost. A good answer normally addresses the stated constraint with the least unnecessary change. Avoid selecting an option because it is familiar if it does not explain the observed symptom or requirement.
Which AWS services deserve hands-on time
Start with the official in-scope service list, but do not interpret it as a promise that every listed service receives equal coverage. AWS says the list is non-exhaustive and subject to change. Use it to find gaps, then prioritize services that participate in common developer workflows: compute, storage, data access, APIs, messaging, identity, deployment, and observability. See the [in-scope services reference](https://docs.aws.amazon.com/aws-certification/latest/developer-associate-02/dva-02-in-scope-services.html).
A useful service map is organized by the decision an application must make. Under application execution, compare Lambda, EC2, Elastic Beanstalk, ECS, and EKS at the level needed for developer scenarios. Under persistence, compare S3, DynamoDB, RDS, Aurora, ElastiCache, EBS, and EFS by access pattern and operational behavior. Under integration, connect API Gateway, EventBridge, SNS, SQS, AppSync, and Step Functions to their interaction patterns.
For developer tooling, learn how CodeBuild, CodeDeploy, CodePipeline, CodeArtifact, CloudFormation, CDK, CloudShell, and the CLI fit into a delivery process. For visibility and control, connect CloudWatch, X-Ray, CloudTrail, Systems Manager, AppConfig, IAM, KMS, Secrets Manager, and WAF to particular application concerns. This approach is more durable than producing a glossary of service names.
Keep a one-page comparison sheet for services that are easy to confuse. Each row should answer: what problem does the service solve, how does an application invoke it, what is the unit of data or work, how is access controlled, what failure would appear first, and what evidence would you inspect? Revise the sheet after every lab or practice review.
What not to do with the service list
Do not treat the in-scope list as a requirement to memorize every console option, quota, feature variation, or regional detail. Do not infer that a service’s presence means you should study it more deeply than the domain tasks justify. Conversely, do not ignore a service because you have never used its console. Learn the role it can play in an application and follow the official task descriptions for depth.
A preparation sequence that builds usable skill
Study in dependency order rather than reading domains as unrelated chapters. First establish how an application runs and communicates. Then add data access and identity, package the application for delivery, and finally create failures and diagnose them. This sequence lets each new topic attach to a working example, while the domain weightings determine how much review time you reserve for each area.
Begin with a baseline assessment using the official domain outline. For every task, mark yourself as can explain, can implement, or cannot yet do. The third category needs a lab; the first category may still need scenario practice; and the second category needs both implementation and explanation. Avoid rating yourself solely by whether a definition looks familiar.
Next, create a narrow reference application. It can expose an API, invoke compute, read or write data, and emit logs. Add one asynchronous path using a queue or event service, and add a deployment path using the developer tools you can access. The application is a study instrument: keep it small enough to rebuild and modify repeatedly.
After the baseline build, study security and deployment as cross-cutting concerns. Add a least-privilege role, a managed secret, an authenticated request path where appropriate, and a repeatable build or deployment process. Then test what happens when permissions, configuration, packaging, or dependency assumptions are wrong.
Finish with mixed-domain practice. A scenario may combine security, deployment, and troubleshooting even when its central problem appears to be a coding issue. When reviewing an answer, explain why each incorrect option fails the requirement. This is more valuable than merely recording the correct letter or memorizing a short rationale.
A four-pass study method
Pass one is orientation: read the target candidate description, domain tasks, response types, and service references. Pass two is construction: implement a small application and exercise its AWS integrations. Pass three is diagnosis: break the application and use logs, metrics, traces, and audit evidence to isolate faults. Pass four is decision practice: answer mixed scenarios under time pressure and revise only the topics your reasoning exposes as weak.
How to use practice questions responsibly
Practice questions are useful for identifying gaps, not for predicting or reproducing live exam content. Treat every explanation as a prompt to verify behavior in AWS documentation or a lab. When an answer depends on a subtle service interaction, recreate the interaction in a safe environment. Memorizing a question pattern can hide a misconception; explaining the requirement, mechanism, and failure mode exposes it.
A practical study roadmap
A roadmap should produce evidence of readiness each week, not just a growing list of watched lessons. Use the outline below as a flexible sequence, adjusting the pace to your programming background, AWS access, and weak domains. Keep the official guide open while you work and replace any study material that conflicts with the version associated with your exam.
In the first stage, map the blueprint and establish your baseline. Read each domain task, list unfamiliar services, and complete a short application exercise using an AWS API, SDK, or CLI. Your deliverable is a gap list with three columns: concept to learn, service behavior to test, and evidence that you can explain the result.
In the second stage, build the application core. Practise compute, API interaction, data access, messaging, and event-driven behavior. Use a language you already know well; this exam is not a good place to learn a programming language from scratch. Write down the request path and the identity used at every service boundary.
In the third stage, secure and deliver the workload. Add permissions deliberately, retrieve sensitive configuration through an appropriate mechanism, package the application, and trace its path through a build or deployment workflow. Review the difference between application configuration and credentials, and between a build artifact and a runtime dependency.
In the fourth stage, create controlled failures. Remove a permission, change a configuration value, break a package, send an invalid request, and create a dependency timeout. Use CloudWatch, X-Ray, CloudTrail, or other relevant evidence where available. For each failure, write a short incident note containing symptom, likely causes, confirming evidence, fix, and prevention.
In the final stage, run mixed review sessions. Allocate more revision to Development with AWS Services (32% of scored content), Security (26% of scored content), Deployment (24% of scored content), and Troubleshooting and Optimization (18% of scored content) according to both the official outline and your diagnostic results. A weak high-weight domain should be addressed before polishing already strong knowledge in a smaller domain.
The readiness checkpoint
Schedule only after you can explain the main service comparisons without depending on a product slogan, implement the core flows in your reference application, identify the permission or configuration boundary involved in a failure, and interpret the domain tasks in the official guide. If you can answer definitions but cannot diagnose a broken deployment or unauthorized API call, continue lab work before booking.
How the exam is delivered and scored
For the supplied DVA-C02 facts, AWS lists 65 questions in multiple-choice or multiple-response format, with 130 minutes to complete the exam. AWS also states that 50 questions affect the score and 15 are unscored; the unscored questions are not identified. Results are reported as a scaled score of 100–1,000, and the minimum passing score is 720.
The two response formats require different habits. A multiple-choice question has one correct response and three incorrect responses. A multiple-response question has two or more correct responses out of five or more options. Read the requested number and the qualifying conditions carefully; an option that is generally true may still be wrong if it violates the scenario’s security, operational, or implementation constraint.
Unanswered questions are scored as incorrect, and AWS states there is no penalty for guessing. Use that policy practically: select an answer for every item, flag uncertain questions when the interface permits, and return only after you have completed the rest. Do not spend so long proving one option that you lose opportunities to answer questions you understand.
A scaled score should not be treated as a direct percentage correct. AWS reports performance on that scale and advises caution when interpreting section-level feedback. Use domain feedback to identify study priorities after an attempt, but do not reverse-engineer a precise percentage threshold from the scaled result.
Time management without inventing a formula
The official duration is 130 minutes for the supplied exam facts. Instead of relying on an artificial per-question target, divide your session into an initial pass and a review pass. Move forward when a question requires an extended chain of recall, mark the uncertainty, and preserve enough time to revisit flagged items and check multiple-response selections.
Choose a testing option and confirm the appointment
AWS lists Pearson VUE testing centers and online-proctored testing as available options for this exam. AWS says appointments can be scheduled through an AWS Certification Account with Pearson VUE, and most online-proctored appointments are available 24 hours a day, seven days a week. Review the current [testing and scheduling instructions](https://aws.amazon.com/certification/certification-prep/testing/) before selecting a delivery method.
Choose a test center if a controlled physical setting is more reliable for you. Choose online proctoring only after reviewing the current system, workspace, identification, and check-in requirements on the official scheduling page. Those requirements can affect whether a preferred date is genuinely convenient, so do not leave the decision until the day you intend to test.
AWS lists the exam languages as English, Japanese, Korean, Brazilian Portuguese, Simplified Chinese, and Latin American Spanish. The certification page lists the exam cost as USD 150, with additional pricing information for foreign-exchange rates. Verify the current price, language availability, appointment locations, and any accommodations in your AWS Certification Account before paying or confirming.
The official scheduling process is the correct place to check live availability and current policies. This guide does not infer appointment availability from a general statement about online testing. Once booked, record the exact exam identifier and version shown in your account, then compare it with the guide you used to prepare.
Language is a preparation choice
If you plan to test in a language other than the language of your study materials, practise reading service names, API concepts, and scenario qualifiers in the selected exam language. Do not assume that translated terminology will match informal translations used in community notes. Confirm the language option in the official certification and scheduling workflow before you design your final review.
Common preparation mistakes and their corrections
The most damaging mistakes are usually planning mistakes: studying a stale version, confusing developer responsibilities with architecture or administration, memorizing service descriptions, and avoiding hands-on diagnosis. Correct them by anchoring every study block to an official task, a service behavior, or a failure you can reproduce and explain.
Mistake one is treating the largest domain as the whole exam. Development with AWS Services is 32% of scored content, but Security is 26% of scored content, Deployment is 24% of scored content, and Troubleshooting and Optimization is 18% of scored content. Study all four named domains and use the weightings to prioritize, not to eliminate.
Mistake two is confusing authentication with authorization. A user or workload may be recognized successfully and still lack permission for the requested resource or action. In labs, write down both questions separately: who or what is making the request, and what is that principal allowed to do? This simple split improves policy analysis and troubleshooting.
Mistake three is learning deployment as a sequence of console clicks. The exam’s developer perspective requires understanding artifacts, build behavior, configuration, permissions, and release outcomes. Rebuild a small delivery flow and deliberately change one variable at a time. You will learn more from explaining why a deployment failed than from completing a successful tutorial once.
Mistake four is using an in-scope list as a memorization checklist. AWS says the list is non-exhaustive and subject to change. Use it to discover areas for investigation, then return to the exam guide’s domain tasks and service references. A service name without an application decision attached to it is weak preparation.
Mistake five is assuming a practice score proves readiness. A practice result can be distorted by repeated exposure, familiar wording, or a narrow service selection. Require yourself to justify the answer, reject the distractors, and implement or verify the underlying behavior when possible. Track recurring reasoning errors rather than collecting scores alone.
Mistake six is ignoring security and observability until the end. An application that works only under broad permissions and cannot explain its own failures is not a strong study project. Add access control and telemetry from the beginning, then use them while testing the application. This makes the cross-domain connections easier to remember.
A better final-week review
In the final review period, stop expanding the service list unless the official guide reveals a clear gap. Revisit your comparison sheet, policy experiments, deployment notes, and failure matrix. Practise reading the question stem for constraints such as least privilege, minimal operational effort, asynchronous processing, deployment safety, or diagnosis from available evidence. Then check the official guide for any version or revision change before the appointment.
What to do after an attempt
Use the result as a diagnostic, not as a reason to memorize isolated answers. AWS reports a pass or fail designation and a scaled score, with section-level feedback that should be interpreted cautiously. If you need another preparation cycle, compare your feedback with your lab evidence and domain notes, then target the underlying capability rather than merely reviewing questions that resemble the ones you remember.
If Development with AWS Services feedback is weak, rebuild your service comparisons and API-driven application flow. If Security is weak, repeat identity, permission, token, secret, and encryption exercises. If Deployment is weak, trace packaging and release artifacts end to end. If Troubleshooting and Optimization is weak, create faults and practise selecting evidence before selecting a fix.
Do not claim that recalled questions, exam dumps, or leaked content can guarantee a pass. They are not a substitute for the skills the certification is designed to validate and may be inaccurate or unauthorized. A defensible recovery plan uses the official guide, current AWS documentation, controlled implementation, and careful review of why each answer fits the requirement.
Before a retake, revisit the version-control step. Confirm that the exam identifier and official guide still match, check the current scheduling information, and update your service and domain notes if AWS has revised the content. The practical objective is not to remember an earlier attempt; it is to become able to make and explain the implementation decisions represented by the exam.
Your next actions
Make the first decision about readiness, not resources: compare your experience with AWS’s target candidate description and list the application tasks you can perform without a tutorial. Then verify the exam version, read the four-domain outline, and create a small lab that exposes an AWS API, stores or retrieves data, and produces observable output.
Within your first study session, complete three tasks: save the official guide and in-scope service list, mark each domain task as explain, implement, or gap, and choose one programming language you already know. In the next session, build or modify the reference application rather than adding another passive course.
When your labs cover development, security, deployment, and diagnosis, use mixed practice to test transfer between domains. Only then review the live scheduling page, select a delivery option, confirm language and appointment details, and check that the guide attached to your exam is the one governing your final preparation.
Conclusion
AWS Certified Developer - Associate preparation is strongest when it mirrors the developer work the exam measures: build an application, connect it to AWS services, secure its access, deliver it through a workflow, and diagnose deliberate failures. Use the supplied DVA-C02 outline and facts as your working basis, but verify the current exam version and appointment details through AWS before scheduling. Your final readiness test is practical explanation: you should be able to state why an implementation fits the requirement, how it is secured, and what evidence would guide the fix when it fails.