DOP-C02 Resilient Cloud Solutions 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.

• ✗

  Increase the Lambda function memory to the maximum allowed.

  Why it's wrong here

  Lambda's concurrency is based on the number of simultaneous invocations, not on the memory allocated to a function. While increasing memory also increases the CPU and network bandwidth allotted to each execution, it does nothing to raise the account's concurrency quota or the function's reserved concurrency. In fact, each concurrent execution consumes a slice of the account's concurrency pool regardless of memory size, so the spike scenario remains completely unresolved.

• ✗

  Enable DynamoDB auto scaling for the table to handle traffic spikes.

  Why it's wrong here

  DynamoDB auto scaling adjusts the provisioned read/write capacity of the table based on utilization, preventing throttling errors from the database when traffic spikes. However, the symptom described is Lambda function throttling, which happens before the function can even invoke and reach DynamoDB. The Lambda concurrency limit is separate from DynamoDB capacity, so scaling the table has no effect on whether Lambda has available execution capacity to handle the incoming requests.

• ✗

  Set API Gateway throttling limits to match the expected peak traffic.

  Why it's wrong here

  API Gateway throttling is a client-side or regional rate limit that controls how many requests enter the integration, but it does not increase the Lambda function's reserved concurrency or account-level concurrency pool. Even if you set throttling to match expected peak, Lambda still has a default account concurrency limit (e.g., 1,000) across all functions, and if the function's concurrency is exhausted, requests will still be throttled with 429 errors. Throttling can shape traffic but cannot guarantee the function has capacity to execute, so it does not address the resilience goal.

• ✓

  Reserve concurrency for the Lambda function to ensure it always has available capacity.

  Why this is correct

  Reserved concurrency sets a hard upper limit on the number of simultaneous executions for a specific function and, more importantly, guarantees that this amount of capacity is reserved exclusively for that function from the account's total concurrency pool. This prevents other functions from exhausting the shared pool and ensures the critical function can always handle its peak load without being throttled. It also makes the function's behavior predictable during traffic spikes, because the reserved capacity is always available for that function's invocations.

Go deeper

Related to this question