Continuous Integration and Delivery Tools Questions

Practical knowledge and hands on experience with continuous integration and continuous delivery tooling and platforms. Topics include tool selection criteria, pipeline authoring and syntax, lifecycle stages, runners and agents, declarative versus scripted pipelines, plugin and extension ecosystems, configuration best practices, security and credential management, scalability and performance considerations for build and test workloads, artifact storage and promotion, integration with source control systems and deployment targets, and basic troubleshooting and observability of pipelines. Candidates should be able to discuss specific platform examples such as Jenkins, GitLab continuous integration, and GitHub Actions, explain trade offs between platforms, and describe how these tools fit into a broader automation and infrastructure ecosystem.

HardTechnical

59 practiced

Propose an architecture for a global, deduplicated pipeline cache used across ephemeral runners and branches (for dependency caches, build outputs, container layers). Discuss the storage backend (object store vs CAS), cache key design, consistency and invalidation strategies, security (encryption, access control), and performance trade-offs.

Sample Answer

**High-level approach**Design a global, content-addressable, deduplicated cache service fronted by an HTTP API and CDN, backed by a CAS for small blobs and an object store for larger artifacts. Ephemeral runners interact via a local agent that uploads/downloads by content-hash and a manifest index for logical keys (branch/build id).

**Storage backend**- CAS (e.g., Bazel remote, gRPC CAS) for deduplication and fast chunk-addressing of build outputs and container layers.- Object store (S3/GCS/Azure Blob) for large blobs and long-term storage; store chunks as objects and maintain manifests in a metadata DB.- Use chunking (content-defined) + Merkle DAG to enable cross-artifact dedupe.

**Cache key design**- Two-layer keys: logical key = {repo, branch, commit, pipeline-step, tool-version, platform}, maps to manifest (list of content digests).- Content-addressed keys: SHA-256 of chunks. Include canonicalization (path normalization, env hashing) to avoid false misses.

**Consistency & invalidation**- Immutable content: once uploaded, content hash immutable. Manifest writes use atomic compare-and-swap with versioned metadata (optimistic concurrency).- Invalidation via TTL on logical keys plus explicit eviction API for branch deletes or retention policies. Garbage collect unreferenced chunks via reference counting or periodic mark-and-sweep using manifests.

**Security**- Encrypt at-rest using KMS-managed keys; enforce server-side encryption for object store and encrypt CAS layer.- Transport: TLS + mTLS for runner-agent.- Access control: short-lived scoped tokens (OIDC/GitHub Actions OIDC), per-repo IAM policies. Audit logs for uploads/downloads.- Sign manifests with repository key to prevent poisoning.

**Performance trade-offs**- CAS gives best dedupe, lower network for shared chunks, but higher complexity and metadata overhead.- Object store is simple, cost-effective for large objects but less efficient for small-chunk dedupe and higher GET PUT latency.- Use a CDN + regional caches for reads; local runner cache for hot data to reduce latency.- Tune chunk size: smaller = better dedupe but more metadata RTTs; larger = fewer requests but worse dedupe.

**Operational notes**- Monitor hit/miss, egress cost, metadata DB latency. Automate GC and retention. Start with object-store + manifest + chunking; add full CAS if dedupe needs justify complexity.

EasyTechnical

63 practiced

What is an artifact repository (e.g., Nexus, Artifactory) and how does it fit into CI/CD pipelines? Explain snapshot vs release artifacts, basic retention policies, and how CI tools typically publish and consume artifacts from these repositories.

Sample Answer

**What an artifact repository is (brief)** An artifact repository (e.g., Nexus, Artifactory) is a binary/package store and metadata service for build outputs: jars, wheels, npm packages, Docker images, Helm charts, etc. It centralizes versioned artifacts, enforces access control, and provides immutable storage, metadata, promotion and caching of remote dependencies.

**How it fits CI/CD** - CI builds produce artifacts and publish them to the repository. - CD pipelines pull specific artifact versions (release/promoted) for packaging, testing, staging, and deployment. - Repos act as the source of truth for deployable binaries and enable traceability between commits, builds, and deployments.

**Snapshot vs Release** - Snapshot: mutable, versioned like 1.2.3-SNAPSHOT. Used for ongoing development; overwritten by subsequent builds. Not suitable for production but for integration testing. - Release: immutable, versioned like 1.2.3. Once published it shouldn’t change; used for production deployments and long-term retention.

**Basic retention policies** - Keep X latest snapshots per artifact (e.g., last 10) and prune older ones to save storage. - Retain all releases (or apply time-based cleanup for very old minor releases). - Automatically delete failed/partial uploads and GC unreferenced blobs. - Tag/promote artifacts to “stable” repositories instead of relying on snapshots.

**How CI tools publish and consume** - Publish: CI (Jenkins/GitLab CI/TeamCity) runs build, runs authenticated publish step using tool-specific plugins or CLI (mvn deploy, npm publish, docker push). Provide credentials via vault/credentials store and artifact coordinates (groupId/artifactId/version or registry/image:tag). - Consume: Pipelines reference repository URL in dependency manager config (settings.xml, .npmrc, pip index URL, Docker registry). Use exact version or a promoted repository alias for environments (e.g., repo-staging vs repo-release) to guarantee immutability.

Example: Jenkins pipeline uses Maven to build, then:- mvn deploy (publishes snapshot to snapshots repo) - On release job, mvn deploy with release profile to releases repo and create Git tag.

This setup ensures reproducible, auditable, and secure deployments.

EasyTechnical

47 practiced

In Jenkins (declarative Jenkinsfile), write a simple pipeline that: checks out the repository, runs `mvn -B -DskipTests=false verify`, archives `target/*.jar` as artifacts, and runs on agents labeled `linux-java`. Provide the Jenkinsfile snippet (declarative syntax).

Sample Answer

**Approach**Use a declarative pipeline that runs on agents labeled "linux-java", checks out SCM, runs the Maven verify goal (not skipping tests), and archives produced JARs from target/.

groovy

pipeline {
  agent { label 'linux-java' }

  stages {
    stage('Checkout') {
      steps {
        checkout scm
      }
    }

    stage('Build') {
      steps {
        sh 'mvn -B -DskipTests=false verify'
      }
    }

    stage('Archive') {
      steps {
        archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
      }
    }
  }

  post {
    always {
      junit 'target/surefire-reports/*.xml'
      cleanWs()
    }
  }
}

**Notes**- I included junit step to collect test results and cleanWs to free workspace.- If multi-module, adjust artifact path (e.g., **/target/*.jar) or use stash/unstash for downstream stages.

MediumSystem Design

46 practiced

Design an artifact promotion workflow for a microservices platform where CI produces artifacts and they must move from dev -> staging -> production without rebuilding. Explain tagging (semantic version vs build id), repository practices, promotion APIs or metadata, and how to preserve provenance.

Sample Answer

**Clarify goals & constraints**- Move CI-built artifacts (containers, jars) through dev → staging → prod without rebuilds- Preserve provenance, allow rollback, support automated gating and manual approvals

**High-level flow**- CI builds artifact once, assigns immutable build-id (e.g., git-sha + CI run id) and optional semantic-version- Push artifact to immutable repo (container registry or artifact repo) with tags: build-id, channel tag (dev/staging/prod), and semantic-tag if release- Promotion updates metadata only; does not rebuild or retag destructive tags

**Tagging strategy**- Build-id: immutable primary identifier (e.g., sha256:... or app-1.2.3+build.456)- Semantic version: used for releases only, stored as signed tag and metadata; never overwritten- Channel tags (dev/staging/prod): mutable pointers pointing to specific build-id; changes are promotions, logged and auditable

**Repository practices**- Use immutable storage + copy-on-promotion: keep original artifact by digest; promotions only create tags/refs- Enforce artifact immutability by digest; enable signed manifests (e.g., Notary/TUF or Cosign)- Store provenance metadata in registry and external metadata store (e.g., DB or Git-backed manifest)

**Promotion APIs & metadata**- Expose a Promotion API: promote(artifact_digest, from_env, to_env, approver, reason) - Validates policies, records timestamp, approver, pipeline id, test evidence pointers - On success: create channel tag (to_env) referencing artifact_digest and append audit entry- CI/CD pipelines call API; UI/CLI for human approvals

**Provenance & security**- Record: build-id, source-repo commit, build pipeline id, dependencies, SBOM, test results, signatures- Sign artifacts and metadata (Cosign/Notary); store signatures with registry- Store audit trail in append-only log (WORM or git) for compliance; correlate with deployment events

**Rollback & rollforward**- Rollback = promote previous build-id to channel tag- Maintain immutable history so rollbacks are reproducible

**Why this design**- Immutable digests + promotion-only tagging prevents drift and accidental rebuild differences- Clear separation: semantic versions for releases; build-id for reproducibility; channel tags for operational convenience- Provenance + signatures enable traceability and secure deployments across environments

EasyTechnical

62 practiced

Explain the concept of 'pipeline as code'. What are the main advantages (versioning, reviewability, reproducibility) and one scenario where pipeline-as-code could introduce operational complexity? How would you mitigate that complexity?

Unlock Full Question Bank

Get access to hundreds of Continuous Integration and Delivery Tools interview questions and detailed answers.

Join thousands of developers preparing for their dream job.