DVA-C02 sample questions — 25 answered and explained

The circuit breaker pattern: stop calling a failing dependency, fail fast or serve a fallback, and probe for recovery after a cooling-off period.

Timeouts and backoff retries handle transient errors, but during an extended outage they still let every request wait out its timeout, which is what exhausted the thread pool. A circuit breaker adds the missing behavior: after a threshold of consecutive failures the circuit opens and subsequent calls fail immediately (or return a fallback such as cached rates), so threads are freed instantly; after a cooling period, a few trial calls test recovery before the circuit closes. Raising the timeout or the retry count increases the time threads spend waiting on a dead dependency. Adding capacity only delays exhaustion while wasting resources. This is exactly the resilience skill DVA-C02 v2.1 added for third-party integrations, whose availability and rate limits you do not control.

1. Note that transient-error tooling (timeouts, backoff retries) is already in place and the failure is an extended outage.
2. Identify the damage mechanism: threads held for the full timeout on every doomed call.
3. Apply a circuit breaker: open after consecutive failures, fail fast or serve a fallback while open.
4. After a cooling-off period, let trial calls test the dependency before closing the circuit.

Exam tip: Timeouts and retries handle transient errors; an extended third-party outage needs a circuit breaker that fails fast instead of tying up threads.

Request and response transformation in API Gateway lives in mapping templates — a REST API feature attached to non-proxy (custom) integrations.

When neither side of an integration can change, the gateway must reshape the payload, and that is exactly what mapping templates do: written in Velocity Template Language and attached to the integration request (or response), they convert the client's JSON into the structure the legacy backend expects. This requires a REST API with a non-proxy integration — with a proxy integration API Gateway passes the request straight through, and HTTP APIs support only proxy-style behavior with no mapping templates at all. Request validators are the enforcement feature: they reject malformed requests but cannot rewrite them. Gateway responses only customize errors that API Gateway itself generates. When an exam stem mentions transforming payloads at the gateway, it is describing a REST API.

1. Establish the constraint: payload must be reshaped and neither client nor backend can change, so the gateway must transform.
2. Recall that transformation is done by mapping templates in VTL, attached to non-proxy integrations.
3. Recall the API-type rule: mapping templates are REST API features; HTTP APIs are proxy-only and cheaper but cannot transform.
4. Eliminate validators (validate, not transform) and gateway responses (customize API Gateway's own errors).

Exam tip: Payload transformation at the gateway = REST API + non-proxy integration + VTL mapping template; HTTP APIs and proxy integrations pass requests through unchanged.

Enforcing validation rules at the gateway: API Gateway request validators check required parameters and JSON Schema models before invoking the backend.

Request validators are the REST API feature built for exactly this: declare which query strings and headers are required and attach a JSON Schema model for the body, and API Gateway rejects invalid requests with a 400 before the integration runs — so the Lambda function is neither invoked nor billed for them. Moving validation earlier inside the handler changes nothing about invocation cost. WAF operates on attack patterns and traffic filtering, not on schema conformance of legitimate-but-malformed API requests. Usage plans meter and throttle keyed clients; they have no view into payload validity. The declarative model also satisfies the least-maintenance qualifier: the schema lives in API configuration rather than code.

1. Identify the cost problem: malformed requests are invoking the backend before being rejected.
2. Recall that REST APIs can validate at the gateway with request validators.
3. Attach required-parameter checks and a JSON Schema model so invalid requests get a 400 before the integration.
4. Eliminate in-handler validation (still billed), WAF (exploit filtering), and usage plans (throttling and quotas).

Exam tip: Use API Gateway request validators (required parameters + JSON Schema models) to reject malformed requests with a 400 before they invoke or bill the backend.

Overriding status codes in API Gateway: integration responses map patterns in the backend response to the method response status the client receives.

Status-code overriding is configured in integration responses on a REST API: a selection pattern — for example a regex matching "ITEM_NOT_FOUND" — is evaluated against the backend response, and matches are mapped to the desired method response status, turning the backend's misleading 200 into a clean 404 with no backend change. Gateway responses are the wrong layer: they customize responses that API Gateway itself generates, such as the body and headers of a 403 from a failed authorizer, and are never triggered by a successful backend response. An integration-request mapping template runs in the request direction, before any response exists. HTTP APIs cannot help because they are proxy-only: the backend's status flows through untouched.

1. Recognize the requirement: remap a backend response (200 + error string) to a different client-facing status.
2. Recall that this is the job of integration responses with selection patterns on a REST API.
3. Configure a pattern matching the error string and map it to a 404 method response.
4. Distinguish gateway responses (API Gateway's own errors) and note HTTP APIs pass backend statuses through unchanged.

Exam tip: To turn a backend error string into a proper HTTP status, use a REST API integration response selection pattern; gateway responses only customize API Gateway's own errors.

SDK pagination: list and query APIs return one page plus a continuation token, and the caller must loop — ideally with the SDK's built-in paginators.

Seeing only the first batch of results while ignoring a NextToken is the textbook symptom of missing pagination. List APIs return a bounded page of results and a continuation token pointing at the rest; the SDK's paginators encapsulate the loop — request, read token, request again — until no token remains, which is more robust than a hand-rolled loop. Timeouts are irrelevant because pagination is by design, not a slow response. Waiters solve a different problem: polling until a resource reaches a target state, with backoff built in. Retry modes govern transient errors like throttling; a paginated 200 response is a success, so no retry behavior will ever surface page two.

1. Spot the symptom: only the first batch of results, with an unused NextToken in the response.
2. Recall that list APIs are paginated: one page per call plus a continuation token.
3. Use the SDK's built-in paginator to loop until the token is absent.
4. Distinguish the other SDK features: waiters poll for resource state, retry modes handle transient errors.

Exam tip: An application that only ever sees the first page of results is ignoring the continuation token — use the SDK's paginators, not bigger timeouts or retries.

Kinesis enhanced fan-out: each registered consumer gets a dedicated 2 MB per second per shard with push delivery, instead of sharing the standard read throughput.

The bottleneck is stated precisely: multiple consumer applications competing for a shard's shared 2 MB per second of read throughput. Enhanced fan-out is the purpose-built fix — each registered consumer receives its own dedicated 2 MB per second per shard, delivered by push, so consumers stop throttling each other and latency drops. Splitting shards multiplies capacity and cost but leaves all consumers still sharing each individual shard's standard read pipe, so contention per shard persists. Switching to SQS breaks the requirements at a deeper level: messages are deleted once processed by one consuming application, so multiple independent readers of the same data — a defining Kinesis capability, along with replayable retention — are lost. Slower polling with bigger batches just trades throughput for latency without addressing the shared limit.

1. Identify the constraint: consumers share each shard's 2 MB per second standard read throughput.
2. Note the requirement: dedicated throughput per consumer with low latency.
3. Map this to enhanced fan-out: dedicated 2 MB per second per shard per registered consumer, push delivery.
4. Reject resharding (consumers still share each shard's pipe) and SQS (one consuming application per queue, no replay).

Exam tip: When multiple Kinesis consumers contend for a shard's shared read throughput, register them as enhanced fan-out consumers for dedicated 2 MB per second per shard each.

Kinesis ordering semantics: the partition key selects the shard, and record order is guaranteed only within a shard — so the key must group the records that need ordering.

Using the sensor ID as the partition key hashes all of one sensor's readings to the same shard, where Kinesis preserves their order, while thousands of distinct sensor IDs give the high cardinality that spreads load across shards for scale. A random partition key achieves the load spreading but destroys the requirement: one sensor's readings scatter across shards, and there is no cross-shard ordering. SQS standard queues provide best-effort ordering only, and SNS makes no ordering promise across its push deliveries. This is also why partition key choice is a design decision: the key must be exactly the identity that needs ordered processing, with enough distinct values to avoid a hot shard.

1. State the ordering unit: per sensor, not global.
2. Recall that Kinesis guarantees order only within a shard, and the partition key chooses the shard.
3. Set the partition key to the sensor ID so each sensor's readings share a shard and stay ordered.
4. Check scale: thousands of sensor IDs are high-cardinality, spreading load evenly across shards.

Exam tip: To order records per entity in Kinesis, make the entity ID the partition key — ordering holds only within a shard, and the key decides the shard.

EventBridge content filtering: rule event patterns can match exact values, prefixes, numeric ranges, and field existence over any field in the event body, moving routing logic into configuration.

EventBridge rules are where content filtering lives: an event pattern with numeric matching on the order total routes only qualifying events to the fraud queue, while other rules carry the rest to standard processing — no service changes, no filtering code. The SNS option fails twice: the architecture already uses EventBridge, and SNS filter policies primarily match message attributes rather than arbitrary fields inside the payload body. A filtering Lambda works mechanically but violates the no-code constraint and adds a component to run and monitor. Publishing conditionally to a second bus moves the business rule into the producer, re-coupling it to a consumer's needs. This declarative routing on event content is precisely why EventBridge is chosen over SNS when routing depends on the payload.

1. Note the routing condition depends on a value inside the event body (order total above a threshold).
2. Recall that EventBridge rule patterns support content filtering, including numeric ranges, on any body field.
3. Create a rule with a numeric-match pattern targeting the fraud SQS queue; let other rules handle the rest.
4. Reject answers that reintroduce code (Lambda filter, conditional publishing) or the wrong service (SNS attribute filtering).

Exam tip: Routing that depends on event content is an EventBridge rule pattern — including numeric-range matches — not consumer code or SNS attribute filters.

API Gateway's IAM authorization authenticates callers as AWS principals: each request is signed with Signature Version 4 using the caller's credentials, and the caller must be allowed the execute-api:Invoke action on the API.

Both halves are required — the SigV4 signature proves who is calling, and execute-api:Invoke permission on the caller's role authorizes the call. This is the natural fit for service-to-service traffic because every service already holds role credentials. API keys and usage plans are metering features, a recurring exam trap: they never authenticate. A Cognito token targets a different authorizer type and is simply not evaluated by an IAM-authorized method.

1. Grant the calling service's execution role execute-api:Invoke on the target API's ARN.
2. Use the SDK or a signing library so requests are SigV4-signed with the role's temporary credentials.
3. Include the session token header, since role credentials are temporary.
4. API Gateway verifies the signature and evaluates IAM policy before invoking the backend.

Exam tip: IAM-authorized APIs need SigV4-signed requests from a principal holding execute-api:Invoke — API keys and usage plans are never authentication.

Resource-based policies attach to the resource itself, carry a Principal element, and are the mechanism for granting another account access without creating a role to assume — but cross-account access requires both sides to allow.

The queue policy in account A names the account B principal and allows sqs:SendMessage; account B must separately allow its application the same action on the queue's ARN — miss either side and the request is denied. An identity-based policy in account A cannot help because such policies name no principal and only govern account A's own identities. Shared access keys are always wrong. And role assumption is one valid cross-account pattern, but not the only one — the stem explicitly rules it out.

1. Attach a queue policy in account A with account B's principal and sqs:SendMessage on the queue.
2. In account B, grant the application's role sqs:SendMessage on the queue's ARN.
3. Verify no explicit deny exists on either side.
4. The application sends messages directly with its own account B credentials.

Exam tip: Cross-account without AssumeRole = a resource-based policy on the resource plus an identity-based allow in the caller's account — both sides must say yes.

IAM policy evaluation starts from an implicit deny, grants access on an explicit allow, and gives explicit deny absolute precedence over every allow, wherever each appears.

The bucket policy's explicit Deny controls the outcome regardless of the identity policy's allow — this single rule resolves the question. There is no ranking between identity-based and resource-based policies and no first-evaluated-wins behavior; all applicable policies are combined. Within one account an allow from either policy family does normally suffice, but only when no explicit deny applies — which is exactly the condition violated here.

1. Gather all applicable policies: the user's identity-based policy and the bucket policy.
2. Check for explicit denies first — the bucket policy has one for this user.
3. Explicit deny overrides the identity policy's allow, so the request fails.
4. Remove or scope the deny statement if the access should be permitted.

Exam tip: Explicit deny beats every allow — check for denies before reasoning about any allow.

IAM policies come in three packages — AWS managed (maintained by AWS, broad), customer managed (you author, version, and reuse), and inline (bound to one principal) — with service control policies operating separately as organizational guardrails.

Every stated requirement — precise scoping to actions and ARNs, versioning, reuse across many roles — describes customer managed policies. AWS managed policies cannot be edited and are deliberately broad, making tight least privilege impossible. Inline policies pin permissions to one principal, defeating reuse. SCPs are the trap for readers skimming for "managed": they constrain what identities in an organization may ever do but grant nothing.

1. Author a policy with specific Action entries and resource ARNs instead of wildcards.
2. Create it as a customer managed policy so it has its own ARN and version history.
3. Attach it to every application role that needs exactly those permissions.
4. Update centrally by publishing a new policy version; all attached roles inherit it.

Exam tip: Customer managed policies are the tool for reusable, versioned, least-privilege permissions; AWS managed are broad, inline are single-principal, SCPs never grant.

API Gateway offers three protection mechanisms — Cognito authorizers for user pool JWTs, Lambda authorizers for custom logic, and IAM authorization for SigV4-signed AWS callers — and the right one follows from who the caller is and what they carry.

The callers carry Cognito user pool JWTs, so the built-in Cognito authorizer validates signature, expiry, and issuer with nothing to build — the least-code answer by construction. A Lambda authorizer is for tokens Cognito validation cannot handle (third-party, legacy, custom schemes); here it would be redundant operational burden. IAM authorization does not fit users holding JWTs. API keys are the recurring non-answer: metering, never authentication.

1. Identify what callers present: JWTs issued by a Cognito user pool.
2. Create a Cognito authorizer on the API referencing that user pool.
3. Attach the authorizer to the API methods and require it.
4. Have clients send the appropriate token; invalid or missing tokens are rejected before the backend runs.

Exam tip: User pool JWTs → Cognito authorizer (no code); custom token schemes → Lambda authorizer; AWS principals → IAM authorization.

A Lambda authorizer returns a policy decision that API Gateway caches — five minutes by default, configurable — so authorization logic does not execute on every request.

The user's earlier request produced an allow that API Gateway cached; until the cache entry expires, the authorizer function never sees the revocation. That is exactly the observed behavior: access persists for a few minutes, then stops. Authorizers are synchronous, so option b is wrong; API Gateway never bypasses an authorizer because a token is unexpired; and a 15-minute database replication delay is invented — the several-minute window is the signature of the 300-second default cache.

1. Recognize the symptom: revoked permissions still working briefly points to result caching.
2. Recall the Lambda authorizer cache TTL — 300 seconds by default.
3. Shorten or disable the cache TTL if revocation must take effect faster, trading off latency and cost.
4. Balance the cache TTL against how quickly revocations must propagate.

Exam tip: Lambda authorizer decisions are cached (default five minutes) — revocations lag until the cached allow expires.

API keys in API Gateway exist for usage plans: identifying known clients to meter and throttle them. They are not an authentication or authorization mechanism.

An API "secured" only by API keys has no authentication at all — anyone holding the static string passes, and keys are routinely embedded in clients where they leak. Real protection comes from an authorizer matched to the caller: Cognito for user pool JWTs, Lambda for custom schemes, IAM for SigV4-signed AWS principals. Rotation, making the API private, and transit encryption all miss the category error: a metering identifier cannot become an identity proof.

1. Classify the mechanism: API keys belong to usage plans (metering and throttling).
2. Note what is missing: no identity verification of the caller.
3. Add an authorizer suited to the callers — Cognito, Lambda, or IAM.
4. Keep API keys, if desired, purely for per-client quotas alongside the authorizer.

Exam tip: API keys meter and throttle — any design using them as the security mechanism is a distractor.

AWS CodeArtifact is the managed repository for package dependencies — npm, PyPI, Maven, and NuGet — with upstream connections that proxy and cache public registries and support for publishing private packages.

CodeArtifact answers all three requirements natively: builds pull only from the organization's repository (controlling approved versions), cached upstream packages survive removal from the public registry, and teams can publish internal packages privately — all without servers to run. S3 cannot speak the npm protocol, ECR handles container images rather than language packages, and running a registry on EC2 is the opposite of low operational overhead.

1. Create a CodeArtifact domain and repository with an upstream connection to the public npm registry.
2. Point build tooling at the CodeArtifact repository endpoint instead of the public registry.
3. Let CodeArtifact cache every upstream package the builds pull, insulating them from upstream removals.
4. Publish internal packages to the same repository so teams consume approved, private versions.

Exam tip: When a question describes a private npm/PyPI/Maven registry or controlling which package versions builds use, the answer is CodeArtifact — not S3 or ECR.

Lambda's only sizing knob is memory (128 MB to 10,240 MB), and CPU scales proportionally with it — at 1,769 MB a function receives the equivalent of one vCPU.

A CPU-bound function that times out is fixed by raising memory, even when measured memory usage is low, because that is the only way to allocate more CPU. There is no independent vCPU setting to configure. Layers carry shared dependencies and add zero compute. Container-level cpu settings live in ECS task definitions, a different service's resource model entirely.

1. Confirm from metrics and timeouts that the function is CPU-bound rather than memory-bound.
2. Increase the memory allocation, which proportionally increases the CPU the function receives.
3. Measure duration at several memory settings to find the point where added CPU stops shortening runs.
4. Settle on the memory setting that balances duration against GB-second cost.

Exam tip: Lambda CPU comes only from the memory dial — fix a CPU-bound function by raising memory, even if memory usage looks low.

Lambda compute is billed on GB-seconds — allocated memory multiplied by execution duration — and because CPU scales with memory, right-sizing is a measurement exercise, not a guess.

For a CPU-bound function, more memory means more CPU and a shorter duration; whenever the duration reduction outpaces the memory increase, the GB-second cost falls even though the per-second rate rises. The flat-rate claim ignores the GB-second compute charge. Memory is configuration, so no artifact rebuild is involved. And there is no separate CPU billing dial — CPU rides on memory, which is the very mechanism that shortens the runs.

1. Record the current duration and GB-second cost at 1,024 MB.
2. Test the function at several higher memory settings and record each duration.
3. Compute GB-seconds (memory times duration) for each setting and compare costs.
4. Choose the setting with the best cost-performance balance rather than assuming more memory always costs more.

Exam tip: Because Lambda bills GB-seconds and CPU scales with memory, raising memory on a CPU-bound function can cut both duration and cost — measure, don't assume.

ECS separates task-level settings — the total cpu/memory envelope for all containers, required on Fargate — from container-level settings, where memory is a hard limit and memoryReservation is a soft guarantee.

A multi-container task divides its envelope with container-level settings, and a hard memory limit on the sidecar is the mechanism that actually stops it from starving the application container — exceed the limit and the sidecar is killed rather than its neighbor. Enlarging the task envelope just feeds the runaway container. memoryReservation alone cannot cap consumption because it is only a soft guarantee. cpu shares are a processor-time control unrelated to memory pressure.

1. Keep the task-level memory as the total envelope for both containers.
2. Add a container-level memory hard limit to the sidecar sized just above its normal peak.
3. Optionally set memoryReservation on the application container as its scheduling guarantee.
4. Load-test and confirm the sidecar is capped while the application container stays healthy.

Exam tip: In a multi-container ECS task, divide the task envelope with container-level limits — a hard memory limit is what stops one container from starving another.

The build-once, promote-everywhere principle: verify one artifact in dev and staging, then promote that same artifact to production, with per-environment values injected via environment variables, Parameter Store, or AWS AppConfig.

Rebuilding per environment means production runs a build that never went through staging — different dependency resolution, different bytes — so passing staging tests proves nothing about production. Building once and promoting the identical artifact removes that gap entirely. Testing in production is detection, not prevention. Synchronized rebuilds are still separate builds. Baking configuration into the artifact institutionalizes the per-environment rebuild that caused the problem.

1. Build the artifact once in CI and publish it to the artifact store (S3 for zips, ECR for images).
2. Deploy that stored artifact to dev, then staging, referencing it by key, tag, or digest.
3. Inject per-environment values at deploy time via parameters, environment variables, or Parameter Store paths.
4. Promote the identical artifact to production once staging verification passes.

Exam tip: Build one artifact and promote it unchanged — rebuilding per environment ships untested bytes to production.

Configuration lives outside the artifact: SSM Parameter Store organizes per-environment values in hierarchical paths (for example /myapp/dev/ versus /myapp/prod/) and encrypts sensitive values as SecureString parameters via AWS KMS.

Hierarchical parameters give each environment its own value set, SecureString satisfies the encryption requirement for the API key, and reading at startup means one artifact serves every environment. Hardcoding per environment reintroduces per-environment builds. Committing .env files or plaintext template values puts a secret into Git, which is exactly where secrets must never live.

1. Create parameters under per-environment prefixes such as /myapp/dev/db-endpoint and /myapp/prod/db-endpoint.
2. Store the API key as a SecureString parameter encrypted with AWS KMS.
3. Grant the application's execution role permission to read its environment's parameter path.
4. Have the application read the parameters at startup (or on a refresh interval), keyed by an environment name it receives at deploy time.

Exam tip: Per-environment values belong in Parameter Store hierarchies — with SecureString for secrets — never in the package or the repository.

ThrottlingException and its DynamoDB-specific cousin ProvisionedThroughputExceededException mean the caller is exceeding allowed throughput. They are transient and retryable, and AWS SDKs apply exponential backoff with jitter automatically.

Because the SDK already handles the immediate retry correctly, the developer's job is the durable fix: raise provisioned throughput, switch the table to on-demand, or redesign a hot partition key. Option b confuses throttling with authorization, option c confuses it with a failed condition check (a deterministic error), and option d — tight retries without delay — pours more load onto an already-throttled resource.

1. Recognize the exception name as a capacity signal, not a defect or permission issue.
2. Confirm the SDK's default retry behavior is intact rather than adding custom retry loops.
3. Check table metrics for throttled requests and identify whether one hot partition key is responsible.
4. Apply the durable fix: more provisioned capacity, on-demand mode, or a higher-cardinality key design.

Exam tip: Throttling errors are retryable and the SDK already backs off — your job is the capacity or key-design fix.

ConditionalCheckFailedException is DynamoDB reporting that a write's condition expression evaluated to false. It is not an outage and not a transient error — it is the developer's own guard doing its job, commonly during optimistic locking.

With optimistic locking, the exception means a concurrent writer won the race and the item's version moved on. The correct response lives in application logic: re-read, reconcile against current state, and reapply only if still valid. Blind retries (b) fail identically because the condition is deterministic; capacity changes (c) are irrelevant because the service evaluated the write and rejected it by design; and permissions (d) would surface as AccessDenied, not a condition failure.

1. Catch ConditionalCheckFailedException specifically rather than treating it as a generic failure.
2. Re-read the item to obtain its current version and attributes.
3. Reconcile: decide whether the intended change still makes sense against the new state.
4. If it does, reapply the update with the fresh expected version; if not, surface the conflict.

Exam tip: A failed condition check is a business signal, not an error to retry — re-read, reconcile, then decide.

AccessDenied and AccessDeniedException mean some policy in the authorization chain — the caller's identity policy, a resource policy, a KMS key policy, or a permissions boundary — refuses the action. They are never capacity or performance problems.

The failure being identical on every attempt is the tell for a deterministic authorization denial: the fix is in policy, and the error message itself names the principal and denied action to guide the search. Retries (a) address transient faults only, resource tuning (c) is orthogonal to authorization, and tracing (d) answers a "where" question that is already answered.

1. Read the full error message to identify the denied action and the principal.
2. Check the execution role's identity policy for the required S3 permissions on the right resource ARN.
3. Check the bucket policy — and the KMS key policy if the bucket uses SSE-KMS — for explicit or implicit denies.
4. Fix the responsible policy and re-invoke to confirm.

Exam tip: AccessDenied is a policy problem: fix IAM or the resource policy — retrying a denied call changes nothing.

CloudWatch embedded metric format (EMF) is a JSON log convention: a log line's _aws metadata block declares the namespace, dimensions, and metric fields, and CloudWatch extracts real metrics from the log stream asynchronously.

EMF satisfies both constraints by design — publication rides the existing logging path, so there is no synchronous call to add latency and no PutMetricData quota in play, and the per-provider dimension is just a field in the JSON. Option a violates both constraints directly. Option c produces data that is not a CloudWatch metric at all. Option d relies on state that ephemeral execution environments cannot reliably hold and still funnels through the synchronous API.

1. Structure a log line with an _aws block declaring the namespace, a PaymentProvider dimension, and the failure-count metric field.
2. Print that line to standard output from the function — on Lambda that is all publication takes.
3. Verify the metric appears in CloudWatch and graph or alarm on it per dimension value.
4. Use Logs Insights on the same events when a metric spike needs the underlying request context.

Exam tip: "Custom metrics without latency or throttling" is the trigger phrase for embedded metric format.