AWS Developer Associate Exam Guide (DVA-C02): Study Plan, AWS Development, and Practice Questions
The AWS Certified Developer – Associate (DVA-C02) certification validates your ability to develop, deploy, secure, troubleshoot, and optimize applications using Amazon Web Services. Unlike certifications primarily focused on infrastructure architecture, Developer Associate emphasizes what happens inside applications: how code calls AWS APIs, how Lambda functions process events, how DynamoDB handles concurrent writes, how credentials are managed, and how software is safely deployed.
This guide explains the DVA-C02 exam structure, its four domains, the AWS development concepts you must understand, and a practical approach to solving scenario-based questions. It also includes a six-week study plan, an embedded YouTube video, a hands-on AWS development project using Python and Terraform, and a full-length practice exam. Because AWS is introducing DVA-C03 in late 2026, the guide also explains how to adjust your preparation for the upcoming exam transition.
Table of Contents
- Introduction to AWS Developer Associate
- Understanding the DVA-C02 Exam
- AWS Development Concepts You Must Master
- How to Solve DVA-C02 Scenario Questions
- Common DVA-C02 Preparation Mistakes
- Six-Week AWS Developer Associate Study Plan
- Test Your Knowledge with a Full DVA-C02 Practice Exam
- Frequently Asked Questions
- Conclusion
Introduction to AWS Developer Associate
Developing applications on AWS involves more than writing code and deploying it to a server. Applications interact with managed databases, object storage, authentication systems, queues, monitoring services, and deployment pipelines. Each integration introduces configuration, permissions, performance characteristics, and failure scenarios that developers need to understand.
Developer Associate focuses on those practical responsibilities. The exam expects candidates to recognize safe and effective ways to implement AWS service integrations, handle errors, protect sensitive information, and release software reliably.
What Is the DVA-C02 Certification?
AWS Certified Developer – Associate is an Associate-level certification focused on developing and maintaining applications that use AWS services.
It validates your ability to:
- Develop applications using AWS SDKs and service APIs.
- Implement serverless functions and event-driven integrations.
- Read and write data using supported AWS storage services.
- Apply authentication, authorization, encryption, and secrets management.
- Package, test, and deploy applications.
- Use CI/CD workflows and supported deployment strategies.
- Investigate application failures through logs, metrics, and traces.
- Optimize AWS application performance and resource usage.
The exam may ask what happens when a DynamoDB request is throttled, why a Lambda function cannot access a service after being attached to a VPC, or how to deploy a new function version without immediately sending all production traffic to it.
These are application development and operational questions rather than broad infrastructure design exercises.
Developer Associate vs. Solutions Architect Associate
Developer Associate and Solutions Architect Associate share knowledge of services such as Lambda, S3, DynamoDB, IAM, and API Gateway, but they test different responsibilities.
Solutions Architect Associate emphasizes selecting services and assembling architectures. Developer Associate places more emphasis on implementing those integrations and understanding their runtime behavior.
For example, an architecture question might ask whether DynamoDB is appropriate for a high-scale key-value workload. A developer question may ask why a DynamoDB query requires pagination, how to avoid duplicate writes, or how to handle UnprocessedItems after a batch operation.
Neither certification is universally more valuable. The better choice depends on whether your work focuses more on solution architecture or application implementation.
Who Should Take the Exam?
DVA-C02 is especially relevant to backend developers, full-stack engineers, serverless developers, DevOps engineers, and platform engineers who implement or maintain software on AWS.
AWS describes the target candidate as having experience developing and maintaining applications using AWS services. Hands-on familiarity with at least one programming language and common application development practices is useful.
If you already develop applications in Python, JavaScript, Java, PHP, or another language, the most valuable preparation will often be learning AWS-specific APIs, authorization mechanisms, deployment behavior, and failure handling.
You do not need to become an expert in every AWS service. You do need to understand the development responsibilities associated with the services covered by the exam guide.
Understanding the DVA-C02 Exam
The DVA-C02 exam tests both service knowledge and the ability to apply that knowledge to application scenarios. Many questions describe code behavior, deployment problems, security requirements, or performance symptoms.
Understanding the official exam domains helps you prepare efficiently rather than studying every AWS product with equal depth.
Exam Format, Scoring, and Duration
The published DVA-C02 exam format is:
| Attribute | Details |
|---|---|
| Certification level | Associate |
| Exam code | DVA-C02 |
| Duration | 130 minutes |
| Total questions | 65 |
| Scored questions | 50 |
| Unscored questions | 15 |
| Question formats | Multiple choice and multiple response |
| Passing scaled score | 720 out of 1,000 |
| Standard exam price | $150 USD |
AWS uses scaled scoring, so 720 should not be interpreted as exactly 72% of questions answered correctly. Scored domains contribute according to their weightings, and the exam uses an overall passing standard.
With 130 minutes for 65 questions, you have an average of two minutes per question. Some questions are short, but scenarios involving multiple AWS integrations can require more careful analysis.
There is no penalty for guessing. If you are uncertain, eliminate clearly incorrect choices, make a reasoned selection, and return to the question later if time permits.
The Four DVA-C02 Exam Domains
The official DVA-C02 exam guide identifies four domains with the following weightings.
| Domain | Weight | Main Topics |
|---|---|---|
| Development with AWS Services | 32% | AWS SDKs, Lambda, event-driven applications, DynamoDB, S3 |
| Security | 26% | IAM, Cognito, KMS, temporary credentials, secrets |
| Deployment | 24% | Application packages, environments, CI/CD, CloudFormation, SAM, deployment strategies |
| Troubleshooting and Optimization | 18% | CloudWatch, tracing, logging, debugging, performance optimization |
These topics overlap. For example, a Lambda function that reads DynamoDB may require development knowledge, IAM permissions, retry behavior, and CloudWatch monitoring in the same question.
Study the domains together through realistic application workflows. This reinforces how the services actually interact.
DVA-C02 vs. DVA-C03: Certification Update
AWS has announced a new Developer Associate exam version, DVA-C03. Registration for the updated exam is scheduled to open October 27, 2026. AWS currently lists November 30, 2026 as the final testing date for DVA-C02, though candidates should verify scheduling availability directly with AWS.
For candidates taking DVA-C02, the four-domain exam guide remains the relevant preparation reference. Those planning for DVA-C03 should review the updated official exam guide when it becomes available.
Fundamental development skills such as SDK integration, IAM, Lambda processing, deployment automation, and troubleshooting remain useful regardless of the exam version.
However, do not assume a DVA-C02 practice exam covers every new or reweighted topic in DVA-C03.
AWS Development Concepts You Must Master
The most important DVA-C02 topics involve using AWS services correctly from application code. Understanding APIs, authentication, error responses, retries, and data consistency is more valuable than memorizing every console setting.
When studying a service, focus on its runtime behavior and how developers should handle failure.
AWS Lambda and API Gateway
Lambda is central to AWS serverless application development. A function receives an event, executes code in a managed environment, and returns a response or processes the event asynchronously.
Know the differences between synchronous, asynchronous, and poll-based invocation. These models have different retry and failure-handling behavior.
Important Lambda concepts include:
- Handler signatures and event payloads.
- Execution roles and temporary AWS credentials.
- Execution environment reuse and initialization outside the handler.
- Memory, CPU allocation, timeout, and concurrency.
- Reserved concurrency versus provisioned concurrency.
- Versions, aliases, and deployment traffic shifting.
- Environment variables, layers, and deployment packages.
- Invocation retries and failure destinations.
A common exam scenario involves a Lambda function creating a new database connection on every invocation. If the execution environment is reused, creating clients and managing connection reuse appropriately can reduce unnecessary setup overhead.
However, execution environment reuse is not guaranteed, and functions must not rely on local state to preserve critical business data across invocations.
API Gateway questions often involve authentication, authorization, request validation, CORS, throttling, HTTP status codes, and Lambda proxy integration response formats.
For example, a Lambda proxy response typically needs a valid object containing fields such as statusCode and a string-valued body. Returning an arbitrary Python dictionary without the expected integration response structure can cause API errors.
For a detailed introduction to the compute model, read What Is AWS Lambda?.
DynamoDB and Amazon S3
DynamoDB questions frequently require understanding the data-access pattern rather than selecting a database from a list of products.
Important concepts include partition keys, sort keys, primary key design, global and local secondary indexes, consistency models, transactions, conditional expressions, and pagination.
Be comfortable with the following situations:
- Conditional writes: Prevent overwriting an existing item or implement optimistic concurrency.
- Pagination: Continue querying when
LastEvaluatedKeyis returned. - Query vs. Scan: Use key-based access patterns efficiently.
- Batch writes: Retry only unprocessed items with appropriate backoff.
- Transactions: Coordinate supported atomic operations across items.
- GSI consistency: Account for eventually consistent global secondary index reads.
For example, two API requests may attempt to create an order with the same ID. A conditional PutItem request can enforce that only one creation succeeds without requiring a separate read-before-write operation.
S3 questions commonly cover object permissions, storage classes, presigned URLs, versioning, multipart uploads, encryption, and event notifications.
A browser that needs to upload a file directly to a private S3 bucket can use a short-lived presigned URL generated by an authorized backend. The browser does not need permanent AWS secret keys.
For large uploads, multipart upload enables retrying individual parts instead of restarting the entire transfer. Applications should also handle incomplete multipart uploads and associated storage costs.
SQS, SNS, EventBridge, and Step Functions
AWS applications frequently communicate asynchronously. This makes message delivery and failure handling important developer responsibilities.
Understand the distinctions among:
- Amazon SQS: Durable queues with visibility timeouts and consumer acknowledgments.
- Amazon SNS: Publish/subscribe message distribution.
- Amazon EventBridge: Event routing and integration through supported event-bus capabilities.
- AWS Step Functions: Workflow orchestration, state transitions, retries, and supported task integrations.
For example, an order service may publish an event, which is distributed to independent notification and analytics consumers. Each downstream consumer can fail or recover independently.
At-least-once delivery means the same logical message may be processed more than once. Application code must therefore protect non-repeatable side effects using stable event IDs or other suitable idempotency mechanisms.
SQS FIFO questions may involve message group IDs. Events for the same entity can share a group ID to preserve ordering within the supported group semantics, while independent entities use different groups for concurrency.
Also study partial batch failures in Lambda SQS consumers. Without the proper response configuration, one failed record can lead to an entire batch being retried, including records that already produced successful business effects.
IAM, Cognito, KMS, and Secrets Management
DVA-C02 security questions emphasize how applications use AWS credentials and protect sensitive data.
Core concepts include:
- IAM roles and temporary credentials.
- Execution roles for Lambda, ECS, and EC2 workloads.
- Resource-based policies and explicit deny behavior.
- Cross-account role assumption through AWS STS.
- Amazon Cognito user pools and identity pools.
- KMS encryption and envelope encryption.
- AWS Secrets Manager and Systems Manager Parameter Store.
- Signed AWS API requests using Signature Version 4.
An application running on AWS compute should normally use its assigned role credentials rather than store long-lived access keys in a configuration file.
A common security scenario involves a rotating database password. Secrets Manager can store and rotate supported secrets, but application code must also refresh cached credentials appropriately rather than holding an obsolete password indefinitely.
Another involves KMS-encrypted objects. An application may have permission to read an S3 object but fail because it lacks the necessary KMS authorization.
For Cognito, distinguish user registration and authentication from obtaining temporary AWS credentials. User pools and identity pools solve related but different problems.
CI/CD, Infrastructure as Code, and Deployment Strategies
Developers must understand how application code moves from a repository into a reliable production release.
Important services and tools include AWS CodeBuild, CodePipeline, CodeDeploy, CloudFormation, AWS SAM, the AWS CDK, and deployment automation through suitable CI systems.
Study:
- Build artifacts and dependency packaging.
- Environment-specific configuration.
- Automated testing in deployment pipelines.
- Immutable artifact references and reproducible releases.
- CloudFormation change sets.
- Lambda versions and aliases.
- Canary and linear traffic shifting.
- Rollback based on monitoring and validation failures.
For example, deploying a Lambda function's $LATEST revision directly to production does not provide the same release stability as publishing an immutable version and routing production traffic through an alias.
Canary deployments allow a limited percentage of traffic to reach a new release before gradually increasing exposure.
A production pipeline should test the actual artifact it intends to deploy. Rebuilding a different artifact after testing can create a mismatch between what was validated and what reaches production.
CloudWatch, X-Ray, and Application Troubleshooting
Developer Associate includes troubleshooting and optimization because production development does not end when code is deployed.
Know how to use CloudWatch Logs, CloudWatch metrics, Logs Insights, tracing integrations, and X-Ray to investigate application behavior.
For example, a Lambda function may show normal execution duration locally but time out after a VPC configuration change. The problem might be missing network egress or a required VPC endpoint rather than inefficient application code.
Useful operational signals include:
- Lambda invocation duration and errors.
- Throttle counts and concurrency.
- API Gateway 4xx and 5xx errors.
- DynamoDB throttling and capacity consumption.
- SQS oldest message age and DLQ depth.
- Application request IDs and distributed trace context.
A custom CloudWatch metric is identified by its namespace, metric name, and dimensions. If an alarm monitors a different dimension combination than the application publishes, the alarm may not evaluate the expected data.
Do not use unique request IDs or user IDs as high-cardinality custom metric dimensions. Logs and traces are generally better for per-request identifiers.
How to Solve DVA-C02 Scenario Questions
DVA-C02 questions often provide symptoms rather than naming the underlying problem. A developer must identify whether the issue concerns application code, an AWS API contract, credentials, configuration, service quotas, or retry behavior.
A useful approach is to identify the failing boundary first, then evaluate the AWS feature that addresses it.
Identify the Application Requirement
Look for phrases that reveal the intended behavior:
- Prevent duplicate records: Consider conditional writes or idempotency mechanisms.
- Retry throttled requests: Use retryable error handling and exponential backoff with jitter.
- Do not expose credentials: Use workload roles, temporary credentials, or appropriate signed operations.
- Process records independently: Consider partial batch failure handling.
- Deploy without downtime: Evaluate versions, aliases, traffic shifting, and rollback.
- Investigate latency: Examine metrics, logs, and traces before changing capacity.
- Ensure ordering: Identify FIFO and message group constraints.
- Support secret rotation: Select a managed secret store and a correct refresh strategy.
Once the requirement is clear, distinguish application behavior from infrastructure behavior. Adding IAM permissions cannot solve a missing network route, and increasing Lambda memory cannot correct an invalid API response structure.
Understand Common AWS Development Trade-offs
Many questions compare two features that sound similar but solve different problems.
For example, reserved concurrency limits or reserves Lambda concurrency capacity for a function, while provisioned concurrency maintains initialized execution environments for supported function versions or aliases.
If a database cannot handle more than 20 concurrent workers, reserved concurrency may be appropriate. If initialization latency is the main problem, provisioned concurrency addresses a different requirement.
Other distinctions worth practicing include:
- DynamoDB conditional writes versus read-before-write validation.
- SQS standard queues versus FIFO queues.
- Secrets Manager versus ordinary application configuration.
- Lambda asynchronous destinations versus SQS dead-letter queues.
- API Gateway authentication versus application-level authorization.
- CloudWatch metrics versus structured logs and distributed traces.
Do not choose a feature solely because it is associated with the AWS service mentioned in the scenario. Choose it because it produces the behavior required by the application.
Production Design Example: Reliable Order Processing
Consider an e-commerce backend using API Gateway, Lambda, DynamoDB, and SQS. Customers submit orders through an HTTP API, while notifications and fulfillment tasks run asynchronously.
The system must satisfy these requirements:
- Repeated HTTP requests must not create duplicate orders.
- Order records must be durably stored before downstream work begins.
- Temporary notification failures must not block the checkout API.
- Workers may retry failed tasks without duplicating shipments.
- Deployment changes must be reversible.
The API Lambda validates the request, derives or receives a stable idempotency key, and writes the order through a DynamoDB conditional operation. If the record already exists, the application checks whether the stored request matches the original request before returning a successful duplicate response.
For reliable downstream distribution, the design must also address the gap between committing a database write and publishing an event. A suitable approach is using DynamoDB Streams to capture committed table changes, then integrating the stream with downstream processing.
Notification and fulfillment consumers should use their own idempotency records because successful delivery does not guarantee exactly-once execution of business side effects.
For Lambda deployment, publish immutable function versions and direct production requests through a managed alias. Use validation and monitoring to determine whether traffic should continue shifting to a new version.
Failure scenarios to test include repeated checkout submissions, conditional write conflicts, DynamoDB throttling, partial processing failures, and downstream service unavailability.
These scenarios illustrate what makes DVA-C02 different from a basic cloud certification: developers must understand not only the service configuration, but also the correctness of application behavior when services fail.
Common DVA-C02 Preparation Mistakes
Many candidates understand how to deploy a simple Lambda function but have limited experience with the service behaviors that create real production bugs.
Preparation should focus on implementing safe application behavior under retries, concurrency, authorization checks, and deployment changes.
Mistakes in AWS Application Development
Common mistakes include:
- Ignoring SDK partial failures: A successful batch response can still contain unprocessed entries.
- Using unconditional writes: Repeated requests overwrite records or cause duplicate business effects.
- Confusing Lambda invocation models: Incorrect assumptions about retries and acknowledgments.
- Storing AWS credentials in code: Long-lived secrets leak through source control or deployment artifacts.
- Ignoring token validation: Authentication is accepted without validating the intended issuer or audience.
- Creating one database connection per request unnecessarily: Connection overhead and resource exhaustion increase.
- Ignoring network egress after VPC attachment: Functions cannot reach public endpoints or AWS APIs.
- Deploying mutable application artifacts: Rollback becomes unpredictable.
- Logging sensitive request payloads: Passwords or authorization tokens appear in operational logs.
- Assuming every delivery is unique: Retries create duplicate side effects.
When studying a service, learn at least one realistic failure scenario and how application code should respond.
Mistakes in Exam Preparation and Time Management
Do not limit preparation to watching videos or reading summaries. Practical experience with AWS SDKs, permissions, error messages, and deployment workflows makes unfamiliar questions easier to solve.
Review incorrect answers carefully. If a question involves DynamoDB throttling, investigate retry handling and capacity behavior rather than memorizing one choice.
Also review correct guesses. A correct answer without a sound explanation may indicate a topic that remains weak.
During timed practice, avoid spending too long on one difficult scenario. Eliminate incorrect choices, make a reasoned selection, and revisit the question if time remains.
Six-Week AWS Developer Associate Study Plan
A useful Developer Associate study plan combines AWS documentation, video learning, coding exercises, troubleshooting, and timed practice questions.
The following six-week schedule is designed for candidates who already know at least one programming language and understand basic application development. Adjust the schedule according to your experience and intended exam date.
Weekly Preparation Schedule
| Week | Focus | Practical Goal |
|---|---|---|
| 1 | AWS SDKs, IAM roles, Lambda, API Gateway | Build and invoke a Lambda function using temporary credentials |
| 2 | DynamoDB, S3, conditional writes, pagination | Implement safe persistence and file operations |
| 3 | SQS, SNS, EventBridge, Step Functions | Implement asynchronous processing and failure recovery |
| 4 | Cognito, KMS, Secrets Manager, IAM authorization | Secure application credentials and data |
| 5 | CI/CD, SAM, CloudFormation, CloudWatch, tracing | Deploy, monitor, and troubleshoot an application release |
| 6 | Full practice exams and targeted review | Identify weak areas and improve timed scenario reasoning |
Do not wait until the final week to write code. Use small exercises throughout the schedule to reinforce service behavior.
For example, after studying DynamoDB, implement a conditional write and deliberately cause a duplicate-key conflict. After studying Lambda, compare synchronous invocation with SQS-triggered processing.
Video Course: AWS Developer Associate Preparation
Video-based learning can reinforce AWS service integrations and development concepts, especially when code examples and architecture diagrams are involved.
Use the following YouTube video as a supplementary resource alongside the official AWS exam guide and hands-on development exercises.
Supplementary video learning resource for AWS Developer Associate preparation. Watch on YouTube.
When reviewing examples, pause before the solution is explained and identify which AWS feature should solve the problem.
For example, if a demonstration involves a repeated DynamoDB write, ask whether the application needs a conditional expression, a transaction, or an idempotency record. If it involves Lambda initialization latency, distinguish memory settings from provisioned concurrency.
Then test the relevant behavior with a small implementation. Direct experience with error responses, retries, and IAM permissions is more valuable than simply recognizing an AWS service name.
Ready-to-Use Example: Lambda and DynamoDB with Terraform
This practical exercise creates a DynamoDB table and a Lambda function that stores orders using conditional writes. It demonstrates how AWS SDKs, IAM permissions, and DynamoDB conditions work together to prevent accidental duplicate records.
The project uses Terraform for infrastructure, Python for the Lambda application, and boto3 for AWS service access.
The goal is to create an order only if its identifier does not already exist. Repeating the same request should return an idempotent result, while trying to reuse the same identifier for a different payload should produce a conflict.
Create this project structure:
dva-c02-lab/
main.tf
outputs.tf
lambda/
handler.py
test_app.py
Create lambda/handler.py:
import hashlib
import json
import logging
import os
import boto3
from botocore.exceptions import ClientError
TABLE_NAME = os.environ["TABLE_NAME"]
logger = logging.getLogger(__name__)
logger.setLevel(logging.INFO)
# Reuse the DynamoDB resource when the Lambda
# execution environment is reused.
dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table(TABLE_NAME)
def response(status_code: int, body: dict) -> dict:
return {
"statusCode": status_code,
"body": json.dumps(body),
}
def lambda_handler(event: dict, context) -> dict:
order_id = event.get("order_id")
customer_id = event.get("customer_id")
amount_cents = event.get("amount_cents")
if not isinstance(order_id, str) or not order_id:
return response(400, {"error": "Invalid order_id"})
if not isinstance(customer_id, str) or not customer_id:
return response(400, {"error": "Invalid customer_id"})
if (
type(amount_cents) is not int
or amount_cents <= 0
):
return response(400, {"error": "Invalid amount"})
# Calculate a stable fingerprint of the
# business request.
payload = json.dumps(
{
"order_id": order_id,
"customer_id": customer_id,
"amount_cents": amount_cents,
},
sort_keys=True,
separators=(",", ":"),
)
fingerprint = hashlib.sha256(
payload.encode("utf-8")
).hexdigest()
item = {
"order_id": order_id,
"customer_id": customer_id,
"amount_cents": amount_cents,
"request_hash": fingerprint,
"status": "created",
}
try:
# Atomic creation without a read-before-write
# race between concurrent requests.
table.put_item(
Item=item,
ConditionExpression=(
"attribute_not_exists(order_id)"
),
)
logger.info(
"Order created: order_id=%s",
order_id,
)
return response(
201,
{
"order_id": order_id,
"result": "created",
},
)
except ClientError as exc:
code = exc.response["Error"]["Code"]
if code != "ConditionalCheckFailedException":
logger.exception("DynamoDB request failed")
raise
# An item already exists: determine whether
# this is a safe retry or a conflicting request.
existing = table.get_item(
Key={"order_id": order_id},
ConsistentRead=True,
).get("Item")
if existing is None:
# Rare concurrent deletion/change:
# let the caller retry instead of assuming
# that the original write succeeded.
return response(
503,
{"error": "Retry the request"},
)
if existing.get("request_hash") == fingerprint:
return response(
200,
{
"order_id": order_id,
"result": "already_exists",
},
)
return response(
409,
{
"error": "Order ID already used",
"order_id": order_id,
},
)
The conditional expression prevents a second request from overwriting an existing order. A strongly consistent read is used after a conditional failure to distinguish a repeated request from a conflicting payload.
This implements a useful creation-idempotency pattern, but it does not represent a complete order-processing workflow. Production systems must also coordinate downstream events, payments, inventory changes, and other side effects.
Next, create main.tf:
terraform {
required_version = ">= 1.5.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 6.0"
}
archive = {
source = "hashicorp/archive"
version = "~> 2.0"
}
}
}
provider "aws" {
region = "us-west-2"
}
# ------------------------------------
# DynamoDB table
# ------------------------------------
resource "aws_dynamodb_table" "orders" {
name = "dva-c02-demo-orders"
billing_mode = "PAY_PER_REQUEST"
hash_key = "order_id"
attribute {
name = "order_id"
type = "S"
}
point_in_time_recovery {
enabled = true
}
tags = {
Project = "dva-c02-study"
}
}
# ------------------------------------
# Lambda execution role
# ------------------------------------
data "aws_iam_policy_document" "trust" {
statement {
actions = ["sts:AssumeRole"]
principals {
type = "Service"
identifiers = ["lambda.amazonaws.com"]
}
}
}
resource "aws_iam_role" "lambda" {
name_prefix = "dva-c02-demo-"
assume_role_policy = (
data.aws_iam_policy_document.trust.json
)
}
# Allow only the required DynamoDB operations.
data "aws_iam_policy_document" "database" {
statement {
actions = [
"dynamodb:PutItem",
"dynamodb:GetItem"
]
resources = [
aws_dynamodb_table.orders.arn
]
}
}
resource "aws_iam_role_policy" "database" {
name = "order-read-write"
role = aws_iam_role.lambda.id
policy = data.aws_iam_policy_document.database.json
}
# Standard Lambda logging permissions.
resource "aws_iam_role_policy_attachment" "logging" {
role = aws_iam_role.lambda.name
policy_arn = (
"arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
)
}
# ------------------------------------
# Lambda function
# ------------------------------------
data "archive_file" "lambda" {
type = "zip"
source_file = "${path.module}/lambda/handler.py"
output_path = "${path.module}/lambda.zip"
}
resource "aws_cloudwatch_log_group" "lambda" {
name = "/aws/lambda/dva-c02-demo-orders"
retention_in_days = 7
}
resource "aws_lambda_function" "orders" {
function_name = "dva-c02-demo-orders"
role = aws_iam_role.lambda.arn
runtime = "python3.12"
handler = "handler.lambda_handler"
filename = data.archive_file.lambda.output_path
source_code_hash = (
data.archive_file.lambda.output_base64sha256
)
timeout = 10
memory_size = 128
environment {
variables = {
TABLE_NAME = aws_dynamodb_table.orders.name
}
}
depends_on = [
aws_cloudwatch_log_group.lambda,
aws_iam_role_policy.database,
aws_iam_role_policy_attachment.logging
]
}
The IAM execution role permits only dynamodb:PutItem and dynamodb:GetItem against the specific order table. It does not grant table deletion, broad DynamoDB administration, or account-wide access.
The Lambda function uses boto3's default credential provider chain, so it receives temporary role credentials without embedding AWS access keys in the source code.
Create outputs.tf:
output "function_name" {
value = aws_lambda_function.orders.function_name
}
output "table_name" {
value = aws_dynamodb_table.orders.name
}
To test the deployed Lambda, create test_app.py:
import json
import os
import boto3
REGION = os.getenv("AWS_REGION", "us-west-2")
FUNCTION_NAME = os.environ["FUNCTION_NAME"]
lambda_client = boto3.client(
"lambda",
region_name=REGION,
)
def invoke_order(
order_id: str,
customer_id: str,
amount_cents: int,
) -> dict:
response = lambda_client.invoke(
FunctionName=FUNCTION_NAME,
InvocationType="RequestResponse",
Payload=json.dumps({
"order_id": order_id,
"customer_id": customer_id,
"amount_cents": amount_cents,
}).encode("utf-8"),
)
result = json.loads(
response["Payload"].read()
)
if response.get("FunctionError"):
raise RuntimeError(result)
body = json.loads(result["body"])
print(
"Status:",
result["statusCode"],
"Body:",
body,
)
return result
def main():
# First request creates the order.
first = invoke_order(
"order-1001",
"customer-42",
4999,
)
# Same logical request is a safe retry.
duplicate = invoke_order(
"order-1001",
"customer-42",
4999,
)
# Same ID with different business content
# must not be accepted as the same request.
conflict = invoke_order(
"order-1001",
"customer-42",
9999,
)
assert first["statusCode"] == 201
assert duplicate["statusCode"] == 200
assert conflict["statusCode"] == 409
if __name__ == "__main__":
main()
The test demonstrates three application outcomes: creating a new record, handling a safe retry, and rejecting an identifier reused with conflicting data.
Deploy and run the exercise:
# Use configured AWS credentials.
export AWS_REGION="us-west-2"
# Provision infrastructure.
terraform init
terraform fmt
terraform validate
terraform plan
terraform apply
# Export deployed resource names.
export FUNCTION_NAME="$(
terraform output -raw function_name
)"
export TABLE_NAME="$(
terraform output -raw table_name
)"
# Prepare the local Python environment.
python3 -m venv .venv
source .venv/bin/activate
pip install boto3
# Execute application integration tests.
python test_app.py
# Inspect the persisted order.
aws dynamodb get-item \
--table-name "$TABLE_NAME" \
--key '{"order_id":{"S":"order-1001"}}' \
--consistent-read
# Inspect application logs.
aws logs tail \
"/aws/lambda/dva-c02-demo-orders" \
--since 15m
# Remove the disposable infrastructure.
terraform destroy
The expected results are HTTP-style statuses 201, 200, and 409. The Lambda function is invoked directly by the test script; API Gateway is not part of this minimal exercise.
The example uses DynamoDB on-demand capacity so you do not need to provision read and write capacity manually. AWS resources may still incur charges, including DynamoDB storage, requests, and point-in-time recovery.
The exercise is intentionally focused on AWS development behavior rather than a large architecture diagram. For deeper infrastructure provisioning concepts, read the SysDesPro article about Terraform in the related reading section.
Developer Readiness Checklist
Before taking a full-length DVA-C02 practice exam, make sure you can explain the following without consulting documentation:
- How AWS SDKs obtain and refresh credentials.
- How Lambda execution environment reuse affects application code.
- When to use reserved versus provisioned concurrency.
- How DynamoDB conditional writes prevent write races.
- How DynamoDB pagination and batch retry behavior work.
- How presigned S3 URLs and multipart uploads work.
- How SQS visibility timeout and DLQs affect retries.
- How SNS filtering and EventBridge routing differ.
- How IAM and KMS permissions interact.
- How Cognito user pools differ from identity pools.
- How to package, version, and deploy a Lambda function.
- How to investigate failures using CloudWatch logs, metrics, and traces.
- How to recognize throttling, timeouts, and invalid integration responses.
If you understand the service name but cannot explain the failure behavior, revisit that topic with a small AWS experiment.
Test Your Knowledge with a Full DVA-C02 Practice Exam
After studying AWS application development and practicing important service integrations, the next step is applying your knowledge to realistic exam scenarios.
A timed practice exam tests whether you can reason through multiple topics without looking up each answer. This is particularly useful for DVA-C02 because the scenarios often contain subtle distinctions between AWS SDK behavior, authorization, deployment, and error recovery.
Why Full-Length Practice Exams Matter
Short quizzes are useful for learning individual services, but a full practice exam tests sustained concentration and time management.
Practice exams help you:
- Identify the underlying cause of AWS application errors.
- Recognize SDK and service behavior described indirectly.
- Compare plausible solutions under specific constraints.
- Practice multiple-response questions.
- Manage a 130-minute examination session.
- Discover which domains require additional preparation.
Try completing at least one full-length test without external documentation. Reviewing explanations afterward provides a more accurate view of your knowledge than answering questions while searching for each solution.
Take the 65-Question DVA-C02 Practice Exam
When you are ready to apply the concepts covered in this guide, try the AWS Developer Associate (DVA-C02) Full Practice Exam on ExamMe.
This free, independent practice exam includes 65 original questions with a suggested duration of 130 minutes. It covers development with AWS services, application security, deployment, troubleshooting, and optimization. It also provides explanations for every answer choice and official references to support further study.
The scenarios include practical AWS developer topics such as DynamoDB conditional writes and pagination, Lambda retries and concurrency, IAM and KMS permissions, Cognito authorization, API Gateway integration errors, SQS message processing, deployment strategies, and application observability.
For the most realistic experience, reserve an uninterrupted 130-minute session and complete the test without checking documentation or asking for help.
The practice exam is independent preparation material and is not an official AWS examination or a guarantee of certification success. It specifically targets DVA-C02, so candidates planning to take DVA-C03 should also study the updated official exam guide.
Analyze Your Results and Improve
The value of a practice exam is not limited to the final score. Review your answers according to both correctness and confidence.
- Correct and confident: You understand the service behavior and can explain why the answer is appropriate.
- Correct but uncertain: You selected the right option without fully understanding the difference between alternatives.
- Incorrect: You missed a requirement, misunderstood an AWS feature, or applied the wrong development pattern.
For each uncertain or incorrect answer, record the underlying concept and reproduce it in documentation or a small implementation.
For example, if you miss a DynamoDB question involving LastEvaluatedKey, implement a paginated query rather than memorizing that pagination is required.
If you miss a Lambda deployment question, publish two versions, configure an alias, and inspect how traffic shifting and rollback work.
Practical review helps turn isolated exam facts into development skills that remain useful after certification.
Frequently Asked Questions
Developer Associate candidates commonly ask about programming requirements, exam difficulty, preparation time, and whether practice exams are sufficient.
How Difficult Is DVA-C02?
DVA-C02 is an intermediate-level AWS certification exam. The difficulty comes from understanding actual AWS application behavior, including error handling, authentication, data operations, deployment, and debugging.
Experienced backend developers may find many concepts familiar, but AWS-specific API contracts and service restrictions still require focused preparation.
Do You Need Programming Experience?
Programming experience is strongly recommended. The exam evaluates development concepts involving application code, AWS SDKs, event handling, deployment packages, and service interactions.
You generally do not write and execute large programs during the exam, but you should understand code behavior and recognize correct implementation approaches.
Which Programming Language Should You Know?
AWS does not require mastery of one specific programming language for certification.
Python, JavaScript, Java, and other supported AWS SDK languages are useful for preparation. Choose a language you already know and use it to experiment with AWS SDK operations, Lambda handlers, and error handling.
How Long Should You Study?
Preparation time depends on your AWS and programming experience. Developers already using Lambda, DynamoDB, API Gateway, and CI/CD may need less time than candidates who are new to cloud application development.
A six-week structured plan is a reasonable starting point for experienced developers. Others may need additional time to build foundational AWS knowledge.
Are Practice Exams Enough?
Practice exams are valuable but should complement official documentation and hands-on development.
Memorizing answers may improve performance on repeated questions without building the understanding needed for new scenarios.
Use explanations and references to identify weak topics, then reinforce them through real SDK calls, configuration changes, and troubleshooting exercises.
Should You Take DVA-C02 or DVA-C03?
If you are already prepared and can schedule DVA-C02 before its retirement, taking the current exam may be reasonable.
If you are beginning preparation near the transition date, consider studying for DVA-C03 using the updated official exam guide when it becomes available. Verify the examination version and final testing dates through AWS before booking.
Conclusion
AWS Certified Developer – Associate validates practical knowledge of building, securing, deploying, and troubleshooting applications using AWS services. It emphasizes application behavior and service integrations rather than large-scale architecture design alone.
Effective preparation requires understanding Lambda invocation and concurrency, DynamoDB operations, S3 access, asynchronous messaging, IAM authorization, encryption, CI/CD deployments, and operational observability.
Use the six-week study plan to organize your learning, the video resource to reinforce concepts, and hands-on code exercises to observe how AWS services behave. Then complete a full-length DVA-C02 practice exam and review every uncertain or incorrect answer.
Regardless of whether you ultimately take DVA-C02 or DVA-C03, these skills remain useful for real application development on AWS.
Key Takeaway: AWS Developer Associate preparation should focus on writing reliable application code, choosing correct AWS service integrations, handling failures safely, and understanding how software moves from development to production. Combine documentation, hands-on coding, and realistic practice questions to build confidence.
More Articles to Read
Continue exploring these related AWS development and infrastructure topics on SysDesPro.
Comments (0)