Free DVA-C02 practice questions

Choosing between orchestration and choreography for multi-step workflows: a central coordinator (AWS Step Functions) versus services reacting to events.

The scenario lists the classic orchestration cues: a defined sequence, visibility into where each order is, per-step error handling, and compensation on failure. Step Functions holds the workflow state centrally and provides built-in retries, catch handling, and compensation paths, which is exactly what the requirements describe. SNS choreography maximizes service independence but deliberately has no central controller, so end-to-end visibility and coordinated compensation would have to be built by hand. SQS chaining buffers each hop but still leaves no owner of the overall state. Direct synchronous invocation is the tightly coupled anti-pattern — the caller shares fate with every downstream service and must implement all coordination logic itself.

1. Identify that the process is a multi-step business workflow with a fixed sequence.
2. Spot the orchestration cues: visibility into progress, per-step retries, and compensation on failure.
3. Recall that on AWS, orchestration means Step Functions, which holds workflow state centrally.
4. Eliminate choreography (SNS) and queue chaining because neither owns end-to-end state, and synchronous chaining because it tightly couples the services.

Exam tip: When a scenario needs visibility, per-step error handling, or compensation across a multi-step process, choose orchestration with Step Functions; choreography is for independent services reacting to events.

Cognito identity pools authorize access to AWS services by exchanging an identity token for temporary AWS credentials from STS — and they are the only Cognito feature that supports unauthenticated (guest) identities.

Two phrases decide this: "temporary AWS credentials" and "anonymous guests" both point exclusively at an identity pool. Signed-in users' tokens and guest identities are each mapped to an IAM role, and the app receives short-lived credentials to call S3 directly. The user pool options fail because user pools authenticate people and issue JWTs — they never vend AWS credentials and cannot represent guests; groups and OAuth scopes only shape authorization for users who have signed in.

1. Spot the requirement for temporary AWS credentials — that is the identity pool's job.
2. Spot the guest requirement — only identity pools support unauthenticated identities.
3. Map authenticated and unauthenticated identities to separate IAM roles with least-privilege S3 permissions.
4. Have the app obtain credentials from the identity pool and upload to S3 directly.

Exam tip: "Access AWS services" or "guest access" in a Cognito scenario means an identity pool — user pools cannot vend AWS credentials.

Each AWS compute target defines its own artifact format, and Lambda offers two: a .zip archive (50 MB zipped for direct upload, 250 MB unzipped including layers) or a container image in Amazon ECR of up to 10 GB.

At 45 MB zipped and 180 MB unzipped, the package is within both zip limits, and the zip format is the simplest option that keeps the function on AWS managed runtimes. A container image is only worth its extra tooling when the package exceeds 250 MB unzipped, needs OS-level packages, or requires a custom runtime. An Elastic Beanstalk source bundle targets a different service entirely, and a layer cannot replace the function's own deployment package.

1. Measure the built package size: 45 MB zipped, 180 MB unzipped.
2. Compare against the Lambda zip limits: 50 MB zipped for direct upload, 250 MB unzipped including all layers.
3. Confirm the function uses an AWS managed runtime with no OS-level package requirements.
4. Choose the .zip deployment package as the simplest artifact that satisfies all constraints.

Exam tip: Use a Lambda zip package when code plus dependencies fit within 50 MB zipped / 250 MB unzipped; reach for a container image only when you exceed those limits or need a custom runtime.

The three observability signals each answer a different diagnostic question: metrics answer "is something wrong?", logs answer "why is it wrong?", and traces answer "where is it wrong?". An incident triage moves through them in that order.

The metric alarm has already answered the "is something wrong and when" question, so the next step is to query the logs for the same time window to learn what the code actually reported. More metrics only restate that a problem exists, sampling rules are configuration rather than evidence, and CloudTrail records account-level API activity, not application request failures.

1. Note the exact window in which the alarm's metric breached its threshold.
2. Open the backend's log group in CloudWatch Logs Insights scoped to that window.
3. Filter for error-level events and read the messages and stack traces behind the failures.
4. If the failure spans services, pivot to a trace to see which hop is responsible.

Exam tip: Metrics say something is wrong, logs say why, traces say where — triage in that order.

Choreography in event-driven architecture: producers emit events describing what happened, and consumers subscribe and react without the producer knowing about them.

The deciding requirement is that consumers can be added without touching the producer. Publishing profile-updated events to an EventBridge bus achieves exactly that: each consuming team attaches its own rule and target, and the producer's code never changes. Step Functions is the opposite trade-off — orchestration gives central visibility but means the coordinator must be updated for every new consumer. Direct REST calls hard-code every consumer into the producer, and a shared polled database couples all services to one schema while adding latency. When services should evolve independently and merely react to facts, choreography over an event bus is the answer.

1. Note the constraint: new consumers must be added with zero producer changes.
2. Recognize this as the defining property of choreography — producers emit events without knowing the consumers.
3. Map choreography onto AWS: publish to an EventBridge event bus (or SNS) and let consumers subscribe with rules.
4. Eliminate orchestration and direct calls, both of which require updating existing code for each new consumer.

Exam tip: If consumers must be added or removed without changing the producer, publish events to a bus (choreography); a central coordinator would need editing for every new consumer.