Which SDK/tool for which job

AWS gives you several ways to talk to services: the AWS SDKs (Boto3 for Python, SDK for JavaScript, Java, .NET etc), the AWS CLI, and the AWS CloudShell. For DVA-C02 you need to know how the SDKs authenticate, retry, and handle errors - not just how to call an API.

Credential chain (default provider chain)

SDKs look for credentials in this order: environment variables, then the shared credentials/config file (~/.aws/credentials), then container credentials (ECS task role), then the EC2 instance metadata service (IMDS) for an instance profile role. Always prefer IAM roles over hard-coded access keys - never bake secrets into code or AMIs.

Retries and exponential backoff

AWS SDKs retry throttled or failed requests automatically using exponential backoff with jitter. This spreads out retries so many clients do not all hammer the service at the same instant. You can tune max retry attempts and backoff strategy in the SDK config (for example retryMode 'standard' or 'adaptive' in newer SDKs). Adaptive mode also throttles the client side send rate when it detects the service is struggling.

Idempotency

Many write APIs (like EC2 RunInstances or SQS SendMessage with a deduplication ID) accept a client token so a retried request does not create duplicate resources. Always pass an idempotency token for any operation you might retry.

Waiters and paginators

Waiters poll an API until a resource reaches a desired state (e.g. waiting for an EC2 instance to reach 'running'), saving you from writing your own polling loops. Paginators automatically handle APIs that return results in pages (using NextToken/Marker), looping through all pages for you.

X-Ray for tracing

The X-Ray SDK instruments your code to trace requests across microservices, showing latency and errors per segment/subsegment. Install the X-Ray daemon (or use the CloudWatch agent) to forward trace data; on Lambda, just enable Active Tracing - no daemon needed.

Exceptions and error handling

SDK calls throw service-specific exceptions (e.g. ThrottlingException, ProvisionedThroughputExceededException for DynamoDB). Catch these and apply backoff rather than failing immediately. HTTP 400s are client errors (fix the request), 500s are server errors (safe to retry).

Common exam traps

• Do not hard-code AWS access keys in application code - use IAM roles.
• The default retry behaviour is already exponential backoff with jitter - you rarely need to write your own.
• IMDSv2 requires a session token via a PUT request first, then a GET with that token header - this closes off SSRF vulnerabilities that affected IMDSv1.
• CLI and SDKs share the same underlying credential chain and config files.

Lambda basics

Lambda runs your code without servers, billed per millisecond of execution (rounded up) plus memory allocated. You pick memory from 128 MB to 10,240 MB, and CPU scales proportionally with memory - more memory means more CPU. Default timeout is 3 seconds, maximum is 15 minutes. Deployment package (zip) limit is 50 MB zipped / 250 MB unzipped including layers; container images can go up to 10 GB.

Cold starts and concurrency

A 'cold start' happens when Lambda provisions a fresh execution environment - this adds latency, worse for languages like Java or .NET. Provisioned concurrency keeps environments warm for predictable latency, at extra cost. Reserved concurrency caps how many concurrent executions a function can use, protecting downstream systems and other functions from being starved. Default account concurrency limit is 1,000 (soft limit, raisable).

Environment and state

Use environment variables for config; encrypt sensitive ones with KMS. Lambda is stateless between invocations but the execution environment can be reused, so anything initialised outside the handler (like a DB connection) persists across warm invocations - a common exam trap.

API Gateway

Supports REST APIs (more features, usage plans, API keys) and HTTP APIs (cheaper, faster, simpler, no usage plans). Integrates with Lambda via Lambda proxy integration, passing the full request and expecting a specific JSON response shape (statusCode, headers, body). Throttling defaults to 10,000 requests/second steady-state with a 5,000 burst, account-wide - configurable per method. Caching is REST-API only, not HTTP API.

DynamoDB essentials

A NoSQL key-value/document store. Partition key alone, or partition key + sort key, forms the primary key. Read/write capacity modes: on-demand (pay per request, scales automatically) or provisioned (set RCU/WCU, can use auto scaling). One RCU = one strongly consistent read of up to 4 KB/second (or two eventually consistent reads). One WCU = one write of up to 1 KB/second. Item size limit is 400 KB.

DynamoDB features to know

DAX is an in-memory cache for DynamoDB, cutting read latency to microseconds - it sits in front, transparent to your app code. Streams capture item-level changes and can trigger Lambda functions. Global Secondary Indexes (GSI) can use different partition/sort keys and have their own capacity; Local Secondary Indexes (LSI) share the base table's partition key and must be created at table creation time.

Common mistakes

Don't confuse Lambda timeout (max 15 min) with API Gateway's own 29-second maximum integration timeout - a long Lambda behind API Gateway will still fail after 29 seconds. Don't forget IAM execution roles - Lambda needs a role attached even if it does nothing but write logs. Remember DynamoDB is eventually consistent by default unless you explicitly request strongly consistent reads.

IAM: the foundations

IAM is global, not regional. Every request is evaluated as an explicit DENY beats an explicit ALLOW, which beats the default implicit DENY. New identities have no permissions until a policy grants them.

• Users, groups and roles all attach policies (JSON documents).
• Roles are the exam favourite: they grant temporary credentials via STS (AssumeRole), used for cross-account access, EC2/Lambda execution, and federation. No long-term keys involved.
• Policy types: identity-based (attached to user/group/role), resource-based (attached to the resource, e.g. S3 bucket policy, allows cross-account without a role), and permissions boundaries (cap the maximum permissions an identity can have).
• IAM access keys should be rotated regularly; the exam expects you to know root account keys should never be used day-to-day.

Cognito: user identity for apps

Cognito has two separate pools and mixing them up is the classic trap.

• User Pools: sign-up/sign-in directory. Issues JWTs (ID, access, refresh tokens) after authentication. Supports MFA, hosted UI, social/SAML federation.
• Identity Pools: exchange a token (from a User Pool, Google, Facebook, SAML) for temporary AWS credentials via STS, so the app can call AWS services directly.
• Remember: User Pool = authentication (who are you), Identity Pool = authorization to AWS resources (what can you touch).
• Access tokens from a User Pool expire (default 1 hour); refresh tokens default to 30 days.

KMS: encryption keys

KMS manages Customer Master Keys (CMKs, now called KMS keys) used to encrypt data, never the data itself directly for large payloads.

• Envelope encryption is the pattern: KMS encrypts a data key, the data key encrypts your actual data (get this for any 'large file' question).
• Symmetric CMKs are default and cannot be exported; asymmetric keys exist for sign/verify or encrypt/decrypt outside AWS.
• Key policies (resource-based) control access to a CMK and always take precedence in the evaluation alongside IAM.
• KMS API calls (Encrypt, Decrypt, GenerateDataKey) are logged to CloudTrail — good for audit questions.
• Automatic key rotation is available for symmetric CMKs on a yearly cycle when enabled.

Secrets Manager vs Parameter Store

Both store config, but the exam tests the differences hard.

• Secrets Manager: built-in automatic rotation (via Lambda), charges per secret per month plus API calls, native RDS/Redshift/DocumentDB rotation templates.
• Systems Manager Parameter Store: free tier (standard parameters), no built-in rotation (you'd script it), supports plain strings, string lists, and SecureString (KMS-encrypted).
• SecureString parameters need kms:Decrypt permission as well as ssm:GetParameter.
• Common mistake: assuming Parameter Store rotates secrets automatically — it does not, you must build that yourself.

Common exam traps

• Confusing resource policies (can grant cross-account access directly) with identity policies (cannot, by themselves, grant access to another account's resource).
• Forgetting that STS temporary credentials are short-lived and must be refreshed, not cached forever.
• Thinking Cognito Identity Pools handle sign-in UI — they don't, that's User Pools.

CI/CD on AWS

CI/CD pipelines automate build, test and release so code ships safely and often. The exam leans on three services working together: CodeCommit (or GitHub) for source, CodeBuild for build/test, CodeDeploy for release, all orchestrated by CodePipeline.

CodePipeline basics

• A pipeline is made of stages, and stages contain actions (source, build, test, deploy, approval).
• Stages run sequentially; actions within a stage can run in parallel.
• Add a Manual Approval action to pause a pipeline until a human approves - useful before a production deploy.
• Pipeline changes trigger automatically on a source change (via CloudWatch Events/EventBridge for CodeCommit, or webhooks for GitHub) - it is event-driven, not purely polling by default.
• Artifacts pass between stages via an S3 bucket - CodePipeline needs an S3 artifact store.

CodeBuild

• Defined by a buildspec.yml with phases: install, pre_build, build, post_build.
• Runs in managed, ephemeral containers - you pay per build minute, no servers to manage.
• Can output build artifacts and logs to CloudWatch Logs.

CodeDeploy deployment types

• EC2/On-Premises: uses an AppSpec file (appspec.yml) with hooks like BeforeInstall, ApplicationStop, AfterInstall, ApplicationStart, ValidateService.
• Lambda: deployment configs control traffic shifting - Canary (small % first, then rest after a wait), Linear (steady % increases at intervals), All-at-once.
• ECS: supports Blue/Green deployments via CodeDeploy, shifting traffic between task sets using an ALB.
• CodeDeploy can auto-rollback on CloudWatch alarm breach or deployment failure.

Elastic Beanstalk

• PaaS: upload code (or a Docker image), Beanstalk provisions EC2, ASG, ELB, and RDS (optional) for you - you don't manage the underlying resources directly.
• Deployment policies: All at once (fastest, downtime), Rolling (batches, reduced capacity), Rolling with additional batch (no capacity loss, launches extra batch first), Immutable (new ASG entirely, safest, slowest, easy rollback), Traffic Splitting (canary-style, % of traffic to new version).
• Configuration lives in .ebextensions/*.config files (YAML/JSON) inside your app bundle, applied in alphabetical order.
• Environments: separate Web Server (fronts an ALB) vs Worker (polls an SQS queue) environment tiers.
• Beanstalk is NOT for zero-downtime by default with All-at-once - pick Immutable or Traffic Splitting when zero downtime matters.

Common exam traps

• CodeDeploy needs an IAM service role AND an appspec.yml at the root of the deployment bundle - a missing appspec.yml fails deployment.
• Blue/Green on EC2 needs an ASG and ELB; on Lambda it's really traffic shifting between versions/aliases, not separate EC2 fleets.
• Beanstalk swap environment URLs (CNAME swap) gives a near-zero-downtime blue/green style cutover between two full environments.

CloudWatch: metrics, alarms and logs

CloudWatch is the default monitoring backbone for AWS. Every service pushes metrics automatically at 5-minute intervals (standard resolution). Enable Detailed Monitoring on EC2 to get 1-minute granularity - this costs extra and is NOT on by default.

Custom metrics are published with PutMetricData. You can go below 1 minute using High-Resolution metrics (down to 1 second), but this needs the StorageResolution parameter set to 1.

Metric retention matters for the exam

• Data at 1-second resolution is kept for 3 hours
• 1-minute data points are kept for 15 days
• 5-minute data points are kept for 63 days
• 1-hour data points are kept for 15 months

CloudWatch automatically 'rolls up' older data to coarser resolution - it does not delete it early.

Alarms

An alarm watches a single metric (or a metric math expression) over a number of evaluation periods and moves between OK, ALARM and INSUFFICIENT_DATA states. Composite alarms combine multiple alarms with AND/OR logic. Alarms can trigger SNS notifications, Auto Scaling actions, or EC2 actions (stop, terminate, reboot, recover).

Logs

CloudWatch Logs organises data into Log Groups then Log Streams. Set retention per log group (default is Never Expire, which quietly costs money forever - a classic gotcha). Use Metric Filters to turn log patterns (like ERROR strings) into numeric CloudWatch metrics you can alarm on. Subscription Filters stream logs in near real time to Lambda, Kinesis or OpenSearch for further processing. CloudWatch Logs Insights lets you query log data with its own query language without building a pipeline first.

CloudWatch Events / EventBridge

EventBridge (the evolution of CloudWatch Events) reacts to AWS service state changes or scheduled rules (cron/rate expressions) and routes them to targets like Lambda or SNS.

X-Ray for distributed tracing

X-Ray traces a request as it moves through microservices, showing a service map and latency breakdown per hop (called segments and subsegments). You must install the X-Ray daemon (or use the built-in agent on Lambda) and instrument your code with the X-Ray SDK. Annotations are indexed key-value pairs you can filter traces by; metadata is not indexed and is for extra context only. Sampling defaults to recording the first request each second plus 5% of additional requests - tune this with sampling rules to control cost.

Common exam traps

• Detailed Monitoring (1-min) is opt-in and chargeable, not default
• Metric filters count matching log LINES, they don't parse arbitrary JSON structure without a defined pattern
• X-Ray needs IAM permissions (xray:PutTraceSegments) even inside Lambda
• Annotations are searchable, metadata is not - mixing these up is a favourite distractor

Why this topic matters

DVA-C02 tests whether you can spot performance and cost problems in code and infrastructure, then fix them using the right AWS feature rather than brute-force scaling. Exam questions usually describe a slow, expensive, or throttled app and ask what change fixes it cheapest/fastest.

Lambda optimisation

• Increasing memory also increases proportional CPU and network - a common fix for slow functions is simply raising memory, not just code changes.
• Provisioned Concurrency removes cold starts by keeping execution environments warm - use for latency-sensitive APIs.
• Keep the handler lean: initialise SDK clients and DB connections OUTSIDE the handler function so they persist across warm invocations.
• Lambda SnapStart (Java, and now other runtimes) caches a snapshot of an initialised execution environment to cut cold-start time drastically.
• Use environment variables and Lambda layers to share code/dependencies instead of duplicating in every deployment package - smaller packages deploy and cold-start faster.

DynamoDB optimisation

• Design partition keys for even distribution - hot partitions throttle throughput even under provisioned capacity.
• Use DynamoDB Accelerator (DAX) for microsecond read caching in read-heavy workloads.
• Switch to on-demand capacity mode for unpredictable traffic; use provisioned with auto scaling for steady, predictable traffic - cheaper at scale.
• Batch operations (BatchGetItem, BatchWriteItem) reduce round trips versus single-item calls.
• Use sparse indexes and projections to avoid pulling unnecessary attributes.

Caching layers

• ElastiCache (Redis/Memcached) offloads repeated reads from RDS/DynamoDB - biggest win for read-heavy relational workloads.
• CloudFront caches at edge locations, cutting origin load and latency for static and semi-static content; use cache behaviours and TTLs per path pattern.
• API Gateway has its own response caching (per stage, TTL configurable 0-3600s) - reduces backend Lambda/API invocations for repeated identical requests.

Code-level and messaging optimisation

• Use SQS to decouple and buffer bursty workloads so downstream services process at their own pace - prevents overload rather than requiring bigger instances.
• Use asynchronous invocation or Step Functions for long-running workflows instead of synchronous blocking calls.
• X-Ray traces reveal exactly which downstream call or segment is the bottleneck - always the first tool the exam expects you to reach for when diagnosing 'why is this slow'.
• CloudWatch Lambda Insights and Application Signals give system-level metrics (memory used vs allocated, cold start counts) to right-size functions.

Common mistakes

• Assuming more compute always fixes it - often it is a hot partition key or missing cache, not raw power.
• Forgetting SDK client re-use across invocations, causing needless re-initialisation cost on every warm call.
• Ignoring API Gateway/CloudFront caching and hitting the backend for identical repeated GET requests.
• Using on-demand DynamoDB for steady, predictable heavy traffic where provisioned + auto scaling is cheaper.