Course menuDVA-C03

Exams / DVA-C03 / Study guide / Logging and CloudWatch Logs Insights

Logging and CloudWatch Logs Insights: DVA-C03 study notes and practice questions

What to know about Logging and CloudWatch Logs Insights for the DVA-C03 exam, from the Troubleshooting and Optimization domain (22% of the exam guide), then 3 free questions to test it. Part of the DVA-C03 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

These questions ask how to make logs useful: write them in a form you can query, keep only the detail you need, and search the right log groups.

Structured JSON logging

Write one JSON object per line, with fields such as level, orderId and message. Each field can be filtered in Logs Insights with no parsing, so filter level = "ERROR" works directly. Plain text such as charge failed errorCode=CardDeclined needs a parse step in every query, and the pattern breaks when someone changes the wording.

Lambda log format and levels

Lambda’s advanced logging controls set the log format (Text or JSON) and two levels:

  • ApplicationLogLevel: TRACE, DEBUG, INFO, WARN, ERROR or FATAL. A setting sends its own level and every less detailed level, so WARN sends WARN, ERROR and FATAL.
  • SystemLogLevel: DEBUG, INFO or WARN. It controls Lambda’s own lifecycle lines.

The default format is plain text, and level filtering works only with JSON. Switching to JSON sets both levels to INFO unless you change them.

To stop paying for DEBUG lines, raise the application level in the console and in the code. Retention is a separate setting on each log group, so keep it short (for example 30 days) to cap storage.

Logs Insights queries

  • Several log groups: one query can read up to 50 log groups. Use this to follow a request across orders-api and orders-worker, filtering on a field both sides share, such as an order ID.
  • Counting in intervals: filter to the events, then use stats count(*) by bin(5m) to count per five-minute bucket.
  • Natural-language query generator: in the console you describe the data in plain words, and it writes a Logs Insights QL query and explains each line. Review it before you rely on it.
  • Limits: a query times out after 60 minutes, and results are kept for 7 days.

How to choose

Scenario wording Answer
“count errors per five minutes” stats count(*) by bin(5m) in Logs Insights
“search two functions’ logs at once” Select both log groups in one query
“stop DEBUG lines being stored” Raise ApplicationLogLevel, and check code-level settings
“keep logs for 30 days” Set retention on the log group
“describe the query in words” The natural-language query generator
“watch log events as they arrive” Live Tail
“events in near real time to another service” Subscription filter, not an export task

Common traps

  • Export tasks copy data to S3 in batches. They are not real-time.
  • A missing log group after a test usually means the execution role cannot write logs.
  • Plain-text parsing when the logger could write JSON fields instead.
  • Changing console levels only while code still sets DEBUG.
  • Never-expire retention on every group.

Try the 3 practice questions

A payments Lambda function writes plain-text log lines such as 'charge failed errorCode=CardDeclined orderId=8841'.

The developer wants, in CloudWatch Logs Insights, the number of failures for each errorCode over the time range selected in the console, with the most frequent codes first. The function writes these lines for every payment, and the team reviews the counts each week.

Which query returns this?

Choose one answer.

  1. A. fields @timestamp, @message | stats count(*) by @message | sort count(*) desc | limit 20
  2. B. parse @message "errorCode=* *" as code, rest | stats count(*) by code | sort count(*) desc | limit 20
  3. C. filter @message like /errorCode/ | sort @timestamp asc | fields @message | limit 20
  4. D. filter @message like /errorCode/ | stats count(*) by bin(24h) | sort count(*) desc | limit 20
Show the answer and explanation

Answer: B

  • A. Wrong: Grouping by @message counts each distinct line, and each line has a different orderId. The counts would not show totals for each error code.
  • B. Right: Correct. parse extracts the text after errorCode= into a field named code, using a glob in which each * becomes a named field. stats then counts the lines for each code, and sort puts the most frequent codes first. Learn more: parse - Amazon CloudWatch Logs (opens in a new tab)
  • C. Wrong: This lists matching lines in time order. It does not count failures or group them by error code.
  • D. Wrong: bin(24h) groups the counts by day, so it shows how many failures there were, but not how they split by error code.

Explanation

The parse command extracts parts of a plain-text line with a glob pattern, and each * becomes an alias. Grouping with stats and sorting by count then shows the most frequent error codes. The 24-hour window comes from the console's time range, not from the query.

Study

A Python Lambda function uses the runtime's standard logger, and its plain-text output includes many DEBUG messages.

In production the team pays for every DEBUG line stored in CloudWatch Logs. The team must stop DEBUG lines from being sent to CloudWatch Logs without changing the function code, and each log entry should carry a level field that can be queried in Logs Insights.

What should the developer configure?

Choose one answer.

  1. A. A metric filter on the log group that drops any line containing DEBUG.
  2. B. Keep the text log format, and set the application log level to INFO.
  3. C. A subscription filter that forwards the log group to Amazon OpenSearch Service for parsing.
  4. D. Set the log format to JSON and the application log level to INFO.
Show the answer and explanation

Answer: D

  • A. Wrong: A metric filter turns matching log lines into metric data, but the lines have already been ingested into the log group. It cannot stop DEBUG lines being sent to CloudWatch Logs.
  • B. Wrong: Log-level filtering needs the JSON log format. With plain text, the application log level setting does not filter the output, so DEBUG lines still reach CloudWatch Logs.
  • C. Wrong: A subscription filter copies log events to another service after they are in CloudWatch Logs, which adds cost. It does not stop DEBUG lines from being ingested.
  • D. Right: Correct. JSON format gives each entry a level field. With an application log level of INFO, Lambda sends INFO and higher levels to CloudWatch Logs and filters out DEBUG, which also reduces volume. No function code change is needed for this runtime. Learn more: Configuring advanced logging controls for Lambda functions (opens in a new tab)

Explanation

Lambda's advanced logging controls can filter application logs by level before they reach CloudWatch Logs, but log-level filtering requires the JSON log format. Metric filters and subscription filters act on logs after they are ingested, so they do not reduce what is stored.

Study

A checkout team's Lambda function writes plain-text logs to Amazon CloudWatch Logs. A developer is testing a fix, and a tester will repeat the failing checkout several times while the developer watches for errors.

The developer needs to see matching log lines appear as they are written. The results do not need to be saved, and the log group also holds many unrelated lines that would fill the screen.

Which approach meets these requirements?

Choose one answer.

  1. A. Run a Logs Insights query over the last 5 minutes each time the tester repeats the checkout, and read the results from the query output.
  2. B. Open Live Tail on the function's log group, and filter the live stream to lines that contain ERROR.
  3. C. Create an export task that copies the log group to Amazon S3, and download the exported files after the tester finishes.
  4. D. Add a subscription filter that sends every log event to a second Lambda function, which writes the errors to its own log group.
Show the answer and explanation

Answer: B

  • A. Wrong: A Logs Insights query returns results for a time range when you run it, so each new line needs another run. It does not show lines as they arrive.
  • B. Right: Correct. Live Tail streams new log events from the selected log group in near real time, and a filter pattern such as ERROR narrows the stream to matching lines. It needs no saved results or query, which fits a live test run. Learn more: Troubleshoot with CloudWatch Logs Live Tail (opens in a new tab)
  • C. Wrong: Export tasks run asynchronously and deliver files to S3 in batches, so the developer would wait a long time for the results. The task does not show errors while the test runs.
  • D. Wrong: This builds a processing pipeline that the test does not need. It adds another function to maintain and more log groups to read, rather than showing the lines to the developer now.

Explanation

Live Tail is the CloudWatch Logs feature for watching log events as they are written, with a filter pattern to narrow the stream. Logs Insights queries and exports work on a time range after the fact, and a subscription filter forwards events to another service. None of those shows the developer matching lines during a live test.

Study

Want more on Logging and CloudWatch Logs Insights? The 5 full-length practice sets have 11 more Logging and CloudWatch Logs Insights questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study Logging and CloudWatch Logs Insights

More Troubleshooting and Optimization topics