Home / cloud-computing / AWS Certified Developer - Associate / Cheat Sheet
AWS Certified Developer - Associate

AWS Certified Developer - Associate Cheat Sheet

DVA-C02 Tests Cloud-Native Development and AWS SDK Proficiency

The exam tests whether you can build, deploy, debug, and optimize applications on AWS — not just describe which services exist.

Check Your Readiness →
Among the harder certs
Avg: Approximately 63–68%
Pass: 750 / 1000
Most candidates understand AWS Certified Developer - Associate concepts — and still fail. This exam tests how you apply knowledge under pressure.

DVA-C02 Developer Decision Framework

DVA-C02 is the developer-focused AWS associate exam. It requires deeper knowledge of application development patterns, CI/CD pipelines, and debugging tools compared to the SAA-C03. Know the AWS SDK patterns, DynamoDB modeling, and Lambda limitations.

  1. 01
    Development — Lambda, API Gateway, DynamoDB, SQS/SNS, Cognito patterns
  2. 02
    Deployment — CodePipeline, CodeBuild, CodeDeploy, Elastic Beanstalk, SAM
  3. 03
    Security — IAM roles, Cognito, Secrets Manager, Parameter Store
  4. 04
    Testing & Debugging — X-Ray, CloudWatch, Lambda function testing
  5. 05
    Optimization — DynamoDB read/write capacity, Lambda performance, caching

Wrong instinct vs correct approach

A Lambda function needs to process messages reliably from an SQS queue
✕ Wrong instinct

Set the Lambda timeout equal to SQS message visibility timeout

✓ Correct approach

Set the Lambda timeout significantly less than the SQS visibility timeout — if Lambda times out, the message must become visible again before the visibility timeout expires to allow retry; Lambda timeout should be ~60% of visibility timeout

An application needs to distribute the same message to multiple processing systems
✕ Wrong instinct

Use SQS with multiple consumers

✓ Correct approach

Use SNS to publish to a topic with multiple SQS queues as subscribers — SNS fan-out delivers the message to all subscribers; SQS standard queues deliver each message to only one consumer

DynamoDB queries are experiencing hot partition issues
✕ Wrong instinct

Increase the provisioned throughput

✓ Correct approach

Hot partitions result from poor key design — increase partition key cardinality (add a random suffix or use composite keys) to distribute load across partitions; more throughput doesn't solve hot partition key design

Know these cold

  • DynamoDB: design for access patterns upfront — partition key cardinality is critical for performance
  • SQS for point-to-point decoupled processing; SNS for fan-out pub/sub notification
  • Lambda Provisioned Concurrency for consistent low-latency; not just larger memory allocation
  • Lambda timeout must be less than SQS visibility timeout to allow retry on failure
  • Secrets Manager for sensitive secrets with rotation; Parameter Store for configuration values
  • X-Ray for distributed tracing; CloudWatch Logs for function output; CloudWatch Metrics for performance
  • SAM (Serverless Application Model) for local testing and simplified serverless deployment

Can you answer these without checking your notes?

In this scenario: "A Lambda function needs to process messages reliably from an SQS queue" — what should you do first?
Set the Lambda timeout significantly less than the SQS visibility timeout — if Lambda times out, the message must become visible again before the visibility timeout expires to allow retry; Lambda timeout should be ~60% of visibility timeout
In this scenario: "An application needs to distribute the same message to multiple processing systems" — what should you do first?
Use SNS to publish to a topic with multiple SQS queues as subscribers — SNS fan-out delivers the message to all subscribers; SQS standard queues deliver each message to only one consumer
In this scenario: "DynamoDB queries are experiencing hot partition issues" — what should you do first?
Hot partitions result from poor key design — increase partition key cardinality (add a random suffix or use composite keys) to distribute load across partitions; more throughput doesn't solve hot partition key design

Common Exam Mistakes — What candidates get wrong

Misdesigning DynamoDB access patterns

DynamoDB requires that all access patterns be defined upfront — it's not a relational database that supports ad-hoc queries. Using the wrong key design (partition key that creates hot partitions, or no sort key for range queries) creates performance and scalability problems.

Confusing SQS and SNS use cases

SQS is a message queue for decoupled, asynchronous processing (one consumer per message). SNS is a pub/sub notification service (many subscribers per message). Candidates use SNS when queue-based processing is needed, or SQS when fan-out notification is required.

Handling Lambda cold starts incorrectly

Lambda cold starts occur when a new execution environment is initialized. Candidates either ignore cold starts in latency-sensitive scenarios or apply incorrect mitigations (increasing Lambda memory when Provisioned Concurrency is needed for consistent low-latency).

Misidentifying when to use Elastic Beanstalk vs. manual EC2 deployment

Elastic Beanstalk manages the underlying infrastructure automatically while giving the developer application-level control. Manual EC2 deployment gives full infrastructure control but requires more management. Beanstalk is the right choice when infrastructure management overhead should be minimized.

Storing secrets in environment variables instead of Secrets Manager

Lambda environment variables are visible in the function configuration. Sensitive values (API keys, database passwords) must be stored in Secrets Manager or Parameter Store and retrieved at runtime via the SDK — not hardcoded in environment variables.

DVA-C02 tests real AWS development decisions. Test whether your cloud-native development thinking is ready.