Free DVA-C02 practice questions

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

A team builds a Lambda function from a custom container image based on a minimal Debian image they already maintain. When they deploy it, Lambda cannot start the function because the image does not implement the Lambda runtime API. The team wants their custom base image to work with Lambda while changing the base image as little as possible. What should they add to the image?

• AInstall the AWS Lambda Runtime Interface Client in the image and set it as the entry point so the container can talk to the Lambda runtime API.check_circle Correct
• BAdd an AWS CLI install step to the image so the container can call Lambda service endpoints and register itself with the runtime when it starts.
• CPlace the function code under /var/task and rely on Lambda to inject its runtime automatically into any container image at invocation time.
• DOpen a port in the image and run an HTTP server so Lambda can send each event to the function as a standard inbound web request over that port.

Why A is correct: The Runtime Interface Client implements the Lambda runtime API for a function, so adding it to a custom base image and using it as the entry point lets Lambda invoke the handler over that API.

Why B is wrong: The AWS CLI issues service API calls and has nothing to do with the per-invocation runtime API contract, so installing it does not let Lambda hand events to the function handler.

Why C is wrong: Lambda injects a runtime only into managed zip runtimes, not arbitrary container images, so a custom image must supply its own runtime client rather than expecting one at invocation.

Why D is wrong: Lambda does not deliver events as inbound HTTP requests to a listening port, so exposing a web server does not satisfy the runtime API contract that container images must implement.

A developer attaches three Lambda layers to a function. Two of the layers contain a file at the identical path /opt/python/shared/config.py, but with different contents. The developer needs to predict which version of that file the function will actually load at runtime. How does Lambda resolve the conflicting file paths across attached layers?

• ALambda rejects the function configuration at deploy time because two attached layers declare the same file path, which it treats as a packaging conflict.
• BLambda keeps both files by appending the layer version to each name, so the handler must reference the fully qualified path that includes the version.
• CLambda loads whichever file comes from the layer with the lowest version number, because lower versions are treated as the stable base set.
• DLambda extracts the layers in the order they are listed and a later layer in the list overwrites the file from an earlier layer at the same path.check_circle Correct

Why A is wrong: Lambda does not validate layer contents for overlapping paths at deploy time, so the configuration is accepted and the conflict is resolved silently by extraction order rather than being rejected.

Why B is wrong: Lambda does not rename or version files inside /opt, so no version suffix is added and the handler cannot select between copies through a fully qualified versioned path.

Why C is wrong: Resolution depends on the attachment order of layers on the function, not on layer version numbers, so a lower version number gives a file no special precedence during extraction.

Why D is correct: Layers are merged into /opt in the order they are added to the function, so when two layers ship the same path the one listed later overwrites the earlier file, and that is the version the runtime loads.

A team wants a Lambda function to emit custom metrics through the CloudWatch embedded metric format (EMF) so a single structured log line is parsed into metrics with no separate metrics API call. Which TWO elements must the log object contain for CloudWatch to extract the metrics correctly? (Select TWO.)

• AAn _aws node holding a CloudWatchMetrics array that names the namespace, the dimension sets and the metric directives.check_circle Correct
• BTop-level properties whose keys match the metric and dimension names referenced in the metric directives.check_circle Correct
• CA call to PutMetricData inside the handler that publishes the same values synchronously to CloudWatch.
• DA StorageResolution property set to 1 so that the metrics are stored at standard one-minute granularity.
• EA CloudWatch metric filter defined on the log group to scan the lines and create the metrics.

Why A is correct: The _aws metadata node with the CloudWatchMetrics array is what tells CloudWatch which properties are metrics, under which namespace and dimensions, so it is required.

Why B is correct: EMF reads the actual numeric values and dimension values from top-level members of the same JSON object, so those keys must be present and match the directives.

Why C is wrong: EMF exists precisely to avoid a synchronous PutMetricData call; adding one defeats the purpose and is not part of the log object.

Why D is wrong: StorageResolution of 1 means high resolution, not standard, and it is optional metadata, not a requirement for EMF extraction to work.

Why E is wrong: Metric filters are a separate text-pattern feature; EMF metrics are extracted automatically from the structured line and need no metric filter.

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.

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 developer must build a CloudWatch Logs Insights query against JSON access logs that have a route field and a numeric durationMs field, to return each route with its average durationMs over the last hour, ordered from slowest route to fastest. Which TWO query commands are essential to produce that result? (Select TWO.)

• AA stats avg(durationMs) by route command to compute the per-route average as an aggregation.check_circle Correct
• BA sort command on the aggregated average in descending order so the slowest route appears first.check_circle Correct
• CA parse command to extract durationMs from the raw message text before aggregating.
• DA dedup command on route to remove duplicate routes from the aggregated output.
• EA bin(1h) grouping in the stats command to bucket the averages into one-hour time intervals.

Why A is correct: stats with avg() grouped by route is the aggregation that turns raw events into one average duration per route, which the requirement demands.

Why B is correct: sort by the aggregated value desc orders the grouped results slowest first, which the requirement explicitly asks for.

Why C is wrong: parse is for unstructured text; the logs are JSON with durationMs already discovered as a field, so parse is unnecessary here.

Why D is wrong: dedup is not a Logs Insights command and stats by route already produces one row per route, so no deduplication is needed.

Why E is wrong: bin() produces a time series within the range; the requirement wants one average per route across the whole hour, not time-bucketed values.