AWS DVA · Domain 4 of 4

AWS DVA Domain 4: Troubleshooting and Optimization

This domain covers finding and fixing problems and improving performance: root-cause analysis with logs and tracing, instrumenting code for observability with CloudWatch and X-Ray, and optimizing applications.

Exam format
18%
Official tasks
3
Assessment estimate
~9
Suggested study time estimate
15–20 hrs

About 9 min read Reviewed October 2026

Overview

Troubleshooting and Optimization covers diagnosing failures and improving application performance. It has three tasks. Root-cause analysis covers reading logs and traces to find why something failed, interpreting error codes and exceptions, and using CloudWatch and CloudTrail. Instrumenting code for observability covers structured logging, custom CloudWatch metrics including embedded metric format, and distributed tracing with AWS X-Ray. Optimizing applications covers caching, concurrency and memory tuning, reducing latency, and using AWS features to improve performance.

At 18%, this is the smallest domain, but it becomes much easier when treated as reading failure clues rather than random debugging. The exam rewards knowing which observability tool reveals which problem, how X-Ray traces a request across services, and how to instrument and optimize code. These skills build on the applications developed and deployed in the earlier domains.

How it's tested

DVA-C02 questions describe a failure symptom, an error or a performance problem and ask how to diagnose or improve it. This domain rewards choosing the right observability tool and the correct optimization. Read the symptom carefully, since it points to the tool and the fix.

  • Read the failure clue

    A symptom or error code is described, and you choose the log, trace or metric that reveals the cause.

  • Instrument for observability

    A visibility gap is described, and you choose structured logging, custom metrics or X-Ray tracing.

  • Optimize the application

    A performance problem is described, and you choose caching, tuning or a service feature to improve it.

Reasoning it through

A request passes through API Gateway, a Lambda function and DynamoDB, and is intermittently slow, but the logs do not show where the time goes. Scanning logs alone cannot isolate the slow hop. AWS X-Ray traces the request across all three services and shows the latency of each segment, pinpointing which component is slow, which is the observability tool the exam expects for distributed performance problems.

Tasks 3

Official tasks from the Amazon Web Services outline, in outline order.

4.1 Assist in a root cause analysisReading logs and traces, error codes, and using CloudWatch and CloudTrail.
What it means
This covers finding why a problem occurred: reading CloudWatch Logs and querying with Logs Insights, interpreting error codes, status codes and exceptions, using CloudTrail to trace API activity, and correlating signals to identify the root cause.
What to understand
Root-cause analysis is systematic: the error code or symptom points to a layer, and logs, traces and API history confirm the cause. HTTP and service error codes carry meaning, such as throttling or permission errors. Correlating logs with traces and metrics isolates the fault.
How it shows up
A failure symptom or error code is described, and you must choose the diagnostic source or interpret the error.
Common confusion
Confusing a client error such as a 4xx with a server error such as a 5xx; they point to different causes.
4.2 Instrument code for observabilityStructured logging, custom CloudWatch metrics, and X-Ray tracing.
What it means
This covers instrumenting applications for observability: structured logging, custom CloudWatch metrics including the embedded metric format, CloudWatch Logs and dashboards, and distributed tracing with AWS X-Ray to follow requests across services.
What to understand
Structured logs are machine-parseable and queryable. Custom metrics track application-specific signals, and the embedded metric format emits metrics from log data efficiently. X-Ray traces a request end to end across services and shows per-segment latency and errors, which plain logs cannot.
How it shows up
A visibility gap is described, and you must choose structured logging, custom metrics or X-Ray.
Common confusion
Expecting logs alone to reveal cross-service latency; X-Ray traces the full request path.
4.3 Optimize applications by using AWS services and featuresCaching, concurrency and memory tuning, and latency reduction.
What it means
This covers improving application performance: caching with ElastiCache, DAX or CloudFront, tuning Lambda memory and concurrency, optimizing database access, reducing latency, and using AWS features to improve throughput and efficiency.
What to understand
Optimization matches resources and patterns to the workload: caching reduces repeated work and latency, raising Lambda memory can speed execution by adding CPU, and provisioned concurrency cuts cold starts. Reducing unnecessary calls and payload sizes also helps. Monitoring data drives these choices.
How it shows up
A performance problem is described, and you must choose the caching, tuning or service feature that improves it.
Common confusion
Scaling infrastructure instead of caching or tuning the application where that would fix the performance problem.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • CloudWatch Logs and Logs Insights

    Centralized logs and a query tool.

    Remember
    Logs Insights queries log content.
    Tested as
    Diagnosis questions.
    Trap
    Expecting logs to show cross-service latency.

  • AWS X-Ray

    Distributed tracing across services.

    Remember
    It shows per-segment latency and errors.
    Tested as
    Tracing questions.
    Trap
    Using logs alone for distributed latency.

  • Error code interpretation

    HTTP and service codes indicate the cause.

    Remember
    4xx is client error, 5xx is server error.
    Tested as
    Root-cause questions.
    Trap
    Confusing client and server errors.

  • Throttling errors

    Signals of exceeding a limit or capacity.

    Remember
    They point to capacity or rate issues.
    Tested as
    Diagnosis questions.
    Trap
    Mistaking throttling for a bug.

  • Structured logging

    Machine-parseable, queryable log output.

    Remember
    It makes logs searchable.
    Tested as
    Observability questions.
    Trap
    Logging unstructured text.

  • Custom metrics and EMF

    Application metrics, emitted efficiently via embedded metric format.

    Remember
    They track app-specific signals.
    Tested as
    Observability questions.
    Trap
    Relying only on default metrics.

  • Caching for performance

    ElastiCache, DAX or CloudFront reduce repeated work.

    Remember
    Caching cuts latency and load.
    Tested as
    Optimization questions.
    Trap
    Scaling instead of caching.

  • Lambda tuning

    Memory scales CPU; provisioned concurrency cuts cold starts.

    Remember
    Tuning improves latency and cost.
    Tested as
    Optimization questions.
    Trap
    Ignoring memory's effect on CPU.

  • Latency reduction

    Fewer calls, smaller payloads, closer data.

    Remember
    Reduce round trips and payload size.
    Tested as
    Optimization questions.
    Trap
    Over-fetching data.

  • CloudWatch alarms and dashboards

    Alert on thresholds and visualize metrics.

    Remember
    They surface problems proactively.
    Tested as
    Monitoring questions.
    Trap
    Only reacting after failures.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

CloudWatch Logs vs. X-Ray vs. metrics

ConceptMeaningKey differenceCommon trap
CloudWatch Logs Application log content What the code logged Expecting cross-service latency
X-Ray Distributed request traces Per-segment latency and errors Using logs for the full path
Metrics Numerical trends and alarms Trends over time Expecting detailed per-request causes

4xx vs. 5xx errors

ConceptMeaningKey differenceCommon trap
4xx client error Caused by the request Fix the client or input Treating it as a server fault
5xx server error Caused by the service or backend Fix the service side Treating it as a client fault

Scale vs. cache vs. tune

ConceptMeaningKey differenceCommon trap
Scale infrastructure Add capacity Handles more load Using it where caching fits
Cache Reuse results Cuts repeated work and latency Scaling instead of caching
Tune Adjust memory, concurrency, payloads Improves efficiency Ignoring configuration tuning

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Logs for distributed latency

    What candidates pick
    Scan CloudWatch Logs to find which service in a chain is slow.
    Why it looks right
    Logs contain timing information.
    Why it's wrong
    X-Ray traces the request across services and shows per-segment latency, which scattered logs cannot.

    Clue to watch for The slowness spans multiple services.

  2. 4xx is a server bug

    What candidates pick
    Investigate the backend for a persistent 4xx error.
    Why it looks right
    Any error could be server-side.
    Why it's wrong
    A 4xx is a client error caused by the request; a 5xx indicates a server-side fault.

    Clue to watch for The error code is in the 4xx range.

  3. Scale for repeated reads

    What candidates pick
    Add database capacity to handle repeated identical reads.
    Why it looks right
    More capacity handles more load.
    Why it's wrong
    Caching with DAX, ElastiCache or CloudFront serves repeated reads far more efficiently.

    Clue to watch for The same data is read repeatedly.

  4. Ignore memory for CPU

    What candidates pick
    Leave Lambda memory low while trying to speed up CPU-bound code.
    Why it looks right
    Memory seems unrelated to CPU.
    Why it's wrong
    Lambda memory also scales CPU, so raising it can speed execution.

    Clue to watch for A CPU-bound function is too slow.

  5. Unstructured logs

    What candidates pick
    Log plain unstructured text and query it later.
    Why it looks right
    It is quick to write.
    Why it's wrong
    Structured logging makes logs machine-parseable and queryable, which speeds root-cause analysis.

    Clue to watch for Logs must be searched and analyzed efficiently.

Answer framework

For any Domain 4 scenario, use these steps to find the answer DVA-C02 expects.

  1. Read the failure clue first: the error code or symptom points to the layer and the likely cause, treating diagnosis as systematic clue-reading rather than guesswork.
  2. For cross-service latency or errors, use X-Ray tracing; for application detail, use CloudWatch Logs and Logs Insights.
  3. Interpret error codes correctly, distinguishing client 4xx from server 5xx and recognizing throttling.
  4. Instrument code with structured logging, custom metrics and tracing so future problems are diagnosable.
  5. For performance, prefer caching and tuning, such as Lambda memory and concurrency, over simply scaling, and document the improvement. Where two options seem to fit, pick the one that most precisely matches the behavior the scenario requires.

Practice question

A request flows through API Gateway, a Lambda function and DynamoDB and is intermittently slow. The developer cannot tell from the logs which component causes the delay. Which AWS service BEST identifies the slow component?

Want more like this? The AWS DVA practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Reframe this domain from debugging to reading clues, which is how the exam treats it. Practice mapping a symptom or error code to the right tool: application detail to CloudWatch Logs, cross-service latency to X-Ray, and trends to metrics. Learn what common error codes mean, especially the 4xx-versus-5xx distinction and throttling.

Next, learn to instrument code for observability: structured logging, custom metrics and the embedded metric format, and X-Ray tracing, so problems are diagnosable before they happen. Then study optimization: caching with DAX, ElastiCache and CloudFront, Lambda memory and concurrency tuning, and reducing latency, preferring these over simply scaling.

Although this is the smallest domain, do not skip it, since questions blend it with the others. Hands-on practice adding X-Ray to an app and querying logs cements it. This is the final domain, so finish with full practice tests spanning all four. Hands-on coding against the AWS SDK in a free-tier account cements these developer patterns far faster than reading, and reviewing missed practice questions by domain shows where to focus next.

FAQ

How much of DVA-C02 is Domain 4?

Troubleshooting and Optimization is 18% of the scored content, the smallest domain, but it blends with the others.

When should I use X-Ray instead of logs?

When you need to see how a single request flows across multiple services and where its latency or errors occur. Logs show per-service detail but do not stitch the full request path.

What is the difference between a 4xx and a 5xx error?

A 4xx is a client error caused by the request, such as bad input or missing permissions. A 5xx is a server-side error in the service or backend.

How do I improve performance for repeated reads?

Add caching with DAX for DynamoDB, ElastiCache for general data, or CloudFront for content, rather than scaling the backend to handle repeated identical reads.

How does tuning Lambda memory help?

Lambda memory also scales CPU, so increasing memory can reduce execution time for CPU-bound functions, and provisioned concurrency reduces cold-start latency.

What is structured logging?

Emitting logs in a machine-parseable format so they can be queried and analyzed efficiently, which speeds root-cause analysis.

How does Domain 4 connect to the rest of the exam?

It observes and optimizes the applications built in Domain 1, secured in Domain 2 and deployed in Domain 3, closing the application lifecycle.

Other Cloud Computing certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 4 knowledge

You have covered root-cause analysis, observability and optimization. Test whether you can read the failure clue and pick the right tool or fix under exam conditions.

Take the AWS DVA practice test Check your AWS DVA readiness

Keep going