How to pass AWS Certified Developer - Associate (DVA-C02)
24 min read4 domains coveredFree practice, no sign-up
The AWS Certified Developer - Associate (DVA-C02) tests how you BUILD on AWS, not how you draw architecture diagrams. Amazon hands you a developer's problem - a Lambda function that retries a poison message forever, a DynamoDB table queried the wrong way, a token sent to the wrong authoriser - and asks for the code change, configuration, or AWS service call that fixes it. The hard part is rarely knowing a service exists. It is knowing the right API behaviour, the right setting, or the adjacent service that solves THIS requirement when three of the four answers look plausible.
It suits developers with around a year of hands-on experience writing, deploying, and debugging applications on AWS using the SDKs, the AWS CLI, and tools such as AWS SAM. The exam draws across four weighted domains: Development with AWS Services carries the most marks, then Security, then Deployment, then Troubleshooting and Optimization. There is no enforced prerequisite, but the questions assume you have actually called the APIs: written a Lambda handler, modelled a DynamoDB table, assumed an IAM role with AWS STS, and read a CloudWatch log.
The exam rewards decision rules and correct API detail, not memorised service datasheets. Most questions are short developer scenarios where two or three answers are technically capable and only one matches the stated requirement: exactly-once ordering, sub-millisecond reads, least privilege, idempotency, or a no-downtime deploy. The skill being tested is choosing correctly under that pressure, which is why practising on scenario questions with a worked explanation, and a reason every wrong option is wrong, beats reading service overviews.
DVA-C02 is a build-it-correctly exam: almost every question is a developer scenario where the right answer is the AWS service, API behaviour, or configuration that satisfies the stated requirement - idempotency, ordering, least privilege, latency, or a safe deploy - with the least operational overhead.
Difficulty
Intermediate
Best for
Working developers who write, deploy, secure, and debug applications on AWS with the SDKs, the AWS CLI, and frameworks such as AWS SAM, and who want to prove they can use Lambda, DynamoDB, API Gateway, the messaging services, IAM, and the CI/CD tooling correctly under real requirements.
Prerequisites
None enforced. AWS recommends around one year of hands-on experience developing and maintaining applications on AWS, plus proficiency in at least one high-level programming language. Practical exposure to the AWS SDKs, Lambda, DynamoDB, IAM roles, and CloudWatch is what actually carries you through the scenarios.
65
Questions
130 min
Time allowed
720 / 1000
Pass mark
$150
Exam cost (USD)
309
Practice questions
How this exam thinks
One habit decides this exam: read the scenario for its requirement, then pick the service, API behaviour, or setting built for it. Almost every question is a short developer situation with a stated need - ordering, exactly-once, idempotency, least privilege, lowest latency, a deploy with no downtime - and the answer is the option that meets that need. Several options will be technically capable. Only one is the best fit once you weigh what the scenario actually asked for.
The default tie-breaker is the managed, requirement-fit, least-operational-overhead option. AWS designs the exam around its own services and well-architected defaults, so when two answers both work, the one with less to build and run usually wins: an IAM role assumed with AWS STS over a stored access key, a dead-letter queue over a hand-rolled retry table, a DynamoDB conditional write over a read-then-write lock, a Lambda alias over a redeploy. Reach for the manual or lower-level option only when the scenario names a reason. That reason is the signal that the obvious managed answer is the trap.
The rest is a handful of discriminations the exam leans on, each driven by the requirement. For messaging, SQS buffers and decouples, SNS fans out, EventBridge routes by rule, and a FIFO queue is the answer only when ordering or exactly-once is named. For data, the access pattern picks query over scan and a GSI over a scan-with-filter. For identity, an assumed role with temporary credentials beats long-lived keys every time, and a Cognito ID token carries identity while the access token carries authorisation scopes. For deploys, the strategy is chosen by the risk tolerance named: canary and linear shift traffic gradually, blue/green swaps whole environments, and a Lambda weighted alias shifts a percentage. Name the requirement, then choose the thing built for it.
What each domain tests and how to study it
The DVA-C02 blueprint is split across 4 domains. Weights are the official share of the exam; see the official exam guide for the authoritative breakdown.
What you must be able to do. Given an application requirement, write or configure the code, Lambda function, data store, and messaging that meets it: event-driven decoupling, idempotency and retries, correct SDK and API calls, Lambda configuration, DynamoDB data modelling, and the right caching and storage choices.
In one sentenceThe biggest domain: writing event-driven, fault-tolerant application code and modelling data correctly in DynamoDB and S3, using Lambda and the SDKs the way AWS intends.
Recall check: answer these from memory first
A consumer keeps reprocessing one malformed SQS message and blocks the queue. What configuration moves that message aside after a set number of receives, and what is the setting called?
A table is keyed on customerId and you must fetch a single customer's orders by status efficiently. Why is a secondary index the answer rather than a scan with a filter expression, and which index type keeps the same partition key?
Two concurrent requests must not both decrement the same DynamoDB item below zero. What single-call mechanism prevents the lost update without a separate read-lock?
What it tests. Building applications on AWS the right way. Designing event-driven and decoupled code with Amazon SQS, Amazon SNS, and Amazon EventBridge, including fan-out and choreography; writing fault-tolerant code with idempotency, retries with exponential backoff and jitter, and dead-letter queues; choosing stateless design and synchronous versus asynchronous patterns; calling AWS services correctly with the SDKs and creating APIs with request validation and response transformation; configuring AWS Lambda memory, timeout, concurrency, layers, extensions, and environment variables, and wiring event source mappings, destinations, and VPC access; modelling Amazon DynamoDB with primary keys, high-cardinality partition keys, and secondary indexes, choosing between query and scan and the right consistency and capacity mode; using Amazon S3 with storage classes, lifecycle, multipart upload, and presigned URLs; and applying caching with Amazon ElastiCache and DynamoDB Accelerator.
How to study it. Make idempotency and the messaging split your reflexes, because they are the most-tested ideas here. Fix the three-way decoupling decision: SQS is a pull-based durable buffer that absorbs spikes, SNS is push-based pub/sub fan-out, EventBridge routes events to targets by rule and content. When ordering or exactly-once is named, the answer is a FIFO queue, not a standard one. Learn the SQS poison-message pattern cold: a redrive policy with a maxReceiveCount sends a repeatedly-failing message to a dead-letter queue instead of blocking the consumer. For DynamoDB, drill the data-modelling rules: a high-cardinality partition key spreads load, a query on a key or index is efficient while a scan reads the whole table, a global secondary index adds a new partition and sort key while a local secondary index reuses the partition key, and a conditional write gives optimistic locking without a read-lock. Know Lambda concurrency (reserved caps a function, provisioned removes cold starts) and that vCPU scales with memory. For S3 from code, learn presigned URLs for time-limited direct access and multipart upload for large objects.
Easy to confuse
Amazon SQS versus Amazon SNS versus Amazon EventBridge. SQS is a pull-based durable queue where one consumer processes each message and bursts are buffered; SNS is push-based pub/sub that fans the same message out to many subscribers at once; EventBridge routes events to targets by matching rules on event content. Use SQS to absorb spikes and decouple at the consumer's pace, SNS to broadcast, EventBridge to route by content to different targets.
DynamoDB Query versus Scan. Query reads items by partition key (and optional sort-key condition) and touches only matching items, so it stays efficient as the table grows; Scan reads every item and then applies any filter expression after the read, so it consumes capacity for the whole table. Filtering does not reduce the read cost of a Scan. Use Query, backed by an index when needed, whenever you know the key.
Global secondary index versus local secondary index. A global secondary index defines a brand-new partition key and sort key and has its own provisioned or on-demand capacity, so it supports access patterns unrelated to the base table's key; a local secondary index keeps the base table's partition key and only adds an alternate sort key, and must be created with the table. Choose a GSI to query by a different attribute, an LSI to sort the same partition differently.
Reserved concurrency versus provisioned concurrency. Reserved concurrency caps and guarantees how many concurrent executions a function can use, protecting downstream resources and other functions from being starved; provisioned concurrency pre-initialises a set number of execution environments so they are warm and respond without a cold start. Reserved limits scale, provisioned removes latency. They solve different problems and can be set together.
Worked example from the DVA-C02 bank
lock_openFree sampleDevelopment with AWS Servicesmedium
A developer is building an order service that publishes an OrderPlaced event. Three independent consumers must each receive every event: an email service polls a queue, an analytics service polls a separate queue, and an inventory service is an HTTP endpoint. The developer wants each consumer to process events at its own pace with retry and buffering. Which design implements this fan-out most directly?
APublish each event to an SNS topic and subscribe the two queues plus the inventory HTTP endpoint to the topic so SNS delivers a copy to every subscriber.check_circle Correct
BPublish each event to one SQS standard queue and let all three consumers poll that single shared queue so every service receives the same message body.
CPublish each event to an SNS topic with the inventory HTTP endpoint subscribed directly and the two services reading from the topic by long polling it for messages.
DPublish each event to an SQS FIFO queue and configure three message group IDs so each consumer reads only the group that matches its own service name reliably.
Use an SNS topic with multiple subscribers to fan out a copy of each event to several independent consumers. SNS implements the publish-subscribe fan-out pattern by pushing a separate copy of every published message to each subscriber, so SQS queues subscribed to the topic buffer messages for their pollers while an HTTP subscriber receives push delivery, letting every consumer process independently.
Why A is correct: SNS fan-out pushes a copy of each message to every subscriber, so both queues buffer for their pollers and the HTTP endpoint receives a direct delivery with retries.
Why B is wrong: A single SQS queue delivers each message to only one consumer that deletes it, so the three services would compete for messages rather than each receiving every event.
Why C is wrong: SNS is push-based and cannot be polled, so subscribing the services by polling the topic is not possible and would lose the buffering the queues provide.
Why D is wrong: Message group IDs order messages within a single FIFO queue but still deliver each message once, so they cannot duplicate every event to three separate consumers.
What you must be able to do. Given an application security requirement, implement authentication and authorisation with Amazon Cognito and IAM, grant least privilege with roles and AWS STS, encrypt data with AWS KMS and TLS, and manage secrets with AWS Secrets Manager or Parameter Store.
In one sentenceThe security domain: authenticating users with Cognito, granting least-privilege application access with roles and temporary credentials, encrypting data with KMS, and keeping secrets out of code.
Recall check: answer these from memory first
A Lambda function must call Amazon S3 and Amazon DynamoDB. What grants it access with no stored credentials, where do the credentials come from, and why is an embedded access key the wrong answer?
In Amazon Cognito, which token proves who the user is for your application, and which token authorises calls to a protected API? What is the difference between a user pool and an identity pool?
An application needs a database password rotated automatically with no code change. Which AWS service provides that, and what does it add over a Parameter Store SecureString?
What it tests. Securing application code and the data it handles. Implementing authentication and federation with Amazon Cognito user pools and identity pools, SAML, and OpenID Connect; granting least-privilege access with IAM roles and AWS STS temporary credentials instead of long-lived keys; reasoning about identity-based and resource-based policies and managed versus customer-managed policies; securing APIs with bearer tokens such as JSON Web Tokens and OAuth through API Gateway authorisers; encrypting data with AWS KMS using customer managed keys, envelope encryption, key rotation, and cross-account access; protecting data in transit with TLS and AWS Certificate Manager and choosing client-side versus server-side encryption; and managing secrets and sensitive data with AWS Secrets Manager, AWS Systems Manager Parameter Store, data classification, and sanitisation.
How to study it. Make least privilege through an assumed role your default answer, because stored access keys are almost always the trap. When code on Lambda, EC2, or a container needs to reach another AWS service, the answer is an IAM role whose temporary credentials come from AWS STS, never an embedded access key and never a wildcard policy. Learn the Cognito split: a user pool is the identity provider that signs users in and issues tokens, an identity pool (federated identities) exchanges a token for temporary AWS credentials to reach AWS services directly. Within the tokens, the ID token carries identity claims about who the user is, while the access token carries the scopes that authorise API calls. Learn the secret-store split: Secrets Manager when you need built-in automatic rotation, Parameter Store SecureString for cheaper static configuration encrypted with KMS. For encryption, understand envelope encryption (KMS encrypts a data key, the data key encrypts the data) and when a customer managed key is required over an AWS managed one for rotation control and cross-account grants.
Easy to confuse
Cognito user pool versus identity pool. A user pool is a managed user directory that authenticates sign-up and sign-in and issues JWTs (ID and access tokens); an identity pool (federated identities) takes a token from a user pool or another provider and returns temporary AWS credentials so the client can call AWS services directly. Use a user pool to sign users in, an identity pool to grant them scoped AWS access.
Cognito ID token versus access token. The ID token is a signed JWT that carries identity claims about the authenticated user (such as email and sub) and is meant to tell your application who the user is; the access token carries the OAuth scopes and groups that authorise calls to protected resources. Send the ID token when the API needs the user's identity, the access token when it checks scopes.
AWS Secrets Manager versus Systems Manager Parameter Store. Secrets Manager has built-in automatic rotation with Lambda rotation functions and charges per secret; Parameter Store SecureString encrypts a value with KMS and is read at runtime but has no native rotation and is free at standard tier. Choose Secrets Manager when the scenario needs managed rotation or cross-Region replication; SecureString is the cheaper fit for static shared configuration.
AWS managed KMS key versus customer managed key. An AWS managed key is created and controlled by the service, rotates on a fixed AWS schedule, and cannot carry a custom key policy or cross-account grant; a customer managed key lets you set the key policy, enable or disable rotation, grant cross-account use, and audit usage. When the scenario needs rotation control, a custom key policy, or sharing a key across accounts, it is a customer managed key.
Worked example from the DVA-C02 bank
lock_openFree sampleSecuritymedium
A developer is building a mobile application that must let end users sign up, sign in with email and password, and reset forgotten passwords, all managed by AWS without running a custom user database. After sign-in the application calls a backend REST API but does not yet need to call AWS service APIs directly. Which Amazon Cognito component should the developer use for this sign-up and sign-in requirement?
AAn Amazon Cognito identity pool, because it provides the hosted sign-up and sign-in screens and stores each user profile and password for the mobile application.
BAn AWS Identity and Access Management user for each application user, because IAM manages credentials and password resets centrally for any kind of human sign-in.
CAn Amazon Cognito identity pool federated to social providers, because it authenticates the email and password and then returns session tokens to the application.
DAn Amazon Cognito user pool, because it is a managed user directory that handles sign-up, sign-in, and password reset and issues tokens after authentication.check_circle Correct
Use an Amazon Cognito user pool as the managed directory that handles end-user sign-up, sign-in, and password reset and issues tokens. A Cognito user pool is a managed identity directory that authenticates end users through sign-up, sign-in, and password recovery flows and returns JWT ID and access tokens on success, whereas an identity pool only exchanges an existing identity for temporary AWS credentials.
Why A is wrong: An identity pool exchanges an existing identity for AWS credentials and does not store user profiles or passwords, so it cannot provide the sign-up and sign-in directory the application needs.
Why B is wrong: IAM users are meant for workforce and service access, not large fluctuating end-user populations, and AWS advises against creating an IAM user per application user for sign-in.
Why C is wrong: An identity pool federates already authenticated identities and never validates an email and password itself, so it cannot perform the primary sign-in that the application requires.
Why D is correct: A Cognito user pool is a fully managed directory that performs sign-up, sign-in, and password recovery and returns ID and access tokens, which matches the stated requirement exactly.
What you must be able to do. Given a deployment requirement, prepare artifacts, manage configuration, version Lambda functions and API stages, define infrastructure as code with SAM or CloudFormation, automate the pipeline with the CI/CD services, and choose the deployment strategy that meets the downtime and risk tolerance.
In one sentenceThe deployment domain: packaging and shipping application code with Lambda versions, API stages, SAM and CloudFormation, CodePipeline, and the canary, linear, or blue/green strategy the risk tolerance demands.
Recall check: answer these from memory first
You must send 10 percent of production traffic to a new Lambda version, watch it, then promote it, with no redeploy. What Lambda feature delivers this, and what is the moving pointer called?
Order the CodeDeploy strategies by how gradually they shift traffic, and say which one gives the fastest rollback by keeping the old environment intact.
A serverless application is defined in a template and you want to preview exactly what a stack update will change before it runs. What CloudFormation feature shows that, and what is SAM in relation to CloudFormation?
What it tests. Packaging and deploying application code on AWS. Preparing Lambda deployment artifacts with packages, layers, container images, and managed dependencies; accessing configuration with AWS AppConfig, Parameter Store, and feature flags; managing Lambda versions and aliases, including weighted aliases, to route traffic; testing and promoting APIs across Amazon API Gateway stages with stage variables and mock integration; defining infrastructure as code with AWS CloudFormation, AWS SAM, and the AWS CDK; automating build, test, and deploy with AWS CodePipeline and AWS CodeBuild and manual approvals; choosing canary, blue/green, and rolling strategies with AWS CodeDeploy and performing rollbacks; and using AWS CodeArtifact, AWS Copilot, and AWS Amplify with branch and label strategies for releases and custom domains.
How to study it. Anchor on two ideas: version and alias so you can shift traffic safely, and match the deployment strategy to the risk named. For Lambda, learn that a published version is immutable and an alias is a movable pointer; a weighted alias sends a percentage of invocations to a new version, which is how you canary a function without a redeploy. For API Gateway, stages plus stage variables let one deployment serve dev, test, and prod with different backends. Drill the CodeDeploy strategies: canary shifts a small percentage, waits, then the rest; linear shifts equal increments on an interval; all-at-once swaps immediately; blue/green stands up a parallel environment and switches over, giving the fastest rollback. For infrastructure, know that SAM is a CloudFormation transform optimised for serverless and that a change set previews a stack update before it runs. For packaging, layers share common dependencies across functions, and a container image is the route when the package exceeds the zip size limit. Learn that CodeArtifact controls which package versions consumers can install through package version status.
Easy to confuse
Lambda version versus alias. A published Lambda version is an immutable snapshot of the code and configuration identified by a number; an alias is a named, movable pointer to a version that can also split traffic by weight between two versions. Invoke through an alias so you can shift or roll back traffic by repointing it, rather than changing every caller when the version changes.
Canary versus linear versus blue/green deployment. Canary shifts a small percentage of traffic, pauses to bake, then shifts the remainder; linear shifts equal increments on a fixed interval until complete; blue/green stands up a separate full environment and cuts over all at once, keeping the old one for an instant rollback. Canary and linear limit blast radius gradually, blue/green optimises for the fastest, cleanest rollback.
AWS SAM versus AWS CloudFormation. AWS SAM is a CloudFormation macro and transform that adds concise serverless resource types (functions, APIs, tables) which expand into full CloudFormation; everything SAM deploys is ultimately a CloudFormation stack. Use SAM for terser serverless templates and the SAM CLI for local testing; it is not a separate engine, so CloudFormation features such as change sets still apply.
Lambda layer versus container image packaging. A layer is a separate archive of shared libraries or runtimes that several functions mount at /opt, keeping each function package small and dependencies shared; a container image packages the whole function and its dependencies into an OCI image and is the route when the unzipped package exceeds the 250 MB layer-and-zip limit (images allow up to 10 GB). Use a layer to share common dependencies, an image for large or custom-runtime functions.
Worked example from the DVA-C02 bank
lock_openFree sampleDeploymentmedium
A developer packages a Python Lambda function whose dependencies, including a large machine learning library and its native binaries, total around 900 MB once unzipped. The deployment must be a single artifact that Lambda can run directly. The developer wants the simplest packaging option that supports this artifact size. Which deployment package format should the developer use?
AUpload the function as a .zip archive directly through the Lambda console, since direct uploads accept artifacts of this unzipped size without extra steps.
BStore the .zip archive in an S3 bucket and point Lambda at the object, because the S3 path raises the unzipped limit high enough for this dependency set.
CBuild the function as a container image, push it to Amazon ECR, and create the function from that image, because image packages support far larger artifacts.check_circle Correct
DSplit the dependencies across five Lambda layers so each stays small, then attach all five layers to the function to assemble the full library at runtime.
Choose a Lambda container image when a function's unzipped code and dependencies exceed the limits of zip-based deployment packages. Zip deployment packages, whether uploaded directly or from S3, are bound by a two hundred and fifty megabyte unzipped limit shared by the function and its layers, so a nine hundred megabyte dependency set only fits a container image, which Lambda supports up to ten gigabytes and runs directly from Amazon ECR.
Why A is wrong: A direct console .zip upload is capped at fifty megabytes zipped, and the unzipped code and dependency limit for zip packages is far below nine hundred megabytes, so this artifact cannot be deployed that way.
Why B is wrong: Loading the zip from S3 raises the upload size but the unzipped code and layers still cannot exceed two hundred and fifty megabytes, so a nine hundred megabyte payload remains over the zip format limit.
Why C is correct: Lambda container images support sizes up to ten gigabytes, comfortably holding a nine hundred megabyte dependency set, and Lambda runs the image directly as a single deployment artifact.
Why D is wrong: Layers share the same two hundred and fifty megabyte unzipped ceiling that the function plus all attached layers must fit within, so splitting the library across layers does not raise the total budget.
What you must be able to do. Given a failing or slow application, find the root cause with CloudWatch and X-Ray, instrument code for observability, emit custom metrics and alerts, and optimise performance with the right Lambda tuning, caching, and messaging settings.
In one sentenceThe troubleshooting domain: tracing failures with X-Ray and CloudWatch Logs Insights, instrumenting code for observability, and tuning Lambda, caching, and messaging for performance.
Recall check: answer these from memory first
A request is slow and the latency is spread across Lambda, DynamoDB, and a downstream HTTP call. Which AWS tool shows where the time goes across all of them, and why are raw CloudWatch Logs not enough?
A service emits a custom latency metric thousands of times a second and PutMetricData is being throttled. What lets you record those metrics without hitting the API call rate, and how does it work?
A Lambda function is CPU-bound and slow. Why can increasing its memory setting make it both faster and cheaper, and what removes cold-start latency for a latency-sensitive function?
What it tests. Finding and fixing application problems and tuning for performance. Performing root cause analysis with Amazon CloudWatch Logs, CloudWatch Logs Insights queries, dashboards, common HTTP error codes, and SDK exceptions; using AWS X-Ray service maps and traces to locate latency and faults across services; instrumenting code for observability with distributed tracing, structured logging, and X-Ray annotations; emitting custom application metrics with the embedded metric format and configuring alerts with CloudWatch alarms and Amazon SNS; and optimising performance by tuning AWS Lambda memory and concurrency, profiling compute needs, and reducing load with API Gateway and Amazon CloudFront caching and Amazon SNS subscription filter policies.
How to study it. Match the tool to the symptom, because that mapping is the whole domain. When latency or a fault spans several services and you need to see where time goes, the answer is an AWS X-Ray service map and traces, not raw logs. When you need to search and aggregate across log events, the answer is CloudWatch Logs Insights with its query language. When a high-throughput service is throttled calling PutMetricData thousands of times a second, the answer is the embedded metric format, which puts structured metrics inside log events so CloudWatch extracts them without per-call API limits. Learn the Lambda performance levers: more memory also adds proportional vCPU, so a CPU-bound function can run faster and cheaper at higher memory; provisioned concurrency removes cold starts for latency-sensitive paths. For messaging optimisation, an SNS subscription filter policy delivers only matching messages to a subscriber so consumers are not woken by events they ignore. For read-heavy APIs, API Gateway caching and CloudFront cut origin load. Know the common HTTP codes: a 429 is throttling, a 5xx from a service often means retry with backoff.
Easy to confuse
AWS X-Ray versus CloudWatch Logs Insights. X-Ray builds a service map and per-request traces that show how a single request flows and where latency or errors arise across multiple services; CloudWatch Logs Insights runs queries over log events to find and aggregate messages. Use X-Ray to locate a fault or latency across a distributed call path, Logs Insights to search and summarise what the logs recorded.
Embedded metric format versus PutMetricData. PutMetricData sends a metric with an explicit API call and is subject to request rate limits, so high-frequency publishing gets throttled; the embedded metric format writes structured metric data inside a log event and CloudWatch extracts the metrics asynchronously, so you record high-cardinality, high-frequency metrics without per-call limits. Use EMF for high-throughput custom metrics.
Reserved concurrency versus provisioned concurrency for performance. Reserved concurrency caps the maximum concurrent executions a function may use; provisioned concurrency keeps a set number of environments initialised and warm. To fix cold-start latency on a critical path you want provisioned concurrency; reserved concurrency does not remove cold starts, it limits scale to protect downstream systems.
API Gateway caching versus SNS subscription filter policy. API Gateway caching stores responses at the stage so repeated identical requests are served without hitting the backend, cutting read latency and load; an SNS subscription filter policy controls which published messages a subscriber receives so consumers are not invoked for events they would discard. One reduces repeated reads, the other reduces unnecessary message delivery.
Worked example from the DVA-C02 bank
lock_openFree sampleTroubleshooting and Optimizationmedium
A developer is investigating intermittent failures in a Lambda function whose JSON logs go to Amazon CloudWatch Logs. Each log event includes a level field and a requestId field. The developer needs to list, for the past hour, every event where level is ERROR together with its requestId, sorted with the most recent first, without exporting the logs anywhere. Which approach should the developer use?
ACreate a metric filter on the log group that matches the ERROR pattern, then read the resulting metric data points to see the failing requestId values for the hour.
BCreate a subscription filter on the log group that streams ERROR events to Amazon Kinesis Data Firehose, then inspect the delivered objects to find the requestId values.
CRun a CloudWatch Logs Insights query over the log group that filters on level equals ERROR, displays the requestId field, and sorts by timestamp descending for the last hour.check_circle Correct
DEnable CloudWatch Contributor Insights on the log group with a rule keyed on requestId, then read the top contributor report to list the failing requests for the hour.
Use CloudWatch Logs Insights to filter on a field, display chosen fields, and sort by time when diagnosing application errors in place. CloudWatch Logs Insights runs queries directly against a log group, so filtering on the parsed level field, projecting the requestId field, and sorting by timestamp returns the exact failing events in time order without exporting the data or building any pipeline.
Why A is wrong: A metric filter only emits a numeric count to a CloudWatch metric and cannot return the requestId field values, so it shows how many errors occurred but not which requests failed.
Why B is wrong: A subscription filter is built for continuous delivery to another service, so it adds a Firehose and storage hop and is far heavier than an ad hoc query for a one-hour investigation.
Why C is correct: Logs Insights queries the log group in place, so a filter on level with a fields and sort by timestamp returns the matching ERROR events and their requestId values newest first without any export.
Why D is wrong: Contributor Insights ranks the top contributors by a key rather than listing every matching event with its fields, so it cannot return the full time ordered set of ERROR events.
A study plan that works
Map the four domains to your real experience
Day 1
Start from the exam guide's four domains and their weights: Development with AWS Services is the largest, then Security, Deployment, and Troubleshooting and Optimization. Mark which you already do at work and which you only read about. Most developers are strong on writing code and weak on the deployment tooling and observability services, so plan your time against the gaps, not the comfort zones.
Drill the core build services until the APIs are reflexive
Week 1
Spend the most time on Lambda, DynamoDB, and the messaging trio. Write a Lambda handler, set its memory, timeout, reserved and provisioned concurrency, and wire an event source mapping with a dead-letter queue. Model a DynamoDB table, run a query and a scan, add a global secondary index, and do a conditional write. Send a message through SQS, fan out with SNS, and route with EventBridge. The exam tests these constantly.
Learn identity, encryption, and secrets as decision rules
Week 2
Practise the security discriminations until they are automatic: an assumed IAM role with AWS STS over stored keys, a Cognito user pool versus identity pool, ID token versus access token, Secrets Manager versus Parameter Store, AWS managed versus customer managed KMS keys. For each, write the one-line reason it wins so you can answer in seconds under exam pressure.
Build and ship with the deployment tooling
Week 3
Define a small application with AWS SAM, deploy it with a change set, and publish a Lambda version behind an alias. Set up a CodePipeline with a CodeBuild stage and a manual approval. Do a CodeDeploy canary and a blue/green cutover so the strategy differences are muscle memory, not trivia. Learn how API Gateway stages and stage variables promote the same deployment across environments.
Instrument, trace, and tune
Week 4
Turn on X-Ray for a multi-service request and read the service map. Run a CloudWatch Logs Insights query over structured JSON logs. Emit a custom metric with the embedded metric format and alarm on it through SNS. Tune a Lambda function's memory to see the vCPU and cost effect, and add provisioned concurrency to kill cold starts. This domain is small but easy marks once the tool-to-symptom mapping is fixed.
Practise on scenario questions and review every wrong option
Week 5
Move to full scenario questions and treat each one as a drill: name the requirement in the stem, predict the answer, then read why every distractor is wrong. The adjacent-service traps (SQS versus SNS, query versus scan, ID versus access token, canary versus blue/green) are where marks are won and lost. Keep a list of the discriminations you miss and re-drill them.
Simulate the exam and close the gaps
Week 6
Sit timed sets of about 65 questions in 130 minutes so the pace is familiar. Flag-and-return on long scenarios rather than stalling. After each set, sort misses by domain and task statement, go back to the service or API behaviour behind each, and re-drill. Stop when you are consistently scoring comfortably above the pass mark on unseen questions.
Know when you're ready
You are ready when you can read a developer scenario, name the requirement it hinges on, and pick the right service, API behaviour, or setting before looking at the options, then explain why each distractor is wrong. Judge that on unseen practice questions, not on a feeling of familiarity: aim to score consistently above the 720 out of 1000 pass mark across full timed sets that mirror the four-domain weighting, with no single domain dragging. When the adjacent-service traps (SQS versus SNS versus EventBridge, query versus scan, ID versus access token, canary versus blue/green, X-Ray versus Logs Insights) stop catching you out, you are ready to book.
Ready to put this into practice?
Free DVA-C02 questions with worked explanations. No sign-up.
Read the scenario for its requirement first - ordering, idempotency, least privilege, latency, no-downtime deploy - then choose the option built for it. The requirement, not the service's popularity, decides the answer.
When two answers both work, pick the managed, least-operational-overhead one unless the scenario names a reason to go lower-level. An assumed role beats a stored key; a conditional write beats a read-then-write lock; an alias beats a redeploy.
Treat any answer with a long-lived access key, a wildcard IAM policy, or the root user as the trap. Application identity is almost always an IAM role assumed with AWS STS.
On DynamoDB questions, check the access pattern: if you know the key, it is a query, not a scan; a filter expression does not cut a scan's read cost; pick a GSI for a new key and an LSI for an alternate sort on the same key.
Capitalise and obey negative words in stems (NOT, EXCEPT, LEAST). On multiple-response questions, the exam tells you how many to choose - select exactly that many.
Flag long scenarios and return to them. With about 65 questions in 130 minutes you have roughly two minutes each, so do not stall on one trace-the-bug question while easier marks wait.
For multiple-response questions, evaluate each option independently as true or false against the stem rather than comparing options, since several can be correct.
Frequently asked questions
Is DVA-C02 worth it, and what comes after?
DVA-C02 is a strong credential for developers who already build on AWS and want to demonstrate they can use Lambda, DynamoDB, the messaging services, and the CI/CD tooling correctly under real engineering requirements, not just in theory. It complements the Solutions Architect Associate by going deeper on application code and the SDK layer rather than architecture selection. A common progression is to pair it with the SAA-C03 for broader AWS coverage, or to move up to the DevOps Engineer Professional if your work centres on delivery pipelines and automation.
Is the AWS Certified Developer - Associate still DVA-C02?
Yes. The current version of the exam is DVA-C02. Always confirm against the official AWS certification page before you book, since AWS refreshes exam versions periodically, but DVA-C02 is the live code.
How is the exam structured and scored?
The exam has 65 questions (50 scored and 15 unscored that do not affect your result) to answer in 130 minutes. Questions are multiple choice (one correct answer) or multiple response (two or more correct from five or more options). It is scored from 100 to 1000 with a passing score of 720, using a compensatory model, so you pass on the overall score rather than per domain.
How much code do I need to write?
You do not write code in the exam, but you must read and reason about it. Questions assume you understand SDK and API behaviour, Lambda configuration, DynamoDB operations, and IAM, and several show short snippets or describe a call you must judge. AWS recommends about a year of hands-on development on AWS and proficiency in at least one high-level language.
How is DVA-C02 different from the Solutions Architect Associate (SAA-C03)?
SAA-C03 tests choosing and combining services to design architectures; DVA-C02 tests building, deploying, securing, and debugging applications as a developer. DVA goes deeper on Lambda, DynamoDB data modelling, the SDKs, CI/CD tooling, and observability, and lighter on networking and large-scale architecture. They overlap on IAM, S3, and the messaging services, so the two associate exams complement each other.
Which services matter most?
Lambda, DynamoDB, IAM with AWS STS, Amazon Cognito, API Gateway, the messaging services (SQS, SNS, EventBridge), CloudFormation and SAM, the CodeStar suite (CodePipeline, CodeBuild, CodeDeploy, CodeArtifact), CloudWatch, and X-Ray. The Development with AWS Services and Security domains together are more than half the exam, so weight your study there.
How long should I study?
With around a year of hands-on AWS development, four to six weeks of focused study is typical: a week or two drilling Lambda, DynamoDB, and messaging, time on security and deployment tooling, and a final stretch on scenario practice. With less hands-on experience, build small applications yourself first, because the exam rewards having actually called the APIs.
What is the most common reason people fail?
Falling for the adjacent-service trap. The distractors are real AWS services that solve a nearby problem - SNS when the answer is SQS, a scan when the answer is a query, the access token when the answer is the ID token, blue/green when the answer is a canary. The fix is to name the exact requirement in the stem and choose the service or setting built for that, not the one that merely sounds relevant.
Examworthy is not affiliated with or endorsed by Amazon Web Services. This guide is original study material based on the public exam blueprint. We never reproduce live exam items. DVA-C02 and related marks belong to their respective owners.
