DOP-C02 Incident and Event Response Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The Lambda function is invoked too frequently, causing CloudWatch to throttle log ingestion.

  Why it's wrong here

  CloudWatch Logs can throttle PutLogEvents API calls when the account exceeds the service quota (e.g., 5 requests per second per log stream), but throttling causes dropped or delayed log events, not a complete absence of data. A zero-byte log group with no log streams indicates the logging calls never succeeded at all, rather than being rate-limited. Even under extreme invocation frequency, Lambda would still emit logs for at least some invocations unless permissions prevent it.

• ✗

  The log group's retention policy of 7 days deletes logs immediately after creation.

  Why it's wrong here

  A log group's retention policy (e.g., 7 days) automatically expires log events older than the retention period, but it does not affect newly written logs. Logs are deleted based on the age of the events, not the log group's creation time; if the function had successfully logged, fresh events would appear regardless of the retention setting. Immediate deletion of all logs would only occur if the retention period were set to 1 day and the group already existed for that long, yet even then the current day's logs would remain. Here, zero bytes means no events were ever ingested, so retention cannot be the cause.

• ✓

  The Lambda execution role lacks permissions to create log streams and put log events.

  Why this is correct

  The Lambda execution role is assigned to the function via the IAM role's trust policy and must include CloudWatch Logs actions like logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents on the relevant log group. Without these permissions, the Lambda runtime's logging agent cannot deliver the function's stdout/stderr output to CloudWatch Logs, causing the invocation to finish successfully while producing zero log bytes. This is the classic cause of a Lambda function that runs without any visible logs, and it also explains why no log group or log stream is created.

• ✗

  The Lambda function does not have a log group; the one shown belongs to another resource.

  Why it's wrong here

  Lambda uses a predictable log group naming convention of /aws/lambda/<function-name>; if the log group in question matches the function name, it is almost certainly the one created for this Lambda. Even if another resource owned the group, the Lambda function would create its own log group automatically upon the first successful log delivery when it has the necessary permissions. Since the function lacks those permissions, no log group is created or written to, and the displayed group—whether shared or not—cannot receive logs from this function. Therefore, the issue is not that the group belongs to another resource, but that the function cannot access it.

Go deeper

Related to this question