DevOps core technologies, detailed review on DevOps & SRE interview questions

Ansible Interview Questions & Answers — Playbooks, Roles, Vault

Mon, 01 Jan 0001 00:00:00 +0000

Ansible core concepts#

Core Concepts#

Agentless: Works over SSH/WinRM. No agent installed on target hosts.
Idempotent: Running the same play multiple times leads to the same state.
Declarative: You describe the desired final state; modules handle the how.
YAML-based Playbooks: Tasks written as YAML documents.
Inventory: List of hosts — static file, dynamic script, cloud plugin.
Modules: Reusable units of work (apt, yum, copy, template, service).
Roles: Standard structure for reusable automation (tasks, handlers, templates).
Facts: System information gathered automatically (ansible_facts).

Inventory#

Default: /etc/ansible/hosts.
Supports groups, nested groups, variables per host/group.
Supports dynamic inventory (AWS, GCP, Azure, Kubernetes…).
Host vars override group vars → group vars override global vars.

Playbooks#

YAML file describing plays: hosts + tasks.
Each task uses a module.
Use handlers for notification-based tasks (restart service only when needed).
Use when for conditionals.
Use loops for repetitive tasks.
Use become: yes for privilege escalation.

Variables#

Several places: playbooks, inventory, group_vars/, host_vars/, vars_files, extra vars.
Precedence: extra vars > task vars > block vars > play vars > inventory.
Use {{ variable }} syntax.
Jinja2 templating for complex expressions.

Roles#

Roles are reusable automation units.
Standard directories: tasks, handlers, templates, files, vars, defaults, meta.
defaults have lowest priority; vars have higher.
Galaxy roles installed using ansible-galaxy install.

Modules#

Most common modules for interviews:

AWS & cloud concepts in general

Mon, 01 Jan 0001 00:00:00 +0000

AWS & cloud concepts in general#

Core AWS Concepts#

Regions = isolated geographic areas.
Availability Zones (AZs) = physically separate datacenters inside a region.
Edge Locations = global CDN points for CloudFront.
IAM = users, roles, policies (JSON). Always assign least privilege. Prefer IAM Roles over access keys.
Organizations = multi-account structure; service control policies (SCPs) to restrict accounts.

Networking#

VPC = isolated virtual network.
Subnets: public (route to IGW) / private (route via NAT or no internet).
IGW = direct internet access.
NAT Gateway = outbound internet for private subnets.
Route Tables = control traffic.
Security Groups = stateful firewall.
NACLs = stateless firewall.
VPC Peering = connect VPCs (no transitive routing).
Transit Gateway = scalable hub for multi-VPC, hybrid networks.
PrivateLink = private connectivity to services without exposing to internet.
Elastic Load Balancers (ELB): ALB (HTTP/HTTPS), NLB (TCP/UDP), CLB (legacy).
Global Accelerator = Anycast routing for TCP/UDP acceleration.

Compute#

EC2#

Instances with different families:

Docker Interview Questions — Images, Networking, Volumes & containerd

Mon, 01 Jan 0001 00:00:00 +0000

Docker and container runtimes#

Core Concepts#

Docker packages applications into containers: isolated, reproducible environments.
Containers share the host OS kernel, unlike VMs. Lightweight and fast.
Containers run from images (immutable templates).
A Dockerfile defines how an image is built.
Layers are cached, enabling fast rebuilds.
A container runtime (Docker, containerd, CRI-O) executes containers.

Docker Architecture#

Docker Engine = Docker CLI + Docker API + Docker daemon + container runtime.
Docker now uses containerd under the hood.
runc is the low-level OCI-compliant runtime that actually spawns containers.
Separation of concerns:
- Docker CLI → user interface
- Dockerd → builds & manages images/containers
- containerd → container lifecycle
- runc → executes containers according to OCI spec

Images & Layers#

Docker images are layered filesystems (UnionFS).
Each Dockerfile line creates a new layer.
Layers are read-only; containers add a writable layer on top.
Layers are reused across images, reducing disk usage.
COPY and RUN create layers; CMD and ENTRYPOINT do not.

Container Lifecycle#

Key states: created → running → paused → stopped → removed.
docker run = create + start.
Containers should be stateless; data must go to volumes.

Volumes & Storage#

Volumes persist data outside container lifecycle.
Types: volumes, bind mounts, tmpfs.
Volumes recommended for production (managed by Docker).
Bind mounts recommended for local development.

Networking#

Default driver: bridge.
Others: host, none, overlay, macvlan.
Overlay networks commonly used in Docker Swarm and Kubernetes (via CNI).
docker run -p maps container port → host port.

Dockerfile Best Practices#

Use small base images (alpine, distroless, scratch).
Use multi-stage builds to reduce size.
Use .dockerignore to avoid huge contexts.
Avoid ADD unless necessary; prefer COPY.
Always define USER (drop root).
Keep layers minimal and logical.

ENTRYPOINT vs CMD#

ENTRYPOINT: fixed executable.
CMD: default arguments.
Combine both:

ENTRYPOINT ["myapp"]
CMD ["--help"]

Security#

Never run containers as root.
Use read-only root filesystem when possible.
Scan images with docker scan or Trivy.
Use minimal images to reduce attack surface.
Namespaces, cgroups, AppArmor/SELinux provide isolation.
OCI runtimes enforce seccomp and capabilities.

containerd (Important for interviews)#

containerd is a container runtime used by Docker and Kubernetes.
Kubernetes uses containerd via CRI (Container Runtime Interface).
Features:
- Image management
- Snapshotters (overlay2, btrfs, zfs)
- Container lifecycle
- gRPC API
runc used by containerd for OCI container execution.
Lightweight, fast, production-grade runtime.

OCI (Open Container Initiative)#

OCI defines two specs:
- Image spec (how images are structured)
- Runtime spec (how containers are executed)
Ensures compatibility between Docker, containerd, CRI-O, Podman.

Docker Compose#

Compose manages multi-container applications.
docker-compose.yml defines services, networks, and volumes.
Used for development; not recommended for production.
Can use profiles to enable/disable specific services.

Performance#

Containers start in milliseconds.
Low overhead since they share host kernel.
Use docker stats for monitoring.
Use build cache + multi-stage builds for optimal performance.

Common Interview Q&A Insights#

Q: Docker vs containerd? A: Docker is a full platform (CLI + daemon + build system); containerd is the low-level runtime Docker uses. Kubernetes uses containerd directly.
Q: How do containers isolate processes? A: Linux namespaces, cgroups, capabilities, seccomp, and rootfs.
Q: Why are images immutable? A: To ensure reproducibility, predictability, and fast deployment.
Q: How do you reduce image size? A: Multi-stage builds, smaller base images, fewer layers, proper caching.
Q: Difference between ENTRYPOINT and CMD? A: ENTRYPOINT = main command; CMD = default args.
Q: Persistent data strategy? A: Volumes or external storage; containers should stay stateless.

Production-grade Dockerfile example#

FROM golang:1.23-alpine AS builder

LABEL org.opencontainers.image.title="my-go-service" \

# Build-time variables
ARG VERSION="dev"

# Runtime env in builder (affects build tools)
ENV CGO_ENABLED=0 \
 GO111MODULE=on \
 GOOS=$TARGETOS \
 GOARCH=$TARGETARCH

# Set shell (handy for strict mode)
SHELL ["/bin/sh", "-ceu"]

WORKDIR /src

# Install build deps (if you need git, ca-certs, etc.)
RUN apk add --no-cache ca-certificates tzdata git

# Copy only go.mod/go.sum first to maximize cache reuse
COPY go.mod go.sum ./
RUN --mount=type=cache,target=/go/pkg/mod \
 go mod download

COPY . .

# Build (with cached build dir)
RUN --mount=type=cache,target=/root/.cache/go-build \
 go build -trimpath \
 -ldflags "-s -w \
 -X main.version=${VERSION} \
 -X main.commit=${COMMIT_SHA}" \
 -o /out/app ./cmd/app

# Minimal runtime stage
FROM gcr.io/distroless/static-debian12:nonroot AS runtime

# Runtime env
ENV APP_ENV=production \
 TZ=UTC \
 PORT=8080

WORKDIR /app

# Copy binary from builder
COPY --from=builder /out/app /app/app

USER nonroot:nonroot

EXPOSE 8080

# Optional volume (for mutable data, logs, etc.)
VOLUME ["/app/data"]

# Healthcheck (note: distroless has no shell; use exec-form)
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
 CMD ["/app/app", "healthcheck"]

# Signal for graceful shutdown
STOPSIGNAL SIGTERM

# Entry + default args
ENTRYPOINT ["/app/app"]
CMD ["serve"]

Docker interview questions#

1. What is the difference between an image and a container?#

Answer: An image is a read-only blueprint (layers + metadata). A container is a running instance of that image with a writable layer on top.

GitHub Actions

Mon, 01 Jan 0001 00:00:00 +0000

GitHub Actions#

Core Concepts#

GitHub Actions is a CI/CD platform integrated into GitHub.
Workflows are defined in YAML under .github/workflows/.
Workflows run on triggers (events), jobs, and steps.
Runners execute jobs — GitHub-hosted or self-hosted.
Reusable workflows allow DRY pipelines across repos.

Workflows#

A workflow = set of jobs triggered by events.
Common triggers:
- push, pull_request, workflow_dispatch, schedule (cron), release, issue_comment.
You can define multiple workflows per repository.

Jobs#

Jobs run in parallel by default.
Use needs: to define dependencies (sequential execution).
Each job runs on its own fresh runner VM.
Common runners: ubuntu-latest, windows-latest, macos-latest, or self-hosted.

Steps#

Steps run inside jobs.
Steps can run shell commands or actions (reusable logic).
Steps share workspace but not environment by default unless env: is set.

Actions#

Reusable units of logic.

GitLab CI/CD Interview Questions — Pipelines, Runners, Environments

Mon, 01 Jan 0001 00:00:00 +0000

GitLab CI/CD core concepts#

Core Concepts#

GitLab CI/CD runs pipelines defined in .gitlab-ci.yml.
Pipelines consist of stages (build → test → deploy).
Each stage contains jobs, executed by GitLab Runners.
Runners can be shared, group, or project level.
Pipelines run automatically on push, MR, or manual triggers.

.gitlab-ci.yml Basics#

Must be in repository root.

Default structure:

stages: [build, test, deploy]
job_name:
 stage: build
 script:
 - command

Use only/except or rules: to control job execution.

Kafka & NATS Interview Questions — Topics, Partitions, Consumer Groups

Mon, 01 Jan 0001 00:00:00 +0000

Kafka, NATS, and streaming & messaging in distributed systems in general#

Messaging in Distributed Systems (Foundations)#

Why messaging is used

It decouples producers from consumers in time and space.
Producers do not block waiting for consumers.
Systems tolerate partial failures better.
Traffic spikes are absorbed by the broker instead of crashing services.

Asynchronous vs synchronous

Messaging is asynchronous by default.
This improves latency isolation but complicates error handling.
Failures move from call-time to processing-time.

Common messaging patterns

Kubernetes Interview Questions — Pods, RBAC, Networking & Autoscaling

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes core concepts#

Core Concepts#

Kubernetes is a container orchestration system for managing containerized apps at scale.
Main objects: Pod, Deployment, ReplicaSet, Service, ConfigMap, Secret, Ingress, PV/PVC, Namespace.
Control plane components: API Server, Scheduler, Controller Manager, etcd.
Node components: kubelet, kube-proxy, container runtime (containerd/Docker/CRI-O).

Pods#

Smallest deployable unit.
Usually 1 container per Pod.
Ephemeral by design — replaced, not repaired.

Deployments & ReplicaSets#

Deployment manages ReplicaSets and provides rollout/rollback features.
Rolling updates by default, supports strategies: RollingUpdate and Recreate.
Revision history stored in ReplicaSets.

Services#

Stable network endpoint for Pods.
Types: ClusterIP, NodePort, LoadBalancer, ExternalName.
Uses kube-proxy (iptables or IPVS) for traffic routing.

Ingress#

HTTP(S) routing + TLS termination.
Requires an Ingress Controller (NGINX, Traefik, HAProxy, Cilium, etc.).
Replaces many NodePort/LoadBalancer services.

ConfigMaps & Secrets#

ConfigMaps hold non-sensitive config.
Secrets hold sensitive data (base64-encoded, optionally encrypted at rest).
Mounted as env vars or files.

Networking#

Every Pod gets a unique IP; Pods can communicate without NAT.
CNI plugins: Calico, Cilium, Flannel, Weave.
kube-proxy manages virtual IPs for services.
Ingress handles L7; Services handle L4.

Volumes & Storage#

PV = cluster-level storage resource.
PVC = claim requesting storage.
StorageClass defines dynamic provisioning.
Common providers: EBS, GCE PD, Ceph, NFS, Longhorn.

Namespaces#

Logical isolation in the cluster.
Important for RBAC, resource quotas, and multi-tenancy.

RBAC#

Role/ClusterRole → set of permissions.
RoleBinding/ClusterRoleBinding → assign permissions.
Follows the principle of least privilege.

Autoscaling#

HPA: scales Pods based on CPU/memory/custom metrics.
VPA: suggests or sets resource requests/limits.
Cluster Autoscaler: scales the node pool.

Probes#

Liveness: restart container if app is stuck.
Readiness: remove from Service endpoints until ready.
Startup: delay other probes until app starts.

Resource Management#

requests = minimum guaranteed resources.
limits = max allowed resources.
Poor requests/limits → throttling, OOMKills, bad scheduling.

Logs & Debugging#

kubectl logs, kubectl exec, kubectl describe, kubectl get events.
Ephemeral containers for debugging in production.
Metrics with Prometheus + Grafana.

Rollouts#

kubectl rollout status, history, undo.
Strategies: rolling, blue/green, canary (via Argo Rollouts/Flagger).

Security#

Disable anonymous access to API server.
Limit capabilities via PodSecurityContext.
Use NetworkPolicies for L3/L4 isolation.
Store secrets in encrypted storage (Vault, KMS).
Scan images (Trivy, Anchore, Clair).

Scheduling#

Scheduler picks best node based on resources + constraints.
Affinity/anti-affinity, taints/tolerations influence scheduling.
NodeSelector = basic placement.
PriorityClasses control eviction order.

DaemonSets, Jobs, CronJobs#

DaemonSet: runs 1 Pod per node (logging, monitoring).
Job: run task once until successful.
CronJob: scheduled Jobs.

etcd#

Strongly consistent key-value store.
Stores all cluster state.
Backups critical for disaster recovery.

Common Interview Questions to Expect#

Explain Pod vs Deployment.
How does service discovery work?
Difference between Ingress and Service.
How HPA works under the hood.
What’s the purpose of RBAC?
Pod rescheduling logic when a node dies.
Taints vs tolerations vs affinity.
Troubleshooting a CrashLoopBackOff.
How to secure a cluster.
StorageClass/PV/PVC workflow.

Kubernetes interview questions#

1. What is the difference between a Deployment and a StatefulSet?#

A Deployment manages stateless apps with interchangeable pods, while a StatefulSet ensures stable network identities, persistent storage per pod, and ordered, deterministic scaling.

Linux Interview Questions for DevOps & SRE — Processes, systemd, Networking

Mon, 01 Jan 0001 00:00:00 +0000

Linux core concepts#

1. Linux Architecture#

Everything is a file (devices, sockets, pipes).
Kernel handles process scheduling, memory, I/O, networking.
System calls bridge user space ↔ kernel space (strace shows them).
Runlevels replaced by systemd targets (multi-user, graphical).

2. Processes & Systemd#

ps aux, top, htop, atop → inspect processes & resource usage.
systemctl start/stop/status/enable/disable/restart unit.
Signals: SIGTERM (15, graceful), SIGKILL (9, force), SIGINT (2, Ctrl+C).
nice & renice → CPU scheduling priorities.
nohup & & → run tasks in background.

3. Filesystems#

Common FS: ext4, xfs, btrfs, zfs.
df -h → disk usage.
du -sh * → directory usage.
lsblk, blkid, mount, umount.
/etc/fstab → persistent mounts.
Inodes track metadata; running out of inodes breaks file creation.

4. Permissions & Ownership#

rwx model for user/group/other.

Networking (TCP/IP, load balancing, etc)

Mon, 01 Jan 0001 00:00:00 +0000

Networking core concepts#

OSI Model (7 layers)#

L1 – Physical: Cables, NICs, bits.
L2 – Data Link: MAC addresses, switches, VLANs, STP.
L3 – Network: IP, routing, subnets, CIDR, ARP.
L4 – Transport: TCP/UDP, ports, handshake, retransmission.
L5 – Session: Connection management. Rare in practical ops.
L6 – Presentation: Encryption, compression, TLS framing.
L7 – Application: HTTP, DNS, SMTP, gRPC.

Key Interview Tip#

OSI layers help troubleshoot: “Which layer is failing?”
Map protocols to layers (HTTP → L7, TLS → L6, IP → L3, etc).

TCP/IP Model (4 layers)#

PostgreSQL Interview Questions — Indexes, MVCC, Replication & Performance

Mon, 01 Jan 0001 00:00:00 +0000

PostgreSQL & database concepts in general#

Architecture#

PostgreSQL uses a process-based architecture (one OS process per connection).
Uses WAL (Write-Ahead Log) to guarantee durability.
Data stored in pages (8 KB) inside tablespaces.
MVCC (Multi-Version Concurrency Control) enables high concurrency without read locks.
Uses shared buffers + OS page cache together.

MVCC#

Each row has xmin/xmax transaction IDs.
No locks for reads → avoids read contention.
Dead tuples accumulate → require VACUUM to clean them.
MVCC ensures consistent snapshot isolation.

Indexes#

Most common: B-Tree (default).
Others: GIN (full-text search, JSONB), GiST (geospatial), BRIN (very large, sequential tables), HASH (rarely used).
Too many indexes slow down writes.
Reindex needed if index bloats.

Replication#

Native replication is physical WAL streaming.

Terraform Interview Questions — State, Modules, Providers & IaC Best Practices

Mon, 01 Jan 0001 00:00:00 +0000

Terraform#

Core Concepts#

IaC tool using declarative syntax (HCL).
Idempotent: same config → same result.
Execution plan: terraform plan shows actions before applying.
State file tracks real infrastructure and resource mappings.
Providers are plugins to manage cloud resources (AWS, GCP, Azure, etc.).

State Management#

terraform.tfstate stores resource attributes.
Remote backends (S3 + DynamoDB, GCS, Azure Blob) enable teamwork + locking.
State locking prevents concurrent writes.
State is sensitive → encrypt + restrict access.
Use terraform state rm/mv for manual state surgery.

Modules#

Reusable components of Terraform configuration.
Improve DRY, structure, and versioning.
Use public registry or private repositories.
Pin version: source = "..." version = "x.y.z".

Variables & Outputs#

Variables defined in variables.tf, passed via .tfvars, CLI, or environment.
Sensitive inputs: sensitive = true.
Outputs expose resource info (IP, URL) and can be marked sensitive.
Input variable precedence: CLI > tfvars > environment > defaults.

Terraform Lifecycle#

terraform init → download providers.
terraform validate → check syntax.
terraform plan → preview changes.
terraform apply → create/update/delete.
terraform destroy → teardown.

Resource Lifecycle Rules#

create_before_destroy prevents downtime.
prevent_destroy = true protects critical resources.
ignore_changes allows external changes without drift detection.

Terraform Provisioners#

Not recommended unless no alternative.
local-exec runs local commands.
remote-exec runs commands on remote machines.
Better use: Ansible, cloud-init, user_data.

Backends#

Store & manage state remotely.
Common backends: S3 (with DynamoDB lock), Consul, Terraform Cloud, GCS, Azure Blob.
Backend configuration cannot use variables.

Workspaces#

Logical separation of state within the same config.
Good for simple multi-env (dev/stage/prod), but many teams prefer separate state files per environment.

Dependency Management#

Terraform handles dependencies automatically via attributes.
depends_on is used when implicit dependency is missing (use sparingly).

Drift Detection#

Run terraform plan frequently.
Config != actual cloud resources → drift.
Use CI pipelines for automated drift checks.

Security Best Practices#

Never store secrets in tfvars or state.
Use Vault or Cloud KMS/Secrets Manager.
Restrict who can read terraform.tfstate.
Use S3 bucket encryption & versioning for state.

Testing & CI/CD#

tflint → syntax + best practices.
tfsec / checkov → security scanning.
terratest → automated infra tests in Go.
pre-commit hooks for fmt, validate.

Common Interview Questions#

Explain Terraform state and why it’s needed.
Difference between local and remote backends.
What happens if you manually modify resources in AWS?
Purpose of modules and how to structure them.
How to handle secrets in Terraform?
Difference between workspaces vs separate repos/states.
How to avoid downtime during resource updates?
Why provisioners are discouraged.

Recommended Terraform directory structure#

terraform/
├── modules/ # reusable building blocks (no env-specific values)
│ ├── vpc/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ │ └── README.md
│ ├── eks/
│ └── rds/
│
├── envs/ # environment roots (compose modules here)
│ ├── dev/
│ │ ├── main.tf # calls modules
│ │ ├── variables.tf
│ │ ├── dev.tfvars # optional: env values
│ │ ├── backend.tf # remote state config
│ │ └── providers.tf
│ ├── stage/
│ └── prod/
│
├── global/ # shared things used by multiple envs
│ ├── iam/
│ ├── route53/
│ └── org-policies/
│
├── scripts/ # helper scripts (plan wrappers, lint, etc.)
│ ├── fmt.sh
│ ├── validate.sh
│ └── drift-check.sh
│
├── policies/ # OPA/Sentinel/Conftest policies
│
├── tests/ # terratest / kitchen-terraform / etc.
│
├── .terraform.lock.hcl
└── README.md

DevOps & SRE interview questions — main page
DevOps middle+, senior interview questions
Ansible — configuration management paired with Terraform
Kubernetes — infrastructure Terraform often provisions
AWS & cloud concepts — cloud provider Terraform manages
GitHub Actions — run Terraform in CI/CD pipelines
GitLab CI/CD — alternative CI for Terraform workflows