12 real DVA-C02 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the DVA-C02 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real DVA-C02 is 65 questions in 130 minutes, pass mark 720 / 1000. For a domain-by-domain breakdown and a study plan, read the DVA-C02 study guide. The full bank has 364 questions.
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.
lock_openFree sampleDevelopment with AWS Servicesmedium
A payment service writes transactions to an SQS queue that a worker fleet polls. Each transaction must be processed once and in the exact order it was submitted per customer account. Duplicate processing would double-charge a customer. Which queue configuration meets the ordering and exactly-once processing requirement?
- AUse an SQS standard queue with a long visibility timeout and rely on the worker to sort messages by a submittedAt timestamp before charging each customer account.
- BUse an SQS FIFO queue with the customer account as the message group ID and content-based deduplication enabled so order and single processing hold per account.check_circle Correct
- CUse an SQS standard queue with deduplication scope set to message group so repeated transactions are dropped and the workers process each account in arrival order.
- DUse an SNS standard topic subscribed to one queue with delivery retries tuned so the topic enforces strict order and removes duplicate transactions before workers poll.
Choose an SQS FIFO queue with a message group ID and deduplication to get ordered, exactly-once processing per key. FIFO queues deliver messages in order within a message group and use a deduplication ID, either supplied or content-based, to discard repeated sends inside a five-minute window, so keying the group by customer account gives ordered, exactly-once processing where standard queues cannot.
Why A is wrong: Standard queues offer best-effort ordering and at-least-once delivery, so a long timeout and client sorting cannot guarantee per-account order or prevent duplicate charges.
Why B is correct: A FIFO queue preserves order within each message group and deduplication suppresses repeats, so transactions for one account are processed in order and exactly once.
Why C is wrong: Standard queues do not support deduplication scope or message groups, so this configuration is invalid and would not stop duplicate or out-of-order processing.
Why D is wrong: SNS standard topics do not guarantee ordering or deduplication, and retries can themselves cause duplicates, so the double-charge risk and ordering gap remain.
lock_openFree sampleDevelopment with AWS Servicesmedium
A worker reads orders from an SQS standard queue and calls a downstream API. Some messages contain malformed data that always fails, so the worker never deletes them and they reappear after the visibility timeout, blocking the queue and wasting compute. The developer wants poison messages isolated automatically after a few failed attempts. What should the developer configure?
- ALower the queue's visibility timeout so failing messages reappear faster and the worker can retry them many more times within the same processing window.
- BIncrease the message retention period so failing messages stay longer, giving the worker additional chances to process them before they are finally deleted.
- CSet a redrive policy on the queue with a dead-letter queue and a maxReceiveCount so messages move to the dead-letter queue after the failed attempts.check_circle Correct
- DEnable long polling with a higher wait time so the worker batches messages and skips the malformed ones until they expire from the queue on their own.
Attach a dead-letter queue with a redrive policy and maxReceiveCount to isolate repeatedly failing poison messages. SQS tracks how many times each message is received, and a redrive policy compares that count to maxReceiveCount, moving the message to the configured dead-letter queue once it is exceeded, so poison messages stop recirculating in the main queue and can be inspected separately.
Why A is wrong: A shorter visibility timeout only makes poison messages reappear sooner, increasing wasted retries rather than removing them from the main queue.
Why B is wrong: A longer retention period keeps poison messages in the queue even longer, which worsens the blocking and waste rather than isolating the bad messages.
Why C is correct: A redrive policy counts receives and moves a message to the dead-letter queue once maxReceiveCount is exceeded, isolating poison messages from the main queue automatically.
Why D is wrong: Long polling reduces empty receive calls but does not skip or remove failing messages, so poison messages keep returning until retention expires.
Security (26% of the exam)
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.
lock_openFree sampleSecuritymedium
An iOS application authenticates users through an Amazon Cognito user pool and now needs each signed-in user to upload files straight to an Amazon S3 bucket from the device using the AWS SDK, scoped by an IAM role. The team does not want to embed any long-lived AWS access keys in the app. Which approach lets the device obtain temporary AWS credentials for these S3 calls?
- AConfigure an Amazon Cognito identity pool that trusts the user pool, then exchange the user pool token for temporary AWS credentials from an assumed IAM role.check_circle Correct
- BPass the user pool ID token directly to the AWS SDK for Amazon S3, because the SDK accepts a Cognito JWT as the signing credential for S3 requests.
- CCreate an IAM user for the bucket and ship its access key and secret key inside the application bundle so the SDK can authorise each upload.
- DAttach a bucket policy that grants the user pool group access, so any token issued by the user pool can call Amazon S3 without further credential exchange.
Use an Amazon Cognito identity pool to exchange a user pool token for temporary IAM role credentials so a device can call AWS services directly. A Cognito identity pool configured with the user pool as an authentication provider exchanges the validated user pool token for temporary credentials from an assumed IAM role through STS, and the AWS SDK then signs S3 calls with those rotating credentials rather than any embedded key.
Why A is correct: An identity pool trusts the user pool as an authentication provider and calls STS to return short-lived role credentials, which the SDK uses to sign the S3 requests with no stored keys.
Why B is wrong: The AWS SDK signs S3 requests with SigV4 access keys, not a raw JWT, so a user pool ID token cannot be used directly as the S3 signing credential.
Why C is wrong: Embedding a long-lived IAM access key in a distributed app exposes the secret to extraction and never rotates, which the requirement and least-privilege practice both forbid.
Why D is wrong: An S3 bucket policy authorises IAM principals, not user pool tokens, so it cannot let a Cognito JWT call S3 and does not produce the temporary credentials the SDK needs.
lock_openFree sampleSecuritymedium
A company wants employees who already sign in through the corporate SAML 2.0 identity provider to access a customer-facing web application that uses an Amazon Cognito user pool, so that employees do not create a separate password. The application should still receive standard user pool tokens after the corporate sign-in completes. How should the developer enable this federated sign-in?
- ACreate an Amazon Cognito identity pool with the SAML provider, because the identity pool issues user pool ID and access tokens once the SAML assertion is validated.
- BAdd the corporate SAML 2.0 provider as an identity provider on the user pool and map its attributes, so the user pool federates the sign-in and issues its own tokens.check_circle Correct
- CReplace the user pool with AWS IAM Identity Center, because only IAM Identity Center can consume a corporate SAML assertion and front a customer web application.
- DStore the corporate users as native accounts in the user pool and run a nightly job that copies their SAML passwords so the existing sign-in form keeps working.
Add a SAML 2.0 identity provider to an Amazon Cognito user pool so federated employees sign in once and the pool issues standard tokens. A Cognito user pool can register an external SAML 2.0 identity provider and map incoming assertion attributes to user pool attributes, so the corporate sign-in is federated through the pool and the application still receives the same ID and access tokens it would for any user pool user.
Why A is wrong: An identity pool returns temporary AWS credentials, not user pool ID and access tokens, so it cannot deliver the standard user pool tokens the application expects after sign-in.
Why B is correct: A user pool supports SAML 2.0 identity providers directly, validating the assertion and mapping attributes, then issues its own ID and access tokens so employees sign in without a new password.
Why C is wrong: IAM Identity Center targets workforce access to AWS and business apps, and swapping out the user pool removes the token model the customer-facing application is built around.
Why D is wrong: SAML providers never expose user passwords to copy, and duplicating accounts defeats single sign-on, so this neither works technically nor meets the no-separate-password goal.
lock_openFree sampleDeploymenthard
A team's Python Lambda functions each bundle their own copy of the same large shared library, pushing several .zip packages toward the unzipped size limit. The developer wants to shrink each function's deployment package and keep the shared library in one central place, while still deploying the functions as .zip artifacts. Which TWO actions together achieve this? (Select TWO.)
- APublish the shared library once as a Lambda layer so a single versioned copy is stored centrally for every function to share.check_circle Correct
- BAttach that layer to each function by its version ARN and remove the bundled library from each function's own .zip package.check_circle Correct
- CSwitch each function to a container image so the shared library is baked into a base image layer rather than a .zip.
- DRaise each function's memory setting, which proportionally increases the allowed unzipped deployment package size.
- EStore the shared library in Amazon S3 and download it into /tmp on each cold start before importing it at runtime.
Shrinking duplicated Lambda packages takes two steps: publish the shared library as a layer, then attach it by ARN and drop the bundled copy from each function's .zip. A Lambda layer stores a shared dependency once as a versioned artifact that functions attach by ARN, and Lambda extracts it to /opt on the runtime path. Publishing the layer centralises the library, and removing the now-redundant bundled copy from each function's .zip is what reduces every package to just its handler code, with the artifacts still deployed as .zip files.
Why A is correct: A Lambda layer holds the shared dependency in one published, versioned artifact, so the library is stored centrally instead of being copied into each function's package.
Why B is correct: Attaching the layer by ARN lets every function load the shared code from the layer, so deleting the bundled copy is what actually shrinks each .zip down to its handler code.
Why C is wrong: A container image would centralise the library, but it changes the artifact to an image pushed to Amazon ECR, which the requirement to keep deploying .zip artifacts rules out.
Why D is wrong: Memory scales CPU for the function, not the package size limit; the unzipped artifact limit is fixed regardless of the memory configured.
Why E is wrong: Downloading at cold start sounds size-saving but adds latency and code, is not a managed packaging mechanism, and is not how Lambda resolves layer dependencies.
lock_openFree sampleDeploymenthard
A team is deciding between packaging a Lambda function as a container image and as a .zip deployment package. The function's dependencies, once unzipped, total roughly 3 GB, and the team already builds and tests with their own Docker toolchain. They need to confirm which facts about the container image option are accurate before committing to it. Which TWO statements about deploying Lambda as a container image are correct? (Select TWO.)
- AThe container image must be pushed to Amazon Elastic Container Registry in the same account and Region as the function before the function can be created from it.check_circle Correct
- BContainer image packaging supports an artifact size up to 10 GB, far above the unzipped .zip limit, which suits the 3 GB dependency set.check_circle Correct
- CThe image can be stored in Docker Hub and Lambda will pull it directly from there when the function is invoked.
- DChoosing a container image lets the function skip the Lambda runtime API, since the image already defines its own entrypoint.
- ELambda automatically attaches any function layers to a container image at deployment, merging their contents into the image filesystem.
Lambda container images are pulled from Amazon ECR in the function's account and Region and support artifacts up to 10 GB, unlike layer-based .zip packages. Container image functions require the image to reside in Amazon ECR in the same account and Region, and they raise the artifact ceiling to 10 GB versus the 250 MB unzipped .zip limit. They cannot use Lambda layers, so all dependencies are baked into the image, and the image must still implement the runtime API to receive events.
Why A is correct: Lambda pulls container images from Amazon ECR; the image must live in ECR in the function's account and Region for the function to be created or updated from it.
Why B is correct: Lambda container images support up to 10 GB, well beyond the 250 MB unzipped .zip limit, so they accommodate the 3 GB dependency footprint.
Why C is wrong: Pulling from a public registry sounds plausible, but Lambda sources container images only from Amazon ECR, not Docker Hub or other external registries.
Why D is wrong: A custom entrypoint does not bypass the contract; the image must still implement the Lambda runtime API, usually via the runtime interface client, to receive invocations.
Why E is wrong: Layers apply to .zip packaging only; container images cannot use Lambda layers, so dependencies must be baked into the image itself.
lock_openFree sampleDeploymenthard
A Lambda function must read a database password stored as a SecureString parameter in AWS Systems Manager Parameter Store, where the value is encrypted with a customer managed AWS KMS key. The function calls GetParameter with WithDecryption set to true but the call fails with an access denied error. The team wants the function's execution role to grant least-privilege access so the call succeeds. Which TWO permissions must the execution role allow on the correct resources? (Select TWO.)
- Assm:GetParameter on the specific parameter Amazon Resource Name under /app/prod/db-passwordcheck_circle Correct
- Bsecretsmanager:GetSecretValue on the secret Amazon Resource Name holding the password
- Ckms:Decrypt on the customer managed key Amazon Resource Name used to encrypt the parametercheck_circle Correct
- Dssm:PutParameter on the parameter Amazon Resource Name so the function can refresh the cached value
- Ekms:GenerateDataKey on the AWS managed alias/aws/ssm key for the account
Reading an encrypted SecureString parameter with a customer managed key requires both ssm:GetParameter on the parameter and kms:Decrypt on that key. Parameter Store does not decrypt SecureString values itself. When WithDecryption is true it invokes KMS Decrypt using the caller's credentials, so the execution role needs ssm:GetParameter to fetch the ciphertext and kms:Decrypt on the customer managed key to obtain the plaintext.
Why A is correct: Reading a single named parameter requires ssm:GetParameter scoped to that parameter ARN, satisfying least privilege for the retrieval call.
Why B is wrong: Tempting because both store secrets, but the value lives in Parameter Store, not Secrets Manager, so this permission targets the wrong service and grants nothing useful here.
Why C is correct: WithDecryption makes Parameter Store call KMS on the caller's behalf, so the role needs kms:Decrypt on the customer managed key or the decryption fails.
Why D is wrong: PutParameter grants write access, which violates least privilege for a read-only function and is irrelevant to a GetParameter call.
Why E is wrong: GenerateDataKey is an encryption operation, not decryption, and the alias/aws/ssm AWS managed key is not the customer managed key in use, so this neither matches the action nor the resource.
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.
lock_openFree sampleTroubleshooting and Optimizationmedium
A high-throughput Lambda function must record per-request custom metrics such as latency and a success flag, broken down by customer tier, while still keeping the full structured log line for later querying. The team wants CloudWatch to extract the metrics asynchronously from the logs rather than making a separate synchronous metrics API call on every invocation. Which approach meets this requirement?
- ACall the CloudWatch PutMetricData API once per request with the latency value and a dimension for the customer tier, and write the structured log line separately.
- BWrite the structured log line to CloudWatch Logs and create a metric filter for each metric, so CloudWatch turns matching log values into metrics over time.
- CSend the metrics directly to a CloudWatch dashboard widget from the function code, so the dashboard stores the latency and success values for each customer tier.
- DEmit the log line using the CloudWatch embedded metric format, declaring the metrics and dimensions in the metadata so CloudWatch extracts metrics from the log asynchronously.check_circle Correct
Use the CloudWatch embedded metric format to emit custom metrics and rich logs in one line so CloudWatch extracts metrics asynchronously. The embedded metric format encodes metric definitions and dimensions in a special metadata section of a structured JSON log event, so a single log write captures both the queryable log and the custom metrics, which CloudWatch extracts asynchronously and avoids a per-request PutMetricData call.
Why A is wrong: PutMetricData adds a synchronous API call and latency on every invocation, which is exactly the per-request metrics call the team wants to avoid in a high-throughput function.
Why B is wrong: Metric filters can extract numeric values from logs, but maintaining a separate filter per metric and dimension combination is rigid and does not scale to per-request high-cardinality breakdowns.
Why C is wrong: A dashboard only visualises metrics that already exist and cannot ingest or store raw values from function code, so it is not a mechanism for emitting custom metrics.
Why D is correct: The embedded metric format lets the function write one structured log line carrying both the raw fields and metric metadata, and CloudWatch extracts the metrics from the logs without a separate synchronous API call.
lock_openFree sampleTroubleshooting and Optimizationmedium
An application writes a log line containing the text OutOfMemory whenever a worker process is killed. The operations team wants an Amazon CloudWatch alarm to notify them when these out of memory events exceed five occurrences in any five minute window, using only data already present in the CloudWatch Logs log group. What should the developer configure?
- ACreate a metric filter on the log group that matches the OutOfMemory pattern and increments a custom metric, then set a CloudWatch alarm on that metric with the threshold.check_circle Correct
- BSchedule a CloudWatch Logs Insights query that counts OutOfMemory lines every five minutes and have the query raise the alarm when the count exceeds the threshold.
- CConfigure a subscription filter that forwards OutOfMemory events to an Amazon SNS topic, so the topic notifies the team each time a matching event arrives in the log group.
- DTurn on CloudWatch anomaly detection for the log group so it learns the normal rate of OutOfMemory lines and alarms when the rate becomes anomalous.
Use a CloudWatch Logs metric filter to convert a log pattern into a metric and alarm on a count threshold over a time window. A metric filter scans incoming log events for a pattern and publishes a numeric metric when it matches, and a CloudWatch alarm evaluating that metric against a sum threshold over a five minute period sends a notification using only the data already in the log group.
Why A is correct: A metric filter converts each matching log line into a data point on a CloudWatch metric, and an alarm on that metric with the count threshold over five minutes triggers the notification entirely from existing logs.
Why B is wrong: Logs Insights runs interactive or scheduled queries but does not itself raise CloudWatch alarms, so the count would have no alarm wired to it to drive the notification.
Why C is wrong: Subscription filters deliver to Kinesis, Firehose, or Lambda rather than directly to SNS, and they cannot apply a count over a time window, so they cannot enforce the five in five minutes rule.
Why D is wrong: Anomaly detection bands apply to existing metrics rather than raw log text, so without first extracting a metric there is nothing for anomaly detection to model against the static threshold required.
Examworthy is not affiliated with or endorsed by Amazon Web Services. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. DVA-C02 and related marks belong to their respective owners.
