CI/CD & Deployment Interview Questions

Summary

Continuous integration merges small changes frequently and verifies each with automated builds and tests. Continuous delivery keeps the main branch always releasable, with deployment to production a one-click decision. Continuous deployment goes further: every change that passes the pipeline deploys to production automatically.

Longer Answer

All three depend on fast, reliable automated tests and small batch sizes. Continuous deployment typically adds progressive rollout and automatic rollback.

Key Points

• CI: integrate and test frequently
• Delivery: always releasable
• Deployment: automatic release
• Small batches, reliable tests

Summary

Checkout → install dependencies (cached) → lint and type-check → unit tests → build artifact/image → integration tests → security scans (SAST, dependencies, image) → publish artifact → deploy to staging → smoke/E2E tests → deploy to production (progressively) → post-deploy verification.

Longer Answer

Fail fast: run cheap checks first. Build the artifact once and promote the same artifact across environments.

Code Example

# .github/workflows/ci.yml (excerpt)
jobs:
  test:
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:17
        env: { POSTGRES_PASSWORD: test }
        ports: ["5432:5432"]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.13", cache: pip }
      - run: pip install -r requirements.txt
      - run: ruff check . && mypy app
      - run: pytest -q

Key Points

• Lint/type-check first
• Tests and scans
• Build once, promote everywhere
• Staging then production
• Post-deploy checks

Summary

Rolling deployments replace instances gradually; blue-green deploys a full new environment and switches traffic at once (instant rollback by switching back); canary releases send a small percentage of traffic to the new version, watch metrics, then ramp up.

Longer Answer

All require backward-compatible changes because old and new versions run simultaneously (rolling, canary) or the database is shared (blue-green).

Key Points

• Rolling: gradual replacement
• Blue-green: switch environments
• Canary: small % first
• Backward compatibility required

Comparison / Tradeoffs

Summary

Use expand/contract: first make backward-compatible additive changes (add nullable columns or new tables), deploy code that writes to both/reads from new, backfill data in batches, switch reads, and only later remove old columns. Avoid long table locks (create indexes concurrently, split large updates).

Longer Answer

Never rename or drop a column in the same deploy that stops using it; old instances still running would break.

Code Example

-- Step 1 (expand): additive and safe
ALTER TABLE users ADD COLUMN display_name text;
CREATE INDEX CONCURRENTLY idx_users_display_name ON users (display_name);
-- Step 2: deploy code writing both columns; backfill in batches
-- Step 3 (contract, a later release): drop the old column
ALTER TABLE users DROP COLUMN nickname;

Key Points

• Expand → migrate → contract
• Additive changes first
• Batched backfills
• Concurrent index creation
• Drop later

Summary

Use small, pinned base images, multi-stage builds to keep build tools out of the runtime image, order layers so dependencies are cached before source code, run as a non-root user, add a .dockerignore, use exec-form CMD, and scan images for vulnerabilities.

Longer Answer

Keep one main process per container, configure via environment variables, and log to stdout/stderr.

Code Example

FROM python:3.13-slim AS build
WORKDIR /app
COPY requirements.txt .
RUN pip wheel --wheel-dir /wheels -r requirements.txt

FROM python:3.13-slim
RUN useradd --create-home app
WORKDIR /app
COPY --from=build /wheels /wheels
RUN pip install --no-cache-dir /wheels/* && rm -rf /wheels
COPY . .
USER app
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Key Points

• Small pinned base images
• Multi-stage builds
• Cache-friendly layer order
• Non-root user
• Scan images

Summary

Readiness says whether an instance should receive traffic (dependencies ready, warmed up); failing removes it from load balancing without restarting. Liveness says whether the process is stuck; failing restarts the container. Startup probes give slow-starting apps time before liveness begins.

Longer Answer

Don't make liveness depend on external services (a database outage would restart every pod and worsen the incident).

Key Points

• Readiness: receive traffic?
• Liveness: restart?
• Startup probe for slow boots
• Keep liveness local

Summary

Store secrets in the CI secret store or a vault, scope them to environments and protected branches, prefer short-lived credentials via OIDC federation (e.g., GitHub Actions to AWS/GCP) over long-lived keys, mask them in logs, and never expose them to untrusted pull requests from forks.

Longer Answer

Rotate secrets and audit access; scan repositories for accidentally committed secrets.

Key Points

• Secret stores / vaults
• OIDC short-lived credentials
• Environment scoping
• No secrets for fork PRs
• Rotation and scanning