Top 30 Advanced CI/CD & Automation Interview Questions and Answers
30 advanced multiple-choice CI/CD & Automation interview questions, the deep end: internals, failure modes, and the design calls a senior engineer is expected to defend. They come from 30 bites in the CI/CD & Automation library, the hardest slice of the 133 CI/CD & Automation interview questions in the library. Answer them here or read straight down. Every question carries the correct option, why it is correct, and a link to the bite it came from.
GitHub Actions, Terraform, ArgoCD, IaC, pipelines
30 questions. Pick an answer, or open “Show the answer” to read it.
Answers are graded in your browser. Nothing is saved, and no XP or streak is earned here. The app keeps score.
Question 1 of 30
A platform team notices their pipeline is consistently green, but lead time for changes has grown from hours to days. Which diagnostic approach best aligns with value stream thinking?
Show the answer
Answer: d · Decompose lead time into queue, active pipeline, and post-pipeline release intervals
Decomposing lead time reveals whether waste hides in pre-merge queues, slow green stages, or post-merge deployment friction. Investigating test flakiness is tempting but misguided because a green pipeline rules out build failures as the cause.
Read the full bite: Pipeline is green but lead time grows. Three areas to investigate?
Question 2 of 30
Which scenario best illustrates a fundamental CI/CD difference between monoliths and microservices regarding blast radius and artifact indivisibility?
Show the answer
Answer: a · A microservice team deploys a signed container side-by-side with the previous version, while a monolith rollback requires reverting the entire application
This captures the core idea that monoliths produce a single indivisible artifact requiring full rollback, while microservices support independent side-by-side deployments with signed images. Option C reverses these architectures and promotes the shared-pipeline anti-pattern the card explicitly warns destroys team autonomy.
Read the full bite: How does your CI/CD strategy differ between monoliths and microservices?
Question 3 of 30
Which characteristic of blue-green deployment most directly enables sub-minute rollback during a failed release?
Show the answer
Answer: c · The blue environment remains fully operational and ready to receive traffic after cutover.
The card states that because the old environment stays warm, rollback is a single traffic switch rather than a redeploy. Option A describes a canary release, which reuses the same infrastructure and gradually shifts traffic, making it a common misconception rather than true blue-green behavior.
Question 4 of 30
After force-pushing a Git history rewritten with git-filter-repo to remove leaked credentials, why must teammates delete their local clones and re-clone rather than pull?
Show the answer
Answer: a · A pull-and-push from their stale local branch would recontaminate the remote with the old commits containing the secret
The card explicitly warns that a teammate who pulls and then pushes from a stale local clone will reintroduce the old commits containing the secret back to the remote. While reflogs retain local history, the critical blast radius is recontamination of the shared repository, not a local merge issue.
Read the full bite: How do you fully remove leaked credentials from Git history?
Question 5 of 30
In a CI/CD context, why does merging an upstream dependency change naturally trigger the parent pipeline with git subtree but not with git submodules?
Show the answer
Answer: b · Subtree creates a new commit in the parent repository when merging the dependency, while submodules only update a pointer requiring a separate superproject commit.
Subtree creates an actual commit in the parent repository when a dependency is merged, which CI systems detect as a repository change, whereas submodules only update a pointer file and require an explicit superproject commit to register. Distractor C describes a real submodule checkout failure mode but confuses clone-time behavior with pipeline trigger semantics.
Read the full bite: Compare git submodules and git subtree for CI/CD
Question 6 of 30
When integrating artifact signing into CI/CD, what is the primary security reason to move signing operations from the build runner to a remote KMS or HSM?
Show the answer
Answer: a · To ensure the private key never touches disk on ephemeral compute treated as untrusted
The card treats build runners as untrusted ephemeral infrastructure, so keeping the private key on a remote KMS or HSM prevents exfiltration if the runner is compromised. Option C is tempting but wrong because signature verification at deploy time must remain a hard gate regardless of how signing is performed.
Read the full bite: How would you integrate artifact signing into CI/CD and secure the keys?
Question 7 of 30
In an automated rollback pipeline triggered by a failed canary smoke test, which step must occur before redeploying the last known good release?
Show the answer
Answer: c · Shift traffic back to the stable baseline and freeze the canary progression
The card states that traffic isolation—freezing the canary and shifting traffic to the stable baseline—must happen before any rollback begins to minimize blast radius. Running health checks against the previous release is part of post-redeploy verification, while manual approval or in-place patches break the automated safety contract.
Read the full bite: Smoke test fails after canary deployment. Design the automated rollback.
Question 8 of 30
Which strategy best balances immediate pipeline unblocking with sustainable reduction of E2E flakiness at scale?
Show the answer
Answer: b · Baseline flakiness rates, auto-quarantine chronic offenders from presubmit, and fix root causes like concurrency
Baselining metrics and quarantining chronic offenders targets root causes while protecting presubmit integrity. Relying solely on retries masks flakiness, delays detection of real breakages, and never reduces the overall flakiness rate.
Read the full bite: How would you diagnose, report, and mitigate E2E flakiness at scale?
Question 9 of 30
Which sequencing of supply chain controls in CI/CD achieves non-repudiable artifacts and automated gating before production deployment?
Show the answer
Answer: c · Generate an SBOM and provenance attestation at build time, sign the artifact immediately after build with ephemeral keyless credentials, scan the packaged image in the registry against severity thresholds, enforce automated policy gates combining signature and scan results before production promotion, and validate signatures at deploy time via an admission controller.
Option C is correct because it sequences SBOM generation, immediate ephemeral signing, registry scanning, automated policy gating, and deploy-time admission control as required for defense-in-depth. Option D is tempting because it includes SBOMs and registry scanning, but storing a persistent private key in CI and skipping runtime verification breaks non-repudiation and leaves production exposed to registry compromise.
Read the full bite: Integrate artifact signing and vulnerability scanning into CI/CD
Question 10 of 30
A transitive dependency two levels deep has a critical CVE. Which approach best identifies all affected production services and blocks vulnerable deployments?
Show the answer
Answer: c · Query the immutable artifact repository using build-time SBOMs to map the blast radius, enforce quarantine gates in CI, and correlate with runtime inventory
Build-time SBOMs and immutable artifact metadata enable precise reverse lookup from a CVE to affected artifacts and automated CI gates that block promotion before deployment, whereas relying solely on runtime scanning detects the vulnerability too late and does not prevent initial rollout.
Question 11 of 30
When an arm64 node pulls a multi-arch image by tag, what does the registry ultimately return?
Show the answer
Answer: a · The matching architecture-specific manifest so only relevant layers are fetched
The card states that after platform content negotiation via headers, the registry returns the matching manifest from the index, not the entire index or a monolithic bundle. While the tag resolves to a manifest list, the node only fetches the manifest and layers for its own architecture.
Read the full bite: How do you manage multi-arch container images under a single tag?
Question 12 of 30
Which strategy best standardizes a new CI/CD stage across hundreds of microservices while avoiding per-repository pipeline edits and uncontrolled blast radius?
Show the answer
Answer: d · Publish a new versioned template and progressively enroll services after canary validation against a subset
Versioned templates with progressive canary enrollment decouple updates from service repos and limit blast radius, whereas forcing consumption of the latest tag risks breaking every build simultaneously without validation.
Question 13 of 30
A team accepts external pull requests on a public repository. Which pipeline configuration best defends against secret exfiltration from a malicious fork PR while preserving contribution workflow?
Show the answer
Answer: c · Use Microsoft-hosted agents for fork builds, disable secrets for untrusted PRs, and require manual trigger via PR comment
Using Microsoft-hosted agents for forks, disabling secrets, and requiring manual triggers isolates untrusted code from corporate networks and credentials. The most tempting distractor pairs branch policies with automatic fork builds, which still lets a malicious PR execute immediately and exfiltrate any reachable secrets.
Read the full bite: Discuss security implications of developer-defined PaC pipelines
Question 14 of 30
What is the most significant downside of dynamically generating CI/CD pipelines from repository contents?
Show the answer
Answer: d · The effective pipeline is not visible in the repo, hurting transparency, debugging, and auditability
Generated pipelines trade explicitness for convenience: developers cannot read their real pipeline from a checked-in file, which complicates debugging, reproduction, and security auditing. Parallelism, Docker builds, and speed are not inherently blocked.
Question 15 of 30
A Terraform apply fails midway, leaving some resources updated and others untouched. What is the first step in a mature operational response?
Show the answer
Answer: c · Lock the state file and inspect what changed before deciding to roll forward or back
Locking the state and inspecting the exact inventory of changes prevents concurrent modifications and deepened inconsistency, whereas rerunning apply immediately is dangerous because it can compound partial state or trigger cascading failures without diagnosing the root cause.
Read the full bite: Infrastructure apply fails midway. What is the state and your immediate steps?
Question 16 of 30
A team uses Terraform remote-exec provisioners to install software and apply security baselines on newly created VMs. What is the primary architectural risk?
Show the answer
Answer: d · It bakes mutable configuration into the provisioning layer, breaking immutability and creating hidden dependencies.
Remote-exec provisioners merge day-1 mutable setup into day-0 immutable orchestration, producing hidden dependencies that Terraform cannot track or reconcile. While storing SSH keys in state is a security concern, it is a secondary operational issue rather than the core architectural anti-pattern.
Read the full bite: Compare Terraform and Ansible: when to use each and both together
Question 17 of 30
Which break-glass workflow best satisfies zero-standing-access requirements when manual production secret access is unavoidable?
Show the answer
Answer: b · Require two senior staff approvals for a one-hour scoped session, record the session, and rotate the secret immediately after use.
Option B is correct because it enforces dual-control approval, time-bound scope, session recording, and immediate rotation as described in the card. Option D lacks dual-control and grants excessive duration, while Option C exemplifies the common mistake of delivering credentials to a laptop despite encryption at rest.
Read the full bite: Prevent developer access to production secrets while preserving debuggability
Question 18 of 30
In a GitOps workflow, how do you supply a database password to a Helm chart without exposing it in release metadata or requiring the app to reload file-based secrets?
Show the answer
Answer: a · Use the Vault Secrets Operator to sync the password into a Kubernetes Secret that the chart mounts by name
Vault Secrets Operator keeps the credential out of Helm values entirely, preventing exposure in release metadata, while native Secret mounts avoid file-reload logic. SOPS-encrypted values are decrypted before Helm consumes them, so the plaintext password still ends up stored in Helm release metadata.
Read the full bite: How do you securely manage and inject Helm secrets in CI/CD?
Question 19 of 30
A team moves a database password from a Deployment's env block into a Kubernetes Secret referenced via envFrom. Which statement accurately describes the remaining and mitigated risks?
Show the answer
Answer: c · The password remains visible in the container's process environment, but it is decoupled from version control and still base64 in etcd readable by the kubelet and authorized identities.
Moving the password into a Secret removes it from the manifest and version control, but because it is still referenced via envFrom it remains in the container's process environment; furthermore, Secrets are stored as base64 in etcd by default and are readable by the kubelet and any authorized identity in the namespace. Option D is tempting because it correctly notes the decoupling from Git but falls into the common misconception that Secrets are encrypted by default and invisible to nodes.
Read the full bite: Compare Kubernetes Secrets versus environment variables for Pod credentials
Question 20 of 30
A container is repeatedly OOMKilled. Which approach correctly diagnoses and fixes it?
Show the answer
Answer: b · Correlate the memory limit with container_memory_working_set_bytes, set requests near the p95 baseline, and raise limits above requests with headroom while distinguishing leaks from spikes.
The correct answer is B because OOMKilled occurs when a container's working set exceeds its cgroup limit, so you must profile working set, set requests to the measured baseline for accurate scheduling, and raise limits with headroom. Option D is wrong because requests do not create a cgroup boundary or cap runtime usage; only limits enforce the hard memory cap that triggers the OOM killer.
Read the full bite: How do you diagnose and fix a Kubernetes OOMKilled application?
Question 21 of 30
In a zero-downtime rolling update, what is the primary purpose of configuring a preStop sleep hook?
Show the answer
Answer: a · It delays SIGTERM briefly so endpoint removal can propagate before draining starts
The preStop hook sleeps before SIGTERM to allow the Service endpoints controller and load balancers to stop sending new traffic to the pod before it begins draining. Distractor A describes terminationGracePeriodSeconds, which governs the SIGTERM-to-SIGKILL window, not the endpoint propagation delay.
Question 22 of 30
When migrating a payment service to a new framework, how can you measure latency under production load without risking duplicate charges or user impact?
Show the answer
Answer: c · Shadow deployment mirroring production traffic to an isolated clone while ensuring mirrored requests cannot trigger side effects like duplicate payments
Shadow deployment mirrors production traffic to an isolated clone, letting you measure latency without user impact as long as you prevent side effects like duplicate payments. Canary deployment is tempting but wrong because it routes real users to the new version, inherently exposing them to risk and potential duplicate charges rather than isolating them.
Read the full bite: Canary vs shadow deployments: use cases and requirements
Question 23 of 30
During a failed blue/green switch-over where blue has been partially decommissioned, when is it appropriate to pivot to a forward fix on green?
Show the answer
Answer: b · Only after confirming blue is truly unusable and cannot be revived for rapid router-level rollback
The card emphasizes that rapid router-level rollback is the pattern's fundamental value, so you should revive blue if any capacity remains and only pivot to green when blue is truly unusable. Option A is wrong because it skips the critical assessment step, and C is wrong because it abandons the fastest recovery path based on bug type rather than blue's operational state.
Question 24 of 30
A flaw is found in a feature rolling out to 5% of users. Which approach preserves the canary metrics and Progressive Delivery model?
Show the answer
Answer: b · Deploy the fix behind a separate feature flag to the existing canary cohort, then jointly promote both changes.
Deploying the fix behind a separate flag to the existing canary cohort decouples deploy from release, preserves live metrics, and lets both changes advance together. Rolling back destroys the canary state and conflates deployment with release, which breaks the Progressive Delivery model.
Read the full bite: How do you deploy a hotfix during a multi-stage canary release?
Question 25 of 30
You need to block privileged containers from reaching the cluster through your deployment pipeline. Which approach correctly applies Kubernetes admission controls as a preventive gate?
Show the answer
Answer: c · Apply Pod Security Admission with the restricted profile and use a ValidatingAdmissionWebhook to reject violating manifests before they persist to etcd.
Pod Security Admission at the restricted level and a ValidatingAdmissionWebhook enforce policy before objects reach etcd, serving as a true preventive gate. Relying solely on a MutatingAdmissionWebhook is dangerous because it does not block intentionally malicious manifests and can silently violate security intent.
Read the full bite: How would you use a Kubernetes Admission Controller as CI/CD security gate?
Question 26 of 30
When correlating deployment events with observability metrics across distributed systems, how should you handle potential clock skew?
Show the answer
Answer: d · Use bounded time windows, monotonic clocks, or NTP synchronization
Bounded time windows, monotonic clocks, or NTP synchronization explicitly reconcile differences between the CI/CD and observability agent clocks. Trusting a single global timestamp ignores cross-region skew and processing delays, which is a red flag.
Read the full bite: Design a system correlating CI/CD deployments with observability metrics
Question 27 of 30
When automating canary analysis across dozens of high-volume metrics, which practice best prevents trivial differences from blocking deployments while still catching genuine regressions?
Show the answer
Answer: c · Smooth with moving medians, trim outliers via MAD thresholds, run Mann-Whitney U per metric, and require both Bonferroni-adjusted significance and a minimum effect size to feed into an aggregate scoring model
The correct approach combines smoothing, outlier rejection, non-parametric testing, multiple comparison correction, and effect-size gating into an aggregate score to distinguish real regressions from noise. Option A is tempting because it uses the right test and correction, but without an effect-size gate, high-volume traffic makes trivial differences statistically significant, causing false alarms.
Read the full bite: What statistical methods automate canary-baseline comparison and handle noise?
Question 28 of 30
Which architecture best provides real-time CI/CD health across hundreds of microservices while preserving team autonomy?
Show the answer
Answer: a · Standardize on a canonical event schema fed into an event bus, compute platform-level SLIs, and present domain-level dashboards while teams retain their existing tools
Canonical events decouple data contracts from tools, enabling real-time platform-level SLIs without forcing teams off their existing CI/CD stacks. Standardizing on a single platform (C) is a tempting shortcut, but it destroys autonomy and ignores sunk costs and specialized workflows.
Read the full bite: How do you unify real-time CI/CD health across hundreds of microservices?
Question 29 of 30
In a GitOps pipeline deploying a microservice to Kubernetes, which approach best handles database schema migrations while preserving declarative source-of-truth principles?
Show the answer
Answer: d · Version migration files in Git and execute them through an idempotent pre-sync job using a dedicated schema tool, separate from infrastructure provisioning
Versioned migration files executed by a dedicated schema tool via a pre-sync hook preserve Git as the source of truth while ensuring the schema is ready before the app starts. Using a Terraform SQL provider to manage live schema state incorrectly couples infrastructure provisioning with imperative data lifecycle operations and risks partial failures.
Read the full bite: Describe a robust strategy for GitOps database schema migrations
Question 30 of 30
In a hub-and-spoke GitOps cluster lifecycle workflow, how should day-two addons like CNI or CSI drivers be delivered to ephemeral workload clusters?
Show the answer
Answer: c · Store addon definitions in Git and have the management cluster's Flux apply them via HelmRelease or Kustomization resources using workload cluster KubeConfig secrets
The management cluster's Flux reconciles addon manifests from Git and pushes them to each ephemeral workload cluster using stored KubeConfig secrets, keeping delivery declarative and auditable. Running an agent inside the workload cluster it manages is a bootstrap error, because that cluster may not yet exist or may be torn down, breaking the GitOps loop.
Read the full bite: How would you use GitOps to manage Kubernetes cluster lifecycles?
Could you explain these out loud?
That is what an interview actually tests. Tezvyn gives you questions like these with 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.