1. Exam Overview

The AWS Certified Developer – Associate (DVA-C02) exam validates the ability to develop, secure, deploy, troubleshoot, and optimize AWS Cloud applications. It is a developer-focused exam: scenarios usually ask for the best application-level implementation choice, not a full enterprise architecture redesign.

Exam format

What the exam rewards

The exam favors solutions that are:

1. Managed: use an AWS feature instead of unnecessary custom code.
2. Loosely coupled: avoid synchronous dependencies when asynchronous processing fits.
3. Least privilege: grant only the actions and resources required.
4. Observable: use metrics, structured logs, traces, alarms, and health checks.
5. Repeatable: deploy immutable artifacts and infrastructure as code.
6. Resilient: design for retries, duplicate messages, partial failures, and rollback.
7. Access-pattern driven: choose a data store and index design from the query pattern.

How to read exam scenarios

Before comparing answers, identify four things:

• Primary requirement: security, latency, ordering, durability, isolation, deployment safety, or troubleshooting?
• Scope: application code, AWS service configuration, IAM permissions, data store design, or release pipeline?
• Constraint words: MOST secure, least operational overhead, near real time, ordered, temporary, without changing code, before invoking the backend.
• Failure model: transient error, poison message, duplicate delivery, hot partition, missing permission, bad deployment, or downstream outage?

A correct answer usually solves the main requirement directly with the smallest appropriate AWS-native mechanism.

2. Exam Domains

Blueprint task map

Revision 2.1 topics to know

The current guide explicitly emphasizes several skills that older study notes may underweight:

• Amazon Q Developer for development assistance and test generation
• Amazon EventBridge event-driven patterns
• Retry logic, circuit breakers, and error handling for third-party integrations
• Lambda real-time processing and transformation
• Specialized stores such as Amazon OpenSearch Service
• Fine-grained application authorization
• Cross-service authentication in microservices
• Data masking and sanitization
• Multi-tenant access patterns
• AWS AppConfig for environment configuration
• Testing event-driven applications
• Structured logging
• Health checks and readiness probes
• Application-level caching and performance analysis

3. Start-to-Finish Study Path

Use this order because each stage supports the next one.

Stage 1: Learn the application building blocks

Focus first on:

• Lambda configuration and invocation behavior
• API Gateway request flow
• SQS, SNS, EventBridge, Step Functions, and Kinesis
• DynamoDB keys, Query vs Scan, consistency, indexes, and TTL
• AWS SDK retries and idempotency

Checkpoint: Given a scenario, you should quickly decide whether the answer is synchronous API, queue, pub/sub fanout, event routing, orchestration, or streaming.

Stage 2: Add security to every pattern

Study:

• IAM roles and temporary credentials
• STS AssumeRole for cross-account access
• Cognito and bearer-token authorization
• KMS and envelope encryption
• Secrets Manager, Parameter Store, and AppConfig
• Multi-tenant authorization and log sanitization

Checkpoint: When credentials appear in an answer, reject long-lived embedded keys unless the scenario explicitly requires something unusual.

Stage 3: Make releases repeatable

Study:

• ZIP and container-image Lambda packaging
• AWS SAM and CloudFormation
• API Gateway stages and Lambda aliases
• CodePipeline, CodeBuild, and CodeDeploy roles
• Canary, blue/green, rolling, and rollback
• Test fixtures, mocks, event-driven tests, and immutable artifacts

Checkpoint: You should know which service orchestrates, which builds, and which deploys.

Stage 4: Operate and optimize

Study:

• CloudWatch metrics, logs, Logs Insights, alarms, and dashboards
• AWS X-Ray traces and annotations
• CloudTrail for AWS API auditing
• Correlation IDs and structured logging
• Readiness probes
• Cache design, hot-key analysis, and Lambda performance tuning

Checkpoint: For each incident, identify whether the first evidence source is logs, metrics, traces, CloudTrail, or deployment output.

Suggested revision cycle

4. Core Concepts by Domain

Domain 1: Development with AWS Services

4.1 Application architecture decisions

Synchronous vs asynchronous

Choreography vs orchestration

• Choreography: services react to events independently. Use EventBridge, SNS, or queues where no central workflow state machine is needed.
• Orchestration: a workflow explicitly controls sequence, branching, retries, and state. Use Step Functions.

Decision rule:
If the question says “multiple services react independently”, think events and queues.
If it says “run A, then B, branch on result, retry C”, think Step Functions.

4.2 Messaging and integration services

SQS, SNS, EventBridge, Step Functions, and Kinesis

SQS rules you must know

Visibility timeout

After a consumer receives an SQS message, the message is hidden temporarily. If processing takes longer than the visibility timeout, another consumer may receive it and process it again.

Use: Set the visibility timeout longer than normal processing time. Extend it when required.

Dead-letter queue (DLQ)

A DLQ isolates messages that repeatedly fail.

Use when: A malformed or poison message is retried repeatedly and delays useful work.

Do not confuse:

• Visibility timeout controls how long a received message stays hidden.
• Retention period controls how long an unprocessed message remains stored.
• DLQ max receive count controls when repeated failures are isolated.

Long polling

Long polling reduces empty receives and unnecessary API calls. It does not solve duplicate processing or poison messages.

Idempotency

SQS and many event-driven patterns can deliver more than once. Consumers must be safe to retry.

A common pattern:

1. Receive an event with a unique business or idempotency key.
2. Check whether the operation has already been applied.
3. Apply the side effect only once.
4. Record completion atomically when possible.

Exam rule: Never assume a standard queue gives exactly-once processing.

Third-party dependency resilience

For unreliable external APIs:

• Set timeouts.
• Use bounded retries.
• Apply exponential backoff with jitter.
• Add a circuit breaker after repeated failures.
• Handle partial failure without cascading across the application.
• Consider asynchronous buffering when immediate completion is unnecessary.

Reject: infinite immediate retries. They amplify outages.