A multi-step FOIA redaction workflow must run separate Lambda tasks with retries per state rather than one mega-function. What should the developer use?
Select an answer to reveal the explanation.
Short Explanation
FOIA redaction is a relay race, not one giant solo sprint. Step Functions lines up each Lambda as a state with its own retries instead of one brittle mega-handler. Browser localStorage is not an orchestration engine.
Full Explanation
A multi-step FOIA redaction workflow that must run separate Lambda tasks with retries per state—rather than one mega-function—should compose those tasks inside AWS Step Functions. Each state can retry independently, catch failures into reviewer queues, and keep an auditable history of redaction stages (classify, redact, legal review, publish). Public-records workloads benefit from visible progress when requests span hours and human approvals.
Collapsing all steps into one Lambda that sleeps between phases until maximum duration creates a fragile timeout cliff and poor retry granularity. Tracking workflow progress only in the citizen browser session loses durability when tabs close. Chaining Lambdas by hardcoding the next function name inside each handler without shared orchestration state yields invisible, hard-to-compensate spaghetti.
Exam caveat: Standard Workflows fit long FOIA processes with human waits; Express fits high-volume short pipelines. Use Task Tokens for human review callbacks. Keep PII out of unnecessary execution input logs.
Operational check: model stages as separate tasks with per-state retries; add a human review wait; emit clear fail states for legal hold; grant auditors execution-history access; and alert on executions older than statutory response clocks.