DVA-C02 Question #300: Real Exam Question with Answer & Explanation

Question

A developer is using AWS Step Functions to automate a workflow. The workflow defines each step as an AWS Lambda function task. The developer notices that runs of the Step Functions state machine fail in the GetResource task with either an IllegalArgumentException error or a TooManyRequestsException error. The developer wants the state machine to stop running when the state machine encounters an IllegalArgumentException error. The state machine needs to retry the GetResource task one additional time after 10 seconds if the state machine encounters a TooManyRequestsException error. If the second attempt fails, the developer wants the state machine to stop running. How can the developer implement the Lambda retry functionality without adding unnecessary complexity to the state machine?

Options

• AAdd a Delay task after the GetResource task. Add a catcher to the GetResource task. Configure
• BAdd a catcher to the GetResource task. Configure the catcher with an error type of
• CAdd a retrier to the GetResource task. Configure the retrier with an error type of
• DDuplicate the GetResource task. Rename the new GetResource task to TryAgain. Add a catcher

Explanation

Option C is correct because AWS Step Functions has a native retrier mechanism built into task states, allowing you to specify error types, retry intervals, and max attempts directly on the task - no extra states required. Configuring a retrier for TooManyRequestsException with MaxAttempts: 1 and IntervalSeconds: 10 handles the retry logic cleanly; since IllegalArgumentException is not in the retrier, it immediately causes the state machine to stop.

Option A is wrong because adding a separate Delay task to simulate a wait is unnecessary complexity - the retrier's IntervalSeconds field provides the delay natively. Option B is wrong because catchers handle errors by redirecting to a different state, not by retrying the same task; you'd need additional states to approximate retry behavior. Option D is wrong because manually duplicating the task as a "TryAgain" state is a workaround that adds unnecessary complexity - exactly what the question says to avoid.

Memory tip: Think "Retrier = Retry same task, Catcher = Catch and redirect." If the requirement says "retry," reach for a retrier; if it says "on error, go to X," reach for a catcher. They can coexist on the same task, but they serve different purposes.

No community discussion yet for this question.