How do you keep build agents and runner images patched and secure over time?
CI/CD & GitOps · Advanced level
Answer
Build agents and runner images should be treated as production infrastructure. I keep them patched with immutable golden images, automated rebuilds, vulnerability scanning, base-image refresh schedules, least-privilege configuration, ephemeral runners, and monitoring for drift or outdated tooling.
Technical explanation
Runner images should be rebuilt from a controlled base and scanned before use.
Long-lived self-hosted runners need stronger isolation because workspace residue and credentials can survive across jobs.
A secure pipeline protects source, build environment, dependencies, artifacts, deployment credentials, and runtime promotion gates as one chain.
Immutable artifacts, SBOMs, signatures, provenance, vulnerability gates, and environment promotion reduce ambiguity about what was built and deployed.
CI runners are high-value targets; isolate untrusted jobs, patch runner images, remove persistent credentials, and prefer ephemeral execution where possible.
Release safety depends on both automation and observability: use canaries, feature flags, rollback plans, and automated metric-based decisions.
Hands-on example
1. Design an advanced delivery exercise for: How do you keep build agents and runner images patched and secure over time using one service, one Git repository, one artifact registry, and one Kubernetes environment.
2. Build a golden runner image weekly from a patched base, install pinned tool versions, scan the image, and publish it only if the scan passes policy.
3. Use ephemeral self-hosted runners for jobs, destroy the VM/Pod after each run, and alert on images older than the approved patch window.
4. Use progressive exposure where relevant: feature flag off by default, canary 5%, automated metric check for error rate and latency, then expand or rollback.
5. Record audit evidence: PR, approver, pipeline run, artifact digest, SBOM location, signature verification result, deployment event, and rollback or forward-fix decision.
Source Note for Current CI/CD and GitOps Items
Most answers are based on stable CI/CD, Jenkins Pipeline, GitOps, Argo CD, GitHub Actions, Git, and supply-chain security concepts. Validate tool behavior against your exact Jenkins plugin versions, Argo CD version, GitHub plan, runner model, and organization security policy before implementing in production.
Jenkins Pipeline syntax reference: https://www.jenkins.io/doc/book/pipeline/syntax/
Jenkins Pipeline overview: https://www.jenkins.io/doc/book/pipeline/
Argo CD automated sync policy: https://argo-cd.readthedocs.io/en/stable/user-guide/auto_sync/
Argo CD sync phases and waves: https://argo-cd.readthedocs.io/en/stable/user-guide/sync-waves/
GitHub Actions OIDC cloud-provider guidance: https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers
OpenGitOps principles: https://github.com/open-gitops/documents/blob/main/PRINCIPLES.md
Check how well your resume matches the role with our free resume checker— match score, ATS check, and the skills you're missing.
More CI/CD & GitOps interview questions
- What is CI/CD, and what is the difference between continuous delivery and continuous deployment?
- What are the goals of a CI pipeline beyond just running tests?
- What is Jenkins, and what is the difference between a controller and an agent?
- What is the difference between a freestyle job and a pipeline job in Jenkins?
- What is the difference between a declarative and a scripted Jenkins pipeline?
- What is a Jenkinsfile, and why keep your pipeline as code in the repo?
- Explain the structure of a declarative pipeline (agent, stages, steps, post).
- What is the post section used for, and what are its conditions (success, failure, always)?