Root cause analysis: DVA-C03 study notes and practice questions
What to know about Root cause analysis for the DVA-C03 exam, from the Troubleshooting and Optimization domain (22% of the exam guide), then 1 free question to test it. Part of the DVA-C03 study guide.
These questions give you a symptom, such as HTTP 429, a 502 or a slowdown, and ask where to look next. The skill is matching the symptom to the right signal, then to the right tool.
Reading the three signals
Metrics show when and how much: a spike in throttles, an iterator age that grows, or concurrency flat at a limit.
Logs show what the code did: an exception, an AccessDenied, or a return value in the wrong shape.
Traces show where the time went: which downstream call was slow.
Start with the metric that matches the symptom, find the matching log events, then open the trace for one slow request.
Matching symptoms to causes
HTTP 429 or TooManyRequestsException with no function logs: the request was throttled before the code ran. Check concurrency limits, not the code.
A 502 from a Lambda proxy integration: the function ran, but its response was not in the format API Gateway expects.
A 500 from an API Gateway Lambda integration: API Gateway may lack permission to invoke the function. Check the function’s resource-based policy.
AccessDenied in a function’s log: read the role ARN in the error, then check the role’s policy and any resource policy.
Deployment failed: open the CloudFormation stack events and find the first CREATE_FAILED or UPDATE_FAILED event. Its status reason names the cause. Later rollback events are a result.
Build or deploy script failed: read the CodeBuild build log, or the CodeDeploy deployment and agent logs on the instance.
Who changed what
CloudTrail records API calls. Management events show who changed a resource, such as a table’s capacity, but the event history covers only recent events, so create a trail for longer retention. Item-level DynamoDB calls, such as PutItem, are data events that you must turn on separately. Without a trail, you cannot answer who made a change weeks ago.
AI-assisted investigation
CloudWatch investigations: starts from an alarm and uses telemetry to suggest likely causes.
Diagnose with Amazon Q in the console: explains an error shown in a console, such as a permissions error, and suggests a fix.
CloudWatch Logs anomaly detection: learns the normal patterns in a log group and flags unusual ones, so you do not write a query for each new error.
These tools suggest; you still confirm the cause with logs and traces.
How to choose
Scenario wording
Answer
“throttled, function logs empty”
Concurrency and throttle metrics
“502 after a refactor”
Compare the returned value with the expected proxy response format
“who changed the table capacity”
CloudTrail trail with management events
“which role wrote each item”
CloudTrail data events for DynamoDB
“find unusual new log errors”
CloudWatch Logs anomaly detection
Common traps
Blaming the code for a throttle. Throttled requests never reach it.
Reading the rollback and missing the first failed resource.
Expecting event history to answer for a change made before any trail existed.
On Monday, the orders-prod DynamoDB table began throttling after its provisioned capacity was changed.
No one on the team remembers making the change, and no trail has been created. The change was made 12 days ago. The developer wants to find the user or role that made the change and the time it was made.
Where should the developer look?
Choose one answer.
AA. The table's CloudWatch metrics, which show consumed capacity by hour.
BB. CloudTrail event history, filtered to the UpdateTable event for the table's ARN.
CC. The table's DynamoDB Streams records, which show each change made to the table's settings.
DD. The application's X-Ray traces, which show each DynamoDB call the application made.
Show the answer and explanation
Answer: B
A. Wrong: Metrics show how much capacity was used and when, but not who changed the table's settings or which API call made the change.
B. Right: Correct. Event history keeps the past 90 days of management events in the Region, and a table update is a management event. Filtering by UpdateTable shows the caller's identity and the time of the call, without a trail. Learn more: Working with CloudTrail event history (opens in a new tab)
C. Wrong: DynamoDB Streams records changes to items in a table, not changes to its capacity or other settings. It cannot show who changed the settings.
D. Wrong: X-Ray traces show the application's DynamoDB calls and their timing. They do not record who changed the table's configuration.
Explanation
CloudTrail event history is on by default and shows management events from the past 90 days in each Region, without any trail. A table update is recorded with the caller, the time and the API name, so it answers who and when. Metrics, streams and traces do not record configuration changes.
Want more on Root cause analysis? The 5 full-length practice sets have 14 more Root cause analysis questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →