SAP-C03 practice question: Serverless data pipelines and durable workflows (Step Functions)
Architecture Design and Implementation Built for the Cloud A free question from our original SAP-C03 practice exam. Try it, then open the answer to see why each option is right or wrong.
A retailer runs product returns as a multi-step workflow. For each return, the workflow checks the order, issues a refund through a payment provider, books a pickup with a courier and waits for a store manager's approval when the refund is above a set amount. Courier pickup confirmations can take up to 30 days.
Each refund must happen at most once, even when a step is retried. Auditors need a complete record of every step for each return, and the operations team does not want custom code that stores workflow state or polls for approvals.
Which solution meets these requirements?
Choose one answer.
AA. Run each return as an AWS Step Functions Standard Workflow. Each task retries with backoff, the approval and courier steps pause on a task token, and the refund call uses an idempotency key built from the return ID.
BB. Run each return as an AWS Step Functions Express Workflow with retries on every task and Wait states for the approval and the courier confirmation. Send the execution logs to CloudWatch Logs for the audit trail.
CC. Store each return's state in an Amazon DynamoDB table, use Amazon EventBridge Scheduler to run a Lambda function every few minutes to check the courier and approval status, and call the refund API from that function.
DD. Pass each step through its own Amazon SQS queue, with a visibility timeout of 30 days on the courier confirmation queue, and have a consumer Lambda function for each queue call the payment provider or the courier.
Show the answer and explanation
Answer: A
A. Right: Correct. Standard workflows can run for long periods and wait for external callbacks with task tokens, so no polling code is needed. The idempotency key keeps a retried refund from being paid twice, and the execution history gives auditors the step-by-step record. Learn more: Call Step Functions with a task token (opens in a new tab)
B. Wrong: Express workflows are built for short, high-volume runs and cannot run longer than five minutes, so a 30-day wait cannot be modeled in one execution. Their at-least-once processing also makes duplicate refunds more likely.
C. Wrong: This design can work, but the team would write and run the state tracking, the polling and the retry logic itself. That is the custom code the operations team wants to avoid, and the audit record would also need building.
D. Wrong: SQS limits the visibility timeout to 12 hours, so a 30-day confirmation cannot be held this way. The functions would also need their own protection against duplicate refunds, and queue messages do not give auditors a complete history of each return.
Explanation
Long waits for human approval and courier callbacks, at-most-once refunds and a full history without custom state code point to a Standard workflow. Express workflows have a short maximum duration, and polling or queue-based designs add custom code or hit service limits.
Want more on Serverless data pipelines and durable workflows (Step Functions)? The 5 full-length practice sets have 5 more Serverless data pipelines and durable workflows (Step Functions) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →