← Back to Hub
AWS Certified Developer — Associate

DVA-C02
Complete Study Guide

Master all four domains: AWS service development, application security, deployment automation, and troubleshooting. Build the skills to write, deploy, and optimize cloud-native applications on AWS.

65
Scored Questions
130
Minutes
720
Passing Score
4
Domains
DVA-C02 Resources: 🃏 Flashcards ⬇ Cheat Sheet PDF 🏠 Back to Hub
Domain 1 · 32% — Development

AWS Lambda

Lambda is the heart of AWS serverless development. The exam tests runtime behavior, event sources, concurrency models, layers, deployment packages, and performance optimization strategies in depth.

01

Development with AWS Services

Lambda · API Gateway · DynamoDB · SQS · SNS · S3 · Kinesis · Step Functions

32%
OF EXAM

Lambda Execution Model

  • Handler function is entry point — receives event + context objects
  • Execution environment is initialized once, reused on warm invocations
  • Code outside handler runs during init phase (DB connections, SDK clients)
  • Max timeout: 15 minutes; default: 3 seconds
  • Memory: 128 MB – 10,240 MB; CPU scales proportionally

Invocation Types

  • Synchronous: API GW, ALB, Cognito, Lex — caller waits for response
  • Asynchronous: S3, SNS, EventBridge — Lambda retries twice on failure; use DLQ
  • Poll-based: SQS, Kinesis, DynamoDB Streams — Lambda polls and processes batches
  • Event Source Mapping for Kinesis/SQS — Lambda manages the polling

Concurrency & Throttling

  • Default account limit: 1,000 concurrent executions (soft, can increase)
  • Reserved concurrency: caps a function's max concurrency; guarantees capacity
  • Provisioned concurrency: pre-warms execution environments; eliminates cold starts
  • Throttled invocations return HTTP 429; async queue retries for up to 6 hours

Lambda Layers & Versions

  • Layers: shared libraries/dependencies up to 250 MB unzipped; max 5 layers
  • Versions: immutable snapshots of function code + config ($LATEST is mutable)
  • Aliases: named pointers to versions; support traffic splitting (canary/weighted)
  • Use aliases with API GW stage variables for blue/green deployments

Environment Variables & Config

  • Encrypted at rest using KMS; encrypted in transit
  • Max 4 KB total; access via process.env or os.environ
  • Use Secrets Manager or SSM Parameter Store for sensitive values (fetched at init)
  • Store config outside code for 12-factor app compliance

Deployment & Packages

  • Zip deployment: 50 MB direct upload, 250 MB unzipped via S3
  • Container images: up to 10 GB; must implement Lambda Runtime Interface
  • AWS SAM simplifies Lambda deployment with sam build / sam deploy
  • CodeDeploy integration for safe Lambda deployments with traffic shifting
Cold Start vs Warm Start
Understanding Lambda Execution Lifecycle
When a Lambda function is invoked with no available warm environment, AWS must download code → start runtime → run init code (cold start). This adds 100ms–2s of latency. Mitigation: Provisioned Concurrency pre-initializes environments. SnapStart (Java) captures a post-init snapshot. Keep packages small and avoid heavy init code. VPC-attached Lambdas had longer cold starts historically (now improved with ENI pre-allocation).
💡
Exam tip: When a question mentions eliminating cold starts, the answer is Provisioned Concurrency. When it mentions sharing code/dependencies across multiple Lambda functions, the answer is Lambda Layers. When it asks about safe deployments with rollback, think CodeDeploy with canary/linear traffic shifting on Lambda aliases.
Domain 1 · 32% — Development

API Gateway

API Gateway is AWS's fully managed API front door. Know the three types (REST, HTTP, WebSocket), their differences in features and cost, and integration patterns deeply.

REST API vs HTTP API

  • REST API: Full features — usage plans, API keys, request/response transformation, WAF integration, caching, custom authorizers
  • HTTP API: 70% cheaper, lower latency; OIDC/OAuth2 native; JWT authorizers; no caching or usage plans
  • Use HTTP API for simple Lambda or HTTP backends; REST API for enterprise features

WebSocket API

  • Maintains persistent connection; clients connect once
  • Routes: $connect, $disconnect, $default, custom routes
  • Backend can push to clients using Connection URL callback
  • Use for real-time chat, live dashboards, collaborative apps

Integration Types

  • AWS_PROXY: Lambda proxy — passes full request; Lambda returns structured response
  • AWS: Custom integration — use mapping templates (VTL) to transform request/response
  • HTTP_PROXY / HTTP: Pass-through to HTTP endpoints
  • MOCK: Returns static response without backend — great for testing

Stages, Deployments & Caching

  • Must deploy API to a stage for changes to take effect
  • Stage variables: like environment variables for API GW stages (e.g., Lambda alias)
  • Response caching: 0.5–237 GB; TTL 0–3600s (default 300s)
  • Canary deployments: route % of traffic to new deployment

Authorization Methods

  • IAM Authorization: Sigv4 signed requests; use for internal/service-to-service
  • Cognito Authorizer: Validates JWT tokens from Cognito User Pools
  • Lambda Authorizer: Custom logic; TOKEN type (JWT/OAuth) or REQUEST type (header/query)
  • Authorizer cache TTL reduces Lambda invocations

Throttling & Errors

  • Default: 10,000 requests/sec (account level), burst 5,000
  • 429 = Too Many Requests (throttled)
  • Usage plans + API keys for per-client rate/quota limits
  • Enable CORS in API GW for browser-based clients (preflight OPTIONS handled)
Domain 1 · 32% — Development

DynamoDB for Developers

DynamoDB is a key-value and document database with single-digit millisecond performance. For DVA-C02, focus on data modeling, indexes, read/write operations, capacity modes, and Streams.

Core Data Model

  • Table → Items → Attributes (similar to rows/columns but schema-free)
  • Primary key types: Simple (Partition Key only) or Composite (PK + Sort Key)
  • Partition key determines the partition; sort key enables range queries within partition
  • Max item size: 400 KB
  • Attribute types: String, Number, Binary, Boolean, Null, List, Map, Set

Read & Write Operations

  • GetItem / PutItem / UpdateItem / DeleteItem: single-item operations by primary key
  • Query: retrieves items with same PK; can filter on SK; use indexes
  • Scan: reads every item in table — expensive; use sparingly
  • BatchGetItem / BatchWriteItem: up to 100 items or 16 MB per batch
  • TransactGetItems / TransactWriteItems: ACID across up to 25 items

Indexes

  • LSI (Local Secondary Index): same PK, different SK; must be created at table creation; strongly consistent reads possible
  • GSI (Global Secondary Index): different PK and SK; eventually consistent; created/deleted anytime; has its own capacity
  • GSI key attributes must be projected into the index
  • Query a GSI like a table for efficient access patterns

Capacity Modes

  • Provisioned: specify RCU/WCU; use with auto-scaling; cheaper for predictable load
  • On-Demand: pay per request; instant scaling; use for spiky/unknown workloads
  • 1 RCU = 1 strongly consistent read OR 2 eventually consistent reads of ≤4 KB item
  • 1 WCU = 1 write of ≤1 KB item per second; transactional writes cost 2× WCU

DynamoDB Streams

  • Ordered log of item-level changes (INSERT, MODIFY, REMOVE)
  • Stream record types: KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES
  • 24-hour retention; replicate changes to Lambda or Kinesis Data Streams
  • Enables event-driven patterns: replicate data, trigger workflows

TTL, DAX & Global Tables

  • TTL: mark attribute as expiry timestamp; DynamoDB auto-deletes expired items (no cost)
  • DAX: in-memory cache; microsecond reads; API-compatible with DynamoDB SDK
  • Global Tables: multi-region, multi-active replication; eventual consistency across regions
  • PITR: Point-in-Time Recovery up to 35 days; protects against accidental delete
Conditional Writes & Optimistic Locking
Avoiding Conflicts in Concurrent Applications
Use ConditionExpression to make writes conditional: attribute_not_exists(pk) prevents overwriting existing items. Version attributes with ConditionExpression implement optimistic locking — read version, write only if version hasn't changed. If condition fails, DynamoDB throws ConditionalCheckFailedException — retry in your application code.
💡
Exam tip: Query requires a PK (and optionally SK condition); Scan reads everything (avoid in production). For access patterns not supported by the primary key, add a GSI. For row-level ACID, use TransactWriteItems. For microsecond read latency, add DAX between app and DynamoDB.
Domain 1 · 32% — Development

Messaging: SQS, SNS & EventBridge

Decoupling services via messaging is fundamental to AWS development. Know when to use SQS vs SNS vs EventBridge and understand the nuances of each service's delivery guarantees and patterns.

SQS Standard Queue

  • At-least-once delivery; best-effort ordering
  • Max message size: 256 KB; max retention: 14 days
  • Visibility timeout (default 30s): hides msg during processing; extend with ChangeMessageVisibility
  • Long polling: WaitTimeSeconds=20 reduces empty responses and cost
  • Dead Letter Queue (DLQ): after maxReceiveCount failed attempts

SQS FIFO Queue

  • Exactly-once processing; strict ordering within a Message Group ID
  • Throughput: 3,000 msg/s with batching; 300 msg/s without
  • Deduplication ID: prevents duplicate processing within 5-minute deduplication interval
  • Name must end in .fifo
  • Higher latency than Standard; use when order matters

SNS (Simple Notification Service)

  • Pub/Sub push model; one message → multiple subscribers
  • Subscribers: SQS, Lambda, HTTP/S, Email, SMS, Mobile Push, Kinesis Firehose
  • Filter policies: subscribers receive only matching messages (JSON attribute-based)
  • Fan-out pattern: SNS → multiple SQS queues (decoupled parallel processing)
  • FIFO SNS: ordered delivery to FIFO SQS queues only

Amazon EventBridge

  • Event bus: default bus (AWS events), custom buses, partner event buses
  • Rules: match event patterns → route to targets (Lambda, SQS, Step Functions, etc.)
  • Scheduled rules: cron or rate expressions for periodic invocations
  • Archive & Replay: store events and replay for debugging
  • Schema Registry: auto-discovers and documents event schemas

Kinesis Data Streams

  • Real-time streaming; ordered by shard; 1 MB/s in and 2 MB/s out per shard
  • Default retention 24 hours; up to 365 days
  • Consumers: Lambda ESM (batch), Kinesis Client Library (KCL), Kinesis Firehose
  • Enhanced Fan-Out: dedicated 2 MB/s per consumer per shard (push model)
  • Partition key determines shard routing

Step Functions

  • Visual workflow orchestration using Amazon States Language (ASL)
  • Standard: exactly-once, up to 1 year, audit via execution history
  • Express: at-least-once, up to 5 minutes, high-throughput, cheaper
  • States: Task, Choice, Wait, Parallel, Map, Pass, Succeed, Fail
  • Use for long-running, multi-step processes; replaces complex Lambda chaining
SQS + Lambda Integration
Event Source Mapping Behavior
Lambda polls SQS automatically via Event Source Mapping. Batch size: 1–10,000 messages. If Lambda returns an error or times out, the entire batch becomes visible again — risk of duplicates. Use bisect-on-error to split failed batches. For partial failures, return batchItemFailures in response to only requeue failed items. Set visibility timeout to at least 6× your Lambda timeout to prevent premature requeue.
Domain 1 · 32% — Development

S3 for Developers

Beyond basic storage, developers must know presigned URLs, event notifications, multipart uploads, and access patterns for building applications on S3.

Presigned URLs

  • Allow temporary access to S3 objects without AWS credentials
  • Generated using caller's credentials; inherits caller's permissions
  • Default expiry: 3,600s; max: 7 days (for user credentials) or 12 hours (for role credentials)
  • Use for: secure file downloads, allowing direct upload from client browsers
  • Presigned POST: direct browser-to-S3 upload with policy conditions

S3 Event Notifications

  • Events: s3:ObjectCreated:*, s3:ObjectRemoved:*, s3:ObjectRestore:*, etc.
  • Destinations: SQS, SNS, Lambda, EventBridge
  • EventBridge recommended: supports filtering, archive, replay, multiple targets
  • Typical pattern: upload to S3 → Lambda → process file → write to DynamoDB

Multipart Upload

  • Recommended for files >100 MB; required for files >5 GB
  • Upload parts in parallel for higher throughput; can pause and resume
  • Parts minimum 5 MB except last part
  • Must call CompleteMultipartUpload to assemble parts
  • Use S3 Lifecycle to abort incomplete multipart uploads (cost management)

S3 Select & Glacier Select

  • Query data directly in S3 using SQL expressions (CSV, JSON, Parquet)
  • Returns only the matching subset — reduces data transfer and cost
  • Up to 400% faster and 80% cheaper than pulling full object
  • Use for analytics on large files without loading into another service

Access Control & Encryption

  • Bucket policies (resource-based), IAM policies, ACLs (legacy, avoid)
  • SSE-S3: AWS-managed; header x-amz-server-side-encryption: AES256
  • SSE-KMS: CMK; auditable via CloudTrail; header aws:kms
  • SSE-C: customer-provided key; HTTPS required
  • Enforce encryption: bucket policy to deny requests without SSE header

CORS & Website Hosting

  • CORS configuration on S3 bucket allows cross-origin browser requests
  • Configure AllowedOrigins, AllowedMethods, AllowedHeaders, MaxAgeSeconds
  • Static website hosting: enable on bucket, configure index/error documents
  • Use CloudFront in front of S3 website for HTTPS and custom domains
Domain 2 · 26% — Security

IAM & STS for Developers

Secure application access patterns using IAM roles, policies, and temporary credentials obtained via STS. Understand how applications authenticate to AWS services without long-term keys.

02

Security

IAM · STS · Cognito · KMS · Secrets Manager · Parameter Store

26%
OF EXAM

IAM Roles for Applications

  • EC2 Instance Profiles: attach IAM role to EC2; SDK auto-retrieves temporary creds from metadata service
  • Lambda execution role: role assumed by Lambda function; grant only needed permissions
  • ECS Task Role: per-task IAM role; separate from task execution role
  • Never hardcode access keys in application code — use roles

STS (Security Token Service)

  • AssumeRole: assume cross-account or same-account role; returns temp credentials
  • AssumeRoleWithWebIdentity: federate with OIDC providers (Google, Facebook) — Cognito preferred
  • AssumeRoleWithSAML: enterprise federation (ADFS)
  • GetSessionToken: MFA-based temp credentials for IAM users
  • Temp credentials: AccessKeyId, SecretAccessKey, SessionToken, Expiration

Policy Evaluation Logic

  • Explicit Deny → allow → implicit deny (in that priority)
  • Identity-based policies + resource-based policies are evaluated together
  • SCPs (from Organizations) restrict the maximum permissions
  • Permission boundaries: maximum permissions an entity can have (does not grant)
  • Least privilege principle: grant minimum required permissions

Resource-Based Policies

  • Attached to AWS resources: S3 bucket policies, SQS queue policies, Lambda resource policies, KMS key policies
  • Allow cross-account access by specifying external account/ARN in Principal
  • S3 + cross-account: both identity-based policy AND bucket policy must allow
  • Lambda resource policy grants API GW / S3 / SNS permission to invoke function
Security Best Practices
Application Credential Management
Never: Hardcode credentials in code, commit to Git, or store in environment variables as plaintext. Always: Use IAM roles for AWS service access. For secrets (DB passwords, API keys), use Secrets Manager (auto-rotation) or SSM Parameter Store SecureString (cheaper, manual rotation). Cache fetched secrets in memory to reduce API call costs. Implement secret rotation using Lambda.
Domain 2 · 26% — Security

Amazon Cognito

Cognito provides fully managed authentication and authorization for web and mobile applications. Understand the difference between User Pools and Identity Pools and when to use each.

User Pools (Authentication)

  • User directory for sign-up, sign-in, MFA, and account recovery
  • Returns JWT tokens: ID token (user info), Access token (API calls), Refresh token
  • Social federation: Google, Facebook, Apple, SAML/OIDC identity providers
  • Hosted UI: pre-built sign-in page; custom domain with ACM certificate
  • Triggers: Lambda triggers for pre/post authentication, custom messages, etc.

Identity Pools (Authorization)

  • Exchange third-party tokens (including Cognito User Pool JWT) for AWS credentials via STS
  • Assign IAM roles to authenticated and unauthenticated users
  • Rule-based role mapping: assign different roles based on user attributes/groups
  • Use when your users need to directly call AWS services (S3, DynamoDB, etc.)

Cognito + API Gateway Integration

  • Configure API GW Cognito Authorizer pointing to your User Pool
  • Client sends JWT Access/ID token in Authorization header
  • API GW validates token signature and expiry automatically
  • Scopes can restrict access to specific API operations
  • For fine-grained authorization, use Lambda Authorizer instead

Common Architecture Patterns

  • Web/mobile to API: User Pool (auth) → JWT → API GW Cognito Authorizer → Lambda
  • Direct AWS access: User Pool + Identity Pool → IAM role credentials → SDK calls
  • S3 per-user folders: Identity Pool role with cognito-identity.amazonaws.com:sub condition
  • Groups in User Pools → map to IAM roles via Identity Pools
Domain 2 · 26% — Security

KMS & Secrets Manager

Know how to encrypt data using KMS in application code and how to retrieve secrets programmatically from Secrets Manager and Parameter Store.

AWS KMS for Developers

  • CMKs (Customer Managed Keys): you control rotation, policies, grants
  • AWS Managed Keys: AWS manages, you use; auto-rotated every year
  • Envelope encryption: KMS generates DEK; encrypt data with DEK; store encrypted DEK with data
  • KMS limits: 4 KB max per encrypt call; use GenerateDataKey for larger payloads
  • All KMS calls logged in CloudTrail for audit

Secrets Manager

  • Store and manage secrets (DB credentials, API keys, OAuth tokens)
  • Automatic rotation: Lambda function rotates secrets on schedule (RDS supported natively)
  • Cross-account access via resource-based policy
  • Versioning: AWSCURRENT, AWSPENDING, AWSPREVIOUS labels
  • SDK: get_secret_value(SecretId=...) — cache in application code

SSM Parameter Store

  • Hierarchy: /prod/myapp/db-password
  • Standard tier: 10,000 params; 4 KB; free; no rotation
  • Advanced tier: 100,000 params; 8 KB; paid; supports TTL policies
  • SecureString: encrypted via KMS; same API with decryption flag
  • Use for non-rotating configs; use Secrets Manager for rotating credentials

SDK Encryption Client

  • AWS Encryption SDK: client-side encryption library; envelope encryption made easy
  • Encrypts data locally before sending to AWS (S3, DynamoDB, etc.)
  • Supports multiple master key providers; data keys cached locally
  • Use when you need to encrypt data before it leaves your code
Domain 3 · 24% — Deployment

CI/CD with CodePipeline

AWS Developer Tools form a complete CI/CD pipeline. Know each tool's role and how they integrate to automate the software delivery lifecycle.

03

Deployment

CodeCommit · CodeBuild · CodeDeploy · CodePipeline · SAM · CloudFormation · Beanstalk

24%
OF EXAM
ServiceRole in PipelineKey Detail
CodeCommitSource — Git repositoryFully managed private Git; triggers pipelines via CloudWatch Events; being sunset — migrating to GitHub Actions recommended
CodeBuildBuild — compile, test, packageRuns in Docker containers (managed images or custom); buildspec.yml defines phases: install, pre_build, build, post_build
CodeDeployDeploy — push to targetsSupports EC2, Lambda, ECS; deployment strategies: in-place, blue/green, canary, linear; appspec.yml config file
CodePipelineOrchestrate — connect stagesChains Source → Build → Deploy stages; manual approval gates; integrates with 3rd-party tools
CodeArtifactArtifact repositoryManaged npm, Maven, PyPI proxy and storage; secures dependencies; integrates with CodeBuild

buildspec.yml Structure

  • phases.install: install runtime, tools
  • phases.pre_build: login to ECR, run pre-tests
  • phases.build: compile, run unit tests, build Docker image
  • phases.post_build: push image, create artifact
  • artifacts: specify files to pass to CodeDeploy or S3
  • cache: speed up builds by caching node_modules, .m2

CodeDeploy Strategies

  • In-Place (EC2/on-prem): stop app, deploy, restart; downtime possible
  • Blue/Green (EC2): new fleet deployed; switch traffic; old fleet kept
  • Blue/Green (Lambda): uses Lambda aliases + traffic shifting (canary/linear)
  • Blue/Green (ECS): new task set deployed; test before cutover
  • Rollback: automatic on CloudWatch alarm or deployment failure

appspec.yml

  • Defines deployment hooks and resource mapping for CodeDeploy
  • EC2: files (source → destination), hooks (BeforeInstall, AfterInstall, ApplicationStart, ValidateService)
  • Lambda: specifies function name, alias, current/target version, lifecycle hooks
  • ECS: container name/port, Load Balancer info, lifecycle hooks

CodePipeline Stages

  • Stages contain one or more Actions running sequentially or in parallel
  • Artifacts stored in S3; passed between stages automatically
  • Stage transitions can be disabled to pause pipeline
  • Manual Approval action: pauses pipeline; sends SNS notification; requires explicit approval
  • Supports GitHub, Bitbucket as source via CodeStar Connections
Domain 3 · 24% — Deployment

SAM & CloudFormation

AWS SAM (Serverless Application Model) is a shorthand extension of CloudFormation specifically for serverless applications. Know both SAM transforms and core CloudFormation concepts.

SAM Template Structure

  • Transform: AWS::Serverless-2016-10-31 — required SAM declaration
  • AWS::Serverless::Function: Lambda function (auto-creates execution role, event sources)
  • AWS::Serverless::Api: API Gateway REST API with SAM shortcuts
  • AWS::Serverless::SimpleTable: DynamoDB table with single hash key
  • AWS::Serverless::LayerVersion: Lambda layer

SAM CLI Commands

  • sam init — scaffold new serverless project
  • sam build — compile dependencies per runtime
  • sam local invoke — test Lambda locally in Docker
  • sam local start-api — local API GW emulation
  • sam deploy --guided — deploy to AWS (uploads to S3, creates/updates stack)
  • sam logs — tail Lambda logs from CloudWatch

CloudFormation Key Concepts

  • Parameters: runtime inputs; use !Ref to reference
  • Mappings: static lookup tables (e.g., AMI IDs by region)
  • Conditions: create resources conditionally (e.g., prod vs dev)
  • Outputs: export values for cross-stack references
  • Fn::Sub / !Sub: string interpolation with variable substitution

CloudFormation Stack Features

  • Change Sets: preview changes before applying; see adds/removes/modifies
  • Drift Detection: compare actual resource state vs template
  • StackSets: deploy across multiple accounts and regions
  • Nested Stacks: break large templates into reusable modules
  • DeletionPolicy: Retain / Delete / Snapshot on stack deletion

CloudFormation Custom Resources

  • Use Lambda-backed custom resources for unsupported resources
  • CloudFormation sends Create/Update/Delete events to Lambda SNS/HTTP endpoint
  • Lambda must respond with SUCCESS/FAILED and Data output
  • Use cases: fetch external config, configure 3rd-party SaaS, run DB migrations

CDK (Cloud Development Kit)

  • Define infrastructure in TypeScript, Python, Java, C#, Go
  • Synthesizes to CloudFormation templates via cdk synth
  • Constructs: L1 (raw CFN), L2 (sensible defaults), L3 (complete patterns)
  • cdk deploy — deploy; cdk diff — preview changes
  • CDK Pipelines: self-mutating CI/CD pipeline for CDK apps
💡
Exam tip: SAM is a CloudFormation extension — all SAM templates are valid CloudFormation templates after transform. The sam local invoke command runs Lambda locally. For deploying serverless apps with a simplified template, use SAM. For infrastructure as code in a programming language, use CDK. CloudFormation Change Sets let you review changes before applying.
Domain 3 · 24% — Deployment

Elastic Beanstalk

Beanstalk is a PaaS for deploying web applications without managing infrastructure. It handles capacity provisioning, load balancing, auto-scaling, and monitoring automatically.

Core Concepts

  • Application: container for environments, versions, configurations
  • Environment: specific deployment (Web Server or Worker tier)
  • Application version: labeled ZIP/WAR/Docker artifact stored in S3
  • Environment tier: Web Server (handles HTTP) vs Worker (processes SQS messages)

Deployment Policies

  • All at once: fastest; downtime during deploy; good for dev
  • Rolling: deploys to batches; reduced capacity during deploy; no downtime
  • Rolling with additional batch: spins extra instances; maintains full capacity
  • Immutable: new ASG with new instances; zero downtime; expensive; easy rollback
  • Blue/Green: new environment; Route 53 swap; instant rollback via DNS

Configuration & .ebextensions

  • .ebextensions/ folder in app root: YAML/JSON config files with .config extension
  • Configure EC2 instances, install packages, run shell commands, create files
  • Environment variables: set via console, CLI, or .ebextensions
  • Buildfile: run commands at build time (before deployment)
  • Procfile: specify processes to run (for Docker/Tomcat platforms)

Platform & Runtime

  • Supported: Node.js, Python, Ruby, Java, PHP, Go, .NET, Docker, Multi-container Docker
  • Custom platforms: use Packer to build AMIs with your runtime
  • Managed platform updates: automatic minor/patch updates during maintenance window
  • Worker environment + SQS: daemon process pulls messages and calls / endpoint
Domain 3 · 24% — Deployment

ECS, ECR & Container Deployments

Know ECS task definitions, service deployments, Fargate vs EC2 launch types, and ECR for container image management.

ECS Core Concepts

  • Task Definition: blueprint for containers — image, CPU/memory, ports, env vars, volumes, IAM roles
  • Task: running instance of a Task Definition
  • Service: maintains desired count of tasks; integrates with ALB
  • Cluster: logical grouping of tasks/services; underlying EC2 or Fargate

Fargate vs EC2 Launch Type

  • Fargate: serverless; no EC2 to manage; pay per vCPU+memory per second; simpler; slower cold start
  • EC2: you manage instances; better price/performance at scale; required for GPU, specific instance types
  • Fargate Spot: up to 70% savings for fault-tolerant tasks
  • Both support EFS for shared persistent storage

Task IAM Roles

  • Task Role: IAM role assumed by the task for AWS API calls (e.g., S3, DynamoDB)
  • Task Execution Role: used by the ECS agent — pull ECR images, write logs to CloudWatch
  • Different role for each task (per-service permissions); principle of least privilege
  • Inject secrets from Secrets Manager / SSM into containers via secrets config

ECR (Elastic Container Registry)

  • Private Docker registry; encrypted at rest (KMS); integrate with IAM
  • Lifecycle policies: automatically expire old images (save storage cost)
  • Image scanning: on push CVE scan (basic) or continuous (enhanced via Inspector)
  • Cross-account: resource-based policy grants push/pull to other accounts
  • aws ecr get-login-password | docker login to authenticate
Domain 4 · 18% — Troubleshooting & Optimization

CloudWatch & X-Ray

Developers must know how to instrument applications, interpret traces, and use CloudWatch Logs Insights to diagnose production issues rapidly.

04

Troubleshooting & Optimization

CloudWatch · X-Ray · Logging · Metrics · Alarms · Performance tuning

18%
OF EXAM

CloudWatch Metrics

  • Default metrics: EC2 every 5 min; detailed monitoring every 1 min (extra cost)
  • Custom metrics: publish with PutMetricData API; standard (1-min) or high-resolution (1-sec)
  • Metric Math: perform calculations across multiple metrics in dashboards/alarms
  • Lambda metrics: Duration, Errors, Throttles, ConcurrentExecutions, DeadLetterErrors
  • Namespace: logical grouping for custom metrics (e.g., MyApp/Cache)

CloudWatch Logs

  • Log Groups → Log Streams → Log Events
  • Lambda automatically creates log group; must grant logs:CreateLogGroup/Stream/PutLogEvents
  • Log Insights: SQL-like query language for log analysis; use for debugging
  • Metric Filters: create custom metrics from log patterns (e.g., count errors)
  • Subscriptions: stream logs to Lambda, Kinesis, Firehose in real time

CloudWatch Alarms

  • States: OK, ALARM, INSUFFICIENT_DATA
  • Actions: SNS notification, EC2 action (stop/reboot), ASG scaling, Lambda
  • Composite Alarms: combine multiple alarms with AND/OR logic; reduce alarm noise
  • Period + evaluation periods + threshold = alarm trigger logic
  • Missing data handling: missing, notBreaching, breaching, ignore

AWS X-Ray

  • Distributed tracing for identifying performance bottlenecks and errors
  • Segment: work done by single service; Subsegment: granular breakdown
  • Trace: end-to-end request across services; unique Trace ID
  • Sampling: default 5% + 1 req/sec; configure rules to sample more/less
  • X-Ray daemon: receives UDP data on port 2000; batches and sends to X-Ray API

X-Ray Integration

  • Lambda: enable Active Tracing in config; AWS X-Ray SDK in code for custom subsegments
  • API Gateway: enable tracing on stage; adds X-Ray header to downstream requests
  • EC2/ECS: install X-Ray daemon; SDK instruments AWS SDK calls automatically
  • Use AWSXRayDaemonWriteAccess managed policy on execution role
  • Service map: visual graph of services and their health/latency

CloudWatch Events → EventBridge

  • CloudWatch Events is now Amazon EventBridge (same service, new name)
  • Schedule expressions: rate(5 minutes) or cron cron(0 12 * * ? *)
  • Event patterns: match AWS service events (EC2 state change, CodePipeline stage change)
  • Targets: Lambda, SQS, SNS, Step Functions, Kinesis, CodePipeline
Domain 4 · 18% — Troubleshooting & Optimization

Performance Optimization & Caching

Optimize application performance through caching strategies, connection reuse, and appropriate service selection for different workload patterns.

ElastiCache (Redis vs Memcached)

  • Redis: persistence, replication, multi-AZ, Sorted Sets, pub/sub, Lua scripts, cluster mode
  • Memcached: simple key-value; multi-threaded; horizontal scaling via sharding; no persistence
  • Cache-aside (lazy loading): app checks cache first, loads from DB on miss, writes to cache
  • Write-through: write to cache and DB simultaneously; no stale data; more writes
  • Session store: store user sessions in Redis (instead of sticky sessions)

CloudFront & Caching

  • Cache behaviors: path-based rules for TTL, compression, headers to forward
  • Cache keys: URL, headers, cookies, query strings (include only what varies response)
  • Invalidation: explicit invalidation costs $0.005/path after first 1,000/month
  • Versioned file names (e.g., app.v2.js) better than invalidation for cache busting
  • Use Origin Access Control (OAC) to restrict S3 access to CloudFront only

Lambda Performance Tips

  • Initialize SDK clients outside handler (reused on warm invocations)
  • Increase memory to increase CPU and network bandwidth proportionally
  • Use /tmp for ephemeral storage (512 MB to 10 GB); not shared between invocations
  • Lambda Power Tuning: open-source tool to find optimal memory/cost balance
  • SnapStart (Java): snapshot post-init state; reduce cold start significantly

DynamoDB Performance

  • Avoid hot partitions: distribute reads/writes across partition key space
  • Read consistency: eventually consistent (default, cheaper) vs strongly consistent (+1 RCU)
  • Projection expressions: retrieve only needed attributes to reduce read cost
  • Batch operations: BatchGetItem / BatchWriteItem reduce round trips
  • Use DAX for microsecond caching of read-heavy workloads

API Gateway Optimization

  • Enable API caching on stage (0.5 GB–237 GB); TTL up to 3,600s
  • Cache key: method + URL + specific headers/query params
  • Invalidate cache: pass Cache-Control: max-age=0 header (requires IAM permission)
  • HTTP API significantly cheaper and faster than REST API for simple use cases
  • Use Lambda function URLs as cheaper alternative for single-function APIs

Connection Management

  • RDS Proxy: pool and share DB connections for Lambda (avoids connection exhaustion)
  • Lambda + RDS without proxy: each Lambda instance opens connection → max connections hit
  • DynamoDB: connectionless HTTP API; scales naturally with Lambda concurrency
  • HTTP keep-alive: reuse connections in Lambda via SDK config for better performance
Common Architecture Pattern
Serverless REST API with Caching
Client → CloudFront (CDN, SSL termination, edge caching) → API Gateway (request throttling, auth, response caching) → Lambda (business logic; init clients outside handler) → ElastiCache Redis (application-level cache) → DynamoDB (source of truth). For DB-heavy reads, add DAX in front of DynamoDB for sub-millisecond latency. Use SQS to buffer spiky writes.
Mock Exam — 100 Questions

Practice Questions

Test your DVA-C02 readiness across all four domains. 720+ to pass.

Exam Complete!

0

out of 100 questions correct