Should a pipeline run ZAP as a fresh container per job or as one long-lived daemon?

## The question behind the question Both topologies work, and teams adopt one by accident far more often than by decision — usually whichever the first person to wire it up happened to copy. It is worth deciding, because the two differ on things a pipeline actually depends on. ## The two shapes | | container per job, one-shot lifetime | one long-lived daemon | |---|---|---| | how the job learns the outcome | the process exit code, produced after the work finished | something you read yourself; the start-up return value is meaningless | | can the automation framework record a status | yes — its status helper is gated on exactly this lifetime | no, the helper returns early | | state between targets | none survives the container | session, history, site tree and configuration edits all persist | | start-up cost | paid per job: image pull, add-on load, model init | paid once | | concurrency | naturally one run per container | several steps share one instance, and can interfere | | the listener | exists only while the job runs | exists continuously, and has an owner | | what a tag change does | changes what that job can do | changes what everything can do | ## What the per-job container buys Isolation is the headline, and it is stronger than it looks. The tool accumulates a session as it works — recorded traffic, a site tree, alerts, whatever a plan set along the way. In a standing instance, the second target inherits all of it, and "we saw an alert on service B that was actually raised against service A" is a real and very hard-to-diagnose failure. A container that dies with its job cannot produce it. The second thing it buys is a verdict that is an actual verdict, for the mechanical reason above rather than by convention. That matters because the alternative — reading a status out of the run's own output — is a thing someone has to build and keep working. ## What the standing daemon buys Amortised start-up is real: loading the program and its add-ons is not free, and a pipeline with many small jobs pays it many times. Beyond that, the genuine reason to want a service is **control**: several steps that drive the run through the API in an order you decide, with your own polling and your own decisions between them. That is a shape a one-shot invocation cannot express, and if you need it you need it. What you take on with it is: no meaningful exit code, shared state, and a listener that outlives any single job. ## What to standardise, and in what order 1. **Pick a default topology and write it down.** Teams should have to justify the other one, not invent one from scratch each time. 2. **Decide where the verdict comes from** before you decide anything else, and make it something a job cannot satisfy by accident. "The process exited zero" is not a verdict on the service topology, and a gate that reports success on every run is worse than no gate. 3. **Pin the image tag** in the pipeline definition, and own the refresh. A moving tag changes what every job can do with no change of yours. 4. **Decide who may reach the listener and with what credential.** A background instance exposes a control surface for as long as it is up; the control-API surface is where that question is answered, and it should be answered on purpose rather than inherited from an example command. 5. **Decide how a run is stopped.** On the service topology, shutting down through the API is what lets any status that was set be returned at all; killing the process discards it. 6. **Decide the isolation boundary between targets** explicitly if you keep a standing instance — a fresh session per target, or an instance per target, or an accepted and documented risk. ## The honest middle The compromise most teams land on is a **container per job that runs the service lifetime inside it**: the steps that need the API get the API, the container still dies with the job so nothing leaks, and the run is shut down through the API at the end so a status can come back. It keeps the isolation and the ownership story of the per-job shape while giving a multi-step job the control surface it wanted. The cost is the start-up you were trying to amortise, which is usually the cheaper thing to give up. ## How to answer this in an interview Do not pick a side and defend it. Name the axes — verdict, state, surface, cost — say which mechanism forces each one, state your default and the condition under which you would switch, and say what you would standardise so that the choice is not remade badly in every repository. The mechanical detail that shows you have used the tool rather than read about it is that the exit status is not merely inconvenient on the service topology: the automation framework does not record one there at all.