DVA-C03 sample questions — 25 answered and explained

At-least-once delivery means consumers that cause side effects must be idempotent.

There are two causes of duplicates. A visibility timeout shorter than processing makes the message reappear, and SQS standard queues deliver at least once, so a message can occasionally arrive twice anyway. Only an idempotency check on a business key covers both causes. A longer visibility timeout fixes only the first cause. FIFO deduplication works on sends, not on redelivery after a timeout. Deleting first trades duplicates for lost orders.

1. List each cause of duplicates the logs reveal.
2. Recall that standard queues guarantee at-least-once, not exactly-once, delivery.
3. Check whether each option removes both causes or only one.
4. Prefer a check on a business key (the order ID) before the side effect.

Exam tip: With at-least-once delivery, make the side effect idempotent; queue settings alone cannot prevent every duplicate.

Graceful degradation: bound the wait on a non-critical dependency and fall back to a reduced result.

The core feature (product details) works; only an optional feature fails. Graceful degradation means the core feature keeps working with reduced functionality. Two pieces are needed: a short timeout so the page does not wait, and a fallback (a cached generic list) so the page still shows something useful. Retrying until success and raising timeouts both lengthen the wait, and returning 503 fails a page that could have been served.

1. Decide which dependency is essential and which is optional.
2. Bound the time spent on the optional dependency.
3. Provide a reduced but useful result when it fails.
4. Reject options that wait longer or fail the whole page.

Exam tip: When an optional dependency fails, time out quickly and serve a fallback.

API Gateway REST API request validation with JSON Schema models.

API Gateway REST APIs can validate the request body against a model (a JSON Schema) and required parameters before calling the backend. Invalid requests are rejected with 400, and the backend never runs. Mapping templates transform, authorizers decide on identity and do not see the body, and WAF inspects patterns rather than schemas.

1. Identify the requirement: reject malformed bodies in API Gateway, no code.
2. Recall that a request validator plus a model validates bodies against JSON Schema.
3. Rule out features built for transformation, authorization or traffic filtering.

Exam tip: Reject bad request bodies at the edge with a model plus a request validator.

REST APIs vs HTTP APIs: request validation is available only on REST APIs.

HTTP APIs are cheaper and simpler, but they leave out several REST API features, including request validation with models. Because the team must keep pre-backend validation without writing code, the REST API is the only option that meets the constraint. Parameter mapping and JWT authorizers are real HTTP API features, but neither validates a body.

1. List the feature the team depends on: request body validation.
2. Recall which API type supports it: REST APIs only.
3. Check whether any HTTP API feature can replace it without code: none does.
4. Let the no-code constraint decide.

Exam tip: Need request validation in API Gateway with no code? That is a REST API feature.

API Gateway data transformation: mapping templates in non-proxy integrations.

Renaming request fields and removing response fields is data transformation, which API Gateway does with VTL mapping templates in the integration request and integration response. Those templates exist only for non-proxy (custom) integrations; proxy integrations deliberately pass everything through. A Lambda function could transform the data, but it adds compute.

1. Recognise the task as transformation in both directions.
2. Recall that mapping templates transform requests and responses.
3. Recall that mapping templates apply only to non-proxy integrations.
4. Use the no-extra-compute constraint to rule out the Lambda option.

Exam tip: Transform in API Gateway with mapping templates, and only on a non-proxy integration.

API Gateway AWS service integrations: credentials plus request mapping.

A direct service integration needs two things that a Lambda proxy integration would otherwise hide. First, credentials: API Gateway assumes the integration's IAM role, which must allow sqs:SendMessage. Second, a request in the shape the service expects: SendMessage takes a MessageBody parameter, so an integration request mapping template wraps the raw JSON body into it, for example as form-encoded Action=SendMessage&MessageBody=... with Content-Type application/x-www-form-urlencoded (SQS also accepts the AWS JSON protocol, which still needs the body mapped into MessageBody). Validators cannot transform, and no VPC link is needed for a public AWS endpoint.

1. Ask how API Gateway gets permission to call SQS: an IAM role on the integration.
2. Ask whether SQS accepts the raw JSON body as is: no, the body must be mapped into the MessageBody parameter.
3. Recall that mapping templates, not validators, transform the request.
4. Reject network components that the public SQS endpoint does not need.

Exam tip: API Gateway to an AWS service needs a role to call it and a mapping template to speak its API.

Kinesis partition keys decide shard placement; low-cardinality keys create hot shards.

Kinesis hashes the partition key to choose a shard, and each shard has its own write capacity. Three keys can use at most three shards, so those shards are throttled while the other seven are idle. A key with many distinct values spreads the load. Adding shards is the tempting answer, but extra shards stay unused while the keys do not change.

1. Compare the total write rate with stream capacity: well below.
2. Conclude that the load is concentrated on a few shards.
3. Trace the cause to a partition key with only three values.
4. Fix the key, not the shard count.

Exam tip: Throttled below total capacity means hot shards; give the stream a partition key with many distinct values.

Kinesis ordering is per partition key within a shard; parallelization factor adds concurrency without breaking it.

Two facts must be combined. Ordering in Kinesis exists only within a shard, so all of a device's records must share a partition key (the device ID). Lambda's parallelization factor lets one shard be processed by several concurrent batches while still keeping records with the same partition key in order. That increases throughput without adding shards. Random keys and standard queues break ordering, and a batch size of one lowers throughput.

1. Secure the ordering requirement: one partition key per device.
2. Find a way to add concurrency per shard without new shards.
3. Recall that parallelization factor preserves order per partition key.
4. Reject options that break ordering or reduce throughput.

Exam tip: Order by partition key; scale a shard's consumer with the parallelization factor.

DynamoDB fine-grained access control limits items by partition key with dynamodb:LeadingKeys and a policy variable for the caller.

The goal is row-level isolation by partition key. dynamodb:LeadingKeys compares the partition key in each request with a value in the policy, and ${cognito-identity.amazonaws.com:sub} resolves to the calling identity's ID, which is exactly what the table stores. The Attributes and Select keys limit attributes, not items, and aws:username is not defined for federated role sessions.

1. Identify that isolation is per item, keyed by the partition key.
2. Choose the condition key that restricts partition key values.
3. Choose the policy variable that holds the Cognito identity ID.
4. Reject keys that only limit attributes.

Exam tip: Per-user DynamoDB rows: LeadingKeys plus ${cognito-identity.amazonaws.com:sub}.

${cognito-identity.amazonaws.com:sub} is the identity pool's identity ID, not the user pool user's sub.

Two Cognito identifiers are easy to confuse. The user pool sub claim identifies the user in the directory, while the identity pool assigns its own identity ID (region:GUID) to each federated identity. The IAM policy variable ${cognito-identity.amazonaws.com:sub} resolves to that identity ID. Because the app writes under the user pool sub, no key ever matches the allowed resource. Using the identity ID returned by GetId (or by the credentials call) as the prefix fixes it. Usernames and aws:userid don't resolve to the right value, and ACL permissions are unrelated.

1. Read what value the app puts in the key: the user pool sub claim.
2. Recall what the policy variable resolves to: the identity pool identity ID.
3. See that the two never match, so every request is denied.
4. Align the key prefix with the policy variable.

Exam tip: In identity-pool policies, cognito-identity.amazonaws.com:sub is the identity ID; key your data by it.

To use MFA from the CLI or SDK, exchange the long-term key plus an MFA code for temporary credentials.

Requests signed directly with an access key cannot include MFA. The way to add it is to call GetSessionToken (or AssumeRole) with SerialNumber and TokenCode, which returns temporary credentials whose requests include MFA context. Calling it without MFA produces credentials that still fail the condition. mfa_serial only prompts for a code in a role-assuming profile, and GetCallerIdentity returns no credentials.

1. Recognise that long-term access keys alone cannot prove MFA.
2. Find the STS call that accepts an MFA code and returns credentials.
3. Use those temporary credentials for the CLI commands.
4. Reject calls that skip the MFA parameters.

Exam tip: MFA for API calls arrives through STS: GetSessionToken or AssumeRole with SerialNumber and TokenCode.

aws:MultiFactorAuthPresent is absent, not false, on requests signed with long-term access keys.

A Bool condition only matches when the key exists and equals the value. Requests made with long-term access keys do not include aws:MultiFactorAuthPresent at all, so the original Deny never matches them. BoolIfExists treats a missing key as a match, so the statement denies both requests without the key and temporary sessions created without MFA, where the key is false. A Null check on the key catches only the long-term key calls, the "true" form denies the MFA users instead, and a MultiFactorAuthAge comparison ignores requests where the key is missing.

1. Ask whether the key exists on a long-term access key request: it does not.
2. Recall that Bool does not match a missing key.
3. Use the IfExists form so a missing key also triggers the Deny.
4. Check that MFA sessions (key true) are still allowed.

Exam tip: To require MFA with a Deny, use BoolIfExists on aws:MultiFactorAuthPresent = false.

Applications on AWS compute get temporary credentials from the role attached to that compute, and the SDK finds them automatically.

An instance profile delivers a role's temporary credentials through the instance metadata service, and the SDK's default credential provider chain picks them up and refreshes them without any code changes. Keys kept in Secrets Manager or an encrypted file are still long-term IAM user keys, and a bucket policy cannot name an EC2 instance as a principal, so the SDK would have nothing to sign with.

1. Note the constraint: no long-term credentials on servers or in code.
2. Recall how EC2 provides temporary credentials: an instance profile role.
3. Confirm the SDK finds role credentials without configuration.
4. Reject options that store an access key or try to grant access to the instance itself.

Exam tip: On EC2, use an instance profile role, never access keys.

The SDK default credential provider chain stops at the first source it finds, and environment variables come before the instance profile.

The error shows the requests are signed as an IAM user, not the role. The SDK checks sources in order (explicit parameters, environment variables, shared files and profiles, then container and instance metadata) and uses the first one that has credentials. The copied startup script exports build-bot's keys, which win over the instance profile. Removing them lets the chain fall through to the role. Changing the role or reattaching the profile doesn't help while the variables are present.

1. Read the principal in the error: an IAM user, not the role.
2. Recall the order of the default credential provider chain.
3. Find where an IAM user's keys could come from: the copied environment variables.
4. Remove them so the chain reaches the instance profile.

Exam tip: If AWS calls run as an unexpected principal, look earlier in the credential chain: environment variables beat the instance role.

S3 presigned URLs grant time-limited access to one object for one operation without changing bucket permissions.

The customer has no AWS credentials and the object must stay private. A presigned URL is signed by a principal that has s3:GetObject and includes an expiration, so the customer's browser can download the invoice directly until the URL expires. Making objects public or editing the bucket policy per request weakens the bucket's security, and a PUT URL authorizes uploads, not downloads.

1. Note that the downloader has no AWS credentials.
2. Use a URL signed by the backend for that object and operation.
3. Match the method to the action: GET for download.
4. Set the expiration to the required window.

Exam tip: Time-limited download of a private S3 object: presigned GET URL.

Docker reuses a cached layer only when the instruction and everything before it are unchanged.

Docker builds layer by layer and reuses a cached layer until an instruction's inputs change; after that, every later layer is rebuilt. COPY . . changes whenever any file changes, so pip install after it always reruns. Copying only requirements.txt, installing, and then copying the rest puts the slow step behind an input that rarely changes. CodeBuild's local Docker layer cache helps only once the Dockerfile is ordered this way.

1. Find the slow step: pip install.
2. Find its inputs: everything copied before it, currently the whole source tree.
3. Narrow the input to requirements.txt and move the full copy after the install.
4. Optionally add build caching so the reused layer survives between builds.

Exam tip: Order Dockerfile steps from least to most frequently changing: dependencies before source.

ECR pull through cache keeps copies of upstream registry images in your private registry.

A pull through cache rule maps a repository prefix in your ECR registry to an upstream registry. The first pull through the ECR URI fetches the image from upstream and stores it; ECR then serves later pulls and checks upstream for updates. Docker Hub as an upstream needs its credentials in an AWS Secrets Manager secret. Replication only copies between ECR registries, CodeArtifact handles language packages, and a custom copy job adds code to maintain.

1. Identify the need: cache third-party images in ECR and keep them current.
2. Rule out replication, which only works between ECR registries.
3. Rule out CodeArtifact, which does not store container images.
4. Create a pull through cache rule and point builds at its prefix.

Exam tip: Upstream images throttling your builds? Use an ECR pull through cache rule.

Native dependencies in a Lambda package must be compiled for the Lambda runtime's operating system and architecture.

Packages with compiled extensions ship platform-specific binaries. Installing them on macOS produces Mach-O binaries that the Linux-based Lambda runtime cannot load, which shows up as invalid ELF header. sam build --use-container installs dependencies inside a container image that matches the Lambda runtime, so the package contains Linux binaries for the function's architecture. A layer, an environment variable or more memory does not change how the binaries were built.

1. Read the error: invalid ELF header means a binary built for another platform.
2. Note the dependency has compiled C extensions.
3. Rebuild the dependencies in a Lambda-compatible Linux environment.
4. Repackage and redeploy the function.

Exam tip: Compiled dependencies for Lambda must be built on a Lambda-like Linux image, for example with sam build --use-container.

Build once, deploy many: keep environment-specific values out of the artifact and inject them at deployment or run time.

To promote the same artifact, the package must not contain anything that differs per environment. The deployment for each environment then supplies its values, for example as Lambda environment variables set from template parameters, or as parameter names the code reads from Parameter Store or AppConfig. Bundling every environment's file keeps one artifact but leaks prod values; per-environment builds or branches satisfy isolation but break the tested-equals-released rule. Only externalised configuration satisfies both.

1. Requirement one: the tested artifact is the released artifact, so build once.
2. Requirement two: prod values must not ship to other environments, so do not bundle them.
3. Reject options that rebuild per environment or bundle every environment's values.
4. Supply values per environment at deployment through the stack's configuration.

Exam tip: Same artifact everywhere, different configuration per environment, supplied outside the package.

AWS CodeArtifact is the managed package repository for language package managers.

CodeArtifact repositories work with npm, pip/twine, Maven, Gradle, NuGet and other clients. Teams publish private packages to a repository and give it upstream repositories; each upstream can hold one external connection to a public registry (for example an npm-store connected to npmjs and a pypi-store connected to PyPI), so the team's repository serves private and public packages, and fetched public versions are kept. Each package format still uses its own repository endpoint URL. ECR is for container images, Distributor is for installing software on instances, and S3 would need a custom registry layer.

1. Identify the artifacts: language packages (npm, Python), not container images.
2. Identify the needs: private publishing plus public packages through the same repository.
3. Match them to a CodeArtifact repository whose upstreams connect to the public registries.

Exam tip: Language packages go in CodeArtifact; container images go in ECR.

X-Ray groups failures into three categories by HTTP status class.

X-Ray records 400-series responses as Error, 500-series as Fault and 429 as Throttle. Mostly Errors on the orders-to-inventory edge means the inventory service is answering with client errors such as 400 or 404. That points at the caller's request, for example a changed payload or a wrong ID, rather than a failure inside the inventory service.

1. Recall Error = 4xx, Fault = 5xx, Throttle = 429.
2. Note which category dominates on the edge.
3. Map 4xx to a defect in the caller's request.
4. Inspect the failing subsegment's request and response for the details.

Exam tip: In X-Ray, Error means 4xx (caller's problem), Fault means 5xx (server's problem) and Throttle means 429.

Subsegments break a trace's time into the downstream calls made during the request.

In a Lambda trace, the function segment contains an Initialization subsegment (only on cold starts) and an Invocation subsegment. Inside it, instrumented SDK and HTTP clients add one subsegment per call. Here the HTTP call takes 2.7 s of the 2.9 s Invocation, so the partner endpoint is the bottleneck. There is no Initialization subsegment, so this was not a cold start, and the DynamoDB call is negligible.

1. Open the slow trace's timeline.
2. Check for an Initialization subsegment to rule cold starts in or out.
3. Compare the downstream subsegments' durations within Invocation.
4. Attribute the latency to the longest subsegment: the partner HTTP call.

Exam tip: In a trace timeline, the longest downstream subsegment inside Invocation is usually the bottleneck.

Only annotations are indexed for X-Ray filter expressions, and OpenTelemetry attributes become metadata unless you mark them.

X-Ray annotations are indexed key-value pairs that filter expressions and GetTraceSummaries can search. Metadata is stored but not indexed. When OpenTelemetry spans are exported to X-Ray, attributes become metadata by default. To make one searchable, add its key to the aws.xray.annotations attribute list. Sampling and groups do not change whether a field is indexed. (The X-Ray SDKs entered maintenance mode in February 2026, and AWS recommends OpenTelemetry for new instrumentation.)

1. Note that the value is present but under metadata.
2. Recall that filter expressions search only annotations.
3. Recall that OTel attributes map to metadata by default.
4. Mark the key in aws.xray.annotations so new traces are searchable.

Exam tip: To filter traces by a field, record it as an annotation. With OpenTelemetry, list it in aws.xray.annotations.

Logs Insights commands run as a pipeline: filter the raw events first, then aggregate with stats.

filter @message like /ERROR/ keeps matching events, and stats count(*) by bin(5m) groups them into 5-minute time buckets, which is what shows when a spike started. Grouping by @logStream gives a per-environment count, putting stats before filter leaves only aggregated rows to filter, and sort plus limit lists events without counting them.

1. Filter raw events to the ones that matter.
2. Aggregate with stats count(*).
3. Group by bin(5m) to bucket by time.
4. Keep filter before stats, because stats replaces the raw fields.

Exam tip: Time-series counts in Logs Insights: filter, then stats count(*) by bin(interval).

Logs Insights automatically discovers fields from Lambda REPORT lines.

For Lambda log groups in plain-text format, Logs Insights finds @type, @requestId, @duration, @billedDuration, @memorySize, @maxMemoryUsed and, on cold starts, @initDuration in the REPORT line that ends each invocation. Filtering to REPORT, selecting @requestId and @maxMemoryUsed, and sorting descending gives the heaviest invocations. START lines have no memory data, @memorySize is the setting rather than the usage, and binned stats lose the request IDs.

1. Know that per-invocation memory use is in the REPORT line.
2. Filter @type = "REPORT".
3. Select @requestId and @maxMemoryUsed.
4. Sort by @maxMemoryUsed descending and limit 20.

Exam tip: Lambda REPORT lines give @maxMemoryUsed, @duration and @initDuration per @requestId.