DevOps & Cloud Interview Questions¶

Infrastructure, deployment, containerization, CI/CD, cloud platforms, and operational concerns.

1. Explain Docker and why containers are useful¶

View Answer

What is Docker?

Docker: Containerization platform that packages application + dependencies into isolated, portable units.

Why Containers?

Property	Benefit
Portability	Runs same everywhere (dev, test, prod)
Isolation	One container doesn't affect others
Lightweight	MBs not GBs (vs VMs)
Fast startup	Seconds not minutes
Consistency	Identical environment across stages
Scalability	Easy to scale (orchestrators like Kubernetes)

Containers vs VMs

Aspect	Container	VM
Size	100-500MB	1-5GB
Startup	Milliseconds	Minutes
Density	Hundreds per host	Tens per host
Isolation	Process-level (namespaces)	Full OS (hypervisor)

Container Workflow

1. Write Dockerfile
2. docker build → Image
3. docker run → Container (running instance)
4. Push to registry
5. Deploy to Kubernetes

📚 Learn more: Docker & Containers

2. What's the difference between Docker images and containers?¶

View Answer

Docker Image: Template

Immutable blueprint containing application + dependencies + configuration.

Base OS (Ubuntu 20.04)
  ↓
Java runtime
  ↓
Dependencies (libraries)
  ↓
Application code
  ↓
Configuration
= Image (immutable)

Docker Container: Running Instance

Running process with isolated filesystem, network, environment.

Image + Writable layer + Runtime = Container

Analogy

Image = Class, Container = Object

Image: Blueprint (one per application)
Container: Instance (many can run from same image)

Key Differences

Property	Image	Container
Mutability	Immutable	Mutable (writable layer)
Persistence	Stored (registry)	Temporary (unless saved)
Size	MB	MB + running state
Quantity	One per app	Many from one image

Layers

Images built from layers

Layer 1: Base OS (ubuntu:20.04)
Layer 2: Java 11
Layer 3: Dependencies
Layer 4: Application code
Layer 5: Configuration

Each layer = file system diff

📚 Learn more: Docker Images & Containers

3. Explain Kubernetes architecture¶

View Answer

Kubernetes Cluster Components

Control Plane (Master)
├─ API Server (REST endpoint)
├─ etcd (key-value store, state)
├─ Scheduler (assigns pods to nodes)
├─ Controller Manager (ensures desired state)
└─ Cloud Controller (cloud integration)

Worker Nodes (run containers)
├─ Node 1
│  ├─ kubelet (agent, runs containers)
│  ├─ kube-proxy (networking)
│  └─ Pods (smallest deployable unit)
├─ Node 2
└─ Node 3

Control Plane: Brain of Cluster

Component	Responsibility
API Server	REST API for all operations
etcd	Distributed database (cluster state)
Scheduler	Places pods on nodes
Controller Manager	Ensures desired state (reconciliation)

Worker Node: Executes Workload

Component	Responsibility
kubelet	Agent that runs containers
kube-proxy	Network routing, load balancing
Container Runtime	Docker, containerd, rkt

Communication Flow

kubectl apply -f deployment.yaml
  ↓
API Server (validates, stores in etcd)
  ↓
Controller Manager (detects desired ≠ actual)
  ↓
Scheduler (finds node for new pod)
  ↓
kubelet on Node (pulls image, runs container)

📚 Learn more: Kubernetes

4. What's the difference between a Pod and a Deployment?¶

View Answer

Pod: Smallest Unit

Smallest deployable unit in Kubernetes. Wrapper around container(s).

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Characteristics:

One or more containers (usually one)
Shared network (localhost communication)
Short-lived (deleted when done)
❌ No automatic restart or scaling

Deployment: Manager of Pods

Higher-level abstraction. Manages ReplicaSets which manage Pods.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

Characteristics:

✅ Automatic pod recreation if crashes
✅ Scaling (replicas)
✅ Rolling updates (zero downtime)
✅ Rollback

Hierarchy

Deployment
  ↓
ReplicaSet (manages pod copies)
  ↓
Pod (actual container)

When to Use

Pod: Temporary debugging, one-off jobs

Deployment: Production applications (99% of cases)

📚 Learn more: Kubernetes Pods & Deployments

5. Explain rolling updates, blue-green, and canary deployments¶

View Answer

Rolling Update: Gradual Replacement

Gradually replace old pods with new ones.

Step 1: 5 pods v1
Step 2: 4 pods v1 + 1 pod v2
Step 3: 3 pods v1 + 2 pods v2
Step 4: 2 pods v1 + 3 pods v2
Step 5: 1 pod v1 + 4 pods v2
Step 6: 5 pods v2 (done)

Advantages: Zero downtime, automatic rollback on error

Disadvantages: Gradual (slower), temporary mixed versions

Default in Kubernetes

Blue-Green Deployment: Switch All At Once

Run two complete versions, switch traffic instantly.

Load Balancer
  ↓ (all traffic to Blue)
Blue Environment (v1, production)
  ↓
Green Environment (v2, staging)
  ↓ (test thoroughly)
  ↓ (if OK: switch traffic to Green)
Green Environment (v2, now production)

Advantages: Instant switch, easy rollback

Disadvantages: Resource-intensive (2x environments), no gradual testing

Canary Deployment: Small Rollout First

Deploy to small % of users, monitor, then increase.

Step 1: Route 5% to v2 (canary)
  ↓ Monitor (errors, latency)
Step 2: If OK, route 25% to v2
  ↓ Monitor
Step 3: If OK, route 50% to v2
  ↓ Monitor
Step 4: Route 100% to v2

Advantages: Safe, gradual validation, early error detection

Disadvantages: Slower deployment, complex monitoring

Comparison Table

Strategy	Speed	Risk	Rollback	Resources
Rolling	Slow	Medium	Automatic	1x
Blue-Green	Instant	High (binary)	Instant	2x
Canary	Medium	Low (gradual)	Manual	1.5-2x

📚 Learn more: Deployment Strategies

6. What's GitOps and how does Argo CD implement it?¶

View Answer

GitOps: Git as Source of Truth

Git repository is the single source of truth for infrastructure and applications.

Git Repo (desired state)
  ↓ (Argo CD pulls)
  ↓ (compares with actual)
  ↓
Kubernetes Cluster (applies changes)

GitOps Workflow

1. Developer commits to Git
2. Argo CD detects change
3. Argo CD syncs to Kubernetes
4. Application deployed automatically
5. Git history = deployment history

Argo CD: GitOps Tool for Kubernetes

Continuous delivery tool that syncs Git to Kubernetes.

# Git repo structure
/k8s
├─ base/
│  ├─ deployment.yaml
│  ├─ service.yaml
│  └─ kustomization.yaml
├─ overlays/
│  ├─ dev/
│  ├─ staging/
│  └─ prod/

Argo CD Components

Application: Defines Git repo + target cluster
Sync: Compares Git vs cluster, applies changes
Health: Monitors resource health
Webhook: Triggered by Git push

Benefits

✅ Audit trail: Git history = all changes
✅ Rollback: Simple git revert
✅ Declarative: Yaml files define desired state
✅ Automation: No manual kubectl commands
✅ Consistency: Same deploy process everywhere

📚 Learn more: Kubernetes & GitOps

7. How do you set up a CI/CD pipeline?¶

View Answer

CI/CD Pipeline Stages

Source (Git push)
  ↓
Build (compile, test)
  ↓
Test (unit, integration, e2e)
  ↓
Package (Docker image)
  ↓
Registry (push to Docker Hub)
  ↓
Deploy (staging)
  ↓
Test (smoke tests)
  ↓
Deploy (production)

Continuous Integration (CI)

Automated testing & building on every commit.

Developer pushes code
  ↓
Webhook triggers pipeline
  ↓
Automated:
  - Compile
  - Unit tests
  - Code quality (SonarQube)
  - Security scan
  - Build artifact

Continuous Deployment (CD)

Automatically deploy to production (if tests pass).

Tests pass
  ↓
Create Docker image
  ↓
Push to registry
  ↓
Deploy to Kubernetes
  ↓
Health checks

Tools & Tech Stack

Stage	Tools
Source Control	GitHub, GitLab, Bitbucket
CI/CD Platform	Jenkins, GitLab CI, GitHub Actions, CircleCI
Build Tool	Maven, Gradle, npm
Container Registry	Docker Hub, ECR, GCR
Deployment	Kubernetes, Argo CD, Helm
Monitoring	Prometheus, Grafana, ELK

Example: GitHub Actions Pipeline

name: CI/CD
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: mvn clean test
      - run: docker build -t app:latest .
      - run: docker push app:latest
      - run: kubectl apply -f k8s/

📚 Learn more: CI/CD Pipelines

8. How do you monitor Kubernetes applications?¶

View Answer

Three Pillars of Observability

1. Metrics (Prometheus)

Quantitative measurements: CPU, memory, latency, error rates

Prometheus (scrapes metrics)
  ↓
Alert Manager (triggers alerts)
  ↓
Grafana (visualize dashboards)

2. Logs (ELK Stack)

Event data: application logs, events

Pods (generate logs)
  ↓
Fluentd/Logstash (collect)
  ↓
Elasticsearch (store)
  ↓
Kibana (visualize)

3. Traces (Jaeger)

Request flow: how requests move through services

Service A → Service B → Service C
(Jaeger tracks timing, latency, errors)

Kubernetes-Specific Monitoring

Resource	Metrics to Monitor
Pod	CPU, memory, restart count, ready status
Node	CPU, memory, disk, network
Deployment	Replicas desired vs actual, rollout status
Application	Request latency, error rate, throughput

Health Checks

livenessProbe:      # Is pod alive?
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:     # Ready to serve traffic?
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

Key Alerts to Set

Pod crashes/restarts frequently
Memory usage > 80%
CPU usage sustained high
Error rate > threshold
Response latency > SLA
Deployment replicas not matching desired

📚 Learn more: Monitoring & Observability