A change workflow must wait for an approval, retry a step that failed, and then run a follow-up step. One Lambda function sleeps between the steps and sometimes stops halfway. What should own the workflow?
Select an answer to reveal the explanation.
Short Explanation
You need the workflow to keep moving even when one function stops, so Step Functions can hold the approval wait, retry the failed step, and run the follow-up as durable states. A longer sleep keeps the work inside one Lambda invocation, which can still end before the workflow finishes. A cron job starts the Lambda function over, while an S3 lifecycle rule responds to a storage-class change—not the approval or failed step.
Full Explanation
A Step Functions state machine is the right owner because it keeps workflow progress as state outside any one Lambda invocation. It can wait for an approval, retry a failed step, and then run the follow-up, matching the required sequence without relying on a single function to remain alive. A longer sleep in the same Lambda function still ties the approval, retry, and follow-up to one execution; that invocation can stop halfway, as it already sometimes does. A cron job that starts the Lambda function again begins at the first step rather than resuming the step that was waiting or failed. An S3 lifecycle rule invokes the function when an object changes storage class; that event neither represents an approval nor retries a named step in the change workflow. Caveat: configure the approval to pause the state machine until a person acts, rather than polling inside another sleeping function, or the same reliability problem remains in a different place. Practical check: make a test step fail and confirm that the state machine retries it; then complete the approval and verify that the follow-up runs without starting the workflow over.