DOP-C02 Practice Question 39: Step Functions Remediation Retry Catch

Step Functions puts retry and failure handling in the workflow definition instead of in application code. Task, Parallel, and Map states "can have a field named Retry, whose value must be an array of objects known as *retriers*", where IntervalSeconds sets the first wait, MaxAttempts the cap, and BackoffRate "the multiplier by which the retry interval... increases after each retry attempt". A Catch block then routes an error that retries could not resolve: "when the error name appears in the value of a catcher's ErrorEquals field, the state machine transitions to the state named in the Next field." Because retries are scoped to the state that failed, a throttled snapshot call is retried on its own without re-running the ticket step, and the execution history records every state and attempt for the review.

Option A keeps the all-or-nothing structure. The function is still one unit of work, so any unhandled failure restarts everything, sleeping inside a Lambda function is billed time, and there is no per-step history beyond whatever the code happens to log.

Option C retries at the wrong granularity. SQS redelivery re-invokes the whole function, so the steps that already succeeded run again, which is exactly how the duplicate tickets are being created today.

Option D loses ordering and shared state. The isolation step should not race the snapshot, four independent rules give no way to route a partial failure to quarantine, and each function would still need its own retry logic hand-written.

Reference: Handling errors in Step Functions workflows