AWS Certified Developer - Associate (DVA-C02) #13 Domain 4-2 Troubleshooting and Optimization — Optimization and Problem Solving
In #12 Observability we covered how to see what’s happening. The last post is about how to improve it and resolve common errors. Along with performance,cost optimization, the exam asks for the ability to interpret specific error codes.
Caching Layers #
If you repeatedly read the same data, a cache reduces latency,cost,backend load. Which layer the cache sits at is the key distinction.
| Cache | Location | Use |
|---|---|---|
| CloudFront | Edge (worldwide) | CDN for static,dynamic content |
| API Gateway cache | API stage | REST API response caching |
| ElastiCache | Application layer | General-purpose in-memory cache in front of a DB (Redis/Memcached) |
| DAX | In front of DynamoDB | DynamoDB-specific microsecond cache |
- “Deliver static assets quickly to users worldwide” → CloudFront.
- “Cache the results of repeated relational-DB queries” → ElastiCache.
- “DynamoDB reads at microseconds” → DAX.
- “Reduce repeated calls of the same API Gateway response” → API Gateway cache.
Caching Strategies #
- Lazy Loading (Cache-Aside) — If it’s not in the cache, read from the DB and fill it. Data that’s never used isn’t cached.
- Write-Through — Update the cache as well when writing. Always fresh, but it also caches data that won’t be read.
- TTL — Prevents stale data via expiration.
Lambda Performance Tuning #
| Knob | Effect |
|---|---|
| Memory setting | Raising memory increases CPU,network proportionally. Often more memory is cheaper and faster |
| Cold start | Provisioned concurrency, reuse initialization outside the handler |
| Concurrency | Isolate with reserved concurrency, prevent throttling |
| Package size | Keep it small, separate dependencies into layers |
Exam key: Lambda sets memory only, and CPU scales proportionally. The answer to “it’s slow because CPU is insufficient” is raising memory. Use Lambda Power Tuning to find the cost,performance sweet spot.
Frequently Appearing Error Codes #
The troubleshooting domain poses questions that infer the cause from an error code. Memorize them and you can answer instantly.
| Code | Meaning | Response |
|---|---|---|
| 429 Too Many Requests / ThrottlingException | Throttling (API Gateway,SDK,service limit) | Exponential backoff retry, raise the limit |
| ProvisionedThroughputExceededException | DynamoDB capacity exceeded | Raise capacity,distribute keys,backoff |
| 502 Bad Gateway | API GW proxy-integration Lambda response format error | Fix the response statusCode/body format |
| 504 Gateway Timeout | Integration timeout (29 seconds) exceeded | Shorten processing,async pattern |
| 403 / AccessDenied | Insufficient permission | Check IAM policy,resource policy |
| ConditionalCheckFailedException | Conditional-write condition mismatch | Optimistic-lock conflict → retry |
| ProvisionedConcurrency / TooManyRequestsException(Lambda) | Concurrency limit exceeded | Adjust reserved/account limits |
A few key mappings:
- 502 = Lambda response format problem (a wrong return in proxy integration).
- 504 = took too long (29-second integration timeout).
- 429 = throttling → exponential backoff.
- ConditionalCheckFailed = concurrent-modification conflict → retry.
Cost Optimization Points #
- Right-size Lambda memory — Too small is slow and thus more expensive; too large is waste. Find the sweet spot with Power Tuning.
- DynamoDB capacity mode — If traffic is intermittent, on-demand; if predictable, provisioned + Auto Scaling.
- S3 lifecycle + storage classes — Move old data to cheaper tiers.
- Caching — Reduces backend-call,data-transfer cost.
Exam question patterns #
- “Lambda is slow and CPU is insufficient.” → Raise memory (CPU scales proportionally).
- “Getting 502 from the API.” → Proxy-integration Lambda response format.
- “Getting 504 from the API.” → 29-second timeout exceeded, shorten processing/make async.
- “Throughput exceeded on DynamoDB reads.” → Capacity,key distribution,backoff.
- “A conditional update fails.” → Concurrent-modification conflict, retry.
- “Repeated DynamoDB reads at microseconds.” → DAX.
- “Reduce latency for worldwide static content.” → CloudFront.
- “How to handle throttling (429).” → Exponential backoff retry.
Common traps #
1) Trying to set Lambda CPU directly #
CPU can’t be set directly. It scales with memory.
2) Confusing 502 and 504 #
502 is a response format error, 504 is a timeout.
3) Confusing cache layers #
DynamoDB-specific is DAX, general-purpose is ElastiCache, edge is CloudFront.
Wrap-up #
What this post locked in:
- Caching — CloudFront (edge),ElastiCache (general),DAX (DynamoDB),API GW cache. Lazy Loading vs Write-Through
- Lambda is memory = CPU. If slow, raise memory
- Error codes — 502 (response format),504 (timeout),429 (throttling),ConditionalCheckFailed (concurrent conflict)
- Cost — right-size memory, capacity mode, lifecycle, caching
Next — Exam Tips #
With thirteen posts, we’ve gone once around the four domains. In #14 Exam Tips, I’ll cover time management, how to filter answer choices with constraint keywords, frequently confused concept pairs, and a just-before-the-exam checklist.