Top 11 Ci cd Interview Questions
Browse 11 real-world technical and behavioral interview questions about Ci cd. Review scenarios, edge cases, and architectural best practices.
Design an autoscaling scheme for a self-hosted CI runner fleet. What are you actually trading off, and how do you decide the numbers?
Runner autoscaling trades idle compute cost against queue time, and the two levers that decide the trade are a warm pool sized to your usual concurrency and a scale-down delay long enough to absorb the next job without a fresh cold start.
How would you design a deployment pipeline that can be rolled back safely?
Build one immutable artefact, promote that same artefact through environments behind ordered quality gates, and deploy so traffic can be shifted back instantly. Rollback only stays possible if schema changes are backward-compatible expand-contract steps decoupled from the code deploy.
You need every service's pipeline to run a security scan, a license check, and require signed artifacts before deploy. How do you enforce that across a hundred repositories without ending up with a hundred slightly different pipeline files?
Ship the gates as a shared, versioned pipeline template that repositories include rather than copy, so an update to the check propagates everywhere at once and drift is visible instead of silent. Use this ci cd answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects compliance to the point an interviewer is testing.
Your monorepo's CI runs the full test suite on every pull request, and it now takes forty minutes regardless of whether someone touched one file or a hundred. How would you fix that?
Build a dependency graph of the repository's build targets, diff the changed files against it to compute the affected subset, and run only that subset; the graph's correctness, not the diff itself, is what determines whether the speedup is trustworthy.
Mobile CI/CD build times have degraded to over 45 minutes. How would you diagnose the bottlenecks and architect advanced caching, modular parallelisation, and test sharding to reduce the feedback loop by 50%?
Evaluate the candidate's expertise in profiling build systems, configuring distributed caching, and optimising CI/CD pipelines for large-scale mobile projects.
How would you architect an ephemeral, auto-scaling GitHub Actions runner infrastructure using spot instances to drastically reduce costs without compromising pipeline reliability or introducing unacceptable queuing delays?
An analysis of the challenges in designing a cost-effective, scalable GitHub Actions runner environment using spot instances, focusing on state management, instance termination handling, and performance tuning.
How do you ship a change to a production prompt safely?
Treat the prompt as a versioned artefact under review, run your eval set in CI against a pinned model version, canary on a slice of traffic with the version recorded per request, and keep rollback a config change rather than a deploy. Pinning is what makes a regression attributable to your edit.
Your pipeline gates every code change. What else reaches production without passing through it?
Configuration, feature flags, content and reference data, schema migrations, infrastructure definitions and dependency updates all change production behaviour, and most organisations ship them through channels that were designed to be faster than the release pipeline.
Some of what you ship - rules files, config bundles, model updates - reaches production without passing through the deploy pipeline. What would you put around that path?
Treat any payload the fleet loads as a release, because it changes behaviour in production exactly as a binary does. It needs schema and replay validation, a canary ring with its own health comparison, and a rollback that survives the change breaking whatever would apply the rollback.
Which tests should run on every commit and which should run nightly, and how do you decide?
Give the blocking stage a fixed time budget and put only fast, deterministic, developer-diagnosable tests inside it; everything slow, environment-dependent or exploratory moves to a scheduled run with a named owner. Use this ci cd answer to show the decision, trade-off, and evidence rather than a memorised definition. It also connects test automation to the point an interviewer is testing.
Your pipeline deploys using a long-lived cloud access key stored as a CI secret. What would you change and why?
Replace the stored key with OIDC federation so each job exchanges a short-lived signed token for temporary credentials, then make the trust policy specific to a repository, branch or environment. Also narrow the pipeline's own token, pin third-party steps to commit SHAs, and attest what you built.