Compare ephemeral container agents versus persistent build agents
Tradeoffs between isolation and speed.
Ephemeral agents ensure clean state but add cold-start latency; persistent agents speed builds via caching yet risk config drift.
What's really being asked
This question tests whether you can reason about build infrastructure tradeoffs beyond personal preference. The interviewer wants to see if you understand reproducibility, caching strategies, operational overhead, and security boundaries in CI/CD systems. They are listening for evidence that you have scaled build environments and felt the pain of both models.
The full answer
A strong answer walks through four dimensions in order. First, reproducibility and hermetic builds: ephemeral containers start from a known image every time, eliminating works-on-my-machine drift and snowflake agents. Second, performance and caching: persistent agents keep incremental compiler caches, dependency downloads, and Docker layer caches warm, which matters when builds run every few minutes. Third, maintenance and security: ephemeral agents reduce patching burden because the host is short-lived, while persistent agents require OS updates, toolchain upgrades, and cleanup scripts to prevent disk exhaustion. Fourth, cost and scalability: ephemeral agents fit serverless or Kubernetes-based autoscaling but may pull large images repeatedly; persistent agents sit idle between jobs unless you manage pool sizing carefully. The best candidates mention hybrid patterns such as VM scale sets that recreate agents periodically or cached sidecars that inject dependencies without full image rebuilds.
The mistakes people make
The biggest red flag is treating one model as universally correct. Another mistake is ignoring startup latency entirely; candidates who claim ephemeral is always faster forget that a two-gigabyte container image pull can take thirty to sixty seconds. Conversely, claiming persistent agents are cheaper without factoring in maintenance labor and security patching is a junior-level answer. A subtle trap is conflating containerized builds with ephemeral hosts; you can run persistent containers or ephemeral VMs, so the answer should separate the host lifecycle from the build sandbox.
What usually comes next
The interviewer may ask how you would cache dependencies in an ephemeral world, how you would detect configuration drift on persistent agents, or what you would do if a build modifies the local toolchain. They might also probe cost optimization, asking when to use spot instances for ephemeral agents or how to right-size persistent pools.
A concrete example
Consider a monorepo with two-hundred engineers running five-hundred builds per day. Purely ephemeral agents would spend significant time reinstalling a three-gigabyte Node_modules tree and compiler toolchain on every job. A persistent agent pool with nightly image refreshes and automated disk cleanup keeps builds under ninety seconds while avoiding week-old state. Alternatively, ephemeral agents with a mounted read-only cache volume or a pre-baked image rebuilt hourly can capture eighty percent of the speed benefit without the drift risk.
Interview question
Which statement best captures a key operational tradeoff between ephemeral and persistent CI build agents?
- a.Containerized builds inherently require an ephemeral host lifecycle, so persistent containers are impractical
- b.Ephemeral agents reduce security patching burden through short lifecycles, while persistent agents require ongoing OS and toolchain maintenanceCorrect
- c.Persistent agents guarantee reproducible builds because they reuse warmed dependency and compiler caches across jobs
- d.Ephemeral agents always deliver faster builds and lower compute costs than persistent agents
Why? this is the answer
Ephemeral agents are short-lived, which minimizes patching and drift, whereas persistent agents accumulate state and need active maintenance. Distractor A is wrong because ephemeral agents can suffer from cold-start latency and repeated image pulls, and persistent agents can be more cost-effective when heavily utilized.
Just read this? Test yourself on what you have been reading.
Read the original → learn.microsoft.com
- #ci/cd
- #build agents
- #infrastructure
- #devops
- #azure pipelines
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles