A parks department runs heavy MapReduce-style jobs only a few nights each month. Which cloud pattern best matches spinning capacity up for the job and releasing it afterward?
Select an answer to reveal the explanation.
Short Explanation
Why leave the carnival lights on all winter for a three-night fair? Ephemeral cloud clusters spin up for the MapReduce-style job and shut down when the work is done. Always-on peak-sized iron wastes budget between those nights.
Full Explanation
Ephemeral elastic clusters that start for a parks MapReduce-style job and terminate when processing finishes match workloads that run only a few nights each month. Cities pay for the carnival while it runs and release capacity afterward instead of leaving peak-sized iron idle between events. That cloud pattern is a practical expression of elasticity for intermittent civic batch work on shared accounts.
Always-on bare-metal clusters sized for the rare peak and left idle otherwise waste budget between those nights and crowd other municipal priorities. Permanent mainframes dedicated solely to printing park maps confuse a niche output device with elastic analytics capacity. Single always-hot GPU workstations under each analyst’s desk neither pool efficiently nor match cluster-style MapReduce jobs for department-wide park data.
Exam caveat: ephemeral clusters need automated bootstrap of libraries, IAM roles, and data access; a cluster that dies before results are written still fails the business job. Operational check: submit a non-production parks job that provisions a temporary cluster, confirm successful output landing, verify the cluster terminates, and compare cost to an always-on baseline of equal peak size.