A municipal Lambda behind API Gateway must remain safe to scale to zero and multiply under load. Developers debate storing citizen wizard progress inside the function container. What should they do?
Select an answer to reveal the explanation.
Short Explanation
Lambda containers come and go like borrowed desks — do not leave the citizen's wizard notes in the drawer. Save progress in DynamoDB (or similar) and treat each invoke as stateless. That stays safe when the function scales to zero or fans out.
Full Explanation
A municipal Lambda behind API Gateway must remain safe to scale to zero and multiply under load, which means wizard progress cannot live inside the function container. Persist progress in an external store such as DynamoDB and keep the handler effectively stateless across invocations. Cold starts, concurrency fan-out, and container recycling are normal; citizens stepping through a multi-page assistance application must resume from durable state, not from whatever /tmp or global happened to be warm last time.
Writing progress only to /tmp and assuming the same warm container always serves the same citizen fails when concurrency routes the next click elsewhere or the sandbox freezes. Module-level globals plus reliance on provisioned concurrency never recycling still risk recycle events and break the scale-to-zero goal. Disabling concurrency so only one container exists serializes the whole city behind one execution environment and rejects the scaling requirement in the stem.
Exam caveat: provisioned concurrency can reduce cold starts but is not a substitute for externalized state. /tmp is scratch space within one execution environment’s lifetime, not a session store.
Operational check: save wizard step and form fields to DynamoDB (or similar) after each page; authorize reads/writes with the citizen’s subject ID; verify progress survives forced new containers; and load-test concurrent wizards without sticky affinity to a single sandbox.