A folk-festival needs a one-off Linux container this weekend to generate wristband PDFs, with no scale-out story and no cluster to operate. Which Azure compute choice fits best?
Select an answer to reveal the explanation.
Short Explanation
One weekend job, no orchestra to conduct—Azure Container Instances is the pop-up booth. Skip AKS node pools and permanent App Service plans when you just need a container that runs and leaves.
Full Explanation
For a one-off Linux container that generates folk-festival wristband PDFs this weekend—with no scale-out story and no cluster to operate—Azure Container Instances is the fit. ACI starts an isolated container quickly, bills for the duration of the run, and avoids Kubernetes node-pool design entirely. That matches a pop-up batch job better than standing up long-lived platform pieces the festival staff will not maintain afterward.
Standing up AKS and sizing a node pool for a single weekend batch job adds control-plane cost and node operations the festival does not need. Creating a long-lived App Service plan solely to keep a weekend batch process always warm pays for always-on capacity that contradicts the one-off requirement. Pushing the image to ACR only stores the artifact; the registry will not execute the PDF job on a schedule by itself.
Exam caveat: ACI is excellent for simple isolated runs and small sidecar groups, but it is not the first choice when you need HTTP autoscale rules, traffic splitting, or many continuously running microservices—those scenarios lean toward Azure Container Apps on AZ-204.
Operational check: push the PDF worker image to ACR, create an ACI container group with that image plus any Azure Files output mount, run the job once, confirm PDFs land in persistent storage, then delete the group when the weekend ends.