DVA-C03 troubleshooting and optimization
Troubleshooting and Optimization is 22% of DVA-C03, up from 18% on the outgoing DVA-C02 and now level with Testing and Deployment. It tests how a developer finds out why an application misbehaves and how to make it faster or cheaper without breaking it. Questions describe a symptom, such as throttling, latency or a message processed twice, and ask for the service feature that reveals the cause or removes the bottleneck. The AWS exam guide splits it into three tasks: assist in a root cause analysis (4.1), apply logging, monitoring and observability best practices (4.2) and optimize applications (4.3).
What the domain is about
| Area | What to reason about |
|---|---|
| Logs | CloudWatch Logs, metric filters, Logs Insights queries, structured JSON logging |
| Metrics and alarms | Built-in and custom metrics, embedded metric format, alarms and actions |
| Tracing | AWS X-Ray segments, subsegments, annotations, metadata, sampling, the service map |
| Lambda tuning | Memory (which also scales CPU), timeouts, reserved and provisioned concurrency, cold starts |
| Data layer | DynamoDB throttling, hot partitions, backoff, caching with DAX (see DAX basics) |
| Caching and delivery | API Gateway caching, CloudFront, ElastiCache |
| Failure handling | Retries, dead-letter queues, visibility timeouts |
| Health and alerts | Application health checks, liveness and readiness probes for containers, alarms on quota limits and deployment completion |
| Concurrency in code | Connection pooling, thread pool management, EC2 Auto Scaling |
AWS says observability skills are consolidated from 8 into 5, and optimisation skills from 9 into 6. Lambda performance tuning moved into this domain (Task 4.3). The guide adds AI tools for analysing errors and generating troubleshooting suggestions (skill 4.1.5) and for finding optimisation opportunities (skill 4.3.6); the exam treats these as tools to use, not as a substitute for understanding the evidence they summarise.
| Task | Skills AWS lists, in short |
|---|---|
| 4.1 Root cause analysis | Debugging code and service integrations, interpreting metrics, logs and traces, querying logs, troubleshooting deployment failures from output logs, AI tools for error analysis |
| 4.2 Logging and observability | Structured logging, code that emits custom metrics, notification alerts (quota limits, deployment completions), tracing, workload health (application health checks, liveness and readiness probes) |
| 4.3 Optimization | Concurrency (provisioned concurrency, EC2 Auto Scaling, thread pools, connection pooling), memory and compute, messaging (SQS, SNS fan-out), caching (ElastiCache, DAX, CloudFront), bottleneck detection with CloudWatch, AI tools for optimisation |
How to think about it
Work from evidence to cause. Metrics tell you that something is wrong and roughly when. Logs tell you what the code reported. Traces tell you where one request spent its time. A slow API can only be pinned to one downstream call with a trace, because averages hide the outliers.
X-Ray annotations are key-value pairs that are indexed, so traces can be filtered by them (for example a customer tier). Metadata is not indexed and is meant for extra detail. Instrumenting an AWS SDK client adds subsegments for each downstream call.
Lambda has three separate levers that are often confused. Memory sets CPU proportionally, so a CPU-bound function can get faster and sometimes cheaper with more memory. Reserved concurrency guarantees a function a share of the account limit and caps it at that share. Provisioned concurrency keeps initialised execution environments ready to remove cold-start latency. A throttled invocation returns a 429 error for synchronous calls; asynchronous ones are retried by the service.
DynamoDB throttling usually means either insufficient capacity or an uneven key distribution. The SDK retries with exponential backoff and jitter; the fix for a hot key is better key design, and the fix for a read-heavy, repeated-read workload is a cache. DAX is an in-memory cache compatible with the DynamoDB API, so it needs few code changes compared with building cache-aside logic on ElastiCache.
Worked mini-scenario
Users report that an order API is fast most of the time, but about one request in fifty takes several seconds. The API runs on API Gateway, Lambda and DynamoDB. CloudWatch shows an acceptable average latency.
Reasoning: averages hide the tail, so look at percentile metrics and, for a single slow request, an X-Ray trace. Active tracing on the function and the SDK instrumentation show whether time went to initialisation (a cold start), to a DynamoDB call (a throttled read retried with backoff) or to another dependency. If the trace shows initialisation, provisioned concurrency or smaller dependencies address it. If it shows DynamoDB retries, check for throttled-request metrics and hot keys. Raising the API timeout or the memory without the trace would be guesswork.
Easy-to-confuse pairs
| Pair | Distinction |
|---|---|
| CloudWatch versus X-Ray | Metrics and logs per resource versus the path of one request across services |
| Annotation versus metadata | Indexed and searchable versus not indexed |
| Reserved versus provisioned concurrency | Guaranteed share and cap versus pre-initialised environments |
| Logs Insights versus metric filter | Ad hoc queries over stored logs versus turning matching log lines into a metric |
| DAX versus ElastiCache | Drop-in DynamoDB cache versus a general cache you manage in code |
| Visibility timeout versus function timeout | Queue-side hiding period versus the maximum run time of the function |
| Throttling (429) versus timeout | The service refused the call versus the call ran too long |
An exam-style pitfall
When a function fails intermittently, the tempting answer is to raise the timeout or memory. The question usually contains a detail that points elsewhere: a timeout shorter than the downstream call, a queue visibility timeout shorter than the function timeout (which causes duplicate processing), or an error only for some customers, which calls for annotations and filtering. Identify the symptom type first, then choose the tool.
Own scenario questions
Question 1. A team traces requests with X-Ray and needs to find all traces for customers on the premium tier. What should the code add to each trace?
- A. Metadata with the customer tier
- B. A log line containing the tier
- C. A tag on the Lambda function
- D. An annotation with the customer tier
Show answer
Answer: D
Annotations are indexed key-value pairs, so traces can be filtered by them. Metadata is stored but not indexed, and log lines or tags on the function do not make individual traces searchable.
Want more questions like this? Full DVA-C03 practice tests →
Question 2. A rarely called, user-facing Lambda function shows several seconds of added latency on the first request after idle periods. What reduces this latency?
- A. Set reserved concurrency to 1
- B. Configure provisioned concurrency
- C. Increase the function timeout
- D. Put DAX in front of the table
Show answer
Answer: B
Provisioned concurrency keeps execution environments initialised, removing cold-start delay. Reserved concurrency guarantees capacity but does not pre-initialise environments, and a longer timeout or a table cache does not change start-up time.
Want more questions like this? Full DVA-C03 practice tests →
Question 3. A product page reads the same few hot items from DynamoDB thousands of times per second. Read throttling occurs and the team wants microsecond reads with minimal code changes. What should they do?
- A. Add a global secondary index
- B. Increase the write capacity units
- C. Put DAX in front of the table
- D. Build a custom cache-aside layer on ElastiCache
Show answer
Answer: C
DAX is an in-memory write-through cache that is API-compatible with DynamoDB, so the application changes mainly the client endpoint. A new index, more write capacity or a custom cache layer either miss the problem or need more code.
Want more questions like this? Full DVA-C03 practice tests →
Where to go next
The domain pages together cover the four weights: development, security, testing and deployment and this one. The study plan schedules them, and is DVA-C03 hard says where candidates struggle.