Cicd Pipelines Practice Exam — LearnCoachAssist

Question 1 Cicd Pipelines

What is the GitLab CI needs keyword?

pull_request_target runs in the context of the target branch (e.g., main) with access to secrets, but is triggered by a PR from a fork. Danger: a malicious PR could run code that exfiltrates secrets.*. Mitigation: never echo attacker-controlled input, and explicitly actions/checkout the PR ref (not the base) only after manual approval. needs: creates directed acyclic graph (DAG) dependencies between jobs, allowing non-stage-order execution:

deploy:
  stage: deploy
  needs: [build, test]
  script: ./deploy.sh

Unlike stage ordering, needs lets deploy run as soon as its specific inputs are ready, reducing pipeline time. GitOps is a practice where Git is the single source of truth for both application code and infrastructure configuration.

Principles:

Declarative – desired state described in Git
Versioned – all changes tracked via commits
Automated – agents reconcile actual state with desired state
Observable – drift detection and alerts

Tools: ArgoCD, Flux

Instead of CI pushing deployments, a GitOps agent pulls changes and applies them to the cluster. Feature branches isolate development work in dedicated branches created from the main branch.

CI/CD integration:

Each push triggers automated builds and tests
Pull requests run status checks before merging
Branch protection rules enforce passing CI
Preview deployments for each PR

Best practices:

Keep branches short-lived (days, not weeks)
Rebase frequently from main
Delete after merging

Question 2 Cicd Pipelines

What is the difference between GitLab CI and Jenkins in pipeline-as-code?

An agent (node) is a physical or virtual machine registered with the Jenkins controller. An executor is a slot on an agent that can run one concurrent build. A 4-CPU agent typically has 4 executors. Configure executors via Manage Nodes → Configure → # of executors. All build container images without a Docker daemon, useful in CI:

Kaniko – builds in-container, no daemon, runs in k8s natively
Buildah – CLI alternative to docker build, daemonless, supports OCI
docker buildx – official BuildKit frontend, supports multi-platform builds, cache export

Choose buildx for most cases; kaniko inside cluster pods; buildah for daemonless systems. GitLab CI tightly integrates with the GitLab repo UI: pipeline runs, logs, artifacts, environments, and merge-request widgets are first-class. Jenkins is repo-agnostic and integrates with any SCM via plugins. GitLab CI uses YAML in-repo; Jenkins uses Groovy (Declarative/Scripted) in-repo. In CI shell steps:

set -e — exit on first error
set -u — error on undefined variables
set -o pipefail — pipeline fails if any command in the pipe fails (not just the last)

Default GitHub Actions shell is bash --noprofile --norc -eo pipefail {0} on Linux, so pipefail is on by default. Explicitly adding set -euo pipefail documents intent and is portable.

Question 3 Cicd Pipelines

What is the difference between a Pipeline job and a Freestyle job in Jenkins?

concurrency ensures that only one run of a workflow (or group) executes at a time, canceling or queuing the others:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Prevents wasted CI on superseded pushes and avoids race conditions in deployments. A Freestyle job is a GUI-configured job (checkboxes, text fields) — limited reusability, no version control on the job config. A Pipeline job uses a Jenkinsfile defined as code, versioned with the repo, supports complex logic, parallel stages, and reusability. New projects should use Pipeline. Ephemeral preview environments are short-lived, per-PR deployments for review. Tools: Vercel, Netlify, Render, Heroku Review Apps, Gitpod, or custom (ArgoCD PR apps). Each PR gets a unique URL, deployed automatically, destroyed on merge/close. Drastically improves design review and integration testing. max-parallel caps how many matrix jobs run concurrently. Useful when you have many combinations but want to throttle resource usage:

strategy:
  matrix: { os: [ubuntu, windows, macOS] }
  max-parallel: 2

Only 2 of the 3 jobs run at a time; the third queues.

Question 4 Cicd Pipelines

What is cancel-in-progress and when should you enable it?

Orbs are reusable packages of CircleCI configuration (jobs, commands, executors) published to the Orb Registry. Example: circleci/node@5 sets up Node, caches npm, and runs common tasks. Orbs are CircleCI's analog of GitHub Actions marketplace actions and Jenkins shared libraries. By default, artifacts are retained for 90 days. You can change this per-artifact with retention-days: on actions/upload-artifact@v4 (1-90 days for public repos, 1-400 for private/enterprise). Older artifacts are auto-deleted. Use Releases or external storage for long-term artifact storage. input is the Jenkins manual approval gate:

stage('Deploy') {
  steps {
    input message: 'Deploy to production?', ok: 'Deploy', submitter: 'admins'
    sh './deploy.sh prod'
  }
}

The job pauses until an authorized user clicks the button. Optionally bound to a timeout. cancel-in-progress: true aborts any previous in-flight run in the same concurrency group when a new one starts. Enable for: PR builds (only the latest commit matters), feature branch pushes. Disable for: production deployments, long-running release jobs where the older run might be a real release.

Question 5 Cicd Pipelines

What is pre-commit and the pre-commit framework?

pre-commit is a framework for managing multi-language git hooks via a .pre-commit-config.yaml file. Each hook is a managed environment (Python, Node, etc.) that auto-installs in its own venv. Examples: black, flake8, eslint, shellcheck, detect-secrets. Hooks run in parallel. Drone is a CI/CD product with a fixed pipeline model (YAML, Docker steps). Tekton is a CNCF framework for building CI/CD systems on Kubernetes, exposing low-level primitives (Task, TaskRun, Pipeline, PipelineRun) as Kubernetes CRDs. Tekton is more flexible but requires Kubernetes expertise; Drone is simpler but less customizable. In CI shell steps:

set -e — exit on first error
set -u — error on undefined variables
set -o pipefail — pipeline fails if any command in the pipe fails (not just the last)

Default GitHub Actions shell is bash --noprofile --norc -eo pipefail {0} on Linux, so pipefail is on by default. Explicitly adding set -euo pipefail documents intent and is portable. An agent specifies where a pipeline or stage runs. Options include:

agent any – run on any available executor
agent none – no global agent; each stage specifies its own
agent { label 'linux' } – run on a node with the given label
agent { docker { image 'node:18' } } – run inside a Docker container

Agents enable distributed builds across multiple machines.

Question 6 Cicd Pipelines

What is the GitLab CI .gitlab-ci.yml file?

Credentials in Jenkins are scoped:

System – visible to all jobs (use sparingly)
Global (default) – visible across folders/agents
Folder – scoped to a Jenkins folder

withCredentials binds a credential to an env var within a block, ensuring the secret is masked in console output. Single-line run: echo hello is one command. Block scalar run: | starts a multi-line string. The indentation of the lines below the pipe is significant — they form one block passed to the shell. Use | (literal newlines preserved) vs > (folded into one line with spaces) for shell commands. Dependency caching stores downloaded packages between pipeline runs to avoid re-downloading them each time.

GitHub Actions example:

- uses: actions/cache@v4
  with:
    path: node_modules
    key: deps-${{ hashFiles('package-lock.json') }}

The cache key uses a hash of the lock file so it invalidates when dependencies change. This can reduce build times by 50% or more. .gitlab-ci.yml at the repo root defines GitLab CI/CD pipelines as YAML. It contains:

Stages – groups of jobs (build, test, deploy)
Jobs – units of work in a stage; jobs in a stage run in parallel
Variables, before_script, after_script
Rules – conditions for inclusion/exclusion

GitLab auto-detects the file and creates a pipeline on every push.

Question 7 Cicd Pipelines

What is the continue-on-error property in GitHub Actions?

Linting is integrated as an early pipeline stage to catch style and syntax issues automatically.

Example GitHub Actions step:

- name: Lint
  run: npm run lint

Common linters:

ESLint – JavaScript/TypeScript
Pylint / Ruff – Python
RuboCop – Ruby
PHP_CodeSniffer – PHP

Best practice: run linting before tests since it's fast and catches obvious issues early. Dependency caching stores downloaded packages between pipeline runs to avoid re-downloading them each time.

GitHub Actions example:

- uses: actions/cache@v4
  with:
    path: node_modules
    key: deps-${{ hashFiles('package-lock.json') }}

The cache key uses a hash of the lock file so it invalidates when dependencies change. This can reduce build times by 50% or more. continue-on-error: true on a step or job causes failures to be logged but not propagated — the run continues and a later if: failure() step can react. Useful for non-blocking checks like "send a Slack warning if a flaky test fails" or for collecting diagnostic info before a hard failure. MTTR (Mean Time To Recover / Restore) is the average time from incident detection to service restoration. Strong CD practices (immutable artifacts, fast rollback, canary analysis) drive MTTR down to minutes. DORA's Elite performers report MTTR under one hour; low performers take days. CI/CD is the primary lever.

Question 8 Cicd Pipelines

What is the difference between actions/setup-node and caching node_modules manually?

GitHub Actions bills by minutes consumed per runner type:

Linux: 1x multiplier (e.g., $0.008/min on Team)
Windows: 2x
macOS: 10x

Free tier: 2,000 min/month for private repos. Storage: artifact & cache storage has its own GB-month price. An agent specifies where a pipeline or stage runs. Options include:

agent any – run on any available executor
agent none – no global agent; each stage specifies its own
agent { label 'linux' } – run on a node with the given label
agent { docker { image 'node:18' } } – run inside a Docker container

Agents enable distributed builds across multiple machines. actions/setup-node@v4 with cache: 'npm' automatically caches the npm/yarn/pnpm cache directory using the lockfile hash. Manual caching with actions/cache@v4 is more flexible — you can cache node_modules directly, but you must compute the cache key yourself (e.g., hashFiles('package-lock.json')). A/B testing deployment routes different user segments to different application versions to compare behavior and outcomes.

Unlike canary (which tests stability), A/B testing measures business metrics:

Conversion rates
User engagement
Revenue impact

Traffic is split based on rules like user ID, geography, or cookies. Requires feature flags or an ingress controller with routing rules.

Tools: LaunchDarkly, Istio, AWS CloudFront

Question 9 Cicd Pipelines

What is deployment frequency in DORA metrics?

Deployment frequency counts how often an organization deploys to production. Elite performers: on-demand (multiple per day). Low performers: between once per month and once per six months. Higher frequency correlates with lower CFR and shorter MTTR — small, frequent changes are safer. github.event is the full webhook payload (object) for the triggering event. github.event_name is just the name string (e.g., 'push', 'pull_request'). Use event_name for branching logic, and event for accessing event-specific fields like github.event.pull_request.number. Auto-scalers dynamically provision self-hosted runners based on job queue depth:

actions-runner-controller (ARC) on Kubernetes
Buildkite Elastic CI on AWS
GitLab Runner with autoscaler driver
CircleCI runner + Nomad

Scales from 0 to N runners; reduces idle compute cost. Multi-environment deployments promote code through progressively higher environments:

dev → staging → production

Implementation:

Use environment-specific config files or variables
Same artifact deployed to each environment
Approval gates between staging and production
Environment-scoped secrets

GitHub Actions example:

deploy-staging:
  environment: staging
deploy-prod:
  needs: deploy-staging
  environment: production

Question 10 Cicd Pipelines

What is the input step in a Declarative Jenkinsfile?

input is the Jenkins manual approval gate:

stage('Deploy') {
  steps {
    input message: 'Deploy to production?', ok: 'Deploy', submitter: 'admins'
    sh './deploy.sh prod'
  }
}

The job pauses until an authorized user clicks the button. Optionally bound to a timeout. upload-artifact stores a file/directory produced by one job so that downstream jobs in the same run (or later, for review) can access it via download-artifact. Common usage: a build job uploads dist/; a deploy job downloads it. Artifacts are not shared across separate workflow runs unless downloaded and re-uploaded. An artifact is the binary output produced by a build (JAR, Docker image, tarball). A release is a named, versioned collection of artifacts plus release notes, typically marked with a Git tag like v1.4.0. Releases are immutable; artifacts are inputs to a release. Test parallelization splits a test suite into shards that run simultaneously. Limits:

Some tests share state (DB, file system) and must run serially
Cost: each parallel runner consumes CI minutes
Diminishing returns past 8-10x parallel
Order-dependent tests break under parallel execution

Tools: pytest-xdist, Jest --shard, Knapsack (Ruby).

Question 11 Cicd Pipelines

What is the average time to recover (MTTR) in a CI/CD context?

push fires on commits to the matching branch(es) — including merges that change main. pull_request fires when a PR is opened, synchronized, or reopened. Best practice: run fast CI on pull_request and longer/heavier jobs on push to main, because PRs run on a separate concurrency group and don't affect deployments. A digest is the content-addressable hash of an image (e.g., sha256:abc123...). Pinning deployments to a digest (not a tag) guarantees the running image is byte-for-byte the one CI built — even if a tag is overwritten. Kubernetes manifests can reference image: myapp@sha256:abc123 for full reproducibility. MTTR (Mean Time To Recover / Restore) is the average time from incident detection to service restoration. Strong CD practices (immutable artifacts, fast rollback, canary analysis) drive MTTR down to minutes. DORA's Elite performers report MTTR under one hour; low performers take days. CI/CD is the primary lever.

Jobs – independent units of work that run on a runner. Jobs run in parallel by default but can depend on each other using needs.
Steps – individual tasks within a job, executed sequentially. Each step either runs a shell command (run:) or uses an action (uses:).
Actions – reusable packaged tasks from the GitHub Marketplace or custom repositories, referenced as uses: actions/checkout@v4.

Question 12 Cicd Pipelines

What is progressive delivery?

GitHub Actions bills by minutes consumed per runner type:

Linux: 1x multiplier (e.g., $0.008/min on Team)
Windows: 2x
macOS: 10x

Free tier: 2,000 min/month for private repos. Storage: artifact & cache storage has its own GB-month price. github.event is the full webhook payload (object) for the triggering event. github.event_name is just the name string (e.g., 'push', 'pull_request'). Use event_name for branching logic, and event for accessing event-specific fields like github.event.pull_request.number. Progressive delivery is the umbrella term for gradual rollout strategies (canary, blue/green, feature flags, dark launches). Goal: reduce blast radius of new releases by exposing them to increasingly larger audiences with automated safety checks (metrics, error budgets). It's a superset of continuous deployment. Jenkins Shared Libraries are reusable Groovy code stored in a separate Git repository. They allow teams to share pipeline logic across multiple Jenkinsfiles.

Structure:

vars/ – global functions callable from pipelines
src/ – Groovy class files
resources/ – non-Groovy files

Usage in Jenkinsfile:

@Library('my-shared-lib') _
myCustomStep()

Question 13 Cicd Pipelines

What is a Buildkite pipeline and how does it differ from GitHub-hosted CI?

Buildkite uses a hybrid model: the orchestration (pipelines, UI, secrets) runs on Buildkite's cloud, but agents run on your own infrastructure. You retain control of build secrets, hardware, and scale, while Buildkite handles scheduling and the web UI. Pipeline definitions live in a pipeline.yml file in the repo. upload-artifact stores a file/directory produced by one job so that downstream jobs in the same run (or later, for review) can access it via download-artifact. Common usage: a build job uploads dist/; a deploy job downloads it. Artifacts are not shared across separate workflow runs unless downloaded and re-uploaded. The controller (formerly "master") is the Jenkins server that hosts the configuration, scheduling logic, and UI. Agents (formerly "slaves") are the machines that actually run build jobs. The controller dispatches jobs to agents based on labels, agent availability, and pipeline agent specifications. Jenkins now recommends running agents as containers/pods to scale elastically. An agent specifies where a pipeline or stage runs. Options include:

agent any – run on any available executor
agent none – no global agent; each stage specifies its own
agent { label 'linux' } – run on a node with the given label
agent { docker { image 'node:18' } } – run inside a Docker container

Agents enable distributed builds across multiple machines.

Question 14 Cicd Pipelines

What is a GitLab CI runner?

A composite action packages multiple run steps into a single reusable action defined in action.yml. Unlike JavaScript/Docker actions, it does not need a build step and can be authored purely in shell.

Use composite actions to DRY up repeated step sequences like "checkout + setup Node + install deps" across many workflows. Kayenta is the automated canary analysis engine used by Spinnaker (originally from Netflix). It pulls metrics (from Prometheus, Datadog, Stackdriver, etc.), compares the canary and baseline distributions using statistical tests (e.g., Jensen-Shannon divergence), and produces a score 0-100. Pipeline advances or rolls back based on the score. A runner is an agent process that executes pipeline jobs. Runners are tagged (e.g., docker, linux, gpu) and jobs target them with tags: [docker]. Types: Shared (across the GitLab instance), Group (within a group), Project (specific repo), Specific (one runner, one project). pre-commit is local, fast, and bypassable (developers can --no-verify). CI is the authoritative gate that runs on the server with no possibility of bypass. Use pre-commit for developer experience (fast feedback, autoformat on save); use CI as the enforcer for what must be true.

Question 15 Cicd Pipelines

What is an immutable tag in container CI/CD?

The Jenkins pipeline-linter REST endpoint (/pipeline-model-converter/validate) validates a Jenkinsfile against the controller's installed plugins. Use in PRs via:
curl -X POST -F "jenkinsfile=<Jenkinsfile" https://jenkins.example.com/pipeline-model-converter/validate
or via the CLI plugin. Catches syntax errors before a real build attempt. retry(3) re-runs the enclosed steps up to 3 times until one succeeds. Common for flaky network operations (npm install, git fetch). Don't retry steps with side effects (e.g., a deploy) — you'll get duplicate executions. Use sleep between retries to let transient issues clear. An immutable tag (e.g., a Git SHA like myapp:abc1234) is a tag that never changes once pushed. Mutable tags like latest or stable can be overwritten, causing non-reproducible deployments. Best practice: use SHA tags for rollouts, and only use latest for local dev convenience. Multi-platform (multi-arch) images bundle binaries for several CPU architectures (amd64, arm64, arm/v7) in a single tag:
docker buildx build --platform linux/amd64,linux/arm64 -t myapp:$SHA --push .
Useful for shipping the same image to Intel servers and ARM (Graviton, M1/M2, Raspberry Pi) without per-arch images. Implemented with manifest lists.

Question 16 Cicd Pipelines

What is a Jenkins Credentials binding and which scopes exist?

Jobs – independent units of work that run on a runner. Jobs run in parallel by default but can depend on each other using needs.
Steps – individual tasks within a job, executed sequentially. Each step either runs a shell command (run:) or uses an action (uses:).
Actions – reusable packaged tasks from the GitHub Marketplace or custom repositories, referenced as uses: actions/checkout@v4.

Credentials in Jenkins are scoped:

System – visible to all jobs (use sparingly)
Global (default) – visible across folders/agents
Folder – scoped to a Jenkins folder

withCredentials binds a credential to an env var within a block, ensuring the secret is masked in console output. Continuous Delivery ensures code is always in a deployable state but requires a manual approval step before production release.

Continuous Deployment goes further: every change that passes all pipeline stages is automatically deployed to production with no human intervention.

Delivery = ready to deploy on demand
Deployment = auto-deployed every time The build stage compiles source code and produces executable artifacts.

Activities include:

Dependency resolution – install packages from lock files
Compilation – compile TypeScript, Java, Go, etc.
Bundling – webpack, Vite for frontend assets
Docker image creation

Best practices:

Use lock files for deterministic builds
Enable build caching
Fail fast on compilation errors
Produce versioned artifacts

Question 17 Cicd Pipelines

What is the difference between pre-commit and CI?

IaC in CI/CD automates infrastructure provisioning as part of the pipeline:

Typical pipeline stages:

terraform fmt -check – validate formatting
terraform validate – syntax check
terraform plan – preview changes
Manual approval gate
terraform apply – apply changes

Tools: Terraform, Pulumi, CloudFormation, Ansible

Store state files remotely (S3, GCS) and use state locking to prevent concurrent modifications. Change Failure Rate (CFR) is the percentage of changes (deploys, releases) that result in degraded service or require remediation (rollback, hotfix, incident). DORA's Elite performers achieve 0-15%; low performers 46-60%. CI/CD practices that lower CFR: small batches, trunk-based dev, automated tests, canary releases. Quality gates are automated checkpoints that enforce minimum standards before code can proceed in the pipeline.

Common quality gates:

Test coverage ≥ 80%
Zero critical security vulnerabilities
No new code smells
All linting rules pass
Performance benchmarks within thresholds

If any gate fails, the pipeline blocks the merge or deployment. This ensures consistent code quality across the team. pre-commit is local, fast, and bypassable (developers can --no-verify). CI is the authoritative gate that runs on the server with no possibility of bypass. Use pre-commit for developer experience (fast feedback, autoformat on save); use CI as the enforcer for what must be true.

Question 18 Cicd Pipelines

What is the difference between webhooks and polling in CI?

rules: is the modern, flexible replacement for only/except. It supports complex conditions:

deploy:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Use when: manual, when: delayed, when: never to control inclusion. Webhooks are push notifications from GitHub/GitLab to the CI server on every push — instant, low overhead. Polling is the CI server periodically git fetch-ing to detect changes — slower, wastes resources. Always prefer webhooks; use polling only as a fallback for SCMs without webhook support. paths and paths-ignore on on.push (or on.pull_request) restrict when the workflow runs based on which files changed:

on:
  push:
    paths: ['src/**', 'package.json']

Saves CI minutes on doc-only changes; common in monorepos. Multi-environment deployments promote code through progressively higher environments:

dev → staging → production

Implementation:

Use environment-specific config files or variables
Same artifact deployed to each environment
Approval gates between staging and production
Environment-scoped secrets

GitHub Actions example:

deploy-staging:
  environment: staging
deploy-prod:
  needs: deploy-staging
  environment: production

Question 19 Cicd Pipelines

What is fail-fast in a build matrix?

Policy engines (e.g., OPA/Gatekeeper, Kyverno, Conftest) evaluate declarative rules against inputs. In CI/CD, they gate promotions: "block deploy unless image is signed", "block deploy if SBOM contains GPL-licensed code". Policies are versioned in Git, auditable, and testable like code. upload-artifact stores a file/directory produced by one job so that downstream jobs in the same run (or later, for review) can access it via download-artifact. Common usage: a build job uploads dist/; a deploy job downloads it. Artifacts are not shared across separate workflow runs unless downloaded and re-uploaded. 5 minutes is the minimum interval — you can schedule with cron: '*/5 * * * *' (every 5 minutes). However, GitHub does not guarantee exact execution time: scheduled runs can be delayed by 3-15 minutes during high load, and missed runs are not backfilled. fail-fast: true (default in GitHub Actions) cancels all in-progress and queued matrix jobs as soon as any one job fails. This saves CI minutes and surfaces the first failure quickly. Set to false if you want to see all failures regardless (e.g., for compatibility reporting across OSes).

Question 20 Cicd Pipelines

What are approval gates in CI/CD?

Approval gates require manual human approval before a pipeline proceeds to the next stage, typically before production deployment.

GitHub Actions: Use environment with required reviewers:

environment:
  name: production

Jenkins:
input message: 'Deploy to production?'

Use cases:

Production deployments
Infrastructure changes
Compliance requirements

Balance between safety and deployment velocity. A composite action packages multiple run steps into a single reusable action defined in action.yml. Unlike JavaScript/Docker actions, it does not need a build step and can be authored purely in shell.

Use composite actions to DRY up repeated step sequences like "checkout + setup Node + install deps" across many workflows. needs: creates directed acyclic graph (DAG) dependencies between jobs, allowing non-stage-order execution:

deploy:
  stage: deploy
  needs: [build, test]
  script: ./deploy.sh

Unlike stage ordering, needs lets deploy run as soon as its specific inputs are ready, reducing pipeline time. OIDC (OpenID Connect) lets your CI provider assume a short-lived cloud IAM role without storing long-lived cloud credentials as secrets. GitHub Actions exposes token: ${{ steps.auth.outputs.token }} from configure-aws-credentials. Benefits: no static AWS keys to leak, automatic credential rotation, auditable per-workflow identity.

Question 21 Cicd Pipelines

What is remote build caching and how does it save CI time?

Test coverage thresholds ensure a minimum percentage of code is tested.

Implementation:

Run tests with coverage: jest --coverage
Set threshold in config:
"coverageThreshold": { "global": { "branches": 80, "lines": 80 } }
Fail the CI step if below threshold

Tools: Jest, Istanbul/nyc, JaCoCo (Java), Coverage.py

Upload reports to SonarQube or Codecov for tracking trends. Remote build caching lets a CI job reuse build outputs from previous runs (and from teammates' machines) via a shared cache. Bazel, Nx, and Turborepo all support it. Typical savings: a fresh CI build for a 5-package monorepo taking 25 minutes drops to under 3 minutes when 4 of 5 packages are cache hits. stash is a per-build, transient file archive shared between stages on the same node; deleted after the build ends. archiveArtifacts is a per-build, persistent file stored on the controller, visible in the build UI, retained per policy, and available across nodes via the artifacts API. Jenkins stores secrets using the Credentials Plugin:

Types:

Username/Password
Secret text
Secret file
SSH key
Certificate

Usage in Declarative Pipeline:

environment {
  AWS_KEY = credentials('aws-access-key')
}

Or with withCredentials block:

withCredentials([string(credentialsId: 'token', variable: 'TOKEN')]) {
  sh 'curl -H "Auth: $TOKEN" ...'
}

Question 22 Cicd Pipelines

What is flaky test quarantine?

workflow_dispatch allows you to manually trigger a workflow from the GitHub UI, API, or CLI. You can define custom input parameters.

Example:

on:
  workflow_dispatch:
    inputs:
      environment:
        type: choice
        options: [staging, production]

Useful for ad-hoc deployments and maintenance tasks. Build once, deploy many is a principle: compile/package the artifact once in CI, then promote the same artifact through staging → canary → production. Avoids "works on my machine" drift and "the deploy that just passed is not the deploy that's in prod". Contrast: rebuilding per environment leads to subtle differences. workflow_run triggers a workflow after another workflow finishes. Common pattern: a CI workflow builds on PRs, a separate workflow_run deploys the merged artifact after the CI workflow on the main branch completes successfully. Lets you split CI and CD with different permissions and approvers. A flaky test quarantine is the practice of isolating known-flaky tests into a separate CI suite that runs less frequently or is excluded from required status checks. Each quarantined test has an owner and a ticket. Goal: stop flakes from blocking PRs while still surfacing them.

Question 23 Cicd Pipelines

What are agents in Jenkins?

An agent specifies where a pipeline or stage runs. Options include:

agent any – run on any available executor
agent none – no global agent; each stage specifies its own
agent { label 'linux' } – run on a node with the given label
agent { docker { image 'node:18' } } – run inside a Docker container

Agents enable distributed builds across multiple machines. artifacts: declares files to attach to a job and pass to downstream jobs in the same pipeline:

test:
  script: npm test
  artifacts:
    paths: [coverage/]
    expire_in: 1 week

expire_in sets retention. reports: sub-key (junit, cobertura, dotenv) adds special parsed reports. .gitlab-ci.yml at the repo root defines GitLab CI/CD pipelines as YAML. It contains:

Stages – groups of jobs (build, test, deploy)
Jobs – units of work in a stage; jobs in a stage run in parallel
Variables, before_script, after_script
Rules – conditions for inclusion/exclusion

GitLab auto-detects the file and creates a pipeline on every push. All build container images without a Docker daemon, useful in CI:

Kaniko – builds in-container, no daemon, runs in k8s natively
Buildah – CLI alternative to docker build, daemonless, supports OCI
docker buildx – official BuildKit frontend, supports multi-platform builds, cache export

Choose buildx for most cases; kaniko inside cluster pods; buildah for daemonless systems.

Question 24 Cicd Pipelines

What is Bazel and how does it integrate with CI?

pull_request_target runs in the context of the target branch (e.g., main) with access to secrets, but is triggered by a PR from a fork. Danger: a malicious PR could run code that exfiltrates secrets.*. Mitigation: never echo attacker-controlled input, and explicitly actions/checkout the PR ref (not the base) only after manual approval. Bazel is Google's remote-cache, hermetic build system. CI integration:

Remote cache (--remote_cache) — build outputs cached across CI runs and developer machines
Remote execution (--remote_executor) — distribute compilation to a build farm
Hermeticity guarantees identical results locally and in CI

Common in monorepos with mixed languages (Java, Go, TS, Python). A flaky test is one that passes and fails intermittently on the same commit, usually due to timing, concurrency, or shared state. Flakes are CI's #1 productivity killer: engineers stop trusting "red" builds. Fixes: isolate the test, use deterministic inputs, avoid sleep(), mock time, retry with caution. Track flake rate as a KPI. The controller (formerly "master") is the Jenkins server that hosts the configuration, scheduling logic, and UI. Agents (formerly "slaves") are the machines that actually run build jobs. The controller dispatches jobs to agents based on labels, agent availability, and pipeline agent specifications. Jenkins now recommends running agents as containers/pods to scale elastically.

Question 25 Cicd Pipelines

What are reusable workflows in GitHub Actions?

Reusable workflows allow you to define a workflow once and call it from other workflows using workflow_call.

The called workflow lives in a .github/workflows/ file and declares inputs and secrets.

Caller syntax:

jobs:
  call-workflow:
    uses: org/repo/.github/workflows/ci.yml@main
    with:
      env: production

This promotes DRY principles across repositories. actions/checkout@v4 clones the repository into the runner workspace so subsequent steps can read source code. Key option: fetch-depth: 0 fetches full git history (needed for git blame, tagging, or version detection). Without it, only the triggering commit is checked out (shallow clone). Notifications alert teams about pipeline results. Common integrations:

GitHub Actions:

- uses: slackapi/slack-github-action@v1
  with:
    channel-id: 'C01234'
    slack-message: 'Deploy ${{ job.status }}'

Common channels:

Slack/Teams – team chat notifications
Email – build failure alerts
PagerDuty – production incident alerts

Best practice: notify on failures always, successes only when relevant. Dependency caching stores downloaded packages between pipeline runs to avoid re-downloading them each time.

GitHub Actions example:

- uses: actions/cache@v4
  with:
    path: node_modules
    key: deps-${{ hashFiles('package-lock.json') }}

The cache key uses a hash of the lock file so it invalidates when dependencies change. This can reduce build times by 50% or more.

Question 26 Cicd Pipelines

How do you drain a self-hosted runner before maintenance?

actions/checkout@v4 clones the repository into the runner workspace so subsequent steps can read source code. Key option: fetch-depth: 0 fetches full git history (needed for git blame, tagging, or version detection). Without it, only the triggering commit is checked out (shallow clone). A canary release is infrastructure-controlled (e.g., 1% of production traffic) and internal — users may not know. A beta release is user-opted-in (TestFlight, Google Play beta track) and serves users who explicitly signed up. Canary measures stability; beta collects user feedback on new features. To safely remove a self-hosted runner:

Remove the runner from the repo/org (it stops picking up new jobs).
Wait for the current job to finish — it shows "Offline" in the runner list when idle.
Stop the actions.runner service on the host.

Removing the runner config without stopping the service can leave a "ghost" agent in the GitHub UI. Jenkins plugins extend functionality by adding integrations, build tools, and features.

Essential CI/CD plugins:

Pipeline – enables Pipeline-as-Code
Git – source code management
Docker Pipeline – build inside containers
Credentials – secure secrets storage
Blue Ocean – modern UI
JUnit – test result reporting

Jenkins has 1,800+ plugins. Manage them carefully — too many plugins can cause compatibility and security issues.

Question 27 Cicd Pipelines

What is the difference between an artifact and a release in CI/CD?

A service container is a sidecar container started alongside a job to provide a dependency like a database or cache:

services:
  postgres:
    image: postgres:15
    env:
      POSTGRES_PASSWORD: test
    ports: ['5432:5432']

Tests connect to localhost:5432; the container is torn down when the job ends. An artifact is the binary output produced by a build (JAR, Docker image, tarball). A release is a named, versioned collection of artifacts plus release notes, typically marked with a Git tag like v1.4.0. Releases are immutable; artifacts are inputs to a release.

Composite action — a reusable step (multiple shell commands), called with uses:
Reusable workflow (workflow_call) — a reusable workflow with its own jobs, called with uses: at job level

Composite = step-level reuse; reusable workflow = multi-job reuse. Both promote DRY across repositories. SAST analyzes source code without executing it to find security vulnerabilities early in the development cycle.

What it detects:

SQL injection patterns
Cross-site scripting (XSS)
Buffer overflows
Hardcoded credentials

Popular tools: SonarQube, Semgrep, CodeQL (GitHub), Checkmarx

SAST runs in CI as a build-time check and is best at finding issues in code you write, not in dependencies.

Question 28 Cicd Pipelines

What is the highest frequency GitHub Actions schedules allow?

Feature flag services let you toggle code paths at runtime without redeploying:

LaunchDarkly – SaaS, targeting rules, experimentation
Flagsmith – open-source + SaaS
Unleash – open-source
GrowthBook – open-source with A/B testing

CI/CD integration: a flag is off in production by default; flip it on via the dashboard, not via deploy. Immutable infrastructure means servers/containers are never modified in place — every change is a new build replacing the old. Combined with CI/CD: a new commit → new image → new VM/container → load balancer shift. Benefits: consistent environments, no configuration drift, easy rollback (just redeploy the previous image). 5 minutes is the minimum interval — you can schedule with cron: '*/5 * * * *' (every 5 minutes). However, GitHub does not guarantee exact execution time: scheduled runs can be delayed by 3-15 minutes during high load, and missed runs are not backfilled. Policy engines (e.g., OPA/Gatekeeper, Kyverno, Conftest) evaluate declarative rules against inputs. In CI/CD, they gate promotions: "block deploy unless image is signed", "block deploy if SBOM contains GPL-licensed code". Policies are versioned in Git, auditable, and testable like code.

Question 29 Cicd Pipelines

What is a workflow_run event and when do you use it?

workflow_run triggers a workflow after another workflow finishes. Common pattern: a CI workflow builds on PRs, a separate workflow_run deploys the merged artifact after the CI workflow on the main branch completes successfully. Lets you split CI and CD with different permissions and approvers. continue-on-error: true on a step or job causes failures to be logged but not propagated — the run continues and a later if: failure() step can react. Useful for non-blocking checks like "send a Slack warning if a flaky test fails" or for collecting diagnostic info before a hard failure. A runner is an agent process that executes pipeline jobs. Runners are tagged (e.g., docker, linux, gpu) and jobs target them with tags: [docker]. Types: Shared (across the GitLab instance), Group (within a group), Project (specific repo), Specific (one runner, one project). A flaky test quarantine is the practice of isolating known-flaky tests into a separate CI suite that runs less frequently or is excluded from required status checks. Each quarantined test has an owner and a ticket. Goal: stop flakes from blocking PRs while still surfacing them.

Question 30 Cicd Pipelines

What is a pull_request_target event and why is it dangerous?

Turborepo is a build orchestrator for JavaScript/TypeScript monorepos. It uses the turbo.json pipeline graph and a content-addressable cache (.turbo/cache or remote cache) to skip work whose inputs haven't changed. CI integration: turbo run test --filter=...[origin/main] runs only tests affected by the PR. actions/cache is a build-time accelerator keyed on inputs (lockfile hash); restored on cache hit, generated on miss; not exposed in the UI for download. actions/upload-artifact is a deliverable: a named bundle (test reports, binaries) downloadable from the run UI, retained per policy, shareable across runs. Caching speeds up; artifacts record results. pull_request_target runs in the context of the target branch (e.g., main) with access to secrets, but is triggered by a PR from a fork. Danger: a malicious PR could run code that exfiltrates secrets.*. Mitigation: never echo attacker-controlled input, and explicitly actions/checkout the PR ref (not the base) only after manual approval. ArgoCD is a GitOps continuous-delivery controller — it watches Git repos and syncs cluster state to match. Argo Rollouts is a progressive-delivery controller — it manages the rollout of a new version using canary/blue-green. They are complementary: ArgoCD applies the new ReplicaSet definition, and Argo Rollouts drives the gradual traffic shift.

Question 31 Cicd Pipelines

What is the artifact retention period in GitHub Actions?

By default, artifacts are retained for 90 days. You can change this per-artifact with retention-days: on actions/upload-artifact@v4 (1-90 days for public repos, 1-400 for private/enterprise). Older artifacts are auto-deleted. Use Releases or external storage for long-term artifact storage. concurrency ensures that only one run of a workflow (or group) executes at a time, canceling or queuing the others:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Prevents wasted CI on superseded pushes and avoids race conditions in deployments. GitHub Secrets are encrypted variables stored at the repository, environment, or organization level.

Access in workflows:
${{ secrets.MY_SECRET }}

Key rules:

Secrets are masked in logs automatically
They are not passed to workflows from forks by default
Environment secrets can require reviewers for approval
Use GITHUB_TOKEN for built-in repo access

Never hardcode secrets in code or workflow files.

pipeline {
  agent any
  stages {
    stage('Build') {
      steps { sh 'make build' }
    }
    stage('Test') {
      steps { sh 'make test' }
    }
    stage('Deploy') {
      steps { sh 'make deploy' }
    }
  }
}

Key blocks: agent (where to run), stages (what to do), steps (individual commands), and optional post (cleanup/notifications).

Question 32 Cicd Pipelines

What is a pipeline as code linter?

agent none at the top of a Declarative pipeline disables the global agent, forcing each stage to declare its own agent. This is required when stages need different environments (e.g., one in Linux, one in Windows, one in a Docker container).

pipeline {
  agent none
  stages { stage('Build') { agent { docker 'maven:3.9' } ... } }
}

pre-commit is local, fast, and bypassable (developers can --no-verify). CI is the authoritative gate that runs on the server with no possibility of bypass. Use pre-commit for developer experience (fast feedback, autoformat on save); use CI as the enforcer for what must be true. Flux CD is a GitOps toolkit for Kubernetes (CNCF graduated). It watches Git repos for changes to manifests or Helm charts and reconciles cluster state. Flux vs ArgoCD: Flux is more modular (CLI + controllers), better for platform teams; ArgoCD has a richer web UI and is friendlier to app teams. Pipeline-as-code linters catch syntax and logic errors before a workflow runs:

actionlint for GitHub Actions
yamllint for general YAML
Jenkins pipeline lint via the pipeline-linter API or Jenkinsfile in PRs
GitLab CI Lint tool

Run them as a fast pre-merge check; faster feedback than waiting for CI.

Question 33 Cicd Pipelines

What is the purpose of a build number in CI/CD?

Jenkins Shared Libraries are reusable Groovy code stored in a separate Git repository. They allow teams to share pipeline logic across multiple Jenkinsfiles.

Structure:

vars/ – global functions callable from pipelines
src/ – Groovy class files
resources/ – non-Groovy files

Usage in Jenkinsfile:

@Library('my-shared-lib') _
myCustomStep()

A build number is a monotonically increasing identifier (e.g., 4231 or 2026.06.22-r17) assigned to each pipeline run. It enables:

Traceability of which exact artifact is deployed
Correlation between logs, metrics, and a specific commit
Reproducible rollback to a known good build

GitHub Actions exposes it as ${{ github.run_number }}; Jenkins provides BUILD_NUMBER. Single-line run: echo hello is one command. Block scalar run: | starts a multi-line string. The indentation of the lines below the pipe is significant — they form one block passed to the shell. Use | (literal newlines preserved) vs > (folded into one line with spaces) for shell commands. A standard CI/CD pipeline includes these stages:

Source – code checkout from version control
Build – compile code and resolve dependencies
Test – run unit, integration, and end-to-end tests
Static Analysis – linting, code quality checks
Security Scan – SAST, dependency scanning
Package – create deployable artifacts
Deploy – push to staging or production
Release – make available to users

Question 34 Cicd Pipelines

What is SLSA (Supply-chain Levels for Software Artifacts)?

Single-line run: echo hello is one command. Block scalar run: | starts a multi-line string. The indentation of the lines below the pipe is significant — they form one block passed to the shell. Use | (literal newlines preserved) vs > (folded into one line with spaces) for shell commands. SLSA is a security framework with levels (1-4) for supply-chain integrity. Level 1: provenance documentation. Level 2: signed provenance from a hosted build platform. Level 3: hardened build platform resistant to runner compromise. Level 4: hermetic, reproducible, two-party review. CI/CD adoption: signed builds, attestation via Sigstore, hardened runners. A step can be conditionally executed via:

- name: Deploy to prod
  if: github.ref == 'refs/heads/main'
  run: ./deploy.sh

Common if expressions:

github.event_name == 'pull_request'
failure() – run only on failure
cancelled() – run on cancel
always() – run regardless of status

Kayenta is the automated canary analysis engine used by Spinnaker (originally from Netflix). It pulls metrics (from Prometheus, Datadog, Stackdriver, etc.), compares the canary and baseline distributions using statistical tests (e.g., Jensen-Shannon divergence), and produces a score 0-100. Pipeline advances or rolls back based on the score.

Question 35 Cicd Pipelines

What is the principle of least privilege in CI/CD?

A deployment freeze blocks production deployments during high-risk windows (holidays, Black Friday, end-of-quarter). Implemented in CI/CD via rules: - if: $DEPLOY_FREEZE == 'true' or pipeline-level guard. Forces a discussion before override. Avoid freezes by improving release safety, not by gating velocity. Grant each CI job, runner, and IAM role the minimum permissions required for its work:

permissions: read-all in GitHub Actions, then escalate per-job
Per-environment IAM roles, not one mega-role
Read-only deploy tokens where possible
Use OIDC federation instead of long-lived secrets

Reduces blast radius if a job is compromised. input is the Jenkins manual approval gate:

stage('Deploy') {
  steps {
    input message: 'Deploy to production?', ok: 'Deploy', submitter: 'admins'
    sh './deploy.sh prod'
  }
}

The job pauses until an authorized user clicks the button. Optionally bound to a timeout. Status checks (legacy) are tied to a commit SHA and submitted via the Statuses API — simple pass/fail. Check runs (Checks API) are richer: they support annotations, multi-step outputs, images, deployment records, and are what GitHub Actions uses by default. Actions uses Check Runs; many external CI systems now also use them.

Question 36 Cicd Pipelines

What is CircleCI orbs?

Pipeline-as-code linters catch syntax and logic errors before a workflow runs:

actionlint for GitHub Actions
yamllint for general YAML
Jenkins pipeline lint via the pipeline-linter API or Jenkinsfile in PRs
GitLab CI Lint tool

Run them as a fast pre-merge check; faster feedback than waiting for CI. Feature branches isolate development work in dedicated branches created from the main branch.

CI/CD integration:

Each push triggers automated builds and tests
Pull requests run status checks before merging
Branch protection rules enforce passing CI
Preview deployments for each PR

Best practices:

Keep branches short-lived (days, not weeks)
Rebase frequently from main
Delete after merging

Orbs are reusable packages of CircleCI configuration (jobs, commands, executors) published to the Orb Registry. Example: circleci/node@5 sets up Node, caches npm, and runs common tasks. Orbs are CircleCI's analog of GitHub Actions marketplace actions and Jenkins shared libraries. 5 minutes is the minimum interval — you can schedule with cron: '*/5 * * * *' (every 5 minutes). However, GitHub does not guarantee exact execution time: scheduled runs can be delayed by 3-15 minutes during high load, and missed runs are not backfilled.

Question 37 Cicd Pipelines

What is a composite action in GitHub Actions?

A standard CI/CD pipeline includes these stages:

Source – code checkout from version control
Build – compile code and resolve dependencies
Test – run unit, integration, and end-to-end tests
Static Analysis – linting, code quality checks
Security Scan – SAST, dependency scanning
Package – create deployable artifacts
Deploy – push to staging or production
Release – make available to users

Pipeline-as-code linters catch syntax and logic errors before a workflow runs:

actionlint for GitHub Actions
yamllint for general YAML
Jenkins pipeline lint via the pipeline-linter API or Jenkinsfile in PRs
GitLab CI Lint tool

Run them as a fast pre-merge check; faster feedback than waiting for CI. A composite action packages multiple run steps into a single reusable action defined in action.yml. Unlike JavaScript/Docker actions, it does not need a build step and can be authored purely in shell.

Use composite actions to DRY up repeated step sequences like "checkout + setup Node + install deps" across many workflows. rules: is the modern, flexible replacement for only/except. It supports complex conditions:

deploy:
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Use when: manual, when: delayed, when: never to control inclusion.

Question 38 Cicd Pipelines

What is the purpose of concurrency in GitHub Actions?

IaC in CI/CD automates infrastructure provisioning as part of the pipeline:

Typical pipeline stages:

terraform fmt -check – validate formatting
terraform validate – syntax check
terraform plan – preview changes
Manual approval gate
terraform apply – apply changes

Tools: Terraform, Pulumi, CloudFormation, Ansible

Store state files remotely (S3, GCS) and use state locking to prevent concurrent modifications. In CI shell steps:

set -e — exit on first error
set -u — error on undefined variables
set -o pipefail — pipeline fails if any command in the pipe fails (not just the last)

Default GitHub Actions shell is bash --noprofile --norc -eo pipefail {0} on Linux, so pipefail is on by default. Explicitly adding set -euo pipefail documents intent and is portable. Dependency caching stores downloaded packages between pipeline runs to avoid re-downloading them each time.

GitHub Actions example:

- uses: actions/cache@v4
  with:
    path: node_modules
    key: deps-${{ hashFiles('package-lock.json') }}

The cache key uses a hash of the lock file so it invalidates when dependencies change. This can reduce build times by 50% or more. concurrency ensures that only one run of a workflow (or group) executes at a time, canceling or queuing the others:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Prevents wasted CI on superseded pushes and avoids race conditions in deployments.

Question 39 Cicd Pipelines

What is pipeline caching of Docker layers?

Docker layer caching stores intermediate image layers between builds:
cache-from: type=gha / cache-to: type=gha,mode=max in docker/build-push-action@v5
The build pushes layers to the GitHub Actions cache; subsequent builds --cache-from them. For 5x-10x speedups when only the last layer (app code) changes. In CI shell steps:

set -e — exit on first error
set -u — error on undefined variables
set -o pipefail — pipeline fails if any command in the pipe fails (not just the last)

Default GitHub Actions shell is bash --noprofile --norc -eo pipefail {0} on Linux, so pipefail is on by default. Explicitly adding set -euo pipefail documents intent and is portable. Webhooks are push notifications from GitHub/GitLab to the CI server on every push — instant, low overhead. Polling is the CI server periodically git fetch-ing to detect changes — slower, wastes resources. Always prefer webhooks; use polling only as a fallback for SCMs without webhook support. By default, actions/checkout configures a persisted git credential helper on the runner, allowing later steps to push tags, commit, or use authenticated git commands. Setting persist-credentials: false removes the credential helper after checkout, reducing the blast radius if a later step is compromised.

Question 40 Cicd Pipelines

What is SonarQube and how is it used in CI/CD?

A canary release is infrastructure-controlled (e.g., 1% of production traffic) and internal — users may not know. A beta release is user-opted-in (TestFlight, Google Play beta track) and serves users who explicitly signed up. Canary measures stability; beta collects user feedback on new features. A Freestyle job is a GUI-configured job (checkboxes, text fields) — limited reusability, no version control on the job config. A Pipeline job uses a Jenkinsfile defined as code, versioned with the repo, supports complex logic, parallel stages, and reusability. New projects should use Pipeline. The build stage compiles source code and produces executable artifacts.

Activities include:

Dependency resolution – install packages from lock files
Compilation – compile TypeScript, Java, Go, etc.
Bundling – webpack, Vite for frontend assets
Docker image creation

Best practices:

Use lock files for deterministic builds
Enable build caching
Fail fast on compilation errors
Produce versioned artifacts

SonarQube is a code quality and security analysis platform that inspects code for:

Bugs – potential runtime errors
Vulnerabilities – security weaknesses
Code smells – maintainability issues
Duplications – repeated code blocks
Coverage – test coverage percentage

It integrates into CI/CD as a quality gate — the pipeline fails if code doesn't meet defined thresholds (e.g., coverage < 80%).

Question 41 Cicd Pipelines

What is a Jenkinsfile?

A Jenkinsfile is a text file that defines a Jenkins pipeline using code (Pipeline as Code). It is checked into the repository root.

Two syntax styles:

Declarative – structured, opinionated syntax with pipeline { } block
Scripted – flexible Groovy-based syntax with node { } block

Declarative is recommended for most use cases due to readability and built-in validation. An ephemeral runner processes exactly one job, then unregisters and (optionally) tears down the VM. Implemented with --ephemeral flag on the runner config or via GitHub's runner scale sets in Actions Runner Controller (ARC). Improves security by ensuring a clean, untrusted state for each job. GitHub Actions bills by minutes consumed per runner type:

Linux: 1x multiplier (e.g., $0.008/min on Team)
Windows: 2x
macOS: 10x

Free tier: 2,000 min/month for private repos. Storage: artifact & cache storage has its own GB-month price. A pre-commit hook runs locally before git commit completes, typically for fast checks (lint, format, type-check). It catches issues before CI, saving round-trip time. Implemented with Husky, pre-commit.com, lefthook. Don't run slow tests in pre-commit — keep it under 5 seconds.

Question 42 Cicd Pipelines

What is GitFlow branching strategy?

workflow_dispatch allows you to manually trigger a workflow from the GitHub UI, API, or CLI. You can define custom input parameters.

Example:

on:
  workflow_dispatch:
    inputs:
      environment:
        type: choice
        options: [staging, production]

Useful for ad-hoc deployments and maintenance tasks. GitFlow uses multiple long-lived branches:

main – production-ready code
develop – integration branch for features
feature/* – new features branched from develop
release/* – prepare a release, bug fixes only
hotfix/* – urgent fixes from main

Pros: structured, clear release process
Cons: complex, long-lived branches can cause merge conflicts

Best suited for projects with scheduled releases. Sigstore is a toolset for signing and verifying software artifacts (containers, binaries, SBOMs). Components: cosign (sign), rekor (transparency log), fulcio (cert authority for short-lived certs). Solves: key management for code signing — no need to manage long-lived signing keys; instead, identities are bound to OIDC tokens. Ephemeral preview environments are short-lived, per-PR deployments for review. Tools: Vercel, Netlify, Render, Heroku Review Apps, Gitpod, or custom (ArgoCD PR apps). Each PR gets a unique URL, deployed automatically, destroyed on merge/close. Drastically improves design review and integration testing.

Question 43 Cicd Pipelines

What is the path filter in GitHub Actions?

paths and paths-ignore on on.push (or on.pull_request) restrict when the workflow runs based on which files changed:

on:
  push:
    paths: ['src/**', 'package.json']

Saves CI minutes on doc-only changes; common in monorepos. Continuous Delivery ensures code is always in a deployable state but requires a manual approval step before production release.

Continuous Deployment goes further: every change that passes all pipeline stages is automatically deployed to production with no human intervention.

Delivery = ready to deploy on demand
Deployment = auto-deployed every time Blue-green deployment maintains two identical production environments:

Blue – the current live environment
Green – the new version being deployed

Traffic is switched from Blue to Green once the new version is verified. If issues occur, you instantly roll back by switching traffic back to Blue.

Pros: zero downtime, instant rollback
Cons: requires double infrastructure, database migrations can be complex Containerized builds run pipeline steps inside Docker containers to ensure a consistent, reproducible environment.

Benefits:

Reproducibility – same environment locally and in CI
Isolation – no dependency conflicts between projects
Version control – Dockerfile defines exact tooling

GitHub Actions:

container:
  image: node:18-alpine

Jenkins:
agent { docker { image 'maven:3.9' } }

Question 44 Cicd Pipelines

What is the difference between a webhook event and a workflow_dispatch API call?

Ephemeral runners (e.g., GitHub Actions self-hosted ARC, Buildkite agents) spin up a fresh VM/container per job and tear it down — no shared state. Container-based CI like GitHub Actions' hosted runners also use fresh VMs, but the job steps still share a runner. Ephemeral models add an outer clean-slate wrapper for stronger isolation. max-parallel caps how many matrix jobs run concurrently. Useful when you have many combinations but want to throttle resource usage:

strategy:
  matrix: { os: [ubuntu, windows, macOS] }
  max-parallel: 2

Only 2 of the 3 jobs run at a time; the third queues. Both can trigger workflows, but:

A webhook event (push, pull_request) is event-driven by the SCM, originating from a git action.
workflow_dispatch is intentional and synchronous, invoked via UI / gh workflow run / REST API.

Use webhooks for reactive automation; use dispatch for manual/operational jobs. Build once, deploy many is a principle: compile/package the artifact once in CI, then promote the same artifact through staging → canary → production. Avoids "works on my machine" drift and "the deploy that just passed is not the deploy that's in prod". Contrast: rebuilding per environment leads to subtle differences.

Question 45 Cicd Pipelines

What is AWS Secrets Manager and when should you use it?

github.event is the full webhook payload (object) for the triggering event. github.event_name is just the name string (e.g., 'push', 'pull_request'). Use event_name for branching logic, and event for accessing event-specific fields like github.event.pull_request.number. Dependency scanning checks third-party libraries for known vulnerabilities using databases like the National Vulnerability Database (NVD).

Tools:

Dependabot (GitHub) – auto-creates PRs for updates
Snyk – scans and monitors dependencies
Trivy – scans containers and filesystems
npm audit / pip-audit – language-specific

Integrate as a CI step to block builds with critical vulnerabilities. Also called Software Composition Analysis (SCA). An immutable tag (e.g., a Git SHA like myapp:abc1234) is a tag that never changes once pushed. Mutable tags like latest or stable can be overwritten, causing non-reproducible deployments. Best practice: use SHA tags for rollouts, and only use latest for local dev convenience. AWS Secrets Manager is a service that stores, rotates, and retrieves secrets like database credentials and API keys.

Use it when:

Your infrastructure runs on AWS
You need automatic secret rotation
You want IAM-based access control
Secrets are consumed by AWS services (Lambda, ECS, RDS)

In CI/CD, use the AWS CLI or SDK to retrieve secrets:
aws secretsmanager get-secret-value --secret-id mySecret

Question 46 Cicd Pipelines

What is the difference between Continuous Delivery and Continuous Deployment?

Continuous Delivery ensures code is always in a deployable state but requires a manual approval step before production release.

Continuous Deployment goes further: every change that passes all pipeline stages is automatically deployed to production with no human intervention.

Delivery = ready to deploy on demand
Deployment = auto-deployed every time A GitHub Actions workflow is an automated process defined in a YAML file under .github/workflows/. It is triggered by events such as push, pull_request, or schedule.

A workflow contains one or more jobs, each consisting of steps that run commands or use actions.

Example trigger:
on: [push, pull_request] By default, artifacts are retained for 90 days. You can change this per-artifact with retention-days: on actions/upload-artifact@v4 (1-90 days for public repos, 1-400 for private/enterprise). Older artifacts are auto-deleted. Use Releases or external storage for long-term artifact storage. Feature flag services let you toggle code paths at runtime without redeploying:

LaunchDarkly – SaaS, targeting rules, experimentation
Flagsmith – open-source + SaaS
Unleash – open-source
GrowthBook – open-source with A/B testing

CI/CD integration: a flag is off in production by default; flip it on via the dashboard, not via deploy.

Question 47 Cicd Pipelines

What is the difference between a CircleCI executor and a step?

Remote build caching lets a CI job reuse build outputs from previous runs (and from teammates' machines) via a shared cache. Bazel, Nx, and Turborepo all support it. Typical savings: a fresh CI build for a 5-package monorepo taking 25 minutes drops to under 3 minutes when 4 of 5 packages are cache hits. Ephemeral preview environments are short-lived, per-PR deployments for review. Tools: Vercel, Netlify, Render, Heroku Review Apps, Gitpod, or custom (ArgoCD PR apps). Each PR gets a unique URL, deployed automatically, destroyed on merge/close. Drastically improves design review and integration testing. An executor is the runtime environment for a job: docker, machine (full VM), macos, windows, or self-hosted. A step is an individual command or action within a job, like - run: npm test or - checkout. Jobs run on executors; steps are units of work within a job. Both can trigger workflows, but:

A webhook event (push, pull_request) is event-driven by the SCM, originating from a git action.
workflow_dispatch is intentional and synchronous, invoked via UI / gh workflow run / REST API.

Use webhooks for reactive automation; use dispatch for manual/operational jobs.

Question 48 Cicd Pipelines

What is the purpose of actions/upload-artifact vs actions/download-artifact?

The default timeout is 360 minutes (6 hours) per job, configurable via jobs.<id>.timeout-minutes (1-43200 minutes). The overall workflow run timeout default is 35 days but configurable to 1-43200 minutes. Jobs exceeding the timeout are terminated and marked failed. A job is a unit of work on a single runner. A workflow run is the overall execution instance triggered by an event, containing all jobs (and their logs, artifacts, statuses). A run is identified by github.run_id; each job has its own github.job name. upload-artifact stores a file/directory produced by one job so that downstream jobs in the same run (or later, for review) can access it via download-artifact. Common usage: a build job uploads dist/; a deploy job downloads it. Artifacts are not shared across separate workflow runs unless downloaded and re-uploaded. A build matrix multiplies configurations (Node 16/18/20 × Ubuntu/macOS/Windows = 9 jobs). Limiting combinations is necessary because:

Each combination consumes CI minutes/cost
Combinatorial explosion slows feedback
Diminishing returns when testing exotic combos

Use fail-fast: true to cancel pending matrix jobs when one fails.

Question 49 Cicd Pipelines

What is the purpose of the Jenkins Cron syntax?

triggers { cron('H 2 * * *') } schedules a Declarative pipeline using a cron-like expression. The H (hash) prefix spreads the load across the hour (H/15 * * * * = every 15 min, jittered) to avoid all jobs firing at :00. Useful for nightly builds, cleanup, dependency updates. push fires on commits to the matching branch(es) — including merges that change main. pull_request fires when a PR is opened, synchronized, or reopened. Best practice: run fast CI on pull_request and longer/heavier jobs on push to main, because PRs run on a separate concurrency group and don't affect deployments. A service container is a sidecar container started alongside a job to provide a dependency like a database or cache:

services:
  postgres:
    image: postgres:15
    env:
      POSTGRES_PASSWORD: test
    ports: ['5432:5432']

Tests connect to localhost:5432; the container is torn down when the job ends. Jenkins Shared Libraries are reusable Groovy code stored in a separate Git repository. They allow teams to share pipeline logic across multiple Jenkinsfiles.

Structure:

vars/ – global functions callable from pipelines
src/ – Groovy class files
resources/ – non-Groovy files

Usage in Jenkinsfile:

@Library('my-shared-lib') _
myCustomStep()

Question 50 Cicd Pipelines

What is the purpose of the test stage in a CI/CD pipeline?

Bazel is Google's remote-cache, hermetic build system. CI integration:

Remote cache (--remote_cache) — build outputs cached across CI runs and developer machines
Remote execution (--remote_executor) — distribute compilation to a build farm
Hermeticity guarantees identical results locally and in CI

Common in monorepos with mixed languages (Java, Go, TS, Python). The test stage validates code correctness through automated testing.

Test types typically run in CI:

Unit tests – test individual functions/methods
Integration tests – test component interactions
End-to-end tests – test full user workflows
Smoke tests – basic sanity checks post-deploy

Best practices:

Run tests in parallel for speed
Use test splitting across runners
Generate JUnit XML reports for CI integration

ARC is a Kubernetes operator that runs GitHub Actions self-hosted runners as pods via the actions.summerwind.dev/v1alpha1 CRDs (RunnerDeployment, HorizontalRunnerAutoscaler). It supports ephemeral runners (one job per pod), labels, and scales based on workflow backlog. The modern way to scale Actions in k8s. The test pyramid has many unit tests at the base, fewer integration tests in the middle, and very few E2E tests at the top. CI mirrors it:

Fast unit tests on every commit
Integration tests after build
E2E tests against staging

Running the full pyramid on every commit is wasteful; tier it.