SAP-C02 Practice Question 24: Long Running Human Approval Workflow
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 3 · question 4 of 10
A lender is rebuilding its loan origination process. A submitted application runs through automated credit checks, then pauses for a human underwriter who typically responds within a few hours but is contractually allowed up to five business days. After the decision, four more automated steps run.
The current implementation is a Lambda function triggered every minute that scans a DynamoDB table for applications whose state has changed. It is expensive, the audit team cannot reconstruct what happened to a given application, and a rewrite is approved. The new design must hold each application's execution open across the full approval window, must not poll, must give auditors a per-application visual history of every step and its input and output, and must resume the moment the underwriter's existing internal tool posts its decision.
Which design should the architect choose?
Show answer and explanation
Answer:
The callback pattern exists for this shape of problem. AWS names waiting for a human approval as a headline use case: the task pauses, a token generated from the context object ($$.Task.Token) is handed to the external system, and the execution stays parked until that system returns the token with SendTaskSuccess or SendTaskFailure. A paused callback task can wait until the execution reaches the one-year service quota, so five business days is comfortably inside the limit, and nothing polls in the meantime. Standard workflows record every state transition in the execution history, which is the per-application audit trail the stem requires.
Option A is the current polling design moved into Step Functions. Standard workflows are billed per state transition, so a Wait/Choice loop firing every 60 seconds for up to five days is tens of thousands of transitions per application, and it still reads DynamoDB on a timer.
Option B cannot be built as written: the maximum Amazon SQS visibility timeout is 12 hours, not five days. Even if the window fit, a queue does not orchestrate the four steps that follow the decision and keeps no execution history.
Option D fails on the workflow type. Express workflows support only the *Request Response* integration pattern, not .waitForTaskToken, and they are capped at a five-minute run time, so they cannot hold an approval open for days regardless of the heartbeat setting.
Reference: Discover service integration patterns in Step Functions