DVA-C02 cheat sheet
104 key facts across 4 exam domains, distilled from the full DVA-C02 revision notes — with the exam pattern behind each topic. Skim it the week of your exam.
Updated
Development with AWS Services
32% of the examApplication Development Patterns on AWS: Architecture, APIs and Messaging
- Loose coupling with asynchronous messaging is the exam's default answer for resilience, burst absorption, and independent scaling
- Choreography = services reacting to events via EventBridge or SNS; orchestration = Step Functions centrally coordinating a visible workflow
- Fanout = one event to many consumers: SNS topic to multiple SQS queues, or an EventBridge rule with multiple targets
- Retry only transient errors, always with exponential backoff plus jitter — and make consumers idempotent, because at-least-once delivery guarantees duplicates
- SQS is a pull queue for one consuming app; SNS pushes to many subscribers; EventBridge routes on event content across AWS, custom, and SaaS sources
- Only API Gateway REST APIs give you mapping templates, request validators, and status-code overrides — HTTP APIs are cheaper but proxy-only
- Kinesis orders records per shard by partition key and lets multiple consumers replay data — unlike SQS, reading does not delete
- Guard third-party calls with timeouts, backoff retries, and a circuit breaker that fails fast while the dependency is down
How the exam tests this
Expect scenario questions that describe a fragile or overloaded architecture and ask for the fix: a downstream outage losing orders points to SQS decoupling, one event needing multiple independent consumers points to SNS or EventBridge fanout, and a multi-step workflow needing per-step error handling points to Step Functions orchestration. Watch for trigger words — decouple, buffer, spiky traffic, fanout, at-least-once, duplicate processing, content-based routing — each maps to a specific service or pattern. API Gateway questions hinge on knowing that mapping templates, request validation, and status-code overrides are REST API features, and resilience questions reward backoff with jitter, idempotent consumers, dead-letter queues, and circuit breakers over naive immediate retries.
AWS Lambda for Developers: Configuration, Events, Concurrency and Tuning
- CPU scales with memory — memory is the primary performance dial, with roughly one vCPU at 1,769 MB
- Maximum timeout is 900 seconds (15 minutes); longer workloads need Step Functions or different compute, not a bigger timeout
- Asynchronous invocations are retried twice (three attempts total); synchronous invocations are never retried by Lambda — the caller must retry
- Prefer an onFailure Destination over a DLQ for async errors: it carries the error and response context, and supports SQS, SNS, EventBridge, or Lambda targets
- For SQS event sources, set the queue's visibility timeout to at least six times the function timeout and enable ReportBatchItemFailures so only failed records retry
- Reserved concurrency guarantees and caps capacity for free; provisioned concurrency pre-warms environments for a price — reserved is how much, provisioned is how fast
- A VPC-attached function loses internet access without a NAT gateway; use VPC endpoints for AWS services and RDS Proxy when Lambda exhausts database connections
- Initialize SDK clients and connections outside the handler — warm environments reuse them, and it is the cheapest cold-start optimization available
How the exam tests this
The exam probes Lambda through precise behavioral questions: which invocation types retry (async twice, sync never, poll-based per the source), what a VPC-attached function can and cannot reach, and which concurrency control fixes a given symptom — reserved for protecting a downstream database or capping scale, provisioned for cold-start latency. Scenario stems about duplicate processing, a blocked shard, or messages reappearing mid-processing point at partial batch responses, bisect-on-error, and the visibility-timeout rule. Watch for trigger words like cold start, connection exhaustion, throttling, in order, and near real time — each maps to a specific feature, and distractors typically apply the right fix to the wrong invocation model.
DynamoDB and AWS Data Stores for Developers (DVA-C02)
- Choose a high-cardinality partition key — a low-cardinality key creates hot partitions that no capacity setting can fix.
- LSI: same partition key, alternate sort key, table-creation only, supports strongly consistent reads. GSI: any keys, created anytime, eventually consistent only.
- Query reads only matching items; Scan reads the whole table and consumes capacity for every item scanned — filter expressions never reduce cost.
- Strongly consistent reads work on tables and LSIs, cost twice the RCUs, and are never available on a GSI.
- DynamoDB items max out at 400 KB — store large payloads in S3 and keep a pointer in the item.
- Lazy loading caches only what is read but risks staleness; write-through stays fresh but doubles write work — combine them with TTLs.
- DAX is the answer for microsecond DynamoDB reads with no cache logic; ElastiCache is the general-purpose cache for everything else.
- Match store to access pattern: S3 for objects, EBS for block, EFS for shared files, OpenSearch Service for full-text search and log analytics, MemoryDB for durable in-memory data.
How the exam tests this
Task 1.3 questions are scenario-driven: a table that throttles under load (hot partition — answer with a high-cardinality key or write sharding), a lookup that must use the least read capacity (Query against a GSI, never Scan with a filter), or a read that must always return the latest write (strongly consistent — which rules out a GSI). Watch the trigger words: microsecond latency with DynamoDB means DAX; full-text search or log analytics means OpenSearch Service; joins or complex queries mean RDS or Aurora; unpredictable traffic means on-demand capacity. Expect at least one question on GSI versus LSI constraints and one on caching trade-offs, where lazy loading risks stale reads and write-through pays a penalty on every write.
Security
26% of the examAuthentication and Authorization on AWS: Cognito, IAM, and STS
- User pool = authentication (who are you, JWTs); identity pool = authorization to AWS (temporary credentials).
- Only identity pools support unauthenticated guest access to AWS services.
- ID token = identity claims, access token = authorize API calls, refresh token = renew both — and it never goes to your API.
- IAM roles with temporary STS credentials always beat long-term access keys embedded anywhere.
- AssumeRole needs two allows: the role's trust policy names the caller, and the caller can sts:AssumeRole.
- Explicit deny beats every allow; anything not explicitly allowed is implicitly denied.
- Cognito authorizer = user pool JWTs with no code; Lambda authorizer = custom logic (cached); IAM auth = SigV4 for AWS callers.
- API keys and usage plans meter clients — they are never an authentication mechanism.
How the exam tests this
Expect scenario questions that hinge on one phrase: "authenticate users" or "user directory" points to a user pool; "access AWS services", "temporary credentials", or "guest users" points to an identity pool; "existing corporate SAML IdP" means federation, never new accounts. Any option that embeds long-term access keys in code, configuration, or an AMI is wrong — the answer is an IAM role with temporary STS credentials. For API protection, match the mechanism to the caller: Cognito authorizer for user pool JWTs, Lambda authorizer for custom schemes, IAM with SigV4 for AWS-native callers. Policy questions almost always resolve with "explicit deny wins" and the cross-account both-sides-must-allow rule.
AWS KMS and Encryption for Developers: Keys, Envelopes, and Certificates
- KMS Encrypt takes at most 4 KB of plaintext — anything larger means envelope encryption with GenerateDataKey.
- Envelope encryption: GenerateDataKey → encrypt locally → store the encrypted data key with the data → Decrypt to unwrap.
- SSE-KMS is the answer when a scenario demands an audit trail of key usage or control over who can decrypt.
- SSE-C: you supply the key on every request and S3 never stores it; client-side: AWS never sees plaintext at all.
- Cross-account KMS needs both sides: the key policy must allow the external account, and its IAM policies must allow the key's ARN.
- Automatic rotation is yearly — opt-in for customer managed symmetric keys, always-on for AWS managed keys; imported material never auto-rotates.
- Old ciphertext still decrypts after rotation — KMS retains every version of the backing key material.
- ACM public certs are free and auto-renew with DNS validation; internal TLS and mTLS certificates come from AWS Private CA.
How the exam tests this
Encryption questions are pattern-matching: "encrypt a large file with KMS" → GenerateDataKey and envelope encryption, never a bare Encrypt call; "audit every use of the key" or "control exactly who can decrypt" → SSE-KMS with a customer managed key; "another account gets access denied when decrypting" → fix the key policy and the caller's IAM policy; "certificates for internal services or mTLS" → AWS Private CA; "enforce encryption in transit to S3" → a bucket policy denying on aws:SecureTransport. Expect at least one rotation edge case — imported key material and asymmetric keys never rotate automatically, while AWS managed keys always do.
Managing Sensitive Data: Secrets Manager vs Parameter Store
- "Automatic rotation" or rotating database credentials means Secrets Manager; "free" or "no additional cost" configuration means Parameter Store standard tier.
- Parameter Store SecureString values are encrypted with KMS but never rotate themselves; retrieving one requires GetParameter with WithDecryption set to true.
- Cross-account secret access is a Secrets Manager resource-based policy — Parameter Store sharing is limited to advanced-tier parameters via AWS RAM.
- Never hardcode credentials in code, repos, AMIs, or container images — attach an IAM role and let the SDK credential provider chain supply temporary credentials.
- Lambda environment variables are KMS-encrypted at rest by default, but anyone who can read the function configuration sees the values — store a secret's name there, not the secret.
- Fetch secrets during initialization, cache them in the execution environment with a TTL, and refetch on authentication failure to survive rotation; the Parameters and Secrets Lambda Extension provides this caching prebuilt.
- Mask or redact PII before it is logged; CloudWatch Logs data protection policies mask detected PII in log groups as a backstop.
- Pool-model tenant isolation in DynamoDB = tenant ID as the leading partition key plus an IAM dynamodb:LeadingKeys condition on per-tenant scoped temporary credentials.
How the exam tests this
Expect scenario questions that hinge on a trigger phrase: "automatic rotation" or rotating RDS credentials points to Secrets Manager, while "no additional cost" or simple encrypted configuration points to a Parameter Store SecureString. "Hardcoded credentials" in code, an AMI, or a container image is always answered with an IAM role plus a secrets service — never with encrypting the file or moving the key to another variable. Lambda questions probe whether you know environment variables are KMS-encrypted at rest yet readable by anyone who can view the configuration, and that fetch-and-cache with GetSecretValue or GetParameter with WithDecryption is the retrieval pattern. The v2.1 additions appear as "tenant isolation" scenarios expecting the dynamodb:LeadingKeys leading-key condition with tenant-scoped temporary credentials, and masking questions distinguishing masking, tokenization, and encryption.
Deployment
24% of the examPreparing Application Artifacts for AWS Deployment
- Lambda zip packages: 50 MB zipped for direct upload, 250 MB unzipped including layers; Lambda container images go up to 10 GB via ECR.
- Match artifact to target: zip or container image for Lambda, ECR images for ECS/EKS, and a root-level zip source bundle for Elastic Beanstalk.
- Lambda layers share dependencies across functions (up to 5 per function) but still count toward the 250 MB unzipped limit — they are not a size workaround.
- Lambda has one sizing knob: CPU scales with memory (about 1 vCPU at 1,769 MB); ECS separates task-level envelopes from container-level limits.
- Build one artifact and promote it unchanged; inject per-environment values via environment variables, Parameter Store, or AWS AppConfig — never rebuild per environment.
- AppConfig deploys configuration like code: validators (JSON Schema or Lambda) check it, deployment strategies roll it out gradually, and alarms trigger rollback.
- Source, IaC templates, and lock files live in Git; built artifacts live in S3/ECR, package dependencies in CodeArtifact; secrets live in none of these.
- Enable ECR tag immutability (or pin digests) so a deployed tag can never silently point at different code.
How the exam tests this
Expect scenario questions that hand you a compute target and ask what to ship: a dependency "larger than the Lambda package limit" (container image), "shared libraries across many functions" (a layer), or a Beanstalk bundle that fails because files are nested in a folder. Configuration questions hinge on trigger phrases — "without redeploying the application", "feature flags", "validate before rollout", "gradually release a configuration change" all point to AWS AppConfig, while "encrypted parameter" points to Parameter Store SecureStrings. Sizing questions test the Lambda memory-CPU coupling: a CPU-bound function is fixed by raising memory. Distractors often propose rebuilding the artifact per environment or deploying the latest image tag — both are wrong.
Testing Applications in AWS Development Environments
- sam local invoke runs one function in Docker; sam local start-api emulates API Gateway for HTTP calls; sam local start-lambda exposes the Lambda invoke API to SDKs and test code.
- Unit tests mock AWS SDK calls for fast logic feedback; integration tests against real dev-stage resources catch what mocks cannot — IAM, configuration, and service behavior.
- API Gateway mock integrations return configured responses with no backend — use them to develop against an API whose real backend does not exist yet.
- One API Gateway API hosts multiple stages (dev/test/prod), each with its own invoke URL, settings, and stage variables — and changes are invisible until deployed to a stage.
- sam deploy to an existing stack is a CloudFormation update; preview it with a change set (--no-execute-changeset) to see adds, modifies, and replacements before they happen.
- sam sync --watch (SAM Accelerate) pushes code-only changes to a dev stack in seconds by bypassing CloudFormation — development environments only, never production.
- Validate an EventBridge rule with TestEventPattern before injecting events with put-events.
- Async outcomes cannot be asserted directly: stamp events with correlation IDs, then poll the target state (queue, table, logs) with a timeout instead of sleeping.
How the exam tests this
This task appears as tooling-selection and debugging scenarios. Expect to pick the right sam local command from a description — "invoke the function locally with a sample S3 event" (generate-event + invoke) versus "test the REST endpoints locally" (start-api) versus "let the test suite call functions through the SDK" (start-lambda). "Tests pass locally but the deployed function fails with AccessDenied" signals mocked unit tests needing real integration tests in a dev environment. Trigger phrases: "preview the changes before updating the stack" (change sets), "see code changes in the dev stack within seconds" (sam sync --watch), "verify the event pattern matches" (TestEventPattern), and "the API changes aren't visible" (not yet deployed to the stage). Event-driven questions reward correlation IDs and polling target state over sleeps or direct assertions.
Automate Deployment Testing: Test Events, Approved Versions, and IaC
- Lambda receives a service-specific JSON event — API Gateway wraps the whole HTTP request, while SQS and S3 deliver a Records array.
- sam local generate-event prints realistic sample payloads you can commit to the repo and replay in automated tests.
- Shareable test events are stored in the EventBridge schema registry so the whole team tests with identical payloads.
- A Lambda version is an immutable snapshot; an alias is a movable pointer — test against aliases, never $LATEST.
- Mutable image tags like latest can change underneath you; immutable tags or digests pin test environments to approved builds.
- SAM is a CloudFormation superset (via its Transform) and the CDK synthesizes to CloudFormation — one engine, one rollback model.
- A change set previews an update before execution; a failed update automatically rolls the stack back to its last working state.
- API Gateway changes go live only when you create a new deployment and attach it to a stage.
How the exam tests this
Expect scenario questions that name a service and ask for its environment lever: stages for API Gateway, aliases over versions for Lambda, branches for Amplify. "Preview changes before applying" points to CloudFormation change sets, "test against an approved version" points to Lambda aliases or immutable image tags, and an API change that "doesn't show up" means nobody created a new deployment to the stage. Also know that SAM's transform expands to plain CloudFormation and that a failed stack update rolls back automatically to the last working state.
AWS CI/CD Services: CodePipeline, CodeDeploy, and Deployment Strategies
- CodePipeline orchestrates; CodeBuild builds and tests; CodeDeploy deploys; CodeArtifact hosts packages.
- buildspec.yml drives CodeBuild (install, pre_build, build, post_build); appspec.yml drives CodeDeploy.
- Lambda and ECS appspec hooks are Lambda functions validating a traffic shift; ValidateService exists only for EC2/on-premises.
- "Different Lambda per stage" means API Gateway stage variables referencing a Lambda alias in the integration ARN.
- "Zero downtime" points to blue/green or immutable; "shift 10% of traffic" points to canary.
- Canary10Percent5Minutes shifts 10% of traffic to the new version, waits five minutes, then shifts the rest.
- Blue/green rollback is fastest because the old environment is still running — recovery is just shifting traffic back.
- CodeDeploy rolls back automatically when the deployment fails or an attached CloudWatch alarm fires.
How the exam tests this
Task 3.4 questions map stated requirements to strategies and services: "zero downtime" points to blue/green or immutable, "shift 10% of traffic and watch alarms" to a CodeDeploy canary configuration, "different Lambda function per stage" to stage variables referencing aliases, and "preview production changes before applying" to a change set plus a manual approval action. Expect appspec hook lists matched to the correct compute platform and buildspec-versus-appspec ownership questions. When rollback speed is the requirement, blue/green wins because traffic simply shifts back to the still-running old environment.
Troubleshooting and Optimization
18% of the examRoot Cause Analysis on AWS: Reading Logs, Metrics, and Error Codes
- Metrics say something is wrong, logs say why, traces say where — alarm, query, trace, in that order.
- A 502 from API Gateway with a healthy Lambda function almost always means a malformed proxy response: statusCode missing or body not a string.
- 504 means the integration exceeded API Gateway's 29-second default timeout; 429 means throttling or quota; 403 is auth or WAF, never throttling.
- ThrottlingException and ProvisionedThroughputExceededException call for exponential backoff with jitter — which AWS SDKs apply automatically.
- ConditionalCheckFailedException is a DynamoDB condition expression doing its job — handle it in application logic, don't blindly retry.
- Embedded metric format publishes custom metrics through log lines: asynchronous, no PutMetricData throttling, context preserved.
- For failed deployments read the service's own output: the first CloudFormation CREATE_FAILED event, the failed CodeBuild phase, the failed CodeDeploy lifecycle hook.
- When an event source stops invoking Lambda, check the event source mapping state and its permissions before the code.
How the exam tests this
Expect scenario questions that hand you a symptom and ask for the most likely cause or the fastest way to confirm it. Trigger words: "502 from API Gateway, Lambda shows no errors" → malformed proxy response; "504" → the 29-second integration timeout; "which service in the chain causes the latency" → the X-Ray service map; "custom metrics without throttling" → embedded metric format; "query logs for specific events" → CloudWatch Logs Insights. Exception names are causes in disguise — throttling means backoff plus a capacity fix, AccessDenied means a policy, and ConditionalCheckFailedException means your own condition expression fired.
Instrument Code for Observability: CloudWatch, X-Ray, and Alarms
- Logging records events, monitoring watches known thresholds, observability lets you diagnose problems you never predicted from telemetry you already emit.
- Never log secrets, tokens, or PII; log state transitions and identifiers at a level set by environment variable, and set log group retention explicitly.
- Structured JSON logs with a correlation ID propagated across every hop make one transaction queryable end to end in Logs Insights.
- Embedded metric format publishes metrics through log lines — asynchronous and immune to PutMetricData throttling; every unique dimension combination is a separate metric.
- X-Ray annotations are indexed and filterable (up to 50 per segment); metadata holds any JSON but can never appear in a filter expression.
- Default X-Ray sampling traces the first request each second plus 5% of the rest; Lambda active tracing runs the daemon for you.
- Metric thresholds alert via CloudWatch alarms to SNS, with composite alarms to cut noise; discrete events like deployment completions route via EventBridge rules.
- Readiness gates traffic and liveness gates restarts — and deep health checks on shared dependencies can cascade one blip into a fleet-wide outage.
How the exam tests this
The exam tests this task through definitions and trigger phrases as much as scenarios. "Filter traces by customer" or any searchable business attribute → annotations, never metadata; "custom metrics without throttling or added latency" → embedded metric format; "understand internal state from outputs" or "diagnose previously unknown issues" → observability, not monitoring; "notify on deployment completion" → an EventBridge rule, while a metric crossing a threshold means a CloudWatch alarm publishing to SNS. Health-check questions hinge on the liveness-versus-readiness distinction and on recognizing that deep checks against shared dependencies cascade failures across a fleet.
Optimize AWS Applications: Concurrency, Caching, and Right-Sizing
- Concurrency is requests in flight: for Lambda, concurrent executions ≈ request rate × average duration, so faster code needs less concurrency.
- Provisioned concurrency answers "consistently low latency"; reserved concurrency caps a function to protect downstream systems.
- More Lambda memory also buys more CPU — a memory sweep (AWS Lambda Power Tuning) often cuts cost because duration falls faster than the rate rises.
- Use RDS Proxy to pool and multiplex Lambda-to-RDS connections instead of letting every concurrent execution open its own.
- SNS filter policies and EventBridge event patterns deliver only relevant messages — never filter after delivery in consumer code.
- Long polling (WaitTimeSeconds up to 20) removes empty ReceiveMessage responses, cutting SQS cost and delivery latency; batch APIs move up to 10 messages per request.
- Cache-key discipline: include only the headers, query strings, and cookies that change the response — forwarding everything destroys the hit ratio.
- Judge latency by p99, not average, and read Init Duration in Lambda REPORT lines to separate cold starts from real bottlenecks.
How the exam tests this
The exam tests this task through symptom-to-fix scenarios: a described inefficiency and four plausible remedies, only one of which needs no redesign or code rewrite. Map trigger phrases fast — "consumers receive only relevant messages without code changes" is an SNS filter policy, "many empty responses from SQS" is long polling, "the cached response must vary by a request header" is a CloudFront cache policy setting, and "reduce Lambda cost without code changes" is memory tuning. When two options both work, prefer the one that measures first (X-Ray subsegments, Logs Insights percentiles) or the managed feature over custom code, such as RDS Proxy over a hand-rolled connection pool.