DVA-C02 Cheatsheet — High-Yield Patterns, Defaults, Decision Tables & Snippets

Keep this page open while drilling questions. Prioritize defaults, failure modes, and the “least-privilege + event-driven” mental model.

Quick facts (DVA-C02)

How DVA-C02 questions work (fast strategy)

• Treat most integrations as at-least-once delivery → design idempotency and safe retries.
• If the question says least operational overhead, prefer managed services and native integrations.
• If you see AccessDenied, separate concerns: identity policy vs resource policy vs KMS key policy.
• Read the last sentence first to capture the constraint (cost, performance, availability, security, operational effort).

1) Request + event flow (mental model)

    flowchart LR
	  C[Client] -->|HTTPS| APIGW[API Gateway]
	  APIGW -->|IAM/Cognito/Lambda authorizer| L[Lambda]
	  L --> DDB[(DynamoDB)]
	  L --> S3[(S3)]
	  L --> EB[EventBridge]
	  EB --> SQS[(SQS)]
	  SQS --> L2[Lambda worker]
	  L2 --> CW[(CloudWatch Logs/Metrics)]
	  L2 --> XR[(X-Ray Traces)]

High-yield takeaway: professional “developer” answers usually combine authn/authz, decoupling, and observability (logs/metrics/traces).

2) Lambda — invocation types, retries, and concurrency

Invocation types (memorize the retry model)

Defaults that matter (common “gotchas”)

• Idempotency: retries and duplicates happen (SQS, async Lambda, EventBridge). Make handlers safe to run multiple times.
• Timeout alignment: downstream timeouts must be lower than upstream timeouts (API Gateway → Lambda → DB).
• Memory != only memory: in Lambda, more memory also means more CPU → often faster and cheaper overall.
• VPC networking: Lambda in a VPC can’t reach the public internet without a NAT; for AWS services, prefer VPC endpoints over NAT.
• Reserved concurrency: cap blast radius (protect downstream services and cost).
• Provisioned concurrency: reduce cold starts for latency-sensitive endpoints.

Partial batch failure (SQS and streams)

Without partial batch response, one failure can cause the whole batch to be retried. Prefer partial batch response when supported.

Lambda batch response format (concept)

1{
2  "batchItemFailures": [
3    { "itemIdentifier": "message-or-record-id" }
4  ]
5}

Idempotency pattern (practical)

Common approach: store a request key (for example, requestId) in DynamoDB with TTL.

11) Put idempotency key with condition attribute_not_exists(PK)
22) If conditional check fails -> return cached result / treat as already processed
33) Process work -> write result

3) API Gateway — picks, auth, throttling

REST API vs HTTP API vs WebSocket API

Auth options (very common on DVA)

API keys: not “security” by themselves; they’re primarily for usage plans and throttling/quota.

Throttling “chain”

If you see throttling, check the whole chain:

1. API Gateway throttles (per-stage, per-route, usage plan)
2. Lambda concurrency throttles
3. Downstream throttles (DynamoDB RCUs/WCUs, SNS/SQS, etc.)

IAM policy: allow invoking one API route (copy-ready)

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Effect": "Allow",
 6      "Action": "execute-api:Invoke",
 7      "Resource": "arn:aws:execute-api:REGION:ACCOUNT:apiId/stage/GET/items"
 8    }
 9  ]
10}

4) DynamoDB — keys, indexes, streams, throttling

The “wins questions” checklist

• Prefer Query over Scan (Scan is a frequent distractor).
• Design keys to avoid hot partitions (high-cardinality partition keys help).
• Use conditional writes for correctness (idempotency, optimistic locking).
• Treat throttling as normal: implement exponential backoff + jitter.

Access pattern chooser (fast table)

Indexes: GSI vs LSI (high-yield differences)

Rule: if you need a new access pattern later, it’s usually a GSI.

Conditional write (concept)

1PutItem with ConditionExpression: attribute_not_exists(PK)

This shows up in questions about idempotency and race prevention.

Streams (common trigger)

Use DynamoDB Streams when you need to react to table changes:

• Trigger Lambda on item inserts/updates/deletes
• Build event-driven projections or caches

Gotcha: stream processing is ordered per shard; failures can block progress until handled (configure retries/handling).

5) S3 + CloudFront — presigned URLs, encryption, edge caching

Storage picker (CLF-level simple, DVA-level useful)

Presigned URLs (classic DVA pattern)

Best for direct-to-S3 upload/download without proxying files through your app.

    sequenceDiagram
	  participant C as Client
	  participant API as API (Lambda)
	  participant S3 as S3
	  C->>API: Request upload URL
	  API-->>C: Pre-signed URL
	  C->>S3: PUT object (direct)

CLI example:

1aws s3 presign s3://my-bucket/path/file.bin --expires-in 3600

S3 encryption choices (high-yield)

Common “AccessDenied” cause: KMS key policy doesn’t allow the caller/service to use the key.

CloudFront basics (what you need for DVA)

• Use CloudFront when you need caching, global performance, and TLS at the edge.
• If you need private S3 content, use Origin Access Control (OAC) (or older OAI patterns) instead of a public bucket.
• Invalidation fixes stale content, but design caching headers/TTLs first.

6) Eventing & orchestration — SQS, SNS, EventBridge, Kinesis, Step Functions

Which one should you pick?

SNS → SQS fanout (high-yield pattern)

    flowchart LR
	  Pub[Publisher] --> T[SNS Topic]
	  T --> Q1[SQS Queue A]
	  T --> Q2[SQS Queue B]
	  Q1 --> L1[Lambda Worker A]
	  Q2 --> L2[Lambda Worker B]
	  Q1 --> DLQ1[DLQ]
	  Q2 --> DLQ2[DLQ]

Why it wins: SNS handles fanout; SQS gives durability and independent retry per consumer.

SQS: the defaults and gotchas you actually get tested on

• Visibility timeout must exceed max processing time (or extend it).
• DLQ catches poison messages (after max receives).
• Long polling reduces empty receives and cost.
• FIFO vs Standard matters for ordering and duplicates.

SNS: what shows up on DVA

• Use filter policies (message attributes) to route messages to specific subscribers.
• SNS is great for “notify many”; pair with SQS when you need durable consumption and retries.

EventBridge: what it’s for

• Event bus + rules: route events based on patterns.
• Useful when you want a consistent event model across AWS services and SaaS integrations.
• Supports DLQ/retry configurations for targets (conceptually: “reliable delivery”).

Kinesis: when it’s the best answer

Pick Kinesis when you need:

• High-throughput streaming ingest
• Ordered processing within shards
• Multiple consumers reading the same stream

If you just need a durable buffer for background jobs, SQS is often simpler.

Step Functions (workflow)

Retry + Catch snippet (Amazon States Language)

 1{
 2  "StartAt": "Work",
 3  "States": {
 4    "Work": {
 5      "Type": "Task",
 6      "Resource": "arn:aws:states:::lambda:invoke",
 7      "Retry": [
 8        {
 9          "ErrorEquals": ["States.ALL"],
10          "IntervalSeconds": 2,
11          "MaxAttempts": 3,
12          "BackoffRate": 2.0
13        }
14      ],
15      "Catch": [
16        {
17          "ErrorEquals": ["States.ALL"],
18          "Next": "Failed"
19        }
20      ],
21      "End": true
22    },
23    "Failed": { "Type": "Fail" }
24  }
25}

7) Security “best answers” — IAM, Cognito, KMS, secrets

IAM evaluation (always true)

• Default deny.
• Explicit deny overrides any allow.
• Permissions can come from identity policies + resource policies; KMS also depends on key policy.

Prefer roles + temporary credentials (STS)

• Apps on AWS should use roles (Lambda execution role, EC2 instance profile, task role).
• Avoid long-lived access keys in code.

Cross-account AssumeRole (trust policy example)

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Effect": "Allow",
 6      "Principal": { "AWS": "arn:aws:iam::111122223333:role/CallerRole" },
 7      "Action": "sts:AssumeRole"
 8    }
 9  ]
10}

Cognito: User Pool vs Identity Pool

Common pattern: API Gateway uses a Cognito User Pool authorizer to validate JWTs.

Secrets Manager vs Parameter Store

Exam cue: if you see “automatic rotation,” choose Secrets Manager.

IAM policy: allow only one DynamoDB table (copy-ready)

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Effect": "Allow",
 6      "Action": [
 7        "dynamodb:GetItem",
 8        "dynamodb:PutItem",
 9        "dynamodb:Query",
10        "dynamodb:UpdateItem"
11      ],
12      "Resource": "arn:aws:dynamodb:REGION:ACCOUNT:table/MyTable"
13    }
14  ]
15}

8) Deployment & IaC — SAM/CloudFormation/CDK + Code* + safe rollouts

CI/CD mental model (what’s happening)

    flowchart LR
	  Repo[Source Repo] --> Pipe[CodePipeline]
	  Pipe --> Build[CodeBuild]
	  Build --> Artifacts[(S3 Artifacts)]
	  Artifacts --> Deploy[CloudFormation/SAM/CodeDeploy]
	  Deploy --> Alias[Lambda Alias/Version]

Lambda safe deployments (versions + aliases)

High-yield terms:

• Version: immutable snapshot of code/config.
• Alias: pointer to a version (used for traffic shifting).
• CodeDeploy for Lambda: canary/linear/all-at-once traffic shifting with automated rollback on alarms.

SAM snippet (Lambda + API + deployment preference)

 1Resources:
 2  Api:
 3    Type: AWS::Serverless::Api
 4  Fn:
 5    Type: AWS::Serverless::Function
 6    Properties:
 7      Handler: app.handler
 8      Runtime: nodejs20.x
 9      AutoPublishAlias: live
10      DeploymentPreference:
11        Type: Canary10Percent5Minutes
12      Events:
13        Get:
14          Type: Api
15          Properties:
16            RestApiId: !Ref Api
17            Path: /items
18            Method: get

Exam cue: if you see “minimize risk” and “automatic rollback,” think CodeDeploy traffic shifting + alarms.

CloudFormation troubleshooting (fast)

• If a stack fails, read stack events from the failure upwards.
• “Roll back” problems often come from missing IAM permissions, missing dependencies, or invalid parameters.

9) Troubleshooting & optimization — CloudWatch, X-Ray, CloudTrail

Observability “stack” (DVA level)

• CloudWatch Logs: what happened (application logs)
• CloudWatch Metrics/Alarms: how often/how bad (rates, latency, errors)
• X-Ray: where time is spent (service map, traces)
• CloudTrail: who did what (API audit trail)

Fast eliminations table

CloudWatch Logs Insights (copy-ready)

1fields @timestamp, @message
2| filter @message like /ERROR|Exception|Task timed out/
3| sort @timestamp desc
4| limit 50

Retry strategy (what “best answer” looks like)

• Use exponential backoff + jitter for throttling and transient errors.
• Make retries safe via idempotency keys (especially for payments/orders).

Pseudo:

1sleep(random(0, base * 2^attempt)); retry

Performance quick wins (common themes)

• Reduce Lambda cold starts with provisioned concurrency and smaller init work.
• Use Query + proper keys/indexes in DynamoDB; add a GSI for new access patterns.
• Use caching when appropriate (CloudFront, ElastiCache, DynamoDB DAX) to reduce hot reads.
• Keep synchronous APIs fast; push heavy work to async (SQS/EventBridge + worker).

Next: drill by objective

• Follow the Syllabus domain-by-domain.
• Launch drills in Practice and keep this cheatsheet open as reinforcement.