Free DVA-C03 practice questions

A queue between two components removes the requirement that both are available and fast at the same moment.

The requirement is that the producer keeps working when the consumer is slow or down, and that work can happen later. That is the definition of temporal decoupling, which an SQS queue provides: the web tier enqueues and returns, and the fulfillment service consumes when it can. A load balancer, API Gateway and longer timeouts all keep a synchronous dependency in place.

1. Identify the coupling: the web tier waits for fulfillment on every request.
2. Note that a delay of minutes is acceptable, so the work can be asynchronous.
3. Choose the component that stores work durably between producer and consumer: an SQS queue.
4. Reject options that only scale or front the synchronous call.

Exam tip: If the caller does not need the result now, put a queue between it and the slow dependency.

A Cognito user pool is a user directory that authenticates users; a Cognito identity pool exchanges an identity token for temporary AWS credentials.

The app needs two things: a place for users to sign up and sign in, and AWS credentials to call S3 without a backend. The user pool provides the first and returns JWTs. AWS services such as S3 only accept SigV4-signed requests, so the identity pool exchanges the user pool token for short-lived credentials from its authenticated role. Sending a JWT straight to S3 fails, and per-user IAM access keys break the no-long-term-credentials requirement.

1. Split the need into authentication (who is the user) and authorization to call AWS APIs.
2. Use a user pool for sign-up and sign-in.
3. Use an identity pool to turn the user pool token into temporary AWS credentials.
4. Reject options that send JWTs to AWS service APIs or embed access keys.

Exam tip: User pool = who you are (JWTs); identity pool = temporary AWS credentials.

Docker clients authenticate to an ECR registry with a short-lived authorization token, not with IAM credentials directly.

The Docker CLI cannot sign requests with AWS credentials, so ECR issues an authorization token through GetAuthorizationToken. The usual command is aws ecr get-login-password piped to docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com, run in the pre_build phase. The token lasts 12 hours. Privileged mode is about running Docker at all, and IAM API calls do not populate Docker's credential store.

1. Read the error: "no basic auth credentials" means Docker has no login for the registry.
2. Note the build succeeded, so the Docker daemon and privileged mode are fine.
3. Recall that ECR issues a Docker password through get-login-password.
4. Log Docker in to the registry URI before the push step.

Exam tip: Docker talks to ECR only after docker login with the token from aws ecr get-login-password.

Lambda logs show which limit an invocation hit, and the fix should match that limit.

'Task timed out after 3.00 seconds' means the invocation reached the function's configured timeout. The dependency can take up to 8 seconds, so the timeout must be longer than that. Memory is not the problem, because Max Memory Used is low and the time is spent waiting on I/O. Concurrency and retries change how many invocations run or how often they run, but every one of them would still stop at 3 seconds.

1. Read the error line: it names the timeout and its value.
2. Compare the timeout with the dependency's worst-case latency.
3. Check REPORT Max Memory Used to rule out memory pressure.
4. Raise the timeout (and consider a client-side timeout on the API call).

Exam tip: 'Task timed out after N seconds' points at the function timeout, not memory or concurrency.

SNS-to-SQS fan-out decouples one producer from many independent consumers.

Two separate problems are stated: the producer must not know its consumers (so it can grow without code changes), and each consumer must be isolated and able to work at its own pace. SNS solves the first by delivering one published message to every subscriber. An SQS queue per subscriber solves the second by buffering each consumer's copy. A single shared queue is the tempting near-twin, but competing consumers split messages between them instead of each receiving all of them.

1. Separate the two requirements: unknown future consumers, and independent processing.
2. Publish/subscribe (SNS) removes the producer's knowledge of consumers.
3. A queue per consumer gives each one a durable buffer and isolates failures.
4. Remember that consumers sharing one queue compete for messages.

Exam tip: One copy to every consumer is SNS fan-out; a queue per consumer lets each one fail and recover alone.