A nightly municipal PDF generation job runs for a few minutes and sits idle the rest of the day. Which compute approach best avoids paying for an always-on VM?
Select an answer to reveal the explanation.
Short Explanation
Why rent a parking space all month for a car that only shows up for five minutes at midnight? Serverless (FaaS) wakes up for the PDF job, does the work, then goes away so you are not paying idle VM time. Sporadic night jobs love that model.
Full Explanation
Serverless or Function as a Service compute runs code in response to events and typically charges primarily for execution rather than for an always-on virtual machine. A nightly municipal PDF generation job that runs for a few minutes and sits idle the rest of the day is a strong candidate for event-triggered serverless compute—or an equivalent scheduled function/job—to avoid paying for idle VM time all day. A dedicated host reserved year-round solely for that short job maximizes cost without matching the duty cycle. An oversized always-on VM left running 24×7 for convenience is exactly the waste pattern serverless is meant to avoid for intermittent batch work. Keeping the job on a continuously billed physical blade in the basement likewise pays for idle capacity around the clock. Exam caveat: serverless fits short, event-driven, stateless-leaning work; long-running stateful database engines may still need always-on compute—choose based on runtime profile rather than fashion. Operational check: package the PDF job as a function or scheduled container job with a nightly trigger, set memory and timeout for worst-case document sets, store outputs in durable encrypted object storage, alarm on failures and duration anomalies, and compare monthly cost against the previous always-on VM baseline for finance.