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 function’s concurrency is fully utilized due to long-running invocations

  Why this is correct

  Lambda concurrency is the number of in-flight invocations across all resources. When a function's execution time is long, each invocation holds a concurrency slot for the entire duration, so the configured reserved concurrency of 100 can be reached with relatively few requests. Once all slots are occupied, Lambda throttles additional invocations with a 429 error, and the SQS event source mapping receives a failure, causing messages to remain in the queue. This is the classic cause of throttling with long-running workers, not the other options.

• ✗

  The Lambda function has a cold start issue

  Why it's wrong here

  Cold starts occur when Lambda needs to provision a new execution environment, which adds initialization latency to the first invocation. They are a performance concern that increases response time, but they do not count against concurrency limits or trigger throttling; Lambda can still create the environment and run the function. Since the issue is throttling, not latency, a cold start would not prevent the function from scaling or cause invocations to be rejected. Thus, while cold starts can degrade user experience, they are unrelated to the throttling behavior described.

• ✗

  The SQS queue is not configured as a FIFO queue

  Why it's wrong here

  SQS standard queues are fully supported as event sources for Lambda, and the service scales automatically by polling the queue and invoking the function. Whether the queue is standard or FIFO does not affect Lambda's concurrency handling or throttling behavior; FIFO is only required when strict message ordering or exactly-once processing is needed. Even with a FIFO queue, if the function's concurrency is exhausted, Lambda will still throttle invocations and leave messages unprocessed. Therefore, not using a FIFO queue does not explain the observed throttling; the root cause is concurrency exhaustion, not queue type.

• ✗

  The reserved concurrency is set too high, exceeding the account limit

  Why it's wrong here

  Reserved concurrency is a limit you set to cap a function's usage, and setting it to 100 is a valid value because the default account-level concurrency limit is 1,000 (and the quota can be increased). It does not exceed any limit—it explicitly restricts the function to 100 simultaneous executions. Setting it too high would only be problematic if it exceeded the account's available concurrency, but 100 is well within the safe range. The issue is not the number 100, but that each invocation runs so long that 100 concurrent executions are insufficient to keep up with the incoming event stream.

Go deeper

Related to this question