Pass records to AWS Step Functions and decouple the sequential steps into tasks and Lambda functions
A company is running a custom-built application that processes records. All the components run on Amazon EC2 instances that run in an Auto Scaling group. Each record's processing is a multistep sequential action that is compute-intensive. Each step is always completed in 5 minutes or less. A limitation of the current system is that if any steps fail, the application has to reprocess the record from the beginning. The company wants to update the architecture so that the application must reprocess only the failed steps. What is the MOST operationally efficient solution that meets these requirements?
Community Votes
100% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
The requirement is per-step resumption after a failure, which requires the workflow state to be externalized so a retry resumes at the failed step rather than the start (D). Step Functions provides that state management together with per-task retry and error handling, and Lambda functions supply the compute for each step, matching the five-minute-per-step shape. Option A persists intermediate results to S3 but still relies on custom orchestration to resume at the right step, and option B's self-invoking container on Fargate provides no workflow state at all, so a failure still restarts the record.
Each record's processing is a multistep sequential and compute-intensive action where every step finishes within five minutes, and the current design restarts the whole record when a step fails. AWS Step Functions is built for exactly this: it holds the state of the workflow between steps, so a failure retries only the failed task rather than restarting from the beginning, and it supports built-in retry and error handling. Decoupling the individual steps into Step Functions tasks backed by AWS Lambda functions therefore removes the need to reprocess the entire record.
Writing records to S3 and passing intermediate results through S3 between steps (A) — storing intermediate output does not by itself provide workflow state or per-step retry, so the orchestration that resumes at the failed step still has to be built and the failure still propagates to the whole record. Having a Fargate container invoke itself to pass state from one step to the next (B) — self-invocation carries no durable workflow state, so there is nothing to resume from after a failure and the record restarts from the beginning, which is the problem to be solved. Using a Kinesis data stream with Lambda consumers (C) — a stream plus consumers does not model a multistep sequential workflow with per-step state, so it does not address the failure-restart behavior.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The problem is that a failure in any step forces the entire record to be reprocessed from the beginning. The fix is to move the orchestration out of the application and into a managed workflow service that maintains per-record state. A web application passes records to AWS Step Functions, and the processing is decoupled into Step Functions tasks implemented by AWS Lambda functions. Step Functions holds the state of the execution between tasks, so when a task fails its built-in retry and error handling apply to that task alone rather than to the whole record, which is exactly the required behaviour. The fact that each step completes within five minutes also fits Step Functions well, since Lambda-backed tasks are suited to short, compute-intensive units of work (D). D is the correct answer.Why the Other Options Are Wrong
A creates a web application that writes records to Amazon S3, uses S3 Event Notifications to publish to an SNS topic, and uses an EC2 instance to poll SNS and start processing while saving intermediate results to S3 to pass to the next step. Persisting intermediate output in S3 does not provide workflow state or per-step retry; the logic that resumes processing at the correct step and that retries only the failed step would still have to be written, and the current failure behaviour would remain. B converts the application to a container on AWS Fargate and configures the container to invoke itself to pass state from one step to the next. Self-invocation carries no durable workflow state, so after a failure there is no execution state to resume from and the record must be processed again from the start, which is precisely the behaviour the requirement asks to eliminate. C passes records to an Amazon Kinesis data stream and decouples the processing into the stream and Lambda functions. A stream with consumers does not model a multistep sequential workflow, so it provides neither ordered step progression nor per-step resume on failure. D is correct.Community Comment Notes
Community voted D unanimously. trungtd identified the three properties that make Step Functions plus Lambda the fit: decoupling tasks, error handling and retry logic, and state management, which between them remove the restart-from-beginning behaviour. jamesf cited the Step Functions documentation as the supporting reference, and tgv confirmed D. No alternative received support.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →