SOA-C03 - Deployment, Provisioning, and Automation - Section 3.7

Build event-driven automation using AWS Lambda, Amazon S3 Event Notifications, Amazon EventBridge and AWS Step Functions.

Build event-driven automation by wiring Amazon S3 Event Notifications and Amazon EventBridge rules to AWS Lambda functions, and orchestrate multi-step workflows with AWS Step Functions state machines. Choose Step Functions over a chain of Lambda invocations when error handling, retries, and state visibility are required.

AWS LambdaAmazon S3 Event NotificationsAmazon EventBridgeAWS Step Functions

Practice question for this objective

Free sampleDeployment, Provisioning, and Automationmedium

An order pipeline runs four sequential Lambda steps where a later step depends on earlier output, some steps need different retry rules with backoff, and a failure must follow a defined error path. The team currently chains the functions by having each one invoke the next and wants reliable orchestration with visibility into where a run failed. Which AWS service should coordinate the workflow?

  • AUse Amazon SQS between each Lambda step so the queues sequence the four functions and provide the retry, ordering and error-path handling for the workflow.
  • BUse an EventBridge event bus where each Lambda step emits an event that a rule routes to the next step, with the bus enforcing retry and ordering across the workflow.
  • CUse AWS Step Functions to define the four steps as a state machine, with per-state retry, catch and ordering handled by the workflow rather than the function code. Correct
  • DUse an SSM Automation runbook to call the four Lambda functions in order and rely on the runbook for the retry, ordering and error-path handling of the workflow.
Choose AWS Step Functions to orchestrate dependent multi-step Lambda workflows with built-in retry, error catching and per-run visibility. Step Functions expresses a workflow as a state machine in which each state can be a Lambda task with its own Retry policy, exponential backoff and Catch handlers that route failures to a defined error path. The service tracks execution history state by state, so operators can see exactly where a run failed without embedding sequencing and retry logic in the function code itself.

Why A is wrong: SQS decouples producers from consumers and offers redrive on failure, but it does not model conditional branching or a defined error path across multiple distinct steps, so the orchestration logic still has to be coded by hand.

Why B is wrong: An event bus routes events to targets and is excellent for loose coupling, but it does not guarantee ordering across steps or hold workflow state, so it cannot express the dependent sequence and shared error path on its own.

Why C is correct: Step Functions models a multi-step workflow as a state machine that sequences the Lambda tasks, applies per-state retry with backoff and catch blocks for error paths, and records each state transition, giving the reliable orchestration and failure visibility the team needs.

Why D is wrong: SSM Automation runbooks orchestrate operational and instance management actions rather than application data workflows, so they are a poor fit for a Lambda order pipeline and lack the rich per-state retry and catch model.

See more SOA-C03 practice questions, answers explained.

More in this domain

Back to all Deployment, Provisioning, and Automation objectives, or the SOA-C03 cert hub.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.