Troubleshooting and Optimization

Troubleshooting and Optimization is the smallest DVA-C02 domain (18% of the exam, versus 32% for Development with AWS Services), yet its three subtopics describe one continuous loop rather than three separate skills. First you instrument the code so it emits signal (Code Observability); then, when something is wrong, you read that signal to find the fault (Root Cause Analysis); and once the signal also tells you where time, money, or capacity is being wasted, you tune the application against a measured baseline (Application Optimization). The loop only closes if step one happened: code that emits nothing can be neither diagnosed nor optimized. Read the domain in that order: instrumentation is the prerequisite for the other two, not a peer of them.

Code Observability and Root Cause Analysis use the same four AWS services but from opposite ends. Observability is the emit side: the developer's job of producing signal, writing structured JSON logs with a correlation ID, publishing custom metrics (EMF or the PutMetricData API), and instrumenting requests with the AWS X-Ray SDK so each call becomes a traceable subsegment. Root cause analysis is the read side: querying that signal during an incident, CloudWatch Logs Insights over the logs, the X-Ray service map over the traces, CloudWatch alarms over the metrics. When an exam question hinges on a code change ("how should the function record this?"), it is an observability question; when it hinges on interpreting evidence ("which signal tells you why it failed?"), it is a root-cause question. Same services, different verb.

Every troubleshooting question on this exam ultimately picks among four AWS signals, and the distractor is almost always the signal that answers the wrong question. CloudWatch Logs answer "what exactly happened in this one request?" (per-event detail). CloudWatch metrics answer "how much, how often, is it trending?" (numeric aggregates and alarms). AWS X-Ray answers "where in the call chain did latency or errors accumulate?" (the service map across hops). CloudTrail answers "who called which AWS API, when, from where?" (the control-plane audit trail), and the classic trap is reaching for CloudTrail to debug application logic, which it never records. Decide what the question is asking before choosing the service; the four are complementary, not interchangeable.

Optimization in this domain is evidence-driven, never speculative: the observability and root-cause work is what turns "the app feels slow" into a specific, measured bottleneck worth fixing. Once a baseline exists, the exam's preferred levers run cheapest-and-least-invasive first: cache an expensive result before scaling the backend, cut chattiness (batch DynamoDB calls, page instead of scan, let the SDK back off on throttles) before adding capacity, and right-size the one dial that matters for Lambda (memory, which also sets CPU) using measured duration rather than a guess. The same telemetry then confirms the change helped, which feeds the next pass of the loop. Optimizing without a measured baseline is guessing, and the exam rewards the answer grounded in data.