DevOps MASTER
Home
DevOps CI/CD Docker Observability

DevOps & CI/CD

Interview-ready guide: pipelines, containers, environments, deployments, monitoring — with real-world traps.

1. DevOps Mindset (the senior answer)

DevOps is not a toolset. It is a collaboration model and a feedback loop between dev and ops to ship reliably and fast.

✅ What to say in interviews

  • Automation: build/test/deploy are repeatable.
  • Short feedback loops: fast detection of issues.
  • Observability: logs, metrics, traces to see reality.
  • Shared ownership: “you build it, you run it”.

⚠️ Traps

  • Thinking DevOps is “a person/team that deploys”.
  • Manual deployments “only in prod”.
  • No monitoring: you discover issues via customers.
  • No rollback plan.

🎯 One-liner that wins

“DevOps is about improving delivery velocity and reliability through automation, observability, and shared ownership.”

2. CI vs CD (don’t confuse them)

CI — Continuous Integration

  • Build + unit tests on every commit/merge request.
  • Static analysis / security scans (SAST).
  • Artifacts produced (docker image, package, zip).

CD — Continuous Delivery/Deployment

  • Delivery: always deployable, but with manual approval.
  • Deployment: auto deploy to prod after checks.
  • Release strategies: canary, blue/green, feature flags.

🚨 Interview Trap

“We do CI/CD” but there are no automated tests and prod deployments are manual SSH… That is not CI/CD.

3. Branching & Release Strategy

Your pipeline depends on how you manage branches, releases, and versioning.

Trunk-based

Small merges, feature flags, fast delivery (common in modern teams).

GitFlow

Many branches (develop/release/hotfix). Can slow teams down.

Release tags

SemVer tags trigger deployment and generate changelog.

# Example: semantic version tags
v1.2.0 # minor release
v1.2.1 # patch release
v2.0.0 # breaking changes

4. Docker Basics (image vs container)

Image

Immutable template (layers). Built once, stored in registry.

Container

Runtime instance of an image. Has writable layer.

🚨 Trap: “Containers are VMs”

Containers share the host kernel. They are lightweight process isolation, not full virtualization.

# Quick Docker commands
docker build -t myapp:1.0 .
docker run -p 8080:8080 myapp:1.0
docker logs -f <container_id>
docker exec -it <container_id> sh

5. Dockerfile Patterns (multi-stage build)

Interviewers love multi-stage builds: smaller images, faster deployments, safer runtime.

# ✅ Multi-stage Dockerfile (example for .NET)
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /out

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /out .
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.dll"]

⚠️ Best practices

  • Small images: only runtime in final stage.
  • Don’t bake secrets into images.
  • Pin versions when needed.
  • Run as non-root if possible.

6. Docker Compose (local environments)

Compose is perfect for dev/stage parity: app + db + broker + observability locally.

# docker-compose.yml (minimal example)
services:
  api:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db

  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: postgres
    ports:
      - "5432:5432"

🚨 Trap: “Compose is production”

Compose is great for local dev. Production needs orchestration (Kubernetes, Nomad, ECS…) plus secrets, scaling, rollouts.

7. CI/CD Pipelines (what “good” looks like)

✅ Typical stages

  • Build: compile + produce artifact
  • Test: unit/integration + coverage
  • Scan: dependencies + SAST
  • Package: docker image + push
  • Deploy: stage → prod (with approvals)
# Example pipeline logic (conceptual)
# 1) Build & Test
dotnet test -c Release
# 2) Build Docker image & push
docker build -t registry/myapp:$CI_COMMIT_SHA .
docker push registry/myapp:$CI_COMMIT_SHA
# 3) Deploy
kubectl set image deploy/myapp myapp=registry/myapp:$CI_COMMIT_SHA

⚠️ Common pipeline mistakes

  • Tests run only locally (not in CI).
  • No artifact immutability (rebuilding “same version” produces different binaries).
  • Deploying from laptops (no audit).

8. Environments (dev / stage / prod)

✅ Good approach

  • Same artifact deployed everywhere (only config changes).
  • Stage mirrors prod (as much as possible).
  • Feature flags to decouple deploy from release.

🚨 Traps

  • Different code per environment (“prod branch”).
  • Secrets stored in git.
  • Manual config edits on servers.

💡 Best practice

Keep code identical across environments. Change only configuration (settings, secrets, endpoints), and validate in stage before prod.

9. Deploy Strategies (rollback-ready)

A senior answer is not “we deploy”. It’s “we deploy safely, with fast rollback and minimal downtime”.

Blue/Green

Two environments (blue and green). Switch traffic when ready. Easy rollback.

Canary

Gradually route a small % of traffic to the new version, monitor, then increase.

Rolling

Update instances gradually. Works well, but rollback can be slower if DB changes are risky.

🚨 Trap: DB migration breaks rollback

If the new version requires a destructive migration, “rollback” may not be possible. Prefer expand/contract migrations: add columns first, deploy code, then remove old fields later.

10. Secrets & Configuration (don’t leak)

Secrets must be injected at runtime, never stored in code or images.

✅ Good patterns

  • Use secret managers (Vault, cloud Key Vault / Secrets Manager).
  • Rotate credentials (DB, API keys) regularly.
  • Principle of least privilege (scoped access).
  • Separate secrets from config (endpoints vs passwords).

🚨 Traps

  • Secrets in appsettings.json committed to git.
  • Secrets baked into Docker images.
  • Using the same credentials for all environments.
  • Logging secrets by accident (headers, connection strings).
# ✅ Example: environment variables (concept)
ConnectionStrings__Db="Host=db;Database=app;Username=app;Password=***"
Jwt__Issuer="https://idp.example.com"
Jwt__Audience="api"

11. Observability (logs, metrics, traces)

Monitoring is “something is wrong”. Observability is “why is it wrong?”.

Logs

Structured logs. Correlation IDs. Minimal noise.

Metrics

Latency, error rate, saturation, throughput.

Traces

Distributed tracing across services (request journey).

💡 What to mention

  • Correlation ID per request (propagate across services).
  • Dashboards for golden signals (latency, errors, traffic, saturation).
  • Alerting based on SLO/SLA, not “CPU 80%”.

🚨 Trap: “We have logs”

If logs are not structured, not searchable, and you can’t correlate requests, you’ll lose hours during incidents.

12. Reliability & Resilience

Resilience is mandatory in distributed systems: retries, timeouts, circuit breakers, idempotency.

✅ Must-have patterns

  • Timeouts (fail fast).
  • Retries with backoff (only for transient errors).
  • Circuit Breaker (stop hammering a failing dependency).
  • Bulkhead (isolate resources).
  • Idempotency (safe retries on commands).

🚨 Traps

  • Retrying everything (can amplify outages).
  • No timeouts (requests hang forever).
  • No rate limiting (self-DoS under traffic spikes).
  • Non-idempotent operations retried (double charge / double create).
// ✅ Simple resilience checklist
// - Timeout per dependency
// - Retry only transient failures (with backoff)
// - Circuit breaker on repeated failures
// - Idempotency keys for write endpoints

13. Winning Interview Answers (copy/paste style)

CI/CD in one sentence

“CI validates every change automatically (build + tests + scans). CD deploys the same immutable artifact across environments safely, using progressive rollout and fast rollback.”

Docker in one sentence

“An image is an immutable build artifact; a container is a runtime instance. Multi-stage builds keep runtime images small and secure.”

Observability in one sentence

“Logs tell me what happened, metrics show trends and saturation, traces explain where time is spent across services.”

14. Most Common DevOps Traps

🚨 “Works on my machine”

No reproducible builds. Fix with containers, locked dependencies, and CI builds as source of truth.

🚨 “We deploy by SSH”

No audit, no repeatability. Fix with pipelines + immutable artifacts + infra as code.

🚨 “No rollback plan”

You need rollback-ready releases, database migration strategy, and feature flags.

15. Senior DevOps Checklist

✅ Delivery

  • Automated build + tests + scans.
  • Immutable artifacts (tagged images).
  • Progressive rollout + rollback.
  • Infrastructure as Code mindset.

✅ Operations

  • Centralized logs + metrics dashboards.
  • Tracing/correlation IDs.
  • SLO-based alerts (error rate/latency).
  • Secrets management + rotation.