DVA-C02

Exam Code: DVA-C02  |  Duration: 130 minutes  |  Questions: 65  |  Passing Score: 720/1000 (~72%)

Format: Multiple choice (1 correct out of 4) and multiple response (2+ correct out of 5)

Cost: $150 USD  |  Validity: 3 years  |  Delivery: Pearson VUE (testing center or online proctored)

Domain Weights:

Question Strategy Tips:

• Time per question — ~2 minutes each (130 min / 65 questions)
• Unscored questions — 15 of the 65 are unscored pilot questions; you won\'t know which
• No penalty for guessing — Always answer every question
• Keywords to watch for — "least operational overhead," "most secure," "serverless," "decouple"
• Scenario-based — Most questions describe a real-world scenario and ask for the best solution

AWS Lambda Key Limits:

Lambda Key Concepts:

• Execution role — IAM role that grants Lambda permissions to access AWS services
• Resource-based policy — Controls which services/accounts can invoke the function
• Versions & Aliases — Immutable snapshots; aliases point to versions (useful for Blue/Green)
• Layers — Shared libraries/dependencies across multiple functions
• Dead Letter Queue — SQS or SNS destination for failed async invocations
• Destinations — Route async success/failure results to SQS, SNS, Lambda, or EventBridge
• Event Source Mapping — Polls SQS, Kinesis, DynamoDB Streams; Lambda invoked synchronously

API Gateway: REST API vs HTTP API:

DynamoDB Key Concepts:

• Partition Key (PK) — Required. Determines data distribution across partitions
• Sort Key (SK) — Optional. Enables range queries within a partition
• GSI (Global Secondary Index) — Different PK+SK, own throughput, eventually consistent only, can be added anytime
• LSI (Local Secondary Index) — Same PK, different SK, shares table throughput, strongly consistent option, must be created at table creation
• On-Demand capacity — Auto-scales, pay-per-request, best for unpredictable traffic
• Provisioned capacity — Set RCU/WCU manually, can use Auto Scaling, cheaper for steady traffic
• Eventually consistent reads — Default, half the cost of strongly consistent reads
• Strongly consistent reads — Guaranteed latest data, 2x the RCU cost
• DynamoDB Streams — Capture item-level changes (INSERT/MODIFY/DELETE) for event-driven processing
• TTL — Automatically delete items after expiration (no cost for deletes)
• Transactions — ACID operations across multiple items/tables (2x the cost of standard operations)
• PartiQL — SQL-compatible query language for DynamoDB

Amazon S3 Key Developer Features:

• Presigned URLs — Time-limited URLs for secure upload/download without AWS credentials
• Event Notifications — Trigger Lambda, SQS, SNS, or EventBridge on object events (PUT, DELETE, etc.)
• Multipart Upload — Required for files >5 GB, recommended for files >100 MB
• S3 Transfer Acceleration — Uses CloudFront edge locations for faster uploads
• S3 Select — Retrieve subset of data from objects using SQL (reduce data transfer)
• Encryption — SSE-S3 (default), SSE-KMS (audit trail), SSE-C (customer-managed keys), client-side
• Versioning — Keep multiple variants of an object; required for cross-region replication

SQS: Standard vs FIFO:

SQS Key Settings:

• Visibility Timeout — 0s–12hr (default 30s). Time message is hidden after being read
• Long Polling — Set WaitTimeSeconds (1–20s). Reduces empty responses and cost
• Dead Letter Queue — Failed messages after maxReceiveCount attempts
• Delay Queue — Delay delivery up to 15 minutes
• Message retention — 1 minute to 14 days (default 4 days)
• Max message size — 256 KB (use Extended Client Library + S3 for larger)

SNS Fan-Out Pattern:

• Publish to SNS topic — Multiple SQS queues subscribe to receive the same message
• Decouples producers from consumers — Add/remove subscribers without changing publisher
• Message filtering — Subscribers can set filter policies to receive only relevant messages
• Supported subscribers — SQS, Lambda, HTTP/S, Email, SMS, Kinesis Data Firehose

Step Functions: Standard vs Express:

Amazon EventBridge Key Concepts:

• Event Bus — Default (AWS services), Custom (your apps), Partner (SaaS integrations)
• Rules — Match events by pattern and route to targets (100+ supported targets)
• Schema Registry — Discover and store event schemas, auto-generate code bindings
• Archive & Replay — Archive events and replay them later for debugging/testing
• Scheduled events — Cron-like scheduling for periodic tasks (replaces CloudWatch Events)

IAM Policy Evaluation Flow:

• Step 1: All requests start as implicitly denied
• Step 2: Check all applicable policies (identity-based, resource-based, SCPs, permission boundaries)
• Step 3: Explicit DENY always wins — overrides any ALLOW
• Step 4: If an explicit ALLOW exists and no explicit DENY, request is allowed
• Step 5: If no explicit ALLOW, request is implicitly denied

Remember: Explicit Deny > Explicit Allow > Implicit Deny (default)

IAM Key Concepts for Developers:

• IAM Roles — Preferred over access keys; used by EC2, Lambda, ECS tasks
• STS AssumeRole — Temporary credentials for cross-account access or role switching
• Policy Variables — Use ${aws:username} for dynamic policies
• Permission Boundaries — Maximum permissions an IAM entity can have (does not grant, only limits)
• Resource-based policies — Attached to resources (S3 bucket, SQS queue, Lambda); allow cross-account without AssumeRole
• Session policies — Limit permissions for a specific session (used with AssumeRole or federation)

Cognito: User Pools vs Identity Pools:

Common pattern: User Pool authenticates user → Identity Pool exchanges token for AWS credentials

Encryption Types (S3 as Example):

KMS Key Concepts:

• CMK types — AWS managed (aws/service), Customer managed (you create & control), AWS owned (shared)
• Envelope encryption — KMS generates data key, data key encrypts data, KMS encrypts data key
• GenerateDataKey API — Returns plaintext + encrypted data key for client-side envelope encryption
• Key rotation — Automatic every year for customer managed keys (optional); always enabled for AWS managed
• 4 KB limit — KMS Encrypt API can only encrypt up to 4 KB directly; use envelope encryption for larger data
• KMS key policy — Resource-based policy; required for cross-account access

Secrets Manager vs Parameter Store:

Rule of thumb: Use Secrets Manager for database credentials and secrets needing rotation. Use Parameter Store for config values and when cost matters.

API Gateway Authorization Methods:

Lambda Security Best Practices:

• Least privilege execution role — Only grant permissions the function actually needs
• Environment variable encryption — Use KMS to encrypt sensitive values; decrypt at runtime
• VPC access — Place Lambda in VPC if it needs to access private resources (RDS, ElastiCache)
• No secrets in code — Use Secrets Manager or Parameter Store for credentials
• Resource-based policies — Control which services/accounts can invoke the function
• Code signing — Ensure only trusted code is deployed to Lambda functions

CloudFormation Key Sections:

• AWSTemplateFormatVersion — Template version (always "2010-09-09")
• Description — Template description text
• Parameters — Input values at stack creation (InstanceType, Env, etc.)
• Mappings — Static key-value lookup tables (region → AMI, etc.)
• Conditions — Conditional resource creation (if prod, if us-east-1, etc.)
• Resources — REQUIRED. The AWS resources to create
• Outputs — Return values (export for cross-stack references)
• Transform — Specify macros (e.g., AWS::Serverless-2016-10-31 for SAM)

CloudFormation Intrinsic Functions:

CDK Construct Levels:

CDK Key Commands:

• cdk init — Create a new CDK project from a template
• cdk synth — Synthesize CloudFormation template from CDK code
• cdk diff — Compare deployed stack with current code
• cdk deploy — Deploy the stack(s) to AWS
• cdk destroy — Delete the stack(s)
• cdk bootstrap — Provision initial resources (S3 bucket, IAM roles) for CDK in a region

SAM (Serverless Application Model):

• Extension of CloudFormation — Uses Transform: AWS::Serverless-2016-10-31
• AWS::Serverless::Function — Lambda function with inline event sources
• AWS::Serverless::Api — API Gateway REST API
• AWS::Serverless::SimpleTable — DynamoDB table with simplified syntax
• sam init — Create new SAM project
• sam build — Build the application (install deps, compile)
• sam local invoke — Invoke Lambda locally in Docker
• sam local start-api — Start local API Gateway for testing
• sam deploy --guided — Deploy with interactive prompts
• sam package — Package and upload artifacts to S3

CI/CD Pipeline Services:

CodeBuild — buildspec.yml Key Phases:

• install — Install dependencies (runtime versions, packages)
• pre_build — Commands before build (login to ECR, run tests)
• build — Actual build commands (compile, package)
• post_build — Commands after build (push image, notifications)
• artifacts — Files to upload to S3 output bucket
• env / variables — Environment variables (plaintext, SSM, Secrets Manager)

Elastic Beanstalk Deployment Policies:

Lambda Deployment Strategies (via CodeDeploy):

Key: Uses Lambda aliases + weighted alias routing. Pre/post traffic hooks can run validation tests.

Elastic Beanstalk Extras:

• .ebextensions/ — YAML/JSON config files in .config format for customizing environment
• Saved configurations — Reusable environment configuration snapshots
• Worker environments — Process background tasks from SQS queues
• Docker support — Single container, multi-container (ECS), or Dockerfile
• Platform hooks — Custom scripts at specific lifecycle stages

AWS X-Ray Concepts:

• Segments — Data about work done by a service (name, request, response, subsegments)
• Subsegments — Granular detail within segments (AWS SDK calls, HTTP calls, SQL queries)
• Traces — End-to-end path of a request through your application (collection of segments)
• Annotations — Key-value pairs that are indexed for search/filter (use for filtering traces)
• Metadata — Key-value pairs that are NOT indexed (use for storing additional data)
• Sampling rules — Control how many requests are traced (reservoir rate + fixed rate)
• Service map — Visual representation of your application architecture and dependencies

X-Ray Integration Setup:

Key SDK env vars: AWS_XRAY_DAEMON_ADDRESS, AWS_XRAY_TRACING_NAME

CloudWatch Key Features:

• Metrics — Time-series data points (CPU, memory, custom metrics). Standard resolution: 1 min; High resolution: 1 sec
• Custom Metrics — PutMetricData API; use dimensions for granularity; StorageResolution=1 for high-res
• Alarms — Watch a metric and trigger actions (SNS, Auto Scaling, EC2). States: OK, ALARM, INSUFFICIENT_DATA
• Logs — Log Groups (per application) → Log Streams (per instance/container). Never expire by default
• Logs Insights — Interactive query language for analyzing log data in real-time
• Logs Agent — Install on EC2 to push logs (older). Use Unified Agent for metrics + logs
• Metric Filters — Extract metric data from log events (e.g., count ERROR occurrences)
• Dashboards — Custom views of metrics and alarms across regions and accounts

CloudWatch vs X-Ray vs CloudTrail:

CloudTrail: Management vs Data Events:

• Management events — Control plane operations (CreateBucket, RunInstances, AttachPolicy). Logged by default
• Data events — Data plane operations (GetObject, PutObject, Invoke Lambda). NOT logged by default (high volume)
• Insights events — Detect unusual API activity patterns (burst of API calls, etc.)

Lambda Optimization Tips:

• Memory = CPU — Increasing memory proportionally increases CPU. Test to find the sweet spot
• Cold starts — First invocation initializes runtime. Mitigate with Provisioned Concurrency
• Provisioned Concurrency — Pre-warm N instances to eliminate cold starts (costs money even when idle)
• Reserved Concurrency — Guarantee N concurrent executions for a function (also limits max concurrency)
• Initialize outside handler — DB connections, SDK clients in INIT phase (reused across warm invocations)
• /tmp caching — Cache files between invocations in the same execution environment (512 MB–10 GB)
• Minimize deployment package — Smaller packages = faster cold starts. Use layers for shared deps
• ARM64 (Graviton2) — Up to 34% better price-performance than x86

DynamoDB Optimization:

• Partition key design — High cardinality keys distribute data evenly; avoid hot partitions
• Write sharding — Append random suffix to partition key to spread writes
• DAX (DynamoDB Accelerator) — In-memory cache, microsecond reads, transparent to application
• Query vs Scan — Query is targeted (uses PK/SK), Scan reads entire table. Always prefer Query
• Projection expressions — Only retrieve needed attributes (reduce RCU usage)
• Parallel scan — Use Segments for large tables (still expensive, use sparingly)
• Batch operations — BatchGetItem (up to 100 items), BatchWriteItem (up to 25 items)
• Exponential backoff — Handle ProvisionedThroughputExceededException with retry + backoff

Caching Strategies:

Best practice: Combine lazy loading + TTL for balanced freshness and performance.

Messaging & Event Services:

API Gateway Types:

Infrastructure as Code: CloudFormation vs CDK vs SAM:

CodeDeploy Deployment Types:

appspec.yml defines lifecycle hooks. EC2 hooks: BeforeInstall, AfterInstall, ApplicationStart, ValidateService. Lambda hooks: BeforeAllowTraffic, AfterAllowTraffic.

ElastiCache: Redis vs Memcached:

Default choice: Redis in most cases. Use Memcached only if you need multi-threaded performance and don\'t need persistence.

Common HTTP Error Codes on AWS:

Key rule: 4xx = client-side error (fix your code/config). 5xx = server-side error (retry with exponential backoff).

Exponential Backoff & Jitter:

• When to use — On 5xx errors and throttling (429). NOT on 4xx errors (except 429)
• Formula — Wait time = base * 2^attempt (e.g., 1s, 2s, 4s, 8s, 16s...)
• Jitter — Add random delay to prevent thundering herd problem
• AWS SDK — Built-in retry with exponential backoff (configurable max retries)
• Max backoff — Cap the wait time (e.g., 32s max) to avoid excessive delays