A developer is building a serverless application on AWS for a workflow that processes high volumes of data. In the workflow, an AWS Step Functions state machine invokes several AWS Lambda functions. O

Question

Options

• AAdd a Retry field in the Step Functions state machine definition. Configure the state machine with
• BAdd a Timeout field in the Step Functions state machine definition. Configure the state machine
• CAdd a Fail state to the Step Functions state machine definition. Configure the state machine with
• DUpdate the Step Functions state machine to pass the invocation request to an Amazon Simple

• A
  73% (19)
• B
  8% (2)
• C
  15% (4)
• D
  4% (1)

Explanation

Option A is correct because AWS Step Functions natively supports automatic retries through the Retry field in a state's definition - you can specify error types (like States.Timeout), retry intervals, max attempts, and backoff rates, making it the purpose-built solution for handling transient Lambda failures without any additional infrastructure.

Option B is wrong because the Timeout field controls the maximum duration a state is allowed to run before it times out - it does not trigger any retry logic on failure.

Option C is wrong because a Fail state explicitly terminates the execution with an error; adding it would cause the workflow to stop, which is the opposite of retrying.

Option D is wrong because routing through Amazon SQS (what this option implies) introduces unnecessary complexity and architectural overhead - it's a workaround, not the native Step Functions retry mechanism designed for this exact use case.

Memory tip: Think of Retry as the "try again" field and Catch as the "give up gracefully" field in Step Functions. Whenever an exam question asks about automatically retrying a failed state, the answer almost always involves the Retry block - it's the only field in the state machine definition that directly instructs the orchestrator to re-invoke a failed state.

No community discussion yet for this question.