How to Automatically Retry Timeout Errors in AWS Step Functions?

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. One of the Lambda functions occasionally fails because of timeout errors during periods of high demand. The developer must ensure that the workflow automatically retries the failed function invocation if a timeout error occurs. Which solution will meet this requirement?

Add a Retry field in the Step Functions state machine definition. Configure the state machine with the maximum number of retry attempts and the timeout error type to retry on. Source Reference Answer
Add a Timeout field in the Step Functions state machine definition. Configure the state machine with the maximum number of retry attempts.
Add a Fail state to the Step Functions state machine definition. Configure the state machine with the maximum number of retry attempts.
Update the Step Functions state machine to pass the invocation request to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe a Lambda function to the SNS topic. Configure the Lambda function with the maximum number of retry attempts for a timeout error type.

Community Votes

100%

100% of anonymous learners picked answer A. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

Tests native Step Functions error-handling capabilities, with the common trap being confusion between execution time limits and explicit retry policy configurations.

This question evaluates native error handling and automatic retry mechanisms in AWS Step Functions when invoking Lambda functions. The community unanimously agrees that configuring the Retry field within the Task state definition is the correct and most efficient approach.

Option B is frequently selected by mistake because it mentions both 'Timeout' and 'retry attempts,' but the TimeoutSeconds field only defines the maximum wait time before a state fails and does not trigger automatic retries without a dedicated Retry block.

Community Discussion (6 comments)

KarBiswa 👍 5 Selected: A

https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#:~:text=Task%2C%20Parallel%2C%20and%20Map%20states%20can%20have%20a%20field%20named%20Retry%2C%20whose%20value%20must%20be%20an%20array%20of%20objects%20known%20as%20retriers.%20An%20individual%20retrier%20represents%20a%20certain%20number%20of%20retries%2C%20usually%20at%20increasing%20time%20intervals.

CrescentShared 👍 5 Selected: A

A is correct.

albert_kuo 👍 1 Selected: A

{ "Type": "Task", "Resource": "arn:aws:lambda:region:account-id:function:function-name", "Retry": [ { "ErrorEquals": ["States.Timeout"], "IntervalSeconds": 2, "MaxAttempts": 3, "BackoffRate": 2.0 } ], "End": true }

preachr 👍 1 Selected: A

https://docs.aws.amazon.com/step-functions/latest/dg/concepts-error-handling.html#error-handling-examples

65703c1 👍 1 Selected: A

A is the correct answer.

SerialiDr 👍 4 Selected: A

AWS Step Functions allows you to handle errors and automate retry policies directly within your state machine definition. By adding a Retry field to the state definition of the Lambda function within the Step Functions state machine, you can specify the error types for which retries should occur, including timeout errors. You can also configure the maximum number of retry attempts, the interval between retries, backoff rate, and more. This solution directly addresses the need for automatic retry in case of specific errors such as timeouts, making it an efficient way to enhance the resilience of serverless workflows.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

AWS Step Functions natively supports fault tolerance through the Retry field in Task state definitions. By specifying ErrorEquals with States.Timeout alongside MaxAttempts, IntervalSeconds, and BackoffRate, the orchestrator automatically catches timeout exceptions and re-invokes the Lambda function according to the defined exponential backoff policy. This directly satisfies the requirement for automatic retry handling during high-demand periods.

Why the Other Options Are Wrong

Option B incorrectly associates the Timeout field with retry logic; TimeoutSeconds merely caps execution duration before triggering a failure, it does not configure recovery attempts. Option C introduces a Fail state, which explicitly halts the workflow and transitions it to a terminal state rather than attempting recovery. Option D unnecessarily routes requests through Amazon SNS, adding architectural complexity and latency while shifting retry responsibility away from Step Functions' native workflow engine.

Community Comment Notes

Multiple candidates verified that AWS documentation explicitly recommends using the Retry array in Task states for automated error recovery [1][4]. Contributors shared exact JSON templates demonstrating the proper syntax, emphasizing that States.Timeout must be matched in the ErrorEquals array to capture these specific failures [3]. The overwhelming consensus confirms that native state machine configuration eliminates the need for external messaging services like SNS for basic retry requirements [2][5].

Official Reference

Exam Strategy

Memorize the native error-handling fields (Retry and Catch) available for each Step Functions state type, as they are heavily tested in DVA-C02 scenario questions. Always distinguish between execution time limits (TimeoutSeconds) and failure recovery logic (Retry), since exam writers deliberately pair these terms to assess your grasp of state machine mechanics.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide