DevOps pipeline-as-code interview questions

Pipeline-as-code means defining CI/CD pipeline configuration in version-controlled text files such as YAML or Groovy, rather than configuring it manually through a web UI. This lets teams review, branch, and reproduce their build and deployment workflows exactly like application code.

Pipeline as code means defining the CI/CD pipeline in a version-controlled configuration file, such as a YAML file, stored in the same repository as the application source code. Because the pipeline definition is versioned, changes can be reviewed, diffed, and rolled back like any other code.

The top-level key is on. For example, on: push means the workflow runs when a push event occurs.

Hypertext Transfer Protocol

Pipeline-as-code lets you version, review, and branch pipeline changes alongside application code. Because the pipeline definition lives in a committed file (e.g., Jenkinsfile or .gitlab-ci.yml), every modification goes through the same code-review and history workflow as source code, giving you traceability, reproducibility, and team collaboration that a web-UI configuration cannot match.

The test stage. GitLab CI/CD's built-in default stages are .pre, build, test, deploy, and .post, and a job with no stage keyword is placed in test.

In a standard linear pipeline defined in .gitlab-ci.yml, the stages run in this order: check out source code, compile the application, run automated tests, deploy to staging, and deploy to production. Each stage must complete before the next begins, so code reaches production only after it has been built and validated.

Storing the pipeline definition in version control alongside source code lets the pipeline itself go through the same pull-request review, branch protection, audit history, and rollback processes as application code, making the CI/CD process reproducible, reviewable, and consistent across environments.

Conditional execution (gating) is the core mechanism: the deployment job only runs when a defined condition evaluates to true. Common implementations include environment-based approvals (requiring manual sign-off before production), branch filters (deploy only from the main branch), and status checks (deploy only after all upstream test jobs pass). These let teams encode safety policies directly in the pipeline definition.

The correct order is: checkout source → build → integration testing against the built artifact → deploy to staging → deploy to production. You must check out source before compiling; you must build the artifact before running integration tests against it; integration tests must pass before deploying to staging; and staging must be validated before promoting to production.

The CI/CD system reads the pipeline definition file from the commit that triggered the run and executes the stages, jobs, and steps exactly as defined in that version of the file. Each pipeline run therefore uses the definition as it existed at the commit being built, not a shared or centrally managed copy. If a feature branch modifies the file, that branch's pipeline uses the modified definition, which is what makes pipeline changes safe to review through pull requests.

Pipeline-as-code stores the pipeline definition as a text file in the application's repository, so it is versioned, diffable, and reviewable through pull requests like any other code. A UI-configured pipeline keeps its definition inside the CI/CD tool's database, where those changes are harder to track and review.

The needs keyword declares that a job depends on other named jobs, so it does not start until those jobs have completed successfully. This lets the pipeline run as a directed acyclic graph (DAG) of job dependencies: independent jobs run in parallel, and a dependent job such as deploy waits only for the jobs it needs, such as test, rather than for an entire stage.

Two concrete advantages: (1) Version history and auditability: every change to the pipeline is tracked in Git with a commit hash, author, timestamp, and diff, so you can see exactly when and why a pipeline stage was added or modified and roll back to any previous version. (2) Peer review through pull requests: proposed pipeline changes can be reviewed and approved by teammates before merging, so a risky change (such as adding a deploy step or changing environment variables) is caught and discussed before it reaches the main branch. UI-configured pipelines lack both of these because their configuration lives in the CI/CD tool's database, not in version control.

The build stage compiles source code (if applicable), installs dependencies, and packages the application into a deployable artifact, such as a container image, a JAR/WAR file, a bundled static asset directory, or a compiled binary. The output artifact is stored or cached so that downstream stages (test, deploy) use the exact same artifact rather than rebuilding it, which ensures consistency between what was tested and what is deployed.

A change to the shared library's default branch can modify every consuming pipeline with no commit in any application repository. Because library 'shared-pipeline-lib' specifies no pinned version, Jenkins resolves the library from its default branch at each build, so the library and the Jenkinsfile are not coupled to the same commit and the library's changes are reviewed in its own repo, not the application's.

In a well-designed pipeline-as-code workflow, each pipeline stage should be idempotent: re-running the stage on the same commit (or re-triggering the entire pipeline) should produce the same end state without accumulating side effects such as duplicate deployments or appended artifacts. This property makes stages safely retriable and the pipeline reproducible.

Pipeline-as-code defines the CI/CD pipeline as version-controlled text files, such as a Jenkinsfile or GitLab CI YAML, stored in the application's repository. This lets pipeline changes be reviewed, branched, and tracked like source code, whereas a UI-configured pipeline keeps its settings in the CI/CD tool's internal database.

We introduce a single reusable workflow at .github/workflows/ci.yml that acts as the shared entry point for every team's pull request and push events. This reusable workflow calls a set of composite actions organized by concern: setup (toolchain + caching), security-scan (SAST, dependency scanning, secret detection), build, test, and publish. Per-team customization is achieved through convention-based discovery: each team's package directory contains a .ci/build.sh and .ci/test.sh (or a ci-config.yml declaring custom steps). The reusable workflow dynamically includes these scripts at the appropriate stage using working-directory and conditional job steps. Teams that need entirely custom logic can supply a composite action at packages/<team>/.ci/custom-action/ that the shared workflow invokes if present, keeping the security baseline (SAST, dependency scanning) non-negotiable while allowing build/test flexibility.

Secrets are managed centrally: organization-level secrets store shared credentials (e.g., artifact store, vault endpoint), and per-team secrets are scoped to GitHub Environments mapped to each package path via deployment-environment naming conventions. For sensitive infrastructure, we federate with OIDC to HashiCorp Vault, issuing short-lived, per-team roles so no static credentials live in GitHub. The reusable workflow references ${{ secrets.* }} only through the environment-scoped injection, preventing teams from accessing each other's secrets.

Runtime reduction comes from three techniques. First, dependency and build-output caching via actions/cache keyed on lockfile hashes, plus Docker layer caching for containerized builds. Second, selective execution: we use dorny/paths-filter or tj-actions/changed-files to detect which packages changed and dynamically generate a matrix of only the affected packages, skipping build/test for unchanged areas. Third, test parallelism: each package's test suite is split into shards using a matrix strategy (e.g., shard: [1/4, 2/4, 3/4, 4/4]) with a test-splitter tool, and independent packages run concurrently as separate matrix entries.

Rollout is phased: we start with two pilot teams, running the new GitHub Actions pipeline in shadow mode alongside their existing Jenkinsfile for two weeks. We compare results and timing, then publish a migration checklist (provide .ci/ scripts, declare environment mappings, validate secret access). Each subsequent team migrates one sprint at a time, with a 1-week overlap period where both pipelines run. A migration tracking dashboard (built from workflow run data) shows which teams have migrated, their CI time delta, and any failing checks. Legacy Jenkinsfiles are archived (not deleted) only after a team's new pipeline has been green for two consecutive weeks, preventing a big-bang failure.

Using pull_request_target and then checking out the pull request's own code is unsafe because that event runs the workflow in the base branch's context with full access to repository secrets and a write-capable GITHUB_TOKEN. Untrusted PR build steps can therefore read and exfiltrate those secrets. Use pull_request for untrusted builds, or restrict pull_request_target to non-build actions that never execute the PR's code.

The team should keep the pipeline definitions in the same Git repository as the code they build, so pipeline changes go through the same review and branch-protection process as application code and can be reverted and audited alongside it. They should also move the shared build, test, scan, and deploy steps into reusable, versioned workflows or composite actions, so the 12 services do not drift apart in their YAML and maintenance stays manageable. Finally, they should lint workflow files with actionlint or yamllint as a pre-merge CI check, so structural and syntax errors are caught at review time rather than at deploy time. An anti-pattern to avoid is hardcoding credentials, such as base64-encoded secrets, inside pipeline files; secrets should be injected at runtime from a platform secret store or external secrets manager. Another is giving the CI runner blanket admin access to the production cluster, which violates least-privilege; each stage should get only the permissions it needs, ideally through short-lived OIDC-issued credentials.

Change detection: a detect-changes job runs on push and compares github.event.before (the branch head before the push) with github.sha (the pushed head), so multi-commit pushes are covered; a paths filter such as dorny/paths-filter yields the changed top-level service directories. If common/ changed, a per-service DEPENDENCIES manifest adds every dependent service to the changed set, and only those services proceed (via a matrix). Reusable logic: one reusable workflow (workflow_call) holds the shared build, test, and deploy jobs and is parameterised by a thin per-service config (language, build command, deploy target); repeated steps live in composite actions under .github/actions/. Build once: each changed service produces a single container image tagged with the commit SHA and pushed to GHCR; dev, staging, and production deploy jobs all reference that same SHA tag, so promotion means redeploying the existing image to the next environment, never rebuilding. Prod gate: the production job declares environment: production, whose required reviewer is the team @org/on-call-approvers. Because GitHub accepts only static users or teams as reviewers, a scheduled job or PagerDuty webhook calls the GitHub Teams REST API to set that team's membership to the current on-call engineer from the rotation; the approval, approver, and timestamp are recorded in the run's audit log. Secrets: dev, staging, and production are separate GitHub Environments, each with its own scoped secrets, and a job can read only the secrets of the environment it declares. Cloud access uses OIDC with one IAM role per environment whose trust policy accepts only that environment's subject claim (for example repo:org/repo:environment:production), so the dev role cannot reach the production cluster.

Architecture Overview

The system has three layers: (1) the service manifest (team-owned, in-repo), (2) the platform render engine (platform-team-owned, in a central repo), and (3) the generated pipeline (ephemeral, never hand-edited).

1. Service Manifest (service.yaml)

Each repo contains a minimal manifest:

apiVersion: platform.io/v1
kind: ServicePipeline
metadata:
  name: payments-api
  team: payments
spec:
  build:
    type: gradle
    runtime: java21
  deploy:
    environments: [dev, staging, prod]
    strategy: blue-green
    healthCheckPath: /actuator/health
  # Teams CANNOT declare gates here — gates are platform-controlled.
  extensions:
    - name: integration-test-sandbox
      uses: platform-gates/custom-integration-test@v3
      with:
        sandboxUrl: https://sandbox.example.com

The manifest declares what the service is and where it deploys, but never what gates run. The extensions field is the only extensibility point and can only reference platform-approved, SHA-pinned reusable components.

2. Platform Render Engine

A central repository (platform-pipelines) contains:

• A set of reusable workflow templates (GitHub Actions reusable workflows, or Tekton Pipeline definitions) one per lifecycle stage: build, security-gates, deploy.
• A render CLI (platform-pipeline) that reads a service.yaml, validates it against a JSON schema, and emits the final pipeline file (e.g., .github/workflows/generated-ci.yml) — though in practice the workflow is a thin stub that calls the platform's reusable workflows.

The actual generated workflow is a minimal stub:

name: CI
on:
  push: { branches: [main] }
  pull_request: {}
jobs:
  ci:
    uses: platform-org/platform-pipelines/.github/workflows/[email protected]
    with:
      manifestPath: service.yaml
    secrets: inherit

This stub is the only thing in the service repo's .github/workflows/ directory. It delegates entirely to the platform workflow.

3. Non-Bypassable Mandatory Gates

The platform reusable workflow ([email protected]) is the single source of truth for gate ordering and enforcement. It:

• Runs SAST (Semgrep), dependency scanning (Trivy), and container image signing (cosign) as required steps — they are hardcoded in the platform workflow and cannot be disabled by the manifest.
• The prod deploy job requires an environment: production approval gate configured at the GitHub org level with required reviewers.
• Branch protection rules (enforced via GitHub Org settings or Terraform-managed) mark the platform workflow's status checks as required. Since the stub workflow always delegates to the platform workflow, the checks always come from the platform — a team cannot substitute their own workflow that skips gates because the required-status-check names are pinned to the platform workflow's job names.

If a team removes the stub workflow or the manifest, branch protection prevents merges because the required checks never report.

4. Secret Scoping and Delivery

Secrets are stored in HashiCorp Vault, organized by path: secret/data/payments/dev, secret/data/payments/staging, secret/data/payments/prod. The platform workflow authenticates to Vault using OIDC federation — the GitHub Actions job exchanges its OIDC token for a short-lived Vault token scoped to that team's environment path. No static credentials exist in GitHub Actions secrets. The manifest's deploy.environments field determines which Vault paths the platform workflow requests, so a dev-only service cannot access prod secrets.

5. Centralized Gate Rollout

To add a new mandatory gate (e.g., SBOM generation):

1. The platform team adds the step to service-ci.yml in the platform-pipelines repo.
2. They tag a new version (e.g., v14.3.0) and update a version manifest (a single file in the platform repo, or an org-level variable) that the render CLI reads.
3. On the next pipeline run, each service's stub workflow resolves @v14.3.0 (if using a moving tag) or the render CLI is re-run to bump the SHA-pinned reference.

Using a moving tag (@v14) means all services pick up the new gate automatically on their next push. Using SHA-pinning with a renovate bot bumping the SHA across all repos provides supply-chain security while still automating rollout.

6. Local Dry-Run

The render CLI supports:

platform-pipeline validate --manifest service.yaml   # schema validation
platform-pipeline render --manifest service.yaml --dry-run  # emits full pipeline to stdout
platform-pipeline render --manifest service.yaml --output .github/workflows/generated-ci.yml

Teams run validate and render --dry-run in a pre-commit hook or local dev workflow. The CLI is distributed as a container image and a Homebrew formula, versioned to match the platform workflow tag.

7. Incremental Migration

• A migration dashboard (backed by a scan of all repos for service.yaml presence) tracks adoption.
• Teams opt in by adding a service.yaml and the stub workflow. Legacy pipelines continue to run in parallel.
• Branch protection is updated per-repo to require the platform checks only after the team confirms the new pipeline is green.
• A sunset date (e.g., 90 days out) is communicated for legacy pipeline support, after which the platform CI runners stop accepting non-platform workflows.
• The platform team provides a migration generator that analyzes an existing Jenkinsfile/GitHub Action and produces a best-effort service.yaml to reduce manual work.

Repository layout: each service lives under services/<team>/<service>/ with its own .pipeline.yml for service-specific build, test and deploy steps. A separate infra/ directory owned by the platform team holds a versioned shared CI/CD library (for example a GitLab CI template project or a GitHub Actions reusable-workflow repository) that defines the compliance gates as mandatory steps. (a) The top-level pipeline file is platform-controlled and includes the team's service pipeline as a child, wrapping it with pre-deployment gates; teams can add steps but cannot reorder or remove the gate sequence. (b) Enforcement: CODEOWNERS requires platform-team approval for changes to infra/ and the top-level pipeline file, and branch protection with required status checks means the gate jobs must succeed before merge and deploy; the gates run in a pipeline stage the service config cannot edit. (c) Reuse: the shared library exposes parameterized templates (build, test, deploy) that teams include by reference. (d) Rollout: the library is semver-versioned and imported by reference (e.g. ref: v2.3.0); the platform team publishes a new version and updates the default reference in the platform-owned top-level config that every service inherits, so no per-team PR is needed; teams needing stability can pin a major version. Multi-cloud: deploy templates take cloud_provider and environment inputs and hide AWS vs GCP specifics behind a common interface; credentials, regions and cluster endpoints come from a central secrets manager such as HashiCorp Vault, keyed by environment and provider, never stored in the repo. (e) Audit: at execution time the fully resolved pipeline definition (after includes and template expansion) is serialized and its SHA-256 hash is stored with the build artifact in the artifact registry; the deployment metadata records that hash, the shared library version and the Git commit SHA, plus the compliance gate results, giving an immutable link from each production deployment to the exact pipeline definition that produced it.

Path-based triggering via a service-to-directory mapping, dependency-graph traversal that finds services transitively depending on a changed shared library, and diffing against the merge-base are correct for selective pipeline execution. The claim that selective execution removes the need for integration testing before production is false, since it only shortens CI feedback time.