AWS DVA-C02 Guide: AWS Certified Developer - Associate

AWS DVA-C02 Developer Associate guide for AWS service APIs, Lambda, event-driven apps, IAM, encryption, secrets, CI/CD workflows, deployment safety, troubleshooting, and optimization.

This guide targets AWS Certified Developer - Associate (DVA-C02), AWS’s current associate-level developer certification for people who build, test, deploy, and troubleshoot cloud applications on AWS. The exam rewards clean judgment about event-driven patterns, Lambda behavior, SDK and API use, IAM boundaries, CI/CD workflows, observability, and the small operational details that make application code reliable in production.

DVA-C02 stays deliberately in the developer lane. AWS expects you to develop and optimize applications, package and deploy with CI/CD workflows, secure application code and data, and resolve application issues. The exam is not asking you to design whole distributed architectures, administer IAM users and groups, administer operating systems, or design networking infrastructure from scratch.

Lambda: AWS serverless compute service for event-driven code execution without managing servers directly.

IAM role: AWS identity that applications or AWS services assume so they can call other AWS services without hard-coded long-term credentials.

Idempotent: Safe to run repeatedly without creating inconsistent duplicates or unintended side effects.

At a glance

Exam fact Current official value
Level Associate
Duration 130 minutes
Format 65 multiple-choice or multiple-response questions, including scored and unscored items
Passing score 720 scaled score
Validity 3 years
Typical next step SOA-C03, SAA-C03, or a deeper specialty-aligned AWS path

As of May 17, 2026, AWS positions DVA-C02 for candidates with 1 or more years of hands-on experience developing and maintaining applications by using AWS services. AWS expects proficiency in at least one high-level programming language, application lifecycle management, cloud-focused application development, development tools, AWS service APIs, the AWS CLI, SDKs, and CI/CD deployment workflows.

The current exam guide lists 50 scored questions and 15 unscored questions. It breaks the scored content into four weighted domains, and this online guide follows that structure directly:

Official scope snapshot

Official domain Weight What this guide emphasizes
1. Development with AWS Services 32% AWS service APIs, SDKs, Lambda events, application integration, APIs, messaging, DynamoDB, data access, retries, and idempotency.
2. Security 26% Application authentication and authorization, IAM roles, temporary credentials, KMS, encryption, secrets, sensitive data, and tenant-safe access.
3. Deployment 24% Packaging, dependencies, repositories, environment configuration, test environments, IaC awareness, CI/CD workflows, deployment strategies, and rollback.
4. Troubleshooting and Optimization 18% Logs, metrics, traces, custom metrics, health checks, concurrency, caching, event filters, bottleneck isolation, and performance tuning.

The useful boundary is simple: answer as the developer responsible for application behavior, secure integration, release safety, and evidence-based debugging. If an answer rebuilds the whole platform when the prompt asks for application behavior, it is probably too broad.

Developer application loop

Most DVA-C02 questions can be placed in this loop.

    flowchart LR
	  C["Application code and SDK/API calls"] --> I["Managed integration: API, event, queue, stream, or data store"]
	  I --> S["Security: role, token, secret, encryption, tenant boundary"]
	  S --> P["Package and deploy through controlled environments"]
	  P --> O["Observe logs, metrics, traces, health, and deployment output"]
	  O --> T["Troubleshoot, tune, roll back, or optimize"]
	  T --> C

If the answer skips security, the app may work but leak access. If it skips deployment safety, the code may be correct but hard to release. If it skips observability, failures become guesses instead of evidence.

What strong answers usually do

  • classify the stem into the right lane before choosing a service
  • separate application logic from platform integration details such as retries, dead-letter handling, and permissions
  • prefer managed event-driven building blocks unless the scenario clearly needs lower-level infrastructure control
  • treat observability and troubleshooting as part of the application design, not as post-deployment cleanup
  • choose the narrowest secure access pattern that still keeps the application maintainable
  • preserve idempotency and failure handling when using queues, streams, retries, and asynchronous triggers
  • distinguish code packaging, runtime configuration, and deployment orchestration before choosing a CI/CD answer

How to use this guide

  1. Start with the study plan if you want a realistic weekly sequence.
  2. Work the four weighted domain chapters in order, starting with Development with AWS Services and Security.
  3. Use the cheat sheet after you already understand the chapter logic.
  4. Use the cheat sheet when API, Lambda, event, IAM, deployment, and troubleshooting choices start to blur.
  5. Keep the glossary open when messaging, IAM, KMS, and deployment terminology begins to blur together.
  6. Use the resources page to stay anchored to the current AWS exam guide and primary service documentation.
  7. Use the FAQ for exam-day rules, final-scope judgment, and last-week review decisions.

Coverage map against the current exam guide

What the exam is really testing

Scenario pressure Strong DVA-C02 reasoning
Lambda behaves differently under retries Check invocation type, event source mapping, timeout, concurrency, DLQ or destination, idempotency, and downstream side effects.
A service call fails from application code Check SDK request shape, IAM role permissions, resource policy, region, endpoint, retries, throttling, and error handling.
Users can sign in but cannot act Separate authentication from authorization; check token claims, app logic, IAM role, resource policy, and tenant boundary.
A secret or key is exposed in config Move secrets to Secrets Manager or Parameter Store, use runtime retrieval, narrow IAM, and avoid logging sensitive values.
A release fails after promotion Check artifact version, runtime config, deployment events, alarms, aliases or stages, rollback path, and recent code changes.
Performance degrades under load Check concurrency, downstream throttling, cache fit, DynamoDB key design, batch size, payload shape, and event filtering before scaling broadly.

Common DVA-C02 traps

Trap Better exam posture
Solving a developer issue with a full architecture redesign Stay in the developer lane unless the prompt explicitly asks for architecture design.
Choosing synchronous integration by habit Use async buffering, event fan-out, or orchestration when spikes, retries, or decoupling require it.
Adding broad IAM permissions to make code work Fix the exact role, action, resource, condition, key policy, or resource policy that blocks the path.
Hiding environment values in artifacts Keep artifacts immutable and move environment-specific configuration to controlled runtime config.
Treating logs, metrics, and traces as interchangeable Use logs for detail, metrics for signals and alarms, and traces for request path and latency breakdown.
Raising capacity before proving the bottleneck Inspect evidence first: throttles, concurrency, downstream latency, cache misses, hot keys, and payload size.

If two answers both sound right

For DVA-C02, the stronger answer is usually the one that stays in the developer lane:

  • choose the option that fixes application behavior before one that redesigns the entire architecture
  • choose the option that uses an existing AWS managed integration before a larger custom platform build
  • choose the option that narrows permissions and secrets exposure instead of embedding credentials in code or config
  • choose the option that reduces blast radius during deployment and rollback instead of maximizing change speed alone

In this section

Revised on Monday, June 15, 2026