CI-CD Pipelines interview questions: pipeline-as-code

False. Pipeline-as-code version-controls the pipeline's structure, not its secret handling — a literal value written into a YAML file is stored, and remains, as plain text in the repository and in every commit in its history, private repo or not. Real secrets handling means referencing a platform secret store (secrets.DEPLOY_KEY in GitHub Actions, a masked CI/CD variable in GitLab, a Jenkins credentials() binding) so the pipeline file only ever contains a name, never the value. A private repo restricts who can read the file at all, but it does nothing to encrypt what's already written inside it — and once a literal secret is committed, rotating it and scrubbing history is the only real fix.

The core idea is that the pipeline definition is source-controlled alongside the application, so it gets the same review, history, and reproducibility as any other code. The practical payoff — and the usual interview follow-up — is auditability and disaster recovery: a UI-clicked pipeline has no diff, no review, and vanishes with the server, whereas pipeline-as-code is just another file you can restore, branch, and roll back.

Both major platforms have dedicated static validation for pipeline definitions: actionlint parses GitHub Actions workflow YAML against its schema and catches invalid expressions, undefined contexts, and shellcheck issues in run: steps, while GitLab exposes a CI Lint endpoint (and a 'Validate' UI tab) that checks .gitlab-ci.yml syntax and merges includes without running the pipeline. npm audit checks package vulnerabilities, not pipeline YAML, and there's no .yaml.lock auto-validation convention — those are invented distractors. Catching structural errors here is far cheaper than discovering them via a failed live run.

The whole point of pipeline-as-code is that the file is versioned — which is exactly why a literal secret written into it is a serious problem: it's now permanently in git history, readable by anyone with repo access, and can't be revoked just by editing the file (a later commit still leaves the old value reachable in history). The fix is Jenkins's credentials() helper, which binds a credential stored in Jenkins's credential store to an environment variable at runtime — AWS_SECRET_ACCESS_KEY = credentials('aws-secret-access-key-id') — so the Jenkinsfile only ever contains a credential id, never the value. The other options describe non-issues: agent any, a top-level environment {} block, and sh steps inside stages are all valid, ordinary declarative-pipeline syntax.

The two live at different levels of the pipeline. A composite action is step-level reuse — it executes inline in the calling job, so it shares that job's runner and environment but must receive secrets as declared inputs rather than reading secrets.* directly. A reusable workflow is job-level (or whole-pipeline-level) reuse: called via jobs.<id>.uses: org/repo/.github/workflows/file.yml@ref, it spins up as an independent job with its own runs-on, and can accept a secrets: inherit shortcut precisely because it's a distinct job boundary, not an inline step. Confusing the two is a common source of 'why can't my composite action see this secret' bugs.

Reusable workflows are called at the job level, not the step level: the calling job's only key is uses: pointing at the workflow file (plus optional with:/secrets:), and GitHub runs it as its own job. That's the structural tell that separates a reusable workflow from a composite action, which is called as a step. Putting the call in steps: (b) is the composite-action pattern and fails schema validation for a workflow_call file; on: (c) declares what triggers a workflow, it isn't how you invoke one; needs: (d) only declares job-ordering dependencies, not a call.

extends and reusable workflows are the two platforms' native mechanisms for defining shared configuration once and reusing it everywhere else, which is exactly what DRY means for pipeline-as-code. Copy-pasting a block into every repo is the opposite of DRY — it's the duplication these features exist to remove, and it means every future change has to be repeated N times by hand. Hardcoding a different literal secret per file isn't a DRY concern at all (secrets shouldn't be literal values in the file to begin with) and duplicates effort rather than removing it.

The mature answer names an actual tool (actionlint / GitLab CI Lint) rather than 'just be careful', and explains the real reason a live run is a poor validation gate: it can carry side effects (deploys, spend, shared-state mutation) and only exercises the one code path that happened to trigger, not every branch or condition the pipeline could hit. Candidates who only say 'run it and see' haven't thought about the blast radius of validating a deploy pipeline by actually deploying.

Changing a template that many repositories depend on needs the same staged-rollout discipline as any shared dependency: change it in isolation, validate the change before anyone consumes it, publish it as a new version rather than force-moving the old one (so nothing breaks for consumers still pinned to v1), prove it on a single low-risk consumer, then propagate. Force-moving the existing tag to point at new code, or rolling out to every consumer at once, both remove the safety net a versioned template exists to provide — a bad change would break everyone simultaneously instead of surfacing on one pilot repo first.

Drift happens whenever platform-side state that affects pipeline behavior lives outside the versioned files. GitHub Environment protection rules (required reviewers, wait timers) are configured entirely through Settings, not through workflow YAML, so a repo's real approval gate can be invisible to anyone reading the code. Branch-protection required-status-checks reference job names as strings maintained in Settings; if a job is renamed in the YAML, the branch-protection entry silently goes stale and permanently blocks pull requests waiting on a check that will never report — a well-documented GitHub gotcha. Pinning to a SHA is the opposite of a drift risk — it's a supply-chain hardening practice that makes behavior more predictable. Running a workflow locally with act only previews a run; it never touches platform configuration, so it can't cause drift.