Each test is 5 questions with varying difficulty.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.
Continuous Integration and Continuous Deployment (CI/CD) represents the operational backbone of modern software engineering. In 2026, CI/CD has evolved far beyond simple bash scripts triggering on git commits, it now encompasses complex, containerised, event-driven pipelines that build, test, scan, and deploy software across multi-cloud environments with full observability and security controls.
CI/CD interview questions assess a candidate's ability to design reliable delivery pipelines, not just configure them. Junior engineers are expected to understand pipeline triggers, stages, artifact management, and basic secrets handling. Mid-level engineers must reason through caching strategies, parallel test execution, environment promotion, and deployment strategies like blue-green and canary. Senior engineers are assessed on DORA metrics, GitOps patterns, self-hosted runner architecture, OIDC authentication, and pipeline security hardening.
This topic is critical for DevOps Engineers, Platform Engineers, and any Software Engineer working in a team that ships code frequently. A strong understanding of CI/CD signals engineering maturity, the ability to ship reliably, recover quickly, and maintain quality.
The engineering and business value of robust CI/CD is directly measurable through DORA (DevOps Research and Assessment) metrics. Elite engineering organisations achieve deployment frequencies of multiple times per day, lead times for changes under one hour, change failure rates below 5%, and mean time to recovery (MTTR) under one hour. These are not aspirational numbers, they are the direct outcome of well-engineered CI/CD pipelines.
From a security perspective, CI/CD pipelines are now a primary attack surface. The SolarWinds and 3CX supply chain attacks exploited compromised build pipelines to inject malicious code. This has driven widespread adoption of SLSA (Supply-chain Levels for Software Artifacts) frameworks, hermetic builds, signed artifacts, and OIDC-based ephemeral credentials. Engineers who understand these controls are increasingly valuable.
As an interview topic, CI/CD reveals engineering operational maturity. A candidate who can design a pipeline with proper caching, parallelism, environment promotion gates, and rollback strategies demonstrates they have shipped software at scale, not just written it. The shift from push-based to pull-based GitOps deployments (ArgoCD, Flux) is a key differentiator between junior and senior pipeline engineers in 2026.
The architecture of a modern CI/CD system is event-driven and decoupled. It begins with a developer action (such as a git push or pull request) that triggers a webhook. The CI/CD orchestrator processes this webhook, evaluates the pipeline configuration file, and schedules jobs on available runners. Runners can be SaaS-hosted or self-hosted, ephemeral or persistent. The runner executes the steps sequentially inside isolated environments (containers or virtual machines), interacting with external systems like artifact registries, secret managers, and cloud provider APIs. Once the build and test phases succeed, the deployment orchestrator coordinates the rollout to target environments using push-based or pull-based (GitOps) mechanisms.
[Git Push / PR Event]
↓
[Webhook Listener / Orchestrator]
↓
[Runner Provisioner]
↓
[Execution Runner]
├── [Checkout Code]
├── [Run Linter / Tests]
├── [Build Container Image]
└── [Push to Registry]
↓
[Deployment Orchestrator]
├── [Canary / Blue-Green]
└── [Production Deploy]Dividing the pipeline into distinct, sequential stages (e.g., Lint -> Test -> Build -> Deploy Staging -> Manual Approval -> Deploy Production). Each stage only executes if the previous stage passes, and artifacts are passed forward rather than rebuilt.
Trade-offs: Improves pipeline reliability and safety, but increases total execution time due to serialization and artifact transfer overhead.
Using an agent inside the target cluster (like ArgoCD) to continuously poll the git repository for changes in manifest files, pulling and applying changes automatically to match the desired state.
Trade-offs: Highly secure as it eliminates the need to expose cluster credentials to external CI systems, but introduces synchronization latency and requires strict manifest management.
Running multiple jobs in parallel across a multi-dimensional configuration grid (e.g., testing 3 different operating systems against 4 different runtime versions simultaneously).
Trade-offs: Drastically reduces overall testing time for multi-environment compatibility, but can significantly increase compute costs and runner queue utilization.
| Reliability | Ensure pipeline reliability by implementing automatic retries for transient network failures, using persistent or warm-started runners to avoid cold starts, and decoupling the CI build phase from the CD deployment phase so that deployment does not depend on external package registries being online. |
| Scalability | Scale CI/CD infrastructure by utilizing Kubernetes-based autoscaling runner pools (e.g., Actions Runner Controller) that scale dynamically based on the queue depth of pending jobs, preventing developer bottlenecking during peak hours. |
| Performance | Optimize pipeline execution speed by utilizing Docker multi-stage builds, leveraging local layer caching (`--cache-from`), minimizing build contexts using `.dockerignore`, and implementing shallow git clones (`fetch-depth: 1`) to avoid downloading historical git history. |
| Cost | Control costs by setting execution timeouts on all jobs, implementing aggressive cache cleanup policies, utilizing spot/preemptible instances for self-hosted runner pools, and restricting highly concurrent matrix builds to release branches. |
| Security | Harden pipelines by enforcing the principle of least privilege for runner credentials, using OIDC to eliminate static cloud keys, scanning source code and container images for vulnerabilities (SAST/DAST) during the build, and running self-hosted runners in isolated, ephemeral environments that are destroyed after a single job execution. |
| Monitoring | Track pipeline health using DORA metrics: Deployment Frequency, Lead Time for Changes, Mean Time to Recovery (MTTR), and Change Failure Rate. Set up alerts for consecutive pipeline failures, runner disk space exhaustion, and credential expiration dates. |
Continuous Delivery ensures that code is automatically built, tested, and prepared for release, but requires a manual trigger or approval to deploy to production. Continuous Deployment automates the entire process, meaning every change that passes all pipeline stages is immediately released to production without human intervention.
Static credentials (like AWS Access Keys) are long-lived and present a high security risk if leaked. OpenID Connect (OIDC) allows the CI/CD runner to request short-lived, temporary credentials from the cloud provider dynamically, eliminating the need to store secrets in the CI/CD platform and reducing the blast radius of a credential leak.
Cloud-hosted runners require zero maintenance, scale automatically, and are highly secure due to clean environments, but they can be expensive and lack access to private networks. Self-hosted runners are cost-effective for heavy workloads and can access private VPC resources, but they require manual patching, scaling, and security hardening.
Database migrations must be backward-compatible (using the expand and contract pattern). The migration is run before the new application code deploys. The database must support both the old and new versions of the application simultaneously, allowing safe rollbacks without data loss if the deployment fails.
In a push-based model, the CI pipeline directly executes commands (like kubectl apply) to deploy to the target cluster, requiring cluster credentials. In a GitOps (pull-based) model, an agent inside the cluster (like ArgoCD) continuously monitors a git repository containing Kubernetes manifests and pulls changes to match the cluster state, keeping credentials secure inside the cluster.
Optimize Docker builds by using multi-stage builds to minimize image size, leveraging Docker BuildKit with registry-backed caching (`--cache-to` and `--cache-from`), minimizing the build context using a `.dockerignore` file, and ordering Dockerfile instructions from least-frequently changed to most-frequently changed to maximize layer reuse.
A blue-green deployment maintains two identical physical environments (Blue for production, Green for staging). Traffic is switched 100% from Blue to Green instantly. A canary deployment incrementally routes a small percentage of production traffic (e.g., 5%, then 25%, then 100%) to the new version, allowing teams to monitor error rates and performance before a full rollout.
Harden pipelines by pinning all third-party actions to specific commit SHAs rather than version tags, restricting runner permissions using the least-privilege principle, running builds in ephemeral isolated environments, scanning dependencies for vulnerabilities (SCA), and generating signed build provenance (such as SLSA attestations).
Concurrency groups ensure that only a single job or workflow run within that group executes at any given time. This is critical during deployment phases to prevent race conditions (e.g., two pipelines trying to deploy different versions to the same environment simultaneously) and can be configured to cancel older, redundant runs automatically.
Flaky tests should be quarantined immediately by moving them out of the blocking CI gate into a separate, non-blocking pipeline. They should be tracked, debugged, and fixed. Allowing flaky tests to remain in the main pipeline erodes developer trust and leads to teams ignoring legitimate test failures.
AI Prep covers AI Agents, Generative AI, ML Fundamentals, NLP & LLMs and a lot more, with adaptive tests and daily challenges. Fully offline on Android. Free to try, one-time unlock for lifetime access.