CI/CD

Junior Questions

Junior

How do you cache effectively in CI pipelines?

Caching reduces CI time by reusing previously computed results.
npm/yarn cache: Cache ~/.npm or node_modules keyed on package-lock.json hash. Saves 2-5 min on most builds.
Docker layer cache: Use --cache-from in CI. Structure Dockerfile for maximum cache reuse (deps before source).
Build output cache: Cache Next.js .next/cache, turbo .turbo. Turborepo/Nx enable distributed build caching.
Cache invalidation: Key caches on lockfile/input hashes — auto-busted when deps change.

What problems does this solve?

CI caching strategy directly impacts developer productivity — a 5-minute build feels different from a 30-second build. Knowing where to cache is a practical skill.

Junior

How do you enforce a performance budget in CI?

Performance budgets set quantitative limits (e.g., JS bundle ≤ 200KB, LCP ≤ 2.5s) that fail the CI build if exceeded.
Bundle size: bundlesize npm package, Webpack performance.maxAssetSize, Vite plugin.
Lighthouse CI: Run Lighthouse in CI against a preview URL. Assert CWV thresholds. Fail the PR if they drop.
Post budget diffs as PR comments — show before/after bundle sizes.
Prevents gradual performance regressions going unnoticed until they impact real users.

What problems does this solve?

Performance budgets in CI are the only reliable way to prevent performance regressions — they create team-wide accountability.

Junior

How do you handle rollbacks in CI/CD?

Container-based: Re-deploy the previous Docker image tag (already in registry). Kubernetes: kubectl rollout undo deployment/app.
Blue/Green: Instant rollback by switching load balancer back to blue.
Database migrations: The hardest part. Always write backwards-compatible migrations first (expand-contract pattern). Never drop columns in the same deployment that removes the code that uses them.
Feature flags: Turn off a feature without redeploying.
Practice rollbacks regularly — untested rollback procedures fail in incidents.

What problems does this solve?

Rollback is where pipelines are battle-tested — database migration handling is the nuance that separates experienced practitioners.

Junior

How does GitHub Actions work?

GitHub Actions automates workflows via YAML files in .github/workflows/. Triggered by events (push, PR, schedule, manual).
Key concepts: Workflow → Jobs → Steps. Jobs run on runs-on (ubuntu-latest, macos, windows). Steps run sequentially. Jobs run in parallel by default (or with needs for dependencies).
Actions: Reusable step units from the marketplace (actions/checkout, actions/setup-node).
Secrets: Encrypted variables accessed via ${{ secrets.NAME }}.
Caching: actions/cache for node_modules, build artifacts.

What problems does this solve?

GitHub Actions is the most widely used CI system — being able to write and explain a basic workflow is a practical skill expected.

Junior

How is linting and code quality enforced in CI?

ESLint: Static analysis for JS/TS/Vue/React. Fail CI on errors.
Prettier: Formatting. Check with --check flag (don't auto-fix in CI).
TypeScript: tsc --noEmit for type checking without emitting files.
Pre-commit hooks: husky + lint-staged — run linters on staged files locally before commit. Faster feedback than waiting for CI.
SonarCloud / CodeClimate: Code smell and duplication analysis on PRs.
Automatically block merges on lint errors — consistency is more important than any individual rule.

What problems does this solve?

Automated code quality gates prevent style debates in code review and enforce standards consistently — pre-commit vs CI positioning matters.

Junior

How is security scanning integrated into CI/CD?

Dependency scanning (SCA): Snyk, Dependabot — check for CVEs in npm packages. Run on every push.
SAST: Semgrep, ESLint security plugins — static code analysis for vulnerabilities.
Container scanning: Trivy, Snyk Container — scan Docker images for OS-level CVEs before pushing to registry.
Secret scanning: GitHub Secret Scanning, truffleHog — detect accidentally committed secrets.
DAST: OWASP ZAP — scan running app for vulnerabilities (in staging).
Block merges on high-severity findings. Auto-create issues for medium findings.

What problems does this solve?

Shift-left security integrated into CI is the modern standard — listing the different scan types (SCA, SAST, container, secret scanning) shows comprehensive security pipeline awareness.

Junior

How is testing integrated into CI?

Unit tests: Run on every commit. Fast (< 1 min). Block merge if failing.
Integration tests: Run on every PR. Use Docker Compose to spin up dependencies (DB, Redis).
E2E tests: Run against a preview/staging deployment. May be gated to main-only for speed.
Coverage gates: Fail if coverage drops below threshold. --coverage --coverage-threshold flags in Vitest/Jest.
Parallelise: Shard test suites across multiple runners for speed.
Test results reported as PR checks — broken tests block merge.

What problems does this solve?

Knowing how to classify tests by type and position them correctly in the pipeline shows CI/CD maturity.

Junior

What is Infrastructure as Code (IaC)?

IaC defines and manages cloud infrastructure through code rather than manual clicks, enabling version control, repeatability, and automation.
Terraform: Cloud-agnostic, declarative HCL. Most widely used. Plan → Apply workflow.
AWS CloudFormation / CDK: AWS-native. CDK lets you define infrastructure in TypeScript/Python.
Pulumi: Uses real programming languages (TS, Python, Go).
IaC runs in CI — infrastructure changes reviewed in PRs. terraform plan output shown in PR comment before applying.

What problems does this solve?

IaC is the standard for production cloud infrastructure management — showing awareness of it signals production engineering maturity.

Mid-Level Questions

Mid

How should environment variables and secrets be handled in CI/CD?

Never hardcode secrets in source code or Dockerfiles.
CI secrets: GitHub Actions Secrets, GitLab CI Variables — encrypted, injected as env vars at runtime.
Runtime secrets: AWS Secrets Manager / SSM Parameter Store, GCP Secret Manager, HashiCorp Vault — fetched at startup.
Environment-specific config: Different values per environment (dev/staging/prod). Use a config hierarchy: defaults → environment overrides.
Principle of least privilege — each service/pipeline step only has access to the secrets it needs.
Rotate secrets regularly. Audit access. Alert on exposure.

What problems does this solve?

Secret management is a common CI/CD security failure point — the pattern of env vars + secret manager + least privilege is the standard answer.

Mid

What are Dockerfile best practices?

Multi-stage builds: Build in a full image; copy only the artifact to a minimal runtime image (alpine). Drastically reduces final image size.
Layer caching: Copy package.json and run npm ci before copying source code — npm install layer is cached unless package.json changes.
Non-root user: Run the app as a non-root user for security.
.dockerignore: Exclude node_modules, .git, test files from build context.
Pin base image versions: Use node:20-alpine not node:latest.
Minimise layers and use COPY --chown where needed.

What problems does this solve?

Multi-stage builds and layer caching order are the two most impactful Dockerfile optimisations — knowing them shows production container experience.

Mid

What are common Git branching strategies?

Trunk-Based Development: All developers commit to main (trunk) frequently. Short-lived feature branches (< 1 day). Fastest CI/CD feedback. Requires feature flags for incomplete work.
GitHub Flow: main is always deployable. Feature branches → PR → merge to main → deploy. Simple. Widely used for web apps.
Git Flow: main, develop, feature/*, release/*, hotfix/* branches. Complex. Good for versioned software with scheduled releases (mobile apps, libraries).
Lean towards simpler strategies — complexity breeds merge conflicts and slows CI.

What problems does this solve?

Branching strategy is the foundation of CI/CD — the wrong strategy (e.g., long-lived branches) undermines CI entirely.

Mid

What are container registries?

Container registries store and distribute Docker images (like npm registry but for images).
Public: Docker Hub — default. GitHub Container Registry (ghcr.io).
Private/Cloud: AWS ECR, Google Artifact Registry, Azure ACR — integrated with cloud IAM.
CI pattern: Build image → tag with git SHA → push to registry → deploy from registry tag.
Tagging with git SHA enables exact traceability between deployed image and source commit.

What problems does this solve?

Registries are the distribution layer of containerised deployments — knowing the cloud-native options and tagging strategies is expected.

Mid

What are feature flags?

Feature flags (feature toggles) let you deploy code to production but control who sees a feature via runtime configuration — decoupling deployment from release.
Use cases: Gradual rollout (% of users), A/B testing, kill switches, beta programmes, hiding incomplete features behind a flag (instead of long-lived branches).
Tools: LaunchDarkly, GrowthBook, Unleash, PostHog, custom env vars (simple).
Clean up: Remove stale flags once fully rolled out — flag debt accumulates quickly.

What problems does this solve?

Feature flags are the enabler of trunk-based development and safe continuous deployment — they're a first-class tool at any high-deployment-frequency organisation.

Mid

What are health checks in containerised deployments?

Health checks let the orchestrator (Docker, Kubernetes) determine if a container is ready to receive traffic.
Liveness probe: Is the app alive? If it fails, restart the container.
Readiness probe: Is the app ready to handle requests? If it fails, remove from load balancer (don't send traffic). Used during startup and degraded states.
Typically an HTTP GET /health endpoint returning 200 if healthy.
Prevents sending traffic to containers still starting up or in a degraded state.

What problems does this solve?

Health checks are the mechanism behind zero-downtime rolling deployments — without them, Kubernetes routes traffic to pods that aren't ready.

Mid

What are monitoring and alerting best practices in CI/CD?

Monitor deployments with metrics, logs, and traces — the "three pillars of observability".
Key signals (RED method): Rate (requests/sec), Errors (error rate), Duration (latency).
Post-deploy monitoring: Watch error rates and latency for 15-30 min after each deployment. Automated rollback if thresholds exceeded.
Tools: Datadog, New Relic, Grafana + Prometheus, Sentry (errors), PagerDuty (alerting).
SLOs/SLAs: Define reliability targets (99.9% uptime = ≤ 8.7h downtime/year) and alert before breaching.

What problems does this solve?

Deployment without monitoring is flying blind — the RED method and post-deploy observability are what separate deployments from releases.

Mid

What are preview deployments?

Preview deployments automatically create a unique URL for each PR with the built code deployed — so reviewers can test changes visually without pulling the branch locally.
Tools: Vercel, Netlify, Cloudflare Pages — native support. GitHub Actions + cloud providers for custom setups.
Enables: visual QA, stakeholder review, E2E test runs against real deployments, lighthouse audits on PR.
Isolated from production — safe to test with real-looking data without risk.

What problems does this solve?

Preview deployments are standard at modern frontend teams — they dramatically improve PR review quality and catch visual regressions before merge.

Mid

What are the Kubernetes basics?

Kubernetes (K8s) is an open-source container orchestration platform — automates deployment, scaling, and management of containerised applications.
Core objects:
- Pod — smallest deployable unit; one or more containers.
- Deployment — desired state declaration for a set of pods (replicas, rolling updates).
- Service — stable network endpoint to a set of pods (load balancing).
- Ingress — HTTP routing rules (routing by hostname/path).
- ConfigMap / Secret — app config and sensitive data injected as env vars or volumes.
Managed services: EKS (AWS), GKE (Google), AKS (Azure) — handle the control plane for you.

What problems does this solve?

K8s is the production container orchestration standard — you don't need to run it day-to-day but knowing its concepts is expected at senior level.

Mid

What is Semantic Versioning?

SemVer: MAJOR.MINOR.PATCH (e.g., 2.4.1).
PATCH (2.4.1 → 2.4.2): Backwards-compatible bug fixes.
MINOR (2.4.1 → 2.5.0): New backwards-compatible features.
MAJOR (2.4.1 → 3.0.0): Breaking changes. Consumers must opt in.
Pre-release: 1.0.0-alpha.1, 1.0.0-beta.2, 1.0.0-rc.1.
Automate version bumping: semantic-release, changesets — derive version from Conventional Commits.

What problems does this solve?

SemVer is the universal versioning contract for libraries — understanding when each number bumps prevents breaking consumers unexpectedly.

Mid

What is an incident response process in a CI/CD context?

Detect: Monitoring/alerting fires. Error rate spikes, latency increases, health checks fail.
Assess: Is this a deployment-related issue? Check: recent deployments, error logs, traces.
Mitigate: Rollback if deployment-related. Throttle traffic if overload. Enable kill switch (feature flag).
Resolve: Fix root cause. Re-deploy.
Post-mortem (blameless): What happened? Why? What process changes prevent recurrence? Document learnings.
On-call runbooks: Document common failure scenarios and remediation steps in advance.

What problems does this solve?

Incident response shows you think about systems holistically, not just development — a CI/CD-aware response (rollback, feature flags) is the fast-path mitigation.

Senior Questions

Senior

What are the core practices of Continuous Integration?

Developers push to the shared main branch frequently (at least daily) — avoids long-running feature branches that cause painful merges.
Every push triggers an automated build and test run. Broken builds are fixed immediately (they block the team).
CI pipeline typically includes: Install dependencies → lint → type-check → unit tests → integration tests → build → package.
Keep the build fast (< 10 min ideally). A slow CI pipeline discourages frequent commits.
The trunk (main branch) must always be in a releasable state.

What problems does this solve?

The "keep the build fast and always green" discipline is what separates teams who benefit from CI from those who just run tests in the cloud.

Senior

What are the main deployment strategies?

Rolling: Gradually replace old instances with new instances. Zero downtime. If new version is bad, some users get the new version before rollback. Default in Kubernetes Deployments.
Blue/Green: Two identical environments. Route traffic to green (new). Keep blue (old) running for instant rollback by switching the load balancer. Expensive (double infrastructure).
Canary: Route a small % of traffic (e.g., 5%) to the new version. Monitor metrics. Gradually increase to 100% or rollback. Best of both worlds.
Feature flags: Deploy code to everyone but enable features selectively. Decouples deployment from release.

What problems does this solve?

Deployment strategy is a key risk management decision — knowing the trade-offs between rolling, blue/green, and canary is essential for senior DevOps/SRE discussions.

Senior

What are the trade-offs between Monorepo and Polyrepo?

Monorepo: All code in one repo. Easy cross-package changes in one PR. Shared tooling/CI config. Enforces consistent versioning. Requires tooling to scale (Turborepo, Nx, Bazel). Used by Google, Meta, Vercel.
Polyrepo: Each service/package in its own repo. Simple setup. Independent release cycles. Cross-repo changes require multiple PRs. Dependency version drift is common.
Recommendation: Monorepo for tightly coupled codebases (shared components, one product). Polyrepo for truly independent services with different teams/release cycles.

What problems does this solve?

Monorepo vs polyrepo is a team topology and tooling question — being able to articulate trade-offs rather than advocating dogmatically shows engineering maturity.

Senior

What does a typical frontend CI/CD pipeline look like?

1. Trigger: On push to PR or main branch.
2. Install: npm ci (clean install from lockfile). Restore cache.
3. Quality gates: Lint (eslint), type-check (tsc), unit tests (vitest).
4. Build: npm run build. Check bundle size against budget.
5. E2E tests: (e.g., Playwright) against built app or preview URL.
6. Docker image: Build → push to registry (tagged with git SHA).
7. Deploy: Update deployment in staging → smoke tests → promote to production (manual gate for CD, automatic for CI Deployment).

What problems does this solve?

Being able to describe a complete pipeline end-to-end shows practical CI/CD experience, not just familiarity with individual tools.

Senior

What is CI/CD?

CI (Continuous Integration): Developers frequently merge code into a shared branch. Each merge triggers an automated build and test suite to catch integration issues early.
CD (Continuous Delivery): Every passing build is automatically prepared for release to production. Deployment is triggered manually. Business decides when to release.
CD (Continuous Deployment): Every passing build is automatically deployed to production without human intervention. Requires high confidence in automated tests.
Goal: Reduce the risk of each deployment by deploying smaller, more frequent changes. Shorten feedback loops and increase development velocity.

What problems does this solve?

CI/CD is foundational to modern software delivery — understanding the difference between delivery and deployment shows process maturity.

Senior

What is Docker Compose and when do you use it?

Docker Compose defines and runs multi-container applications via a docker-compose.yml file. Starts all services, networks, and volumes with a single docker compose up.
Use cases: Local development (app + DB + Redis + queue). Integration test environments. Not for production (use Kubernetes or managed container services).

What problems does this solve?

Docker Compose is the default local development setup for any multi-service app — being able to write a basic compose file is a practical expectation.

Senior

What is Docker and how does it work?

Docker packages an application and its dependencies into a container — a lightweight, isolated runtime environment.
Image: Read-only snapshot of the filesystem (layers). Container: Running instance of an image.
vs VMs: Containers share the host OS kernel. Much lighter (MB vs GB) and faster to start (seconds vs minutes). Less isolation than VMs.
Key commands: docker build -t app ., docker run -p 3000:3000 app, docker ps, docker logs.
Solves "works on my machine" — the container includes everything the app needs.

What problems does this solve?

Docker is the standard for modern deployment — understanding images, containers, and the VM distinction is baseline knowledge.

Senior

What is Trunk-Based Development?

A branching strategy where all developers commit directly to main (trunk) or use very short-lived feature branches (merged same day).
Enables true CI: No long-lived branches means no painful integration merges. You're always building on the latest code.
Requirements: Feature flags for incomplete work, excellent test coverage, automated CI gate before merge, fast build feedback.
Used by Google and most high-deployment-frequency organisations.
vs Git Flow: Dramatically simpler. Fewer merge conflicts. Forces collaboration and small incremental changes.

What problems does this solve?

Trunk-based development is the branching strategy that makes continuous deployment practical — advocating for it shows awareness of high-performance engineering practices.

Senior

What is artifact management?

Build artifacts are the outputs of the CI build process: compiled bundles, Docker images, test reports, coverage data.
Storage: GitHub Actions Artifacts (ephemeral), S3/GCS, Docker registries (for images), npm registry (for packages).
Versioning: Tag artifacts with git SHA and/or SemVer. Never overwrite — always traceable to source.
Retention policies: Keep last N builds or builds from the last M days. Prune old artifacts to control storage costs.
The same artifact built in CI is promoted through staging → production — you never rebuild for different environments.

What problems does this solve?

"Build once, deploy many" is the correct CI/CD artifact discipline — rebuilding for each environment introduces environment-specific bugs.

Senior

What is the difference between Continuous Delivery and Continuous Deployment?

Continuous Delivery: Automated pipeline produces a deployable artifact after every successful build. Deployment to production requires a manual approval step. Appropriate when business/compliance requires release control.
Continuous Deployment: No manual gate — every green build auto-deploys to production. Requires excellent test coverage, feature flags, observability, and fast rollback. Used by companies like Netflix and Amazon (deploys thousands of times per day).
Most organisations start with Delivery and graduate to Deployment as confidence grows.

What problems does this solve?

The manual gate distinction is a common interview question — knowing when each approach is appropriate shows pragmatic engineering judgment.

Senior

What should a CI/CD maturity checklist cover?

Build: Automated on every push. Fast (< 10 min). Reproducible. Artifacts versioned with git SHA.
Quality gates: Lint, type-check, unit tests, E2E tests all blocking merge.
Security: Dependency scanning, SAST, secret scanning, container scanning.
Performance: Bundle size budget, Lighthouse CI on PRs.
Deployment: Automated to staging. Manual gate (or automatic) to production. Preview URLs per PR.
Deployment strategy: Rolling/canary with automated rollback on threshold breach.
Observability: Post-deploy monitoring, error tracking, distributed tracing.
Secrets: Managed via secret manager, never in code.
Runbooks: Documented rollback, incident response, on-call procedures.

What problems does this solve?

A CI/CD maturity checklist demonstrates systematic thinking across the entire delivery pipeline — showing breadth from code quality to production observability.