Linux_Practical_Interview_751 1000

Linux Practical Interview Questions (751-1000)

Level 15: Advanced Linux and SRE

Containers

Q751: How do you implement container orchestration?

What it is: Container orchestration covers scheduling and placement, automatic scaling, networking through a service mesh, storage via CSI, and security policies.

Why it is used: To run containers at scale with automated placement and lifecycle management.

# Container orchestration
# 1. Scheduling
# Placement

# 2. Scaling
# Auto

# 3. Networking
# Service mesh

# 4. Storage
# CSI

# 5. Security
# Policies

Interview talking point: “CSI and CNI are the extension points for storage and networking, so the orchestrator stays generic while plugins supply environment-specific behavior.”

Q752: How do you implement container orchestration?

What it is: Container orchestration manages scheduling/placement, auto-scaling, service mesh networking, CSI storage, and security policies.

Why it is used: To run containerized workloads at scale with reliability and security.

# Scheduling
# Placement

# Scaling
# Auto

# Networking
# Service mesh

# Storage
# CSI

# Security
# Policies

Interview talking point: “Service mesh and CSI extend networking and storage control, while security policies and scheduling balance resilience with constraints.”

Q753: How do you manage Docker images?

What it is: Docker images are the templates containers run from: images lists them, pull fetches nginx:latest, build makes one, tag gives it a registry name and version, push uploads, rmi removes.

Why it is used: Versioning and distributing application images between hosts and registries.

# List images
docker images

# Pull image
docker pull nginx:latest

# Build
docker build -t myimage .

# Tag
docker tag myimage registry/myimage:v1

# Push
docker push registry/myimage:v1

# Remove
docker rmi image

Interview talking point: “Explicit tags matter: docker tag myimage registry/myimage:v1 pins a version before push, so deployments can reference v1 instead of a moving latest, and docker rmi removes an image tag.”

Q754: How do you manage Docker volumes?

What it is: Volumes store data outside a container’s writable layer; named volumes are created by Docker while bind mounts expose a host path at a container path.

Why it is used: To keep database and application data when containers are recreated or images updated.

# Create volume
docker volume create mydata

# Mount volume
docker run -v mydata:/data mysql

# Bind mount
docker run -v /host/path:/container/path nginx

# Volume driver
docker volume create --driver local myvolume

# View volumes
docker volume ls
docker volume inspect mydata

Interview talking point: “docker volume create mydata followed by -v mydata:/data gives a Docker-managed path, whereas -v /host/path:/container/path ties the container to a specific host directory. docker volume inspect reveals where the data really lives.”

Q755: How do you manage Docker volumes?

What it is: Docker volumes are named storage areas created with docker volume create and mounted with -v, distinct from bind mounts of host paths and tmpfs memory mounts.

Why it is used: To persist database and application data beyond a container’s lifetime.

# Create volume
docker volume create mydata

# Mount volume
docker run -v mydata:/data mysql

# Bind mount
docker run -v /host/path:/container/path nginx

# tmpfs mount
docker run --tmpfs /tmp nginx

# List volumes
docker volume ls

# Inspect volume
docker volume inspect mydata

# Remove unused volumes
docker volume prune

# Backup volume
docker run --rm -v mydata:/data -v $(pwd):/backup alpine \
  tar cvf /backup/backup.tar /data

Interview talking point: “a named volume is managed by Docker while a bind mount pins an explicit host path, and the alpine container running tar over /data copies a volume out to the host for backup.”

Q756: How do you use Buildah in rootless mode?

What it is: Buildah builds OCI images, and these commands do it unprivileged, using the vfs storage driver or the keep-id user namespace mapping to retain the calling user’s UID.

Why it is used: To build images as a normal user on locked-down or CI hosts.

# Build
buildah --storage-driver vfs bud -t myimage .

# Without root
buildah --userns=keep-id bud -t myimage .

Interview talking point: “vfs avoids needing overlayfs support so rootless builds work anywhere, while —userns=keep-id keeps file ownership aligned with your own user instead of remapping it.”

Q757: How do you use Buildah?

What it is: Buildah builds OCI images without a daemon. buildah bud builds from a Dockerfile, or build, run, and commit steps assemble an image manually, and buildah push uploads it.

Why it is used: To build container images on build servers or rootless hosts without running a container daemon.

# Build from Dockerfile
buildah bud -t myimage .

# Build without Dockerfile
buildah from alpine
buildah run alpine -- apk add nginx
buildah commit alpine myimage

# Use multiple containers
buildah bud --layers -t myapp

# Push to registry
buildah push myimage

Interview talking point: “buildah bud —layers caches each build step so later builds reuse them, while buildah from plus run plus commit builds step by step with no Dockerfile at all. Both routes finish at buildah push.”

Q758: How do you use Buildah?

What it is: Buildah builds container images either from a Dockerfile with bud or interactively with from, run, and commit. —layers caches intermediate layers and push sends the image to a registry.

Why it is used: To build images without a running daemon, especially in rootless CI pipelines.

# Build from Dockerfile
buildah bud -t myimage .

# Build without Dockerfile
buildah from alpine
buildah run alpine -- apk add nginx
buildah commit alpine myimage

# Layers
buildah bud --layers -t myapp

# Push
buildah push myimage docker://registry/myimage:latest

Interview talking point: “from plus run plus commit builds an image step by step with no Dockerfile, while bud reads a Dockerfile, and the —layers flag reuses cached layers across builds.”

Q759: How do you use containerd-shim?

What it is: containerd-shim is the small supervising process placed between each container and containerd. Here ctr pulls an image and starts a detached nginx container through containerd.

Why it is used: To run and manage containers directly on containerd without the Docker daemon.

# Run with containerd
ctr images pull docker.io/library/nginx:latest
ctr run -d docker.io/library/nginx:latest nginx

Interview talking point: “Because each container is parented by its shim, restarting containerd does not kill running containers, which is the reason the shim exists.”

Q760: How do you use cri-dockerd?

What it is: cri-dockerd adapts Docker to the Kubernetes CRI. It is installed into /usr/local/bin and run as a systemd service that requires docker.service and starts with a CNI plugin and pause image.

Why it is used: To let Kubernetes use Docker as its runtime after dockershim was removed from kubelet.

# Install
wget https://github.com/Mirantis/cri-dockerd/releases/latest/download/cri-dockerd-amd64
install -o root -g root -m 0755 cri-dockerd-amd64 /usr/local/bin/cri-dockerd

# Run with systemd
# /etc/systemd/system/cri-docker.service
[Unit]
Description=CRI-Docker
After=network-online.target firewalld.service docker.service
Requires=docker.service

[Service]
ExecStart=/usr/local/bin/cri-dockerd --network-plugin=cni --pod-infra-container-image=pause:3.9

Interview talking point: “The unit carries Requires=docker.service plus After=network-online.target firewalld.service docker.service, so dependency and ordering are configured separately. The flags —network-plugin=cni and —pod-infra-container-image=pause:3.9 decide how pods are wired and which sandbox image is used.”

Q761: How do you use Docker build cache?

What it is: Docker caches image layers between builds. docker build —no-cache ignores stored layers, —cache-from reuses layers from a named image, and docker builder prune removes cached build data.

Why it is used: To speed up repeated builds and decide when stale layers must be rebuilt.

# Build with cache
docker build .

# No cache
docker build --no-cache .

# Cache from
docker build --cache-from image:tag .

# Prune cache
docker builder prune

Interview talking point: “Seeding with —cache-from lets a CI job inherit layers pushed by an earlier run instead of starting cold, and docker builder prune is what reclaims disk when the cache grows large.”

Q762: How do you use Docker compose extends?

What it is: Compose extends lets a service inherit its definition from another file. Here the local web service takes build and environment from a base file and adds ports of its own.

Why it is used: To reuse common service settings across compose files without copying them.

services:
  web:
    build: .
    environment:
      - ENV=production

# docker-compose.yml
services:
  web:
    extends:
      file: docker-compose.base.yml
      service: web
    ports:
      - "80:80"

Interview talking point: “extends pulls in only the named service, so shared keys live once in the base file while environment-specific keys like ports stay in each local file.”

Q763: How do you use Docker Compose for orchestration?

What it is: A Compose file declares services, port mappings, networks, dependencies, healthchecks, environment variables, images, and named volumes for a multi-container application.

Why it is used: To define and start an entire application stack with one command.

version: '3.8'
services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    networks:
      - frontend
    depends_on:
      - app
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/"]
      interval: 30s
      timeout: 10s
      retries: 3

  app:
    build: .
    networks:
      - frontend
      - backend
    environment:
      - DATABASE_URL=postgres://db:5432/myapp

  db:
    image: postgres:14
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend

networks:
  frontend:
  backend:

volumes:
  db-data:

Interview talking point: “Splitting frontend and backend networks keeps the database off the web tier, and the named db-data volume preserves PostgreSQL data across container recreation.”

Q764: How do you use Docker compose networking?

What it is: Compose lets services join named networks. web is attached only to frontend, api to both frontend and backend, and the backend network is declared with the overlay driver.

Why it is used: To segment services so only the ones that should talk can reach each other.

version: '3'
services:
  web:
    build: .
    networks:
      - frontend
  api:
    build: .
    networks:
      - frontend
      - backend

networks:
  frontend:
  backend:
    driver: overlay

Interview talking point: “Because api is on two networks and web is only on frontend, web can reach api but nothing beyond it, giving straight separation declared right in the compose file.”

Q765: How do you use Docker Compose?

What it is: Docker Compose describes multi-container stacks in docker-compose.yml; this one runs nginx with a host port and bind mount plus MySQL with an environment password, started detached by up -d.

Why it is used: Reproducible multi-container environments defined in one version-controlled file.

version: '3'
services:
  web:
    image: nginx
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html
  db:
    image: mysql
    environment:
      MYSQL_ROOT_PASSWORD: secret

# Commands
docker-compose up -d
docker-compose down
docker-compose ps
docker-compose logs -f

Interview talking point: “The ./html:/usr/share/nginx/html bind mount makes host files visible inside the container for editing, and docker-compose down removes the whole stack while up -d recreates it from the file.”

Q766: How do you use Docker Compose?

What it is: A Compose file declares services with their builds, ports, environment, networks, and named volumes so a whole stack starts together. Networks and volumes are defined at the top level.

Why it is used: To describe and launch a multi-container application with one command.

version: '3.8'
services:
  web:
    build: .
    ports:
      - "80:80"
    environment:
      - NODE_ENV=production
    depends_on:
      - db
    networks:
      - frontend
      - backend

  db:
    image: postgres:14
    volumes:
      - dbdata:/var/lib/postgresql/data
    networks:
      - backend

networks:
  frontend:
  backend:

volumes:
  dbdata:

Interview talking point: “Here web joins frontend and backend while db joins only backend, so db is unreachable from frontend, showing how Compose networks act as isolation boundaries between services.”

Q767: How do you use Docker configs?

What it is: Docker configs carry non-sensitive files like nginx.conf. Create one with docker config create, list with docker config ls, then attach it to a service with a source, target path, and mode.

Why it is used: To change application configuration without rebuilding the image.

# Create config
docker config create nginx_config nginx.conf

# Use
docker config ls

# In service
configs:
  - source: nginx_config
    target: /etc/nginx/nginx.conf
    mode: 0444

Interview talking point: “The mode 0444 in the service mapping shows configs mount read-only, and that plus their plain-file nature is what separates configs from secrets in Swarm.”

Q768: How do you use Docker healthchecks in compose?

What it is: A compose healthcheck runs a command test against the container with an interval, timeout, retries, and a start period before failures start counting.

Why it is used: So a service that is up but broken gets detected and reported.

services:
  web:
    image: nginx
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Interview talking point: “The test is written as an exec-style array rather than a shell string, and start_period of 40s lets a slow-starting service avoid being marked unhealthy during boot.”

Q769: How do you use Docker logging drivers?

What it is: A logging driver decides where container stdout and stderr go. Shown are json-file with max-size and max-file caps, syslog to a remote address, and fluentd to a log collector.

Why it is used: To centralize logs and stop them from filling the local disk.

# JSON file
docker run --log-driver json-file --log-opt max-size=10m --log-opt max-file=3 nginx

# Syslog
docker run --log-driver syslog --log-opt syslog-address=tcp://localhost:514 nginx

# Fluentd
docker run --log-driver fluentd --log-opt fluentd-address=localhost:24224 nginx

Interview talking point: “The default json-file driver grows without limit unless max-size and max-file are set, which is a classic cause of full disks on Docker hosts.”

Q770: How do you use Docker multi-stage builds?

What it is: A multi-stage build uses several FROM stages in one Dockerfile. This example compiles the Go binary in golang:1.20, then copies only that binary into a slim alpine:3.18 runtime stage.

Why it is used: To produce small production images that leave compilers and source behind.

# Build stage
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

# Runtime stage
FROM alpine:3.18
COPY --from=builder /app/main /app/main
CMD ["/app/main"]

Interview talking point: “COPY —from=builder moves just the artifact across stages, so the final image contains no Go toolchain or source, cutting both image size and attack surface.”

Q771: How do you use Docker networking?

What it is: Docker networks come in drivers: bridge for the default isolated network, host for the host network stack, and overlay for swarm across hosts. DNS and aliases attach to containers.

Why it is used: To control how containers reach each other and the outside network.

# Create network
docker network create mynet

# Host network
docker run --network host nginx

# Bridge
docker run --network bridge nginx

# Overlay (swarm)
docker network create --driver overlay myoverlay

# DNS
docker run --dns 8.8.8.8 nginx
docker run --network-alias myapp nginx

Interview talking point: “host networking removes port mapping because the container shares the host stack, while bridge requires published ports, and overlay is what you need only for multi-host swarm traffic.”

Q772: How do you use Docker networks?

What it is: Docker networks connect containers. docker network create makes a bridge by default or an overlay with -d, containers join via —network, and connect can pin a static IP.

Why it is used: To isolate traffic, enable service name resolution, and control how containers reach each other.

# Create network
docker network create mynet

# Overlay
docker network create -d overlay mynet

# Use network
docker run --network mynet nginx

# Static IP
docker network connect --ip 10.0.0.10 mynet container

Interview talking point: “Overlay is the driver that spans hosts in Swarm, while containers on the default bridge do not get DNS-based name resolution between each other.”

Q773: How do you use Docker resource limits?

What it is: Docker resource limits constrain a container: -m caps memory, —cpus caps CPU share, a device read bandwidth limit throttles disk, and —restart controls automatic restart behavior.

Why it is used: To stop one container from starving the host or its neighbors.

# Memory
docker run -m 512m nginx

# CPU
docker run --cpus=0.5 nginx

# Blkio
docker run --device-read-bps /dev/sda:50mb nginx

# Restart policy
docker run --restart=unless-stopped nginx

Interview talking point: “restart policy unless-stopped brings the container back even after a daemon or host restart, so it is the setting for services that must survive a reboot.”

Q774: How do you use Docker rootless?

What it is: Rootless Docker runs the daemon and its containers as an ordinary user, installed via docker-ce-rootless-extras, set up with dockerd-rootless-setuptool.sh, and started as a per-user systemd service.

Why it is used: To run containers without root privileges on shared or hardened hosts.

# Install
apt install docker-ce-rootless-extras

# Setup
dockerd-rootless-setuptool.sh install

# Start
systemctl --user enable docker
systemctl --user start docker

# Use
docker run nginx

Interview talking point: “Note it is enabled with systemctl —user, so it runs in the user’s systemd session rather than as a system service, and the docker CLI then talks to that user’s daemon.”

Q775: How do you use Docker volumes?

What it is: A bind mount maps a host path into a container, a named volume is managed by Docker, and tmpfs mounts a memory-only filesystem. The ro suffix makes a mount read-only.

Why it is used: To persist data beyond container lifetime and to share files with the host.

# Bind mount
docker run -v /host/path:/container/path nginx

# Named volume
docker volume create mydata
docker run -v mydata:/data nginx

# tmpfs
docker run --tmpfs /run nginx

# Read-only
docker run -v /data:/data:ro nginx

# Backup volume
docker run --rm -v mydata:/data -v $(pwd):/backup alpine tar cvf /backup/backup.tar /data

Interview talking point: “The backup example starts a temporary alpine container that tars the named volume into the current directory, so backups never require the original data container to be running.”

Q776: How do you use Docker volumes?

What it is: Docker volumes persist data outside containers: named volumes created with docker volume create, bind mounts of a host directory, a tmpfs mount in memory, and an NFS-backed volume.

Why it is used: To keep data across container restarts and share files with the host or network.

# Named volume
docker volume create myvol
docker run -v myvol:/data nginx

# Bind mount
docker run -v $(pwd):/data nginx

# tmpfs
docker run --tmpfs /tmp nginx

# NFS
docker volume create --driver local \
  -o type=nfs \
  -o o=addr=192.168.1.10,rw \
  -o device=:/path nfsvol

Interview talking point: “tmpfs lives only in memory and disappears with the container, while a bind mount exposes the host path directly, so the host directory’s permissions apply inside the container.”

Q777: How do you use Docker?

What it is: docker ps -a lists containers, run -d -p 8080:80 starts nginx detached with a port mapping, build creates an image, exec opens a shell, and logs -f streams output.

Why it is used: Running applications in isolated, repeatable containers.

# List containers
docker ps -a

# Run container
docker run -d -p 8080:80 --name web nginx

# Build image
docker build -t myimage .

# Manage
docker start/stop/restart container
docker exec -it container /bin/bash
docker logs -f container
docker rm container

Interview talking point: “-p 8080:80 maps host port 8080 to container port 80, and docker exec -it gives an interactive shell while logs -f follows output, which together cover most container debugging.”

Q778: How do you use Podman generate systemd?

What it is: podman generate systemd emits a unit file for a container, either streamed by name or written out with —files and —new, plus a directory for drop-ins.

Why it is used: To give a Podman container restart behavior and dependencies handled by systemd.

# Generate unit files
podman generate systemd --name mycontainer > container.service

# With dependencies
podman generate systemd --name mycontainer --files --new

# Create drop-in
mkdir -p /etc/systemd/system/container.service.d

Interview talking point: “The —files and —new combination writes units that create a fresh container on each start instead of reusing the old one, which makes restarts reproducible.”

Q779: How do you use Podman networks?

What it is: Podman networks are created with podman network create, containers join with —network, and a per-container DNS server can be supplied with —dns.

Why it is used: To give containers private network segments and controlled name resolution.

# Create network
podman network create mynet

# Run with network
podman run -d --network mynet nginx

# DNS
podman run -d --network mynet --dns 8.8.8.8 nginx

Interview talking point: “Unlike Docker these commands work with no daemon in the picture, and —dns lets one container on a shared network resolve through a different resolver than its peers.”

Q780: How do you use Podman Quadlet?

What it is: Podman Quadlet converts a .container unit file into a systemd service, declaring image, published port, restart policy, and install target in standard INI sections.

Why it is used: To manage containers as normal systemd services with boot-time startup.

# nginx.container
[Container]
Image=nginx:latest
PublishPort=8080:80

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Interview talking point: “With WantedBy=multi-user.target the container starts at boot through systemd itself, and there is no Podman daemon behind it, unlike Docker’s restart policies.”

Q781: How do you use Podman?

What it is: Podman runs containers without a daemon, including rootless ones. It runs and lists containers, follows logs, builds and pushes images, and can generate a systemd unit for a container.

Why it is used: To run and automate containers where a long-running Docker daemon is unwanted or prohibited.

# Rootless containers
podman run -d nginx
podman ps
podman logs -f container

# Build image
podman build -t myimage .
podman push myimage registry.example.com/myimage

# Systemd service
podman generate systemd --name myapp > myapp.service
systemctl enable --user myapp

Interview talking point: “podman generate systemd —name myapp emits a unit you enable with systemctl enable —user, giving restart-on-boot without a central daemon. Rootless operation also means the containers belong to the unprivileged user account.”

Q782: How do you use Podman?

What it is: Podman runs containers without a daemon, often rootless, and builds images the same way. It can generate a systemd unit, or a Quadlet .container file can be started by systemd.

Why it is used: To run containers on servers where a privileged background daemon is unwanted.

# Rootless
podman run -d nginx

# Build
podman build -t myimage .
podman build -f Dockerfile.custom

# Systemd integration
podman generate systemd --name container > container.service

# Quadlet
cat > container.container <<EOF
[Container]
Image=nginx
PublishPort=8080:80

[Service]
Restart=always
EOF
systemctl --user start container

Interview talking point: “Quadlet files such as container.container let systemd handle restart policy and ordering for a user service, replacing the unit files produced by podman generate systemd.”

Q783: How do you use Skopeo?

What it is: Skopeo works with registry images without pulling them locally. It inspects a remote image, copies between registries, lists tags, and deletes a tag from a registry.

Why it is used: To move or audit images across registries, or check metadata without downloading gigabytes to the host.

# Inspect remote image
skopeo inspect docker://nginx:latest

# Copy between registries
skopeo copy docker://source/nginx:latest docker://dest/nginx:latest

# List tags
skopeo list-tags docker://registry.example.com/myimage

# Delete
skopeo delete docker://registry.example.com/myimage:tag

Interview talking point: “skopeo copy moves an image directly between two docker:// endpoints, so mirroring needs no local daemon. inspect and list-tags answer questions about a remote image without ever pulling its layers down to disk.”

Q784: How do you use Skopeo?

What it is: Skopeo works with container images without running containers. It inspects remote images, copies them between registries, lists tags, and syncs a registry or directory to local storage.

Why it is used: To move or examine images across registries without pulling them into a local daemon.

# Inspect
skopeo inspect docker://nginx:latest

# Copy
skopeo copy docker://src/nginx:latest docker://dest/nginx:latest

# List tags
skopeo list-tags docker://registry/myimage

# Sync
skopeo sync --src docker --dest dir nginx /local/path

Interview talking point: “skopeo copy can move an image between two registries directly on the server, so no local daemon storage is involved and mirroring an air-gapped cluster becomes a single command.”

Q785: How do you optimize container images?

What it is: Container image optimization using a minimal base image, fewer layers, build cache, multi-stage builds, and security scanning.

Why it is used: Shrinks images, speeds builds and pulls, and reduces attack surface.

# Container image optimization
# 1. Base image
# Minimal

# 2. Layers
# Reduce

# 3. Caching
# Build cache

# 4. Multi-stage
# Build

# 5. Scanning
# Security

Interview talking point: “Multi-stage builds address the classic tradeoff of build tools versus runtime size: compilers and caches stay in the first stage and only artifacts ship. Layer reduction plus caching helps both pull time and build time.”

Q786: How do you optimize container images?

What it is: Container image optimization uses minimal base images, reduces layers, leverages build cache, applies multi-stage builds, and performs security scanning.

Why it is used: To build smaller, faster, and more secure container images.

# Base image
# Minimal

# Layers
# Reduce

# Caching
# Build cache

# Multi-stage
# Build

# Scanning
# Security

Interview talking point: “Multi-stage builds and minimal bases shrink attack surface and size, while caching and scanning improve build efficiency and security.”

Q787: How do you optimize Docker images?

What it is: Image optimization uses Alpine base images, multi-stage builds that copy only artifacts from a builder stage, merged run layers, and a dockerignore file.

Why it is used: To shrink image size, speed pulls, and reduce the attack surface.

# Use Alpine
FROM node:18-alpine

# Use multi-stage build
FROM node:18-alpine AS builder
WORKDIR /build
COPY package*.json ./
RUN npm ci --only=production

FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node

# Combine layers
RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*

# Use .dockerignore
# node_modules
# .git
# *.log

Interview talking point: “Copying just node_modules out of the builder stage leaves compilers and caches behind, and combining package install with cleaning apt lists in one RUN avoids carrying a stale layer.”

Q788: How do you optimize Docker images?

What it is: Docker image optimization using a small Alpine base, a multi-stage build that copies only built artifacts, a non-root USER, and a .dockerignore file.

Why it is used: To shrink image size, cut pull time, and reduce the attack surface.

# Use minimal base image
FROM alpine:3.18

# Multi-stage build
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .

FROM node:18-alpine AS production
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app .
USER node
EXPOSE 3000
CMD ["node", "index.js"]

# .dockerignore
node_modules
.git
*.md
.env*

Interview talking point: “Multi-stage builds leave compilers and source behind in the builder stage, and .dockerignore keeps node_modules and .git out of the build context so COPY never bloats layers.”

Q789: How do you optimize Docker?

What it is: A multi-stage Dockerfile builds inside a heavy image and copies only the resulting binary into a small final stage. .dockerignore excludes files from the build context.

Why it is used: To shrink image size, speed builds, and keep build tools out of production images.

# Use multi-stage builds
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

FROM alpine:3.18
COPY --from=builder /app/main /app/main
CMD ["/app/main"]

# .dockerignore
node_modules
.git
*.md

# Build args
ARG VERSION
ENV VERSION=$VERSION

Interview talking point: “The builder stage with golang is discarded entirely, so only the compiled binary lands in the alpine image, and .dockerignore entries such as node_modules keep the uploaded context small.”

Q790: How do you optimize Linux for containers?

What it is: Container tuning raises limits such as fs.file-max, kernel.pid_max, and net.core.somaxconn, disables swap, and sets transparent huge pages to never.

Why it is used: To keep dense container hosts from hitting PID, file descriptor, or memory limits.

# Kernel parameters
net.core.somaxconn = 1024
net.ipv4.ip_local_port_range = 1024 65535
fs.file-max = 2097152
kernel.pid_max = 4194304

# Disable swap
swapoff -a

# Transparent huge pages
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# SELinux/AppArmor
setenforce 0

Interview talking point: “swapoff -a matters because containers under memory pressure otherwise swap and stall, and setting both THP files to never avoids latency spikes in long-running services.”

Q791: How do you optimize Linux for containers?

What it is: Container host tuning sets sysctl values like bridge-nf-call-iptables, ip_forward, swappiness, file-max and TCP backlog applied with sysctl -p, plus a Docker config with overlay2 and capped logs.

Why it is used: Keep networking, file limits and logging predictable under many concurrent containers.

# Kernel parameters for containers
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.ipv4.ip_forward=1

# Disable swap
vm.swappiness=0

# File limits
fs.file-max=65536

# Network
net.core.somaxconn=1024
net.ipv4.tcp_max_syn_backlog=2048

# Apply
sysctl -p

# Container-optimized OS
# Use Ubuntu Core, RancherOS, Flatcar

# Docker daemon
# /etc/docker/daemon.json
{
  "storage-driver": "overlay2",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "live-restore": true,
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 64000,
      "Soft": 64000
    }
  }
}

Interview talking point: “The json-file log driver with max-size and max-file stops container logs from filling the disk, and live-restore keeps containers running when the Docker daemon restarts or upgrades.”

Q792: How do you optimize Linux for containers?

What it is: Container optimization means a minimal OS, a container-tuned kernel, overlay2 for storage, a CNI for networking, containerd as the runtime, and hardened security settings.

Why it is used: To run more containers per host with less overhead and safer defaults.

# Container optimization
# 1. OS
# Minimal OS

# 2. Kernel
# Tuned for containers

# 3. Storage
# Overlay2

# 4. Network
# CNI

# 5. Runtime
# containerd

# 6. Security
# Hardened

Interview talking point: “Overlay2 and the CNI are named as the storage and network layers, so container performance questions usually come down to the filesystem driver and the plugin beneath the runtime.”

Q793: How do you optimize Linux for containers?

What it is: Optimizing Linux for containers involves using minimal OS images, tuned kernels, and container-appropriate storage and networking.

Why it is used: It improves security, reduces overhead, and increases container density on hosts.

# OS
# Minimal OS

# Kernel
# Tuned for containers

# Storage
# Overlay2

# Network
# CNI

# Runtime
# containerd

# Security
# Hardened

Interview talking point: “Using Overlay2 for storage with a CNI and containerd runtime provides a lean, efficient container host.”

Q794: How do you use Docker compose profiles?

What it is: Compose profiles tag services so they only start when selected. Here db belongs to the database profile, admin to the admin profile, and web runs with no profile at all.

Why it is used: To keep optional or heavy services out of the default compose up.

version: '3.9'
services:
  web:
    image: nginx
  db:
    image: mysql
    profiles: ["database"]
  admin:
    image: adminer
    profiles: ["admin"]

Interview talking point: “Services with a profile are skipped unless that profile is chosen, so a developer can run the web tier alone and bring in the database only when needed.”

Q795: How do you implement container security?

What it is: Container security reduces privilege and blast radius using dropped capabilities, non-root users, read-only filesystems, resource limits, and network isolation applied at run time.

Why it is used: To prevent a container escape or a noisy neighbor from harming the host and other workloads.

# Docker security
# Run without privileges
docker run --rm -it --cap-drop ALL --user 1000:1000 nginx

# Read-only root filesystem
docker run --rm -it --read-only nginx

# Resource limits
docker run --rm -it --memory=256m --cpus=0.5 nginx

# Network isolation
docker run --rm -it --network none nginx

# SELinux/AppArmor
docker run --rm -it --securitymor:default nginx

#-opt appar Seccomp profile
docker run --rm -it --security-opt seccomp:default nginx

# Rootless Docker
# Install
apt install docker-ce-rootless-extras

# Setup
dockerd-rootless.sh

# Verify
docker info

# Check capabilities
docker run --rm -it --rm nginx capsh --print

Interview talking point: “Running with cap-drop ALL and adding back only what is needed beats running privileged, and docker info plus capsh inside the container verify what was actually granted.”

Q796: How do you design for container registry?

What it is: Container registry design involves deploying a registry, enabling automatic scanning, enforcing retention policies, using IAM for access control, and configuring multi-region replication.

Why it is used: It provides secure, scalable storage for container images.

# Registry
# Deploy

# Scanning
# Automatic

# Retention
# Policy

# Access control
# IAM

# Replication
# Multi-region

Interview talking point: “Automatic scanning with strict retention and IAM controls helps prevent vulnerable images from persisting across regions.”

Kubernetes

Q797: How do you handle state in Kubernetes?

What it is: StatefulSets run replicated pods with stable identity and per-pod storage via volumeClaimTemplates, here requesting 10Gi ReadWriteOnce volumes for three replicas.

Why it is used: To run databases or queues that need persistent, uniquely named storage.

# Use StatefulSets
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: myapp
spec:
  serviceName: myapp
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    spec:
      containers:
      - name: myapp
        image: myapp:latest
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

Interview talking point: “volumeClaimTemplates gives each replica its own claim, so pod-0 and pod-2 keep separate disks across restarts rather than sharing one volume as pods of a Deployment might.”

Q798: How do you handle upgrades?

What it is: A Kubernetes upgrade runs in order: kubeadm upgrade plan and apply for the control plane, then a pinned kubelet package version on the nodes.

Why it is used: To move to a new Kubernetes version while keeping workloads running.

# Kubernetes upgrade
# 1. Upgrade control plane
kubeadm upgrade plan
kubeadm upgrade apply v1.26.0

# 2. Upgrade kubelet
apt-get install kubelet=1.26.0-*

# 3. Upgrade worker nodes
kubectl drain node-1
apt-get install kubelet=1.26.0-*
kubectl uncordon node-1

Interview talking point: “kubectl drain node-1 evicts pods before the kubelet is replaced and uncordon makes the node schedulable again, so traffic shifts off a node during its own upgrade.”

Q799: How do you configure Cilium?

What it is: Cilium is an eBPF-based Kubernetes network plugin installed through the Cilium CLI. Hubble is its observability layer, enabled separately and checked with cilium status.

Why it is used: To deploy the cluster network plugin and gain visibility into pod connectivity and traffic flows.

# Install Cilium CLI
curl -sL https://raw.githubusercontent.com/cilium/cilium-cli/main/install.sh | bash

# Install
cilium install

# Enable Hubble
cilium hubble enable

# Check status
cilium status
cilium hubble ui

Interview talking point: “cilium status confirms cluster health after install, while cilium hubble ui opens a view of service-to-service flows, so health checking and observability are separate steps.”

Q800: How do you configure containerd with TLS?

What it is: containerd’s config sets the CRI sandbox image and points registries at a certs.d directory, where a hosts.toml names the registry server and a host entry with pull capability.

Why it is used: To trust a specific registry endpoint for image pulls on a Kubernetes node.

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.9"

[plugins."io.containerd.grpc.v1.cri".registry]
  config_path = "/etc/containerd/certs.d"

# /etc/containerd/certs.d/docker.io/hosts.toml
server = "https://docker.io"
[host."https://registry-1.docker.io"]
  capabilities = ["pull"]

Interview talking point: “certs.d keeps per-registry host configuration in its own directory, and the capabilities list lets that host entry be restricted to pull only.”

Q801: How do you configure DNS for K8s?

What it is: CoreDNS serves cluster DNS from a Corefile held in a ConfigMap. The example resolves cluster.local names and forwards other queries to /etc/resolv.conf.

Why it is used: To control how pods and services resolve names inside the cluster.

# CoreDNS config
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        forward . /etc/resolv.conf
        prometheus :9153
        cache 30
    }

Interview talking point: “The fallthrough directive lets unmatched reverse-DNS queries pass to the forward plugin, showing that CoreDNS chains plugins in order until one handles the request.”

Q802: How do you configure gVisor?

What it is: gVisor is the runsc runtime, a user-space kernel; installing runsc and setting runtime_handler to runsc in containerd makes crictl run sandboxed containers.

Why it is used: To shrink the kernel attack surface exposed to container workloads without running a full VM.

# Install
apt install runsc

# Configure containerd
# /etc/containerd/config.toml
[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
    runtime_handler = "runsc"

# Run
crictl run --runtime runsc container.json pod.json

Interview talking point: “gVisor intercepts application syscalls in user space while Kata runs a real kernel in a VM, and both are selected the same way through containerd handlers.”

Q803: How do you configure Helm charts?

What it is: Helm packages Kubernetes manifests into reusable charts with parameterized values for different environments.

Why it is used: Manage complex application deployments with versioning and easy rollbacks.

# Install Helm
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Add repo
helm repo add stable https://charts.helm.sh/stable
helm repo update

# Create chart
helm create mychart

# Chart structure
# mychart/
#   Chart.yaml
#   values.yaml
#   templates/
#       deployment.yaml
#       service.yaml

# Install
helm install myrelease mychart
helm install myrelease mychart --set replicaCount=3

# Upgrade
helm upgrade myrelease mychart

# Rollback
helm rollback myrelease 1

# Values override
helm install myrelease mychart -f values-prod.yaml

Interview talking point: “values.yaml overrides defaults at install time; helm rollback reverts to a previous release revision when issues occur.”

Q804: How do you configure Helm charts?

What it is: Helm charts package manifests, with Chart.yaml holding chart metadata and version and values.yaml supplying overridable defaults for replicas, image, service, ingress and resources.

Why it is used: Install and upgrade applications repeatably with environment-specific values instead of edited copies.

apiVersion: v2
name: myapp
description: My application
type: application
version: 1.0.0
appVersion: "1.0"

# values.yaml
replicaCount: 3

image:
  repository: myapp
  pullPolicy: IfNotPresent
  tag: "latest"

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  className: nginx
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
  hosts:
  - host: myapp.example.com
    paths:
    - path: /
      pathType: Prefix

resources:
  limits:
    cpu: 500m
    memory: 128Mi
  requests:
    cpu: 250m
    memory: 64Mi

Interview talking point: “Chart version tracks the packaging while appVersion tracks the shipped application, and values.yaml is the override surface per environment rather than editing the templates themselves.”

Q805: How do you configure Helm workflows?

What it is: Helm charts package Kubernetes manifests with values files, template functions for names and release metadata, dependencies, and hooks that run at install phases.

Why it is used: To deploy parameterized applications consistently and to manage upgrades and releases.

# Create chart
helm create myapp

# Add dependencies
# Chart.yaml
dependencies:
  - name: nginx
    version: "1.0.0"
    repository: "https://charts.bitnami.com/bitnami"

# Install with dependencies
helm dependency build
helm dependency update

# Template functions
# values.yaml
replicaCount: 3

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "myapp.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}

# Common functions
{{ .Values.image.repository }}:{{ .Values.image.tag }}
{{ include "myapp.fullname" . }}
{{ .Release.Name }}
{{ .Release.Namespace }}

# Hooks
hooks:
  - name: backup
    manifest: |
      apiVersion: v1
      kind: Pod
      metadata:
        name: backup
    hook: pre-install
    weight: 10

Interview talking point: “helm dependency build downloads the charts listed in Chart.yaml, and template values like .Release.Name let one chart install into many namespaces unchanged.”

Q806: How do you configure K3s service mesh?

What it is: Linkerd is a service mesh installed from run.linkerd.io; linkerd inject adds sidecars to workloads as manifests are applied, and linkerd viz dashboard opens the UI.

Why it is used: To get mutual TLS, retries and per-route metrics between services without changing code.

# Install Linkerd
curl -sL https://run.linkerd.io/install | sh

# Inject
kubectl get deploy -o yaml | linkerd inject - | kubectl apply -f -

# Check
linkerd viz dashboard

Interview talking point: “The pipeline sends kubectl output through linkerd inject and back to kubectl apply, so existing deployments gain sidecars without hand editing any YAML.”

Q807: How do you configure K3s?

What it is: K3s is a lightweight Kubernetes distribution. The install script can pass —write-kubeconfig-mode 644, the server can run in a privileged Docker container, and agents join with K3S_URL and K3S_TOKEN.

Why it is used: To stand up a small Kubernetes cluster quickly for edge, lab, or single-node use.

# Install
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--write-kubeconfig-mode 644" sh -

# Or with Docker
docker run -d --privileged -p 8080:6443 -v /var/lib/rancher/k3s:/var/lib/rancher/k3s rancher/k3s:latest server

# Agent
curl -sfL https://get.k3s.io | K3S_URL=https://server:6443 K3S_TOKEN=TOKEN sh -

Interview talking point: “—write-kubeconfig-mode 644 makes the kubeconfig readable so kubectl works without root, trading away some file permission protection. A worker joins by pointing K3S_URL at the server API and presenting K3S_TOKEN.”

Q808: How do you configure K3s?

What it is: K3s is a lightweight Kubernetes distribution. The install script starts a server, optionally disabling traefik, agents join with the server URL and node token, and the config becomes the kubeconfig.

Why it is used: To stand up a small Kubernetes cluster on edge or test machines quickly.

# Install server
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--disable traefik" sh -

# Token
cat /var/lib/rancher/k3s/server/node-token

# Install agent
curl -sfL https://get.k3s.io | \
  K3S_URL=https://server:6443 \
  K3S_TOKEN=TOKEN \
  sh -

# kubectl
mkdir -p ~/.kube
cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
chmod 600 ~/.kube/config

Interview talking point: “The generated kubeconfig lives at /etc/rancher/k3s/k3s.yaml and needs chmod 600 after copying, since it holds cluster admin credentials for the API server.”

Q809: How do you configure Kubernetes networking?

What it is: A Service gives pods a stable virtual IP: ClusterIP is internal only, LoadBalancer asks the cloud for an external IP, and Ingress routes by host and path.

Why it is used: Expose applications inside the cluster, from outside it, or behind one hostname with path rules.

apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

---
apiVersion: v1
kind: Service
metadata:
  name: myapp-lb
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

Interview talking point: “Services operate at layer four using selector and targetPort to pick pods, while Ingress works at layer seven with host and path rules and annotation-driven rewrites.”

Q810: How do you configure Kubernetes networking?

What it is: Kubernetes networking relies on a CNI plugin such as Flannel or Calico for pod connectivity, plus NetworkPolicy resources controlling ingress and egress traffic.

Why it is used: To connect pods and to restrict which pods may talk to each other.

# CNI plugins
# Install Flannel
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

# Install Calico
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# Network policies
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
EOF

# Allow specific traffic
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
EOF

# Service mesh (Istio)
istioctl install --set profile=demo
kubectl label namespace default istio-injection=enabled

Interview talking point: “A NetworkPolicy with an empty podSelector and both policy types becomes a default deny, so later allow policies open specific paths back up.”

Q811: How do you configure Kubernetes networking?

What it is: Kubernetes networking combines a Service mapping a virtual port to pod targetPorts, an Ingress routing by hostname to a service, and a default-deny NetworkPolicy.

Why it is used: To expose pods inside the cluster, publish them externally and restrict pod-to-pod traffic.

# Service
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

---
# Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

---
# NetworkPolicy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Interview talking point: “the Service translates port 80 to targetPort 8080 on the pods, the Ingress sends myapp.example.com traffic to that service, and an empty podSelector NetworkPolicy blocks everything until exceptions are added.”

Q812: How do you configure Kubernetes node?

What it is: A Kubernetes node is prepared with kubeadm, kubectl and kubelet installed from the package repository. kubeadm init starts the control plane with a pod network CIDR, kubeadm join adds a worker, and kubectl applies the flannel network.

Why it is used: To stand up a cluster or add capacity by joining new worker machines.

# Install kubeadm
apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" > /etc/apt/sources.list.d/kubernetes.list
apt-get update && apt-get install -y kubelet kubeadm kubectl

# Initialize master
kubeadm init --pod-network-cidr=10.244.0.0/16

# Join node
kubeadm join 192.168.1.10:6443 --token token --discovery-token-ca-cert-hash sha256:hash

# Install pod network
kubectl apply -f https://raw.githubusercontent.com/flannel/flannel/master/Documentation/kube-flannel.yml

Interview talking point: “kubeadm init prints the exact join command with a token and CA cert hash, and the pod network CIDR given at init time must match what the CNI plugin expects.”

Q813: How do you configure Kubernetes on Linux?

What it is: Bootstrap sequence for a cluster: add the Kubernetes apt repository, install kubelet, kubeadm, and kubectl, run kubeadm init with a pod network CIDR, join nodes with a token, add a network plugin, then deploy and expose nginx.

Why it is used: To stand up a Kubernetes cluster on Linux hosts.

# Install kubeadm
apt-get update && apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list
apt-get update
apt-get install -y kubelet kubeadm kubectl

# Initialize cluster
kubeadm init --pod-network-cidr=10.244.0.0/16

# Join nodes
kubeadm join <master-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

# Install network plugin
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

# Deploy application
kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=LoadBalancer

Interview talking point: “kubeadm init with pod-network-cidr must match the range the CNI plugin expects, and pods stay NotReady until that network plugin is applied.”

Q814: How do you configure Kubernetes services?

What it is: A Kubernetes Service gives pods a stable network entry point. The record shows ClusterIP for internal access, NodePort exposing port 30080 on every node, and LoadBalancer, each selecting pods by label and mapping port to targetPort.

Why it is used: To reach pods despite restarts and IP changes, and to expose an app inside or outside the cluster.

apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80

# NodePort
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080

# LoadBalancer
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80

# Apply
kubectl apply -f service.yaml

Interview talking point: “The selector matches pod labels, which is what ties the service to the deployment, and the type decides exposure: ClusterIP stays internal, NodePort opens a fixed high port on each node, LoadBalancer asks for an external balancer.”

Q815: How do you configure Kubernetes storage?

What it is: PersistentVolumes are cluster storage resources, PersistentVolumeClaims request a slice of one, and StorageClasses define dynamic provisioning parameters for new volumes.

Why it is used: To give pods durable storage that outlives container restarts and rescheduling.

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: standard
  hostPath:
    path: /mnt/data

---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

---
# StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  replication-type: regional-pd

---
# Use in Pod
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
    - name: my-storage
      mountPath: /data
  volumes:
  - name: my-storage
    persistentVolumeClaim:
      claimName: my-pvc

Interview talking point: “A claim of 5Gi can bind to a 10Gi volume, and access mode ReadWriteOnce means that volume mounts on only one node at a time.”

Q816: How do you configure Kubernetes?

What it is: Kubernetes configuration installs kubectl, points ~/.kube/config at the cluster admin credentials, and creates, scales, exposes and inspects workloads.

Why it is used: To deploy and operate applications on a cluster from the command line.

# Install kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

# Configure
mkdir -p ~/.kube
cp /path/to/admin.conf ~/.kube/config

# Create deployment
kubectl create deployment nginx --image=nginx

# Scale deployment
kubectl scale deployment nginx --replicas=3

# Expose service
kubectl expose deployment nginx --port=80 --type=LoadBalancer

# View resources
kubectl get pods,svc,deployments
kubectl describe pod nginx
kubectl logs nginx

# Apply configuration
kubectl apply -f deployment.yaml
kubectl delete -f deployment.yaml

Interview talking point: “kubectl expose builds a Service in front of a deployment, while kubectl apply -f takes manifest files, which is how cluster state gets reviewed in version control instead of typed by hand.”

Q817: How do you configure limit ranges?

What it is: A LimitRange sets per-container bounds: maximum and minimum CPU and memory, plus default and defaultRequest values applied when a pod omits them.

Why it is used: To block oversized or unbounded pods and fill in missing resource specs.

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "4"
      memory: 8Gi
    min:
      cpu: 100m
      memory: 128Mi
    default:
      cpu: 500m
      memory: 1Gi
    defaultRequest:
      cpu: 200m
      memory: 512Mi
    type: Container

Interview talking point: “LimitRange applies per container while ResourceQuota applies per namespace, and the default entries automatically supply requests so quota checks never fail on missing values.”

Q818: How do you configure local PV?

What it is: A local PersistentVolume points at a path on one node with Retain reclaim policy, and nodeAffinity pins it to a named hostname.

Why it is used: To expose fast local disks such as SSDs to a specific pod placement.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node-1

Interview talking point: “nodeAffinity is required because a local volume only exists on that node, so scheduling must match or the pod would attach to missing storage.”

Q819: How do you configure OPA policies?

What it is: OPA Gatekeeper enforces policies on Kubernetes resources using CRD-based constraints.

Why it is used: It ensures workloads meet compliance rules before being admitted to the cluster.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-app-labels
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]
  parameters:
    labels:
    - key: app

Interview talking point: “Unlike raw OPA, Gatekeeper uses ConstraintTemplates and constraints to validate resources declaratively.”

Q820: How do you configure persistent storage?

What it is: A PersistentVolumeClaim requests a size and access mode, the pod mounts it at a path, and a StorageClass names the provisioner and disk type that fulfills it.

Why it is used: Decouple pods from storage details so data survives container restarts and reschedules.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

---
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: myapp
    image: nginx
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: mypvc

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  replication-type: regional-pd

Interview talking point: “ReadWriteOnce means a single node may attach the volume, and a StorageClass such as gce-pd with pd-ssd dynamically creates the backing disk when the claim is satisfied.”

Q821: How do you configure pod resources?

What it is: A pod spec sets per-container resource requests and limits plus liveness and readiness HTTP probes with initial delays and check intervals.

Why it is used: Requests size pods for scheduling, limits cap usage, and probes drive restarts and traffic routing.

apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: myapp
    image: myapp:latest
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

Interview talking point: “Requests drive scheduling and the utilization targets an HPA aims at, while limits cap usage; exceeding the CPU limit throttles a container, exceeding the memory limit kills it.”

Q822: How do you configure RBAC?

What it is: RBAC grants permissions through Role rules listing apiGroups, resources and verbs, attached to subjects by a RoleBinding, while a ClusterRole holds cluster-wide rules.

Why it is used: Give users and services least-privilege access without handing out admin credentials.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list", "watch"]

Interview talking point: “A Role with a RoleBinding is scoped to one namespace, whereas a ClusterRole needs a binding of its own to apply cluster-wide; get, list, watch on pods and pods/log is strictly read-only.”

Q823: How do you configure resource constraints?

What it is: Cluster constraints control where and when resources run: colocation ties them together, order sequences them, location expresses preference, plus stickiness and utilization values.

Why it is used: To shape failover behavior so services land on the right nodes in the right sequence.

# Colocation constraint
pcs constraint colocation add WebService VirtualIP INFINITY

# Order constraint
pcs constraint order VirtualIP then WebService

# Location constraint (preference)
pcs constraint location WebService prefers node1=50

# Location constraint (avoid)
pcs constraint location WebService avoids node2

# Resource stickiness
pcs resource meta WebService resource-stickiness=100

# Migration threshold
pcs resource meta WebService migration-threshold=3

# Priority
pcs resource priority WebService=10

# Utilization
pcs node utilization node1 cpu=4 memory=16
pcs resource utilization WebService cpu=2 memory=4

Interview talking point: “resource-stickiness makes a healthy resource prefer to stay put, while migration-threshold sets how many failed starts trigger a move to another node.”

Q824: How do you configure service mesh?

What it is: Istio service mesh injects sidecars into pods to provide traffic management, security, and observability.

Why it is used: Enable advanced routing patterns like canaries and weighted traffic splits transparently.

# Install Istio
curl -L https://istio.io/downloadIstio | sh -
istioctl install --set profile=demo

# Enable injection
kubectl label namespace default istio-injection=enabled

# Deploy application
kubectl apply -f app.yaml

# Configure traffic
# VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 80
    - destination:
        host: myapp
        subset: v2
      weight: 20

# Monitor
istioctl dashboard kiali
istioctl dashboard prometheus

Interview talking point: “VirtualService objects define routing rules; namespace injection automatically adds sidecars to eligible workloads.”

Q825: How do you create Kubernetes configmap and secrets?

What it is: A ConfigMap holds non-sensitive configuration as key-value data and a Secret holds credentials, written here in stringData. Both are mounted into pods or injected as environment variables.

Why it is used: To keep configuration and credentials out of container images and manifests.

# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  database_url: "postgres://db:5432/myapp"
  cache_enabled: "true"

---
# Secret
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  username: admin
  password: secret123

Interview talking point: “Secret data is only base64 encoded rather than encrypted by default, so anyone who can read the object can decode it, and stringData is just a convenience field you write plaintext into.”

Q826: How do you create Kubernetes deployment?

What it is: A Deployment runs a set number of replica pods from a template, with a selector matching its labels. Requests reserve 250m CPU and 64Mi while limits cap at 500m and 128Mi.

Why it is used: To run replicated, self-healing application pods with defined resource boundaries.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"

Interview talking point: “Requests drive scheduling while limits cap usage, so exceeding the CPU limit throttles the container but exceeding the memory limit terminates it, which is a distinction worth stating clearly.”

Q827: How do you create Kubernetes deployments?

What it is: A Kubernetes Deployment declares how many pod replicas to run and the pod template describing the container image, ports and resource requests and limits. kubectl apply -f deployment.yaml creates it.

Why it is used: To run application pods with a desired replica count that the cluster keeps in place.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: nginx:latest
        ports:
        - containerPort: 80
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
          requests:
            memory: "64Mi"
            cpu: "250m"

# Apply
kubectl apply -f deployment.yaml

Interview talking point: “resources.requests size the pod for scheduling while limits cap what it may consume, so requests of 250m CPU and 64Mi with limits of 500m and 128Mi define both placement and the ceiling.”

Q828: How do you create Kubernetes ingress?

What it is: An Ingress routes HTTP by hostname and path to a named service, with annotations controlling rewrites and a tls section pointing at a secret for certificates.

Why it is used: To expose several services through one hostname with TLS instead of one load balancer each.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-svc
            port:
              number: 80
  tls:
  - hosts:
    - myapp.example.com
    secretName: tls-secret

Interview talking point: “The rewrite-target annotation changes what path reaches the backend, and pathType Prefix matches the path plus everything under it, while TLS terminates at the ingress using the referenced secret.”

Q829: How do you create Kubernetes job and cronjob?

What it is: A Job runs a pod to completion with a restart policy such as OnFailure, while a CronJob launches Jobs on a schedule expression like 0 * * * *.

Why it is used: To run batch tasks and recurring maintenance inside Kubernetes instead of on cron hosts.

# Job
apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
      - name: job
        image: busybox
        command: ["echo", "Hello from job"]
      restartPolicy: OnFailure

---
# CronJob
apiVersion: batch/v1
kind: CronJob
metadata:
  name: mycronjob
spec:
  schedule: "0 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cron
            image: busybox
            command: ["echo", "Hello from cron"]
          restartPolicy: OnFailure

Interview talking point: “The CronJob schedule field is a standard five-field cron expression, and it spawns a Job each time, so completion history and failures come from the Jobs it creates.”

Q830: How do you create Kubernetes persistent volume?

What it is: A PersistentVolumeClaim requests storage with an access mode, size, and storage class, and a pod references it through a volumeMount. ReadWriteOnce allows access from one node.

Why it is used: To give containers durable storage that survives restarts and rescheduling.

# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: gp3

---
# Pod using PVC
spec:
  containers:
  - name: app
    image: nginx
    volumeMounts:
    - name: data
      mountPath: /data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: mypvc

Interview talking point: “The PVC is the request while the backing volume is the supply, and ReadWriteOnce means the volume attaches to a single node, which constrains where the pod can be scheduled.”

Q831: How do you create Kubernetes service?

What it is: A Service gives pods a stable virtual IP and selects them by label. ClusterIP is internal only, NodePort exposes a port on every node, and LoadBalancer requests an external balancer.

Why it is used: To reach a changing set of pods reliably without tracking their individual IPs.

# ClusterIP
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80

# NodePort
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080

# LoadBalancer
spec:
  type: LoadBalancer
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80

Interview talking point: “NodePort opens a fixed port such as 30080 on each node while ClusterIP never leaves the cluster, and all three types pick endpoints through the same label selector.”

Q832: How do you create Kubernetes statefulset?

What it is: A StatefulSet runs replicated pods with stable identity and ordering, using a headless serviceName and volumeClaimTemplates that give each replica its own persistent volume.

Why it is used: To run databases or other stateful workloads that need stable names and per-pod storage.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

Interview talking point: “volumeClaimTemplates create a separate claim per replica rather than one shared PVC, and pods get ordered startup plus stable names, which is why databases use StatefulSet instead of Deployment.”

Q833: How do you implement backup for K8s?

What it is: Velero backs up Kubernetes resources and volumes, restores from a backup, and schedules recurring runs with a cron expression such as daily at midnight.

Why it is used: To protect cluster workloads against accidental deletion and cluster loss.

# Use Velero
# Install
kubectl apply -f https://raw.githubusercontent.com/vmware-tanzu/velero/main/install/v1.10.0/velero.yaml

# Backup
velero backup create mybackup --include-namespaces default

# Restore
velero restore create --from-backup mybackup

# Schedule
velero schedule create daily --schedule="0 0 * * *" --include-namespaces default

Interview talking point: “velero schedule create daily takes a cron string, so backup frequency is set the same way as any scheduled job, and restore mirrors it with restore create from a backup.”

Q834: How do you implement ingress controller?

What it is: An ingress controller exposes HTTP routes from outside the cluster. NGINX Ingress is installed by applying its deployment manifest, then an Ingress object maps host and path to a service.

Why it is used: To route external traffic to internal services by hostname and path instead of one load balancer per service.

# Install NGINX Ingress
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.5.1/deploy/static/provider/cloud/deploy.yaml

# Create Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp
            port:
              number: 80

Interview talking point: “The rewrite-target annotation changes the path sent to the backend, and pathType Prefix means every path beginning with the given prefix matches the rule.”

Q835: How do you implement Kubernetes networking?

What it is: Kubernetes networking uses a CNI plugin such as Calico or Flannel, network policies for segmentation, service types for exposure, an ingress controller, and CoreDNS for DNS.

Why it is used: To connect pods and expose services inside the cluster.

# Kubernetes networking
# 1. CNI plugin
# Calico/Flannel

# 2. Network policies
# Segmentation

# 3. Services
# Types

# 4. Ingress
# Controller

# 5. DNS
# CoreDNS

Interview talking point: “Network policies only take effect if the CNI plugin enforces them, so choosing a plugin without policy support limits the segmentation security you can actually apply.”

Q836: How do you implement Kubernetes networking?

What it is: Kubernetes networking implementation deploys CNI plugins (Calico/Flannel), applies network policies for segmentation, configures service types, ingress controllers, and CoreDNS.

Why it is used: To provide secure, routable connectivity for pods and services.

# CNI plugin
# Calico/Flannel

# Network policies
# Segmentation

# Services
# Types

# Ingress
# Controller

# DNS
# CoreDNS

Interview talking point: “Network policies enable segmentation, while CNI choice, ingress, and CoreDNS control traffic flow and service discovery.”

Q837: How do you implement multi-cluster?

What it is: Multi-cluster operation uses federation or a single ArgoCD managing several clusters, adding each with argocd cluster add and targeting them from an Application.

Why it is used: To deploy one application consistently across multiple clusters.

# Use Federation
# Or use ArgoCD with multiple clusters

# Add cluster to ArgoCD
argocd cluster add context-name

# Deploy to all clusters
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  destination:
    server: https://kubernetes.default.svc
  # Or use ClusterResourceQuota

Interview talking point: “argocd cluster add registers an external cluster, so one GitOps controller becomes the deployment plane for many clusters instead of needing one controller per cluster.”

Q838: How do you implement network policies in Kubernetes?

What it is: A NetworkPolicy with an empty podSelector and both policyTypes selects every pod and denies ingress and egress by default.

Why it is used: To make deny-all the starting point, then allow only explicitly needed pod traffic.

# Default deny
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Interview talking point: “Once a pod is selected by a policy, only rules in matching policies allow traffic, so an empty selector with no allow rules means deny all.”

Q839: How do you implement network policies?

What it is: Kubernetes NetworkPolicies control ingress and egress traffic between pods and namespaces.

Why it is used: They enforce segmentation and limit communication to only authorized sources.

# Allow from specific namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: production

Interview talking point: “Using namespace selectors with labels allows selective access, enabling secure multi-tenant communication without opening broad network access.”

Q840: How do you implement priority classes?

What it is: A PriorityClass assigns a numeric priority to pods, optionally as a global default, and pods reference it by name through priorityClassName.

Why it is used: To ensure critical workloads are scheduled and evicted last under pressure.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "Critical workloads"

# Use in pod
priorityClassName: high-priority

Interview talking point: “Higher values win during scheduling contention, and preemption lets a high-priority pod evict lower-priority ones, so priority decides who runs when the cluster is full.”

Q841: How do you implement RBAC?

What it is: RBAC implementation defines roles, maps permissions onto them, assigns roles to users, audits regularly, and integrates with tools such as LDAP.

Why it is used: To grant access by role instead of maintaining per-user grants that sprawl out of control.

# RBAC implementation
# 1. Roles
# Define

# 2. Permissions
# Map

# 3. Assignment
# Users

# 4. Audit
# Regular review

# 5. Tools
# LDAP integration

Interview talking point: “Permissions attach to roles and users only receive roles, so revoking access means changing one role definition rather than chasing every individual account.”

Q842: How do you implement RBAC?

What it is: RBAC defines roles, maps permissions to those roles, and assigns them to users or groups.

Why it is used: It enforces least privilege by centralizing access decisions in a structured way.

# Roles
# Define

# Permissions
# Map

# Assignment
# Users

# Audit
# Regular review

# Tools
# LDAP integration

Interview talking point: “Regular audits of role assignments help prevent permission creep as teams and responsibilities change.”

Q843: How do you implement secrets management in K8s?

What it is: external-secrets syncs values from a store such as Vault into Kubernetes Secrets; a ClusterSecretStore names the backend and an ExternalSecret maps keys on an interval.

Why it is used: To keep real secret material out of manifests while still exposing it to pods.

# Use external-secrets
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
  name: vault-backend
spec:
  provider:
    vault:
      server: "https://vault:8200"
      path: "secret"
      version: "v2"

---
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: mysecret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: mysecret
  data:
  - secretKey: api_key
    remoteRef:
      key: myapp/api_key

Interview talking point: “refreshInterval 1h means Vault changes appear in the cluster automatically, so rotation happens upstream without editing or reapplying Kubernetes objects.”

Q844: How do you implement service catalog?

What it is: Backstage is a service catalog installed with Helm; catalog-info.yaml declares a Component with type, lifecycle, owner and APIs, registered by URL and applied with kubectl.

Why it is used: Maintain one inventory of services, owners and dependencies across every team.

# Backstage installation
helm repo add backstage https://backstage.github.io/helm-charts
helm install backstage backstage/backstage

# Create catalog
# catalog-info.yaml
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: my-service
  annotations:
    github.com/project-slug: org/repo
spec:
  type: service
  lifecycle: production
  owner: team-a
  providesApis:
    - my-service-api

# Register in Backstage
# app-config.yaml
catalog:
  locations:
    - type: url
      target: https://github.com/org/repo/blob/main/catalog-info.yaml

# Add to service catalog
kubectl apply -f catalog-info.yaml

Interview talking point: “The owner field plus the GitHub project-slug annotation is what makes a service findable with someone accountable, turning a repo list into a genuine ownership map.”

Q845: How do you implement service catalog?

What it is: A service catalog provides a self-service portal, standardized templates, approval-based governance, and auto-generated documentation.

Why it is used: To let teams consume approved services quickly without filing ad hoc requests.

# Service catalog
# 1. Self-service
# Portal

# 2. Standardization
# Templates

# 3. Governance
# Approval

# 4. Documentation
# Auto-generated

Interview talking point: “Templates provide standardization while approvals provide governance, so self-service does not mean uncontrolled access to infrastructure.”

Q846: How do you implement service catalog?

What it is: A service catalog is a self-service portal of standardized service templates with governance through approvals and auto-generated documentation.

Why it is used: To enable consistent provisioning while maintaining control and compliance.

# Self-service
# Portal

# Standardization
# Templates

# Governance
# Approval

# Documentation
# Auto-generated

Interview talking point: “Standard templates reduce variation and approvals enforce guardrails, so self-service remains predictable without sacrificing governance.”

Q847: How do you implement service discovery?

What it is: Consul registers services with periodic health checks and answers lookups over DNS on port 8600 or the HTTP catalog API on port 8500.

Why it is used: So clients find service instances by name instead of hardcoding addresses that change on every deploy.

# Consul
# Install
apt install consul

# Configuration
# /etc/consul/config.json
{
  "datacenter": "dc1",
  "data_dir": "/var/consul",
  "ui_config": {
    "enabled": true
  },
  "retry_join": ["provider=aws tag_key=consul tag_value=server"],
  "server": true,
  "bootstrap_expect": 3
}

# Register service
# /etc/consul/service.json
{
  "service": {
    "name": "web",
    "port": 80,
    "check": {
      "http": "http://localhost:80/health",
      "interval": "10s"
    }
  }
}

# DNS interface
# Query service
dig @127.0.0.1 -p 8600 web.service.consul

# HTTP API
curl http://127.0.0.1:8500/v1/catalog/service/web

# Register in code
import consul
c = consul.Consul()

# Register service
c.agent.service.register(
    'web',
    service_id='web-1',
    port=80,
    check=consul.Check.http('http://localhost:80/health', '10s')
)

Interview talking point: “Two lookup paths exist: dig at 127.0.0.1 port 8600 for name.service.consul, or curl the HTTP catalog. Because the check runs every 10s, unhealthy instances drop out of results automatically.”

Q848: How do you implement service discovery?

What it is: Service discovery registers services with DNS-backed tools like Consul, runs health checks at registration, performs client-side load balancing, and fails over automatically.

Why it is used: To let services find each other as instances come and go with changing addresses.

# Service discovery
# 1. DNS
# Consul

# 2. Health checks
# Registration

# 3. Load balancing
# Client-side

# 4. Failover
# Automatic

Interview talking point: “Client-side load balancing means the caller picks a healthy instance from discovery, which removes an extra hop through a central proxy.”

Q849: How do you implement service discovery?

What it is: Service discovery allows services to locate each other dynamically without hardcoded addresses.

Why it is used: It supports scaling, failover, and dynamic environments like containers or cloud.

# DNS
# Consul

# Health checks
# Registration

# Load balancing
# Client-side

# Failover
# Automatic

Interview talking point: “DNS-based discovery with health checks enables automatic registration and failover when instances become unhealthy.”

Q850: How do you implement service mesh?

What it is: A service mesh like Istio is installed with istioctl, and labeling a namespace enables sidecar injection so proxies are added to new pods automatically.

Why it is used: To get traffic management, telemetry, and security between services without changing application code.

# Install Istio
istioctl install --set profile=demo

# Enable sidecar injection
kubectl label namespace default istio-injection=enabled

# Deploy
kubectl apply -f deployment.yaml

# View traffic
istioctl dashboard kiali

Interview talking point: “The istio-injection label decides which namespaces receive the sidecar, so only labeled namespaces get proxied, and istioctl dashboard kiali then opens the traffic visualization.”

Q851: How do you implement service mesh?

What it is: An Istio VirtualService splits traffic 80/20 across subsets, routes by a header match, and sets retries and timeouts, while a DestinationRule defines pool limits.

Why it is used: To control routing, retries, and connection limits between services without changing application code.

# Istio VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 80
    - destination:
        host: myapp
        subset: v2
      weight: 20
  - match:
    - headers:
        x-api-version:
          exact: v2
    route:
    - destination:
        host: myapp
        subset: v2
  retries:
    attempts: 3
    perTryTimeout: 2s
  timeout: 10s
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: UPGRADE
        http1MaxPendingRequests: 100
        http2MaxRequests: 1000
    loadBalancer:
      simple: ROUND_ROBIN

Interview talking point: “perTryTimeout applies to each retry attempt while timeout caps the whole call, so three retries at 2s each still finish inside the 10 second overall budget.”

Q852: How do you implement service mesh?

What it is: Istio adds a sidecar control plane: PeerAuthentication enforces mutual TLS, VirtualService splits traffic by weight between versions, and telemetry feeds dashboards such as Kiali.

Why it is used: To get encryption, traffic routing, and visibility between services without changing application code.

# Istio installation
istioctl install --set profile=demo

# Deploy application
kubectl apply -f myapp.yaml

# Enable mutual TLS
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
EOF

# Traffic management
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

# Observability
# Enable tracing
istioctl install --set values.telemetry.enabled=true

# View dashboards
istioctl dashboard kiali

Interview talking point: “The VirtualService weights show gradual rollout in the mesh, sending 90 percent to v1 and 10 to v2. PeerAuthentication in STRICT mode refuses plaintext, so every caller must present a certificate.”

Q853: How do you implement service mesh?

What it is: A service mesh adds traffic routing, mutual TLS, tracing, and retry resilience between services, implemented by Istio, Linkerd, or Consul Connect.

Why it is used: To gain cross-cutting networking behavior without changing application code.

# Service mesh
# 1. Traffic management
# Routing

# 2. Security
# mTLS

# 3. Observability
# Tracing

# 4. Resilience
# Retries

# Tools
# Istio
# Linkerd
# Consul Connect

Interview talking point: “mTLS in the mesh encrypts and authenticates service-to-service traffic automatically, which would otherwise have to be implemented inside every team’s application.”

Q854: How do you implement service mesh?

What it is: Istio installs a service mesh, injects sidecars by labeling a namespace, and adds PeerAuthentication for mTLS plus VirtualService for routing.

Why it is used: To get encryption, traffic control, and observability between services without code changes.

# Install Istio
curl -L https://istio.io/downloadIstio | sh -
istioctl install --set profile=demo

# Enable injection
kubectl label namespace default istio-injection=enabled

# Deploy application
kubectl apply -f app.yaml

# Configure mTLS
kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
EOF

# Configure traffic
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

Interview talking point: “Labeling the namespace enables sidecar injection, PeerAuthentication STRICT forces mTLS, and a VirtualService with weights 90 and 10 splits traffic for a canary release.”

Q855: How do you implement service mesh?

What it is: A service mesh provides traffic control, security, and observability for service-to-service communication.

Why it is used: It offloads cross-cutting concerns from application code in distributed systems.

# Traffic management
# Routing

# Security
# mTLS

# Observability
# Tracing

# Resilience
# Retries

# Tools
# Istio
# Linkerd
# Consul Connect

Interview talking point: “mTLS in a service mesh encrypts traffic between services automatically, improving security without code changes.”

Q856: How do you implement zero trust in K8s?

What it is: Zero trust in Kubernetes involves enforcing mTLS everywhere with a service mesh, using short-lived and regularly rotated certificates, implementing microsegmentation, and verifying every request.

Why it is used: Zero trust assumes no implicit trust between workloads, reducing lateral movement in case of compromise.

# mTLS everywhere
# Service mesh

# Short-lived certificates
# Regular rotation

# Network policies
# Microsegmentation

# Verify every request
# Use identity-based access
# Continuous verification

Interview talking point: “Combining identity-based access with continuous verification and network microsegmentation ensures that every connection is authenticated and authorized.”

Q857: How do you manage Kubernetes configmaps and secrets?

What it is: ConfigMaps hold non-sensitive configuration and Secrets hold credentials, both created from literals or files with kubectl create. The example injects keys into a pod as environment variables through configMapKeyRef and secretKeyRef.

Why it is used: To keep settings and credentials out of container images and out of the pod spec.

# Create configmap
kubectl create configmap app-config \
  --from-literal=ENV=production \
  --from-file=app.properties=app.properties

# Create secret
kubectl create secret generic db-credentials \
  --from-literal=username=admin \
  --from-literal=password=secret

# From file
kubectl create secret generic tls-cert \
  --from-file=tls.crt=tls.crt \
  --from-file=tls.key=tls.key

# Use in pod
env:
  - name: ENV
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: ENV
  - name: PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

Interview talking point: “Both are created with kubectl create from literals or files, and both are wired into the pod through env valueFrom, so the practical difference is that one carries configuration and the other carries credentials.”

Q858: How do you manage Kubernetes ingress?

What it is: A Kubernetes Ingress routes HTTP traffic by hostname and path to a service. The record defines a rule for myapp.example.com with path / as Prefix, pointing at myapp-svc on port 80, plus a rewrite-target annotation.

Why it is used: To publish several services through one entry point and one address instead of a load balancer per service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-svc
            port:
              number: 80

# Apply
kubectl apply -f ingress.yaml

Interview talking point: “Ingress sits above Services, and behavior like URL rewriting comes from controller annotations such as nginx.ingress.kubernetes.io/rewrite-target, so the YAML alone does not fully describe what the proxy will do.”

Q859: How do you use Argo Events?

What it is: Argo Events listens with an EventSource, here a webhook on port 12000 accepting POST, and a Sensor reacts to that event by firing a trigger.

Why it is used: To start actions from external events such as an incoming HTTP POST.

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: webhook
spec:
  webhook:
    example:
      port: "12000"
      endpoint: /example
      method: POST

---
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: webhook-sensor
spec:
  dependencies:
  - name: webhook-dep
    eventSourceName: webhook
    eventName: example
  triggers:
  - template:
      name: log-trigger
      log:
        message: "{{ .webhook-dep.body }}"

Interview talking point: “EventSource and Sensor are separate objects: the source exposes endpoint /example, and the sensor depends on eventSourceName webhook plus event name example, then renders the request body into the trigger message.”

Q860: How do you use Argo Rollouts?

What it is: A Rollout replaces a plain Deployment for progressive delivery: a canary strategy shifts weight to 10, 20, then 100 percent, pausing ten minutes between steps.

Why it is used: To release changes gradually and observe them before giving the new version all traffic.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: myapp
spec:
  replicas: 10
  strategy:
    canary:
      canaryService: myapp-canary
      stableService: myapp-stable
      trafficRouting:
        nginx:
          stableIngress: myapp-ingress
      steps:
      - setWeight: 10
      - pause: {duration: 10m}
      - setWeight: 20
      - pause: {duration: 10m}
      - setWeight: 100
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:latest

Interview talking point: “The steps show the canary schedule: setWeight 10 with a 10 minute pause, then 20, then 100, and trafficRouting with nginx stableIngress splits live traffic between canaryService and stableService during the ramp.”

Q861: How do you use Argo Workflows?

What it is: An Argo Workflow declares an entrypoint template with a DAG of tasks; here test depends on build, and each task runs its own container command.

Why it is used: To run build and test steps as Kubernetes pods in a defined dependency order.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: myworkflow-
spec:
  entrypoint: main
  templates:
  - name: main
    dag:
      tasks:
      - name: build
        template: build
      - name: test
        template: test
        dependencies: [build]
  - name: build
    container:
      image: golang:latest
      command: [make, build]
  - name: test
    container:
      image: golang:latest
      command: [make, test]

Interview talking point: “The dependencies entry listing build on the test task is what orders the DAG, and because each task declares its own image, build and test can use different toolchains instead of sharing one job pod.”

Q862: How do you use Buildpacks?

What it is: Buildpacks detect an application’s needs and assemble its image. The pack CLI checks its version, builds against a builder, detects the project type, and rebases onto a new run image.

Why it is used: To get production-ready images from source without writing a Dockerfile.

# Install pack
pack --version

# Build
pack build myapp --builder paketobuildpacks/builder:base

# Detect
pack detect myapp

# Rebase
pack rebase myapp --run-image gcr.io/paketo-buildpacks/run:base-cnb

Interview talking point: “pack rebase swaps only the run image under the existing app layers, so base image updates ship without a full rebuild.”

Q863: How do you use cadvisor?

What it is: cadvisor runs with the root filesystem, /var/run, /sys, and the Docker data directory mounted read-only, and serves container usage data on port 8080.

Why it is used: To watch container CPU, memory, and network usage from a browser.

# Install
docker run -d \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --publish=8080:8080 \
  gcr.io/cadvisor/cadvisor

# Access
# http://localhost:8080

Interview talking point: “cadvisor needs those mounts to see host and container state, and the ro flag on each volume guarantees the monitor never writes to the host filesystem it observes.”

Q864: How do you use Calico?

What it is: Calico is a Kubernetes network plugin applied from its manifest; calicoctl lists BGP peers, and a BGPPeer resource declares peerIP and asNumber for peering.

Why it is used: To enforce network policy and advertise pod routes to data center routers using BGP.

# Install
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# BGP peering
calicoctl get bgppeer

# Apply BGPPeer
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
  name: my-peer
spec:
  peerIP: 192.168.1.1
  asNumber: 64512

Interview talking point: “Calico goes beyond a simple overlay by speaking BGP: the BGPPeer resource with peerIP and asNumber lets cluster pod CIDRs be advertised directly to your routers, which avoids encapsulation overhead on east-west traffic.”

Q865: How do you use CDK8s?

What it is: A CDK8s TypeScript chart constructing a KubeDeployment with three replicas and an nginx container, synthesized to YAML files by app.synth.

Why it is used: Generates Kubernetes manifests from typed, reusable code.

import { Construct } from 'constructs';
import { App, Chart, YamlOutputType } from 'cdk8s';

export class MyChart extends Chart {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    new KubeDeployment(this, 'deployment', {
      spec: {
        replicas: 3,
        selector: {
          matchLabels: { app: 'myapp' }
        },
        template: {
          metadata: { labels: { app: 'myapp' } },
          spec: {
            containers: [{
              name: 'myapp',
              image: 'nginx:latest',
              ports: [{ containerPort: 80 }]
            }]
          }
        }
      }
    });
  }
}

const app = new App({ outputType: YamlOutputType.FILE });
new MyChart(app, 'mychart');
app.synth();

Interview talking point: “app.synth writes ordinary YAML to disk, so the code is a build-time generator and the cluster only ever consumes standard manifests, not the TypeScript itself.”

Q866: How do you use crictl with Kata Containers?

What it is: Kata Containers run each pod inside a lightweight VM; containerd is pointed at runtime handler io.containerd.kata.v2 and crictl run launches containers with it.

Why it is used: To give untrusted workloads hardware virtualization isolation while keeping the usual CRI workflow.

# Install Kata Containers
kata-runtime --version

# Configure containerd
# /etc/containerd/config.toml
[plugins]
  [plugins."io.containerd.grpc.v1.cri"]
    runtime_handler = "io.containerd.kata.v2"

# Use runtime
crictl run --runtime io.containerd.kata.v2 container.json pod.json

Interview talking point: “Passing the runtime flag to crictl selects the VM-backed runtime per request, so isolation becomes a runtime choice rather than a change to the container image.”

Q867: How do you use crictl with TLS?

What it is: crictl is the CLI for a Kubernetes container runtime. /etc/crictl.yaml sets the runtime and image endpoints to the containerd socket and lists CA, certificate, and key files for TLS.

Why it is used: To inspect pods and images directly on a node when kubectl cannot show runtime detail.

runtime-endpoint: unix:///var/run/containerd/containerd.sock
image-endpoint: unix:///var/run/containerd/containerd.sock
tls:
  ca_file: /path/to/ca.crt
  cert_file: /path/to/cert.crt
  key_file: /path/to/key.crt

Interview talking point: “Setting runtime-endpoint and image-endpoint to the same socket means one config drives both pods and images, and the tls block only matters when that endpoint is remote.”

Q868: How do you use crictl?

What it is: crictl is a CLI for CRI runtimes, configured in /etc/crictl.yaml with a runtime endpoint. It pulls images, runs containers from JSON specs, and lists pods, containers, and logs.

Why it is used: To inspect and debug pods directly on a Kubernetes node below kubectl.

# Configure
cat > /etc/crictl.yaml <<EOF
runtime-endpoint: unix:///var/run/dockershim.sock
image-endpoint: unix:///var/run/dockershim.sock
EOF

# Pull
crictl pull nginx:latest

# Run
crictl run -r docker pod.json container.json

# List
crictl pods
crictl ps

# Logs
crictl logs container-id

Interview talking point: “crictl talks to the container runtime socket while kubectl talks to the API server, so when pods never get created, crictl ps and crictl logs reveal node-level state.”

Q869: How do you use CRIU?

What it is: CRIU checkpoints a running process with criu dump, brings it back with criu restore, and criu predump captures memory ahead of the final dump.

Why it is used: To freeze and resume processes for live migration, fast restart, or container checkpointing.

# Install
apt install criu

# Checkpoint
criu dump -t PID --images-dir /tmp/checkpoint

# Restore
criu restore --images-dir /tmp/checkpoint

# Pre-dump
criu predump -t PID --images-dir /tmp/checkpoint

Interview talking point: “predump captures memory before the final dump so criu dump pauses the process for less time, trading extra I/O for a shorter stop.”

Q870: How do you use Crossplane composition?

What it is: A Crossplane Composition that maps a composite Database type to concrete resources such as an RDS DBInstance, using patchSets to copy labels across them.

Why it is used: Turns a high-level API request into real cloud infrastructure declaratively.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: composition.example.com
spec:
  compositeTypeRef:
    apiVersion: example.com/v1alpha1
    kind: Database
  patchSets:
  - name: metadata
    patches:
    - fromFieldPath: metadata.labels
      toFieldPath: metadata.labels
  resources:
  - name: rds
    base:
      apiVersion: rds.aws.upbound.io/v1beta1
      kind: DBInstance
      spec:
        forProvider:
          engine: postgres
          instanceClass: db.t3.micro

Interview talking point: “The patchSet propagates metadata.labels to every composed resource in one place, so label changes are maintained once instead of repeated inside each resource definition.”

Q871: How do you use Crossplane?

What it is: Crossplane is installed with Helm, then a provider such as provider-aws is applied and a ProviderConfig supplies credentials from a Secret in the crossplane-system namespace.

Why it is used: To manage cloud resources through Kubernetes APIs so infrastructure is declared alongside workloads.

# Install
helm repo add crossplane-stable https://charts.crossplane.io/stable
helm install crossplane crossplane-stable/crossplane --namespace crossplane-system --create-namespace

# Install AWS provider
kubectl apply -f https://github.com/crossplane/provider-aws/releases/latest/download/provider-aws.yaml

# Create ProviderConfig
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
  name: default
spec:
  credentials:
    source: Secret
    secretRef:
      namespace: crossplane-system
      name: aws-creds
      key: credentials

Interview talking point: “Crossplane separates the provider from its configuration: applying provider-aws installs the controllers, while ProviderConfig with source Secret and secretRef supplies AWS credentials, so a Kubernetes Secret rather than an environment variable holds the keys.”

Q872: How do you use Dapr?

What it is: Dapr is a sidecar runtime for microservices. The CLI is installed with a script, initialized on Kubernetes, apps deployed with kubectl, and methods called with dapr invoke.

Why it is used: Gives services invocation, state, and messaging plumbing without baking a framework into application code.

# Install CLI
wget -q https://raw.githubusercontent.com/dapr/cli/master/install.sh | /bin/bash

# Initialize
dapr init --kubernetes

# Deploy app
kubectl apply -f deploy.yaml

# Invoke
dapr invoke --app-id myapp --method mymethod --payload '{}'

Interview talking point: “dapr invoke targets an app by its logical app-id through the sidecar rather than a pod IP, so addressing survives rescheduling and pods can be replaced freely.”

Q873: How do you use Docker BuildKit?

What it is: BuildKit is Docker’s newer build engine. It is turned on per shell with DOCKER_BUILDKIT=1 or for the whole daemon via the features key, and docker build —progress=plain prints each step.

Why it is used: For faster builds and readable per-step output in CI logs.

# Enable
export DOCKER_BUILDKIT=1

# In daemon
# /etc/docker/daemon.json
{
    "features": {
        "buildkit": true
    }
}

# Build
docker build --progress=plain .

Interview talking point: “The export only affects the current shell session, while features.buildkit set to true in daemon.json makes BuildKit the default for every build on that host.”

Q874: How do you use Envoy?

What it is: Envoy is a proxy configured by YAML listing listeners, filter chains, routes, and clusters. This example listens on port 8080 and forwards to 127.0.0.1:80.

Why it is used: To front services with a configurable proxy that handles routing and load balancing.

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: my_service
  clusters:
  - name: my_service
    type: STATIC
    lb_policy: ROUND_ROBIN
    hosts:
    - socket_address:
        address: 127.0.0.1
        port_value: 80

Interview talking point: “The config separates listeners from clusters, so the proxy binds 0.0.0.0:8080 yet balances ROUND_ROBIN across backend hosts, decoupling the inbound socket from upstream targets.”

Q875: How do you use Falco effectively?

What it is: Falco is a runtime security tool that detects anomalous behavior using rule-based policies.

Why it is used: It provides real-time alerts for suspicious activity like container escape attempts.

# Detect container escapes
- rule: Container escape attempt
  desc: Detect container escape attempts
  condition: (evt.type=unshare and evt.dir=< and proc.name != containerd-shim)
  priority: CRITICAL
  tags: [container, security]

Interview talking point: “Falco rules can target specific syscall patterns and container context, allowing precise detection of high-severity events like unshare attempts.”

Q876: How do you use Falco rules?

What it is: Falco is a runtime security tool that uses YAML rules to detect suspicious activity in containers and hosts.

Why it is used: It helps detect threats like shell access inside containers in real time.

- rule: Terminal shell in container
  desc: notice shell activity
  condition: container.id != host and proc.name = bash
  output: "Shell in container (user=%user.name container=%container.id image=%container.image.repository)"
  priority: WARNING
  tags: [container, shell]

Interview talking point: “A key talking point is that Falco rules can filter by container context, so alerts distinguish between host and container activity.”

Q877: How do you use Falco?

What it is: Falco runs as a DaemonSet and alerts on runtime behavior; rules in falco-rules.yaml combine a condition on process name with an output message and priority.

Why it is used: To detect suspicious activity inside containers, such as a shell being opened, at runtime.

# Install
kubectl apply -f https://raw.githubusercontent.com/falcosecurity/falco/master/integrations/k8s-using-daemonset/falco-daemonset-configmap.yaml

# Rules
# /etc/falco/falco-rules.yaml
- rule: Shell in container
  desc: notice shell activity
  condition: container.id != host and proc.name = bash
  output: "Shell in container (user=%user.name container_id=%container.id image=%container.image.repository)"
  priority: WARNING

Interview talking point: “The condition container.id not equal host and proc.name equal bash fires whenever bash starts in a container, and the output interpolates user, container id, and image so the alert names exactly what to investigate.”

Q878: How do you use Firecracker?

What it is: Firecracker is a VMM for microVMs; a config file names the vmlinux kernel, rootfs image and network interface, and firecracker —config-file boots it.

Why it is used: To boot lightweight VMs fast for serverless functions or one VM per container host.

# Install
apt install firecracker

# Create microVM
# config.json
{
  "boot-source": "vmlinux",
  "kernel-image": "vmlinux",
  "drive": {
    "path": "rootfs.ext4"
  },
  "network-interfaces": [
    {
      "guest-device": "eth0"
    }
  ]
}

# Run
firecracker --config-file config.json

Interview talking point: “Firecracker boots a real kernel from vmlinux with a minimal device model, which is why its startup time is far below traditional hypervisors.”

Q879: How do you use Flannel?

What it is: Flannel is a CNI plugin installed by applying its kube-flannel.yml manifest, whose embedded net-conf.json sets the pod network CIDR and a vxlan backend type.

Why it is used: To give pods routable IPs across nodes with a simple VXLAN overlay in small clusters.

# Install
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

# Configure
# kube-flannel.yml
net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "vxlan"
    }
  }

Interview talking point: “The manifest sets Network to 10.244.0.0/16 and Backend Type to vxlan, so the pod CIDR lives in one config file, and changing the backend there swaps encapsulation without touching node networking.”

Q880: How do you use Garden?

What it is: A Garden project defining local and dev environments, a kubernetes provider, and a container module with a build command and kubectl manifests for deployment.

Why it is used: Automates building, deploying, and testing per environment from a single config.

kind: Project
name: myproject
environments:
  - name: local
    defaultNamespace: default
  - name: dev
    providers:
      - name: kubernetes
        namespace: dev
        buildMode: kaniko

providers:
  - name: kubernetes

modules:
  - name: api
    type: container
    build:
      command: docker build -t myproject/api .
    deploy:
      kubectl:
        manifests:
          - manifest/deploy.yaml
        files:
          - manifest/configmap.yaml

Interview talking point: “The dev environment overrides namespace and buildMode kaniko while the module stays unchanged, showing environment-specific behavior lives in the environment block, not the module.”

Q881: How do you use Helm efficiently?

What it is: Helm is a package manager for Kubernetes. Install, upgrade, and rollback manage releases, helm template renders a chart locally, and repo add and update manage chart sources.

Why it is used: To deploy and version charts consistently and preview output before applying.

# Common commands
helm install myrelease stable/nginx
helm upgrade myrelease stable/nginx
helm rollback myrelease 1

# Template
helm template myrelease stable/nginx

# Repo management
helm repo add stable https://charts.helm.sh/stable
helm repo update
helm search repo nginx

Interview talking point: “helm template shows exactly what a chart will produce before install, while helm rollback returns a release to a prior revision when an upgrade goes wrong.”

Q882: How do you use Helm?

What it is: Helm is a package manager for Kubernetes. You add chart repositories and update them, install and upgrade named releases, render manifests with helm template, and override settings with -f values.yaml.

Why it is used: To deploy and version whole applications consistently instead of hand-editing many Kubernetes manifests.

# Install
curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

# Add repo
helm repo add stable https://charts.helm.sh/stable
helm repo update

# Install
helm install myrelease stable/nginx

# Upgrade
helm upgrade myrelease stable/nginx

# Template
helm template myrelease stable/nginx

# Values
helm install -f values.yaml myrelease stable/nginx

Interview talking point: “Every install has a release name like myrelease, which is what helm upgrade targets later. helm template renders a chart locally so you can review the output, and -f values.yaml supplies your configuration before install or upgrade.”

Q883: How do you use Helm?

What it is: Helm is a package manager for Kubernetes. It adds chart repositories, installs named releases with overridable values, upgrades them, renders templates locally, and packages a chart directory.

Why it is used: To install and version complex applications consistently across environments.

# Add repo
helm repo add stable https://charts.helm.sh/stable
helm repo update

# Install
helm install myrelease stable/nginx
helm install myrelease stable/nginx --set service.type=NodePort

# Upgrade
helm upgrade myrelease stable/nginx

# Template
helm template myrelease stable/nginx -f values.yaml

# Package
helm package mychart/

# Hooks
helm install --dry-run --debug

Interview talking point: “helm template with values.yaml renders manifests without touching the cluster, which is ideal for review in CI, and install with —dry-run —debug checks a release before it commits.”

Q884: How do you use Helmfile?

What it is: Helmfile is a declarative file listing Helm repositories and releases, with each release naming a chart and its values file in helmfile.yaml.

Why it is used: To declare and apply a whole set of Helm releases as one unit.

repositories:
  - name: nginx
    url: https://helm.nginx.com/stable

releases:
  - name: nginx-ingress
    chart: nginx/nginx-ingress
    values:
      - ./values.yaml

Interview talking point: “Because repositories and releases are declared together, the whole stack applies in one pass instead of running separate repo add and install commands per chart.”

Q885: How do you use Helmfile?

What it is: Helmfile declares many Helm releases in one file: environments map to value files, repositories are registered, and each release names a chart, version, and values file.

Why it is used: To install and upgrade many charts consistently across staging and production from a single manifest.

environments:
  production:
    values:
      - production.yaml
  staging:
    values:
      - staging.yaml

repositories:
  - name: nginx
    url: https://helm.nginx.com/stable
  - name: ingress-nginx
    url: https://kubernetes.github.io/ingress-nginx

releases:
  - name: nginx-ingress
    chart: ingress-nginx/ingress-nginx
    version: "4.0.0"
    values:
      - ingress-nginx.yaml

  - name: myapp
    chart: ./myapp-chart
    values:
      - {{ .Environment.Name }}.yaml

Interview talking point: “environments stage production and staging values files, and the templated values entry resolves per environment, so one helmfile drives both clusters while release versions such as 4.0.0 stay pinned.”

Q886: How do you use k0s?

What it is: k0s is a minimal Kubernetes distribution: one install script, k0s controller starts the control plane, and k0s worker joins using a token file.

Why it is used: To stand up a small Kubernetes cluster with no packaging dependencies on bare hosts.

# Install
curl -sSLf https://get.k0sproject.io | sh

# Start
k0s controller

# Add worker
k0s worker --token-file /var/lib/k0s/worker.token

Interview talking point: “The worker joins with a token from worker.token, showing k0s setup is just a controller plus token rather than a full installer stack.”

Q887: How do you use K3s in production?

What it is: K3s is a lightweight Kubernetes distribution installed from get.k3s.io; the server writes a node token and extra agents join with K3S_URL and K3S_TOKEN.

Why it is used: To run a conformant Kubernetes cluster on edge or resource limited nodes.

# Install with high availability
# Use embedded etcd or external DB

# Install
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--write-kubeconfig-mode 644" sh -

# Token
cat /var/lib/rancher/k3s/server/node-token

# Add agent
curl -sfL https://get.k3s.io | K3S_URL=https://server:6443 K3S_TOKEN=TOKEN sh -

Interview talking point: “The write-kubeconfig-mode 644 flag makes the kubeconfig world readable, trading access control for easier kubectl use on a small cluster.”

Q888: How do you use K3s storage?

What it is: Longhorn is a Kubernetes storage provisioner installed by applying its manifest; a PVC with storageClassName longhorn requests a replicated block volume.

Why it is used: To give K3s workloads persistent block storage that survives node loss.

# Use Longhorn
# Install
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml

# Create PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 1Gi

Interview talking point: “The PVC sets accessModes ReadWriteOnce, meaning the volume attaches to one node at a time, so only a single pod can mount it.”

Q889: How do you use k9s?

What it is: k9s is a terminal UI for Kubernetes; colon commands such as :ns, :po, :svc and :dp jump between resource views.

Why it is used: To monitor and navigate cluster resources quickly without typing long kubectl commands.

# Install
curl -sS https://webinstall.dev/k9s | bash

# Run
k9s

# Commands
# :ns - namespace
# :po - pods
# :svc - services
# :dp - deployments

Interview talking point: “k9s wraps the same API calls as kubectl, so it is a faster interface rather than a different permission model, and your RBAC still applies.”

Q890: How do you use Kaniko?

What it is: Kaniko builds images with no daemon by running its executor against a workspace context, an optional Dockerfile path, and a destination image reference.

Why it is used: To build images in CI where a Docker daemon or privileged mode is unavailable.

# Build
docker run -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest \
  --context /workspace \
  --destination gcr.io/myproject/image:tag

# With dockerfile
docker run -v $(pwd):/workspace gcr.io/kaniko-project/executor:latest \
  --context /workspace \
  --dockerfile /workspace/Dockerfile \
  --destination gcr.io/myproject/image:tag

Interview talking point: “Since the executor is just a process with no privileged access needed, it fits restricted CI runners where docker-in-docker is forbidden.”

Q891: How do you use KEDA?

What it is: A KEDA ScaledObject that scales the myapp workload between 0 and 10 replicas based on a Prometheus requests-per-second threshold, polling every 15 seconds with a 300 second cooldown.

Why it is used: Scales services from external metrics and lets them scale to zero when idle.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: myapp-scaler
spec:
  scaleTargetRef:
    name: myapp
  pollingInterval: 15
  cooldownPeriod: 300
  minReplicaCount: 0
  maxReplicaCount: 10
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: http_requests_per_second
      threshold: "100"

Interview talking point: “minReplicaCount 0 is the KEDA differentiator, since a plain HPA always keeps at least one replica, and cooldownPeriod controls how long the idle pod lingers before shutdown.”

Q892: How do you use Kind?

What it is: Kind builds Kubernetes clusters inside Docker containers, created with kind create cluster or a kind-config.yaml, and kind load docker-image pushes local images in.

Why it is used: To run multi-node Kubernetes in CI or locally wherever Docker is available.

# Install
go install sigs.k8s.io/kind@v0.20.0

# Create cluster
kind create cluster

# Custom cluster
kind create cluster --config kind-config.yaml

# Load image
kind load docker-image myimage:latest

Interview talking point: “kind load docker-image is required because nodes cannot pull from your local Docker daemon, which surprises people testing private or freshly built images.”

Q893: How do you use Knative?

What it is: A Knative Service manifest declaring an image, container port 8080, and CPU and memory requests and limits that Knative Serving runs as a serverless app.

Why it is used: Deploys containerized HTTP services with automatic scaling and revision management.

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: myapp
spec:
  template:
    spec:
      containers:
      - image: gcr.io/knative-samples/helloworld-go
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: "1000m"
            memory: "256Mi"
          requests:
            cpu: "250m"
            memory: "128Mi"

Interview talking point: “requests guarantee the scheduled minimum while limits cap the ceiling, so a limit above the request makes the container burstable whereas equal values make it Guaranteed QoS.”

Q894: How do you use Kourier?

What it is: Kourier is a Knative networking layer. Its release manifest is applied to install it, then the config-network ConfigMap in knative-serving is patched to enable kourier-enabled.

Why it is used: Acts as the ingress routing external traffic to Knative services once turned on.

# Install
kubectl apply -f https://github.com/knative/net-kourier/releases/download/v0.26.0/kourier.yaml

# Configure
kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"kourier-enabled":"true"}}'

Interview talking point: “Enabling Kourier is a ConfigMap patch rather than a control-plane redeploy, showing Knative swaps ingress implementations through configuration alone.”

Q895: How do you use KServe?

What it is: A KServe InferenceService named sklearn-iris whose predictor declares the sklearn model format and pulls the model artifact from an s3 storage URI.

Why it is used: Serves machine learning models on Kubernetes while model files stay in object storage.

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-iris
spec:
  predictor:
    model:
      modelFormat:
        name: sklearn
      storageUri: "s3://bucket/sklearn/mymodel"

Interview talking point: “Because the model is referenced by storageUri, shipping a new model is a URI change, keeping model artifacts decoupled from container image rebuilds.”

Q896: How do you use Kube-bench?

What it is: kube-bench checks clusters against security benchmarks; run it with targets like node, or apply its job.yaml so the checks run inside the cluster.

Why it is used: To audit benchmark compliance on masters, etcd, and nodes.

# Run
kube-bench run --targets node

# As job
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Specific targets
kube-bench run --targets=master,etcd,node

Interview talking point: “kube-bench run with targets node limits the check to node-level controls, while targets master,etcd,node widens it, and the job.yaml path lets the same checks run as a pod rather than from your workstation.”

Q897: How do you use kubectl efficiently?

What it is: kubectl is the Kubernetes CLI. Aliases shorten frequent commands, config get-contexts and use-context switch clusters, and dry-run with -o yaml generates manifest files.

Why it is used: To work faster and avoid running commands against the wrong cluster.

# Aliases
alias k=kubectl
alias kgp='kubectl get pods'
alias kga='kubectl get all'
alias kdp='kubectl describe pod'
alias klf='kubectl logs -f'

# Contexts
kubectl config get-contexts
kubectl config use-context production

# Quick access
kubectl run nginx --image=nginx --restart=Never --dry-run=client -o yaml > nginx.yaml

Interview talking point: “kubectl run with —dry-run=client -o yaml writes a valid manifest without touching the server, and checking contexts first prevents accidentally targeting production.”

Q898: How do you use kubectl?

What it is: kubectl is the Kubernetes command-line client. It reads a config file, lists nodes, pods, services, and deployments, applies manifests, and offers describe, logs, and exec for debugging.

Why it is used: To inspect cluster state, deploy changes, and troubleshoot individual pods from a terminal.

# Configure
mkdir ~/.kube
cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
chmod 600 ~/.kube/config

# Commands
kubectl get nodes
kubectl get pods -A
kubectl get services
kubectl get deployments

# Apply
kubectl apply -f deployment.yaml

# Debug
kubectl describe pod name
kubectl logs -f pod name
kubectl exec -it pod name -- /bin/bash

Interview talking point: “The config is copied to ~/.kube/config and chmod 600 because it carries cluster credentials. kubectl describe pod surfaces events and status, kubectl logs -f streams output live, and exec opens an interactive shell inside the container.”

Q899: How do you use Kubeflow?

What it is: Kubeflow installed from upstream manifests, with a PipelineRun resource that references a named pipeline and supplies parameter values for that execution.

Why it is used: Runs machine learning pipelines as repeatable Kubernetes-native jobs.

# Install
kubectl apply -f https://github.com/kubeflow/manifests.git/v1.6-branch/kfdef/kfctl_k8s_istio.v1.6.0.yaml

# Pipeline
apiVersion: kubeflow.org/v1beta1
kind: PipelineRun
metadata:
  name: my-pipeline-run
spec:
  pipelineRef:
    name: my-pipeline
  params:
  - name: param1
    value: value1

Interview talking point: “The PipelineRun names the pipeline and passes params, separating the pipeline definition from each execution the same way a template is separate from its instances.”

Q900: How do you use Kubernetes cert-manager?

What it is: cert-manager automates certificates: a ClusterIssuer talks to Let’s Encrypt over ACME with an http01 solver behind the nginx ingress class, and a Certificate requests a secret for a DNS name.

Why it is used: To issue and renew TLS certificates for ingresses without manual work.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
    - http01:
        ingress:
          class: nginx

---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: myapp-tls
spec:
  secretName: myapp-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
  - myapp.example.com

Interview talking point: “The Certificate stores the issued material in secretName, so apps consume that secret, and cert-manager handles renewal on schedule after the initial issuance.”

Q901: How do you use Kubernetes Cilium?

What it is: Cilium is a Kubernetes networking component installed with its CLI; the CLI tarball is checksum verified with sha256sum, extracted to /usr/local/bin, then cilium install deploys it.

Why it is used: To run eBPF-based pod networking and policy, with cilium status reporting install health afterwards.

# Install Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
CLI_ARCH=$(uname -m)
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin

# Install
cilium install

# Status
cilium status

Interview talking point: “The install fetches an architecture-matched tarball and checks the sha256sum before extracting, then cilium status gives a direct health check after cilium install instead of inferring state from pod listings.”

Q902: How do you use Kubernetes HorizontalPodAutoscaler?

What it is: A HorizontalPodAutoscaler scales a Deployment between minReplicas and maxReplicas using metrics like average CPU utilization, with a behavior block shaping how scale-down happens.

Why it is used: To add and remove pod replicas automatically as traffic load changes.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: myapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: myapp
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

Interview talking point: “The 300-second stabilization window plus a 10 percent per minute policy slows scale-down, which prevents replica thrash when traffic arrives in short spikes.”

Q903: How do you use Kubernetes ingress controller?

What it is: An Ingress exposes services by host and path, sending myapp.example.com requests on path prefix / to service myapp-svc port 80, with a rewrite annotation.

Why it is used: To publish several services behind one entry point with host-based routing.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: myapp-svc
            port:
              number: 80

Interview talking point: “pathType Prefix makes / match every path under it, and the rewrite-target annotation controls what path the backend actually receives.”

Q904: How do you use Kubernetes LimitRange?

What it is: A LimitRange sets per-container bounds and defaults, defining maximum, minimum, default, and default request values for CPU and memory of type Container.

Why it is used: To make sure every container gets sane resource values without the author specifying them.

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimits
spec:
  limits:
  - max:
      cpu: "4"
      memory: 8Gi
    min:
      cpu: 100m
      memory: 128Mi
    default:
      cpu: 500m
      memory: 1Gi
    defaultRequest:
      cpu: 200m
      memory: 512Mi
    type: Container

Interview talking point: “The default fills in when a limit is set but no request, defaultRequest fills a missing request, and together they produce values a ResourceQuota can then enforce.”

Q905: How do you use Kubernetes NetworkPolicy?

What it is: NetworkPolicy controls pod traffic. One policy selects all pods and declares Ingress and Egress, another allows TCP port 80 into app web pods only from app api pods.

Why it is used: To enforce least-privilege network access between pods in a cluster.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - protocol: TCP
      port: 80

Interview talking point: “Because the empty podSelector matches every pod, the first policy makes deny the default and the second opens one path, giving you an allow list rather than a block list.”

Q906: How do you use Kubernetes on cloud?

What it is: Managed Kubernetes clusters created with each cloud’s own CLI. eksctl builds an EKS cluster with a node group of t3.medium workers, gcloud creates a GKE cluster in a zone, and az aks creates an AKS cluster with monitoring.

Why it is used: To launch a working Kubernetes control plane without assembling and operating the components yourself.

# EKS
eksctl create cluster --name mycluster --region us-east-1 --nodegroup-name standard-workers --node-type t3.medium --nodes 3
# GKE
gcloud container clusters create mycluster --zone us-east1-a --num-nodes 3
# AKS
az aks create --resource-group mygroup --name mycluster --node-count 3 --enable-addons monitoring

Interview talking point: “The three commands show each provider’s flavor: eksctl models the node group explicitly, GKE pins a zone, and AKS takes a plain node count plus an add-on flag for monitoring.”

Q907: How do you use Kubernetes PDB?

What it is: A PodDisruptionBudget limits voluntary evictions by requiring either minAvailable 2 or at most maxUnavailable 25 percent of the pods matched by a label selector.

Why it is used: To keep enough replicas running while nodes are drained or upgraded.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

---
# Or percentage
spec:
  maxUnavailable: 25%
  selector:
    matchLabels:
      app: myapp

Interview talking point: “PDBs cover voluntary disruptions like drains, not crashes or OOM kills, and minAvailable and maxUnavailable are two ways to express the same protection.”

Q908: How do you use Kubernetes PodDisruptionBudget?

What it is: This PodDisruptionBudget requires at least two pods labeled app myapp to stay available whenever voluntary disruptions occur.

Why it is used: To protect availability during node drains and maintenance windows.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Interview talking point: “With minAvailable 2 on a two-pod deployment, a drain is blocked until replacements exist, which is the practical consequence to expect during maintenance.”

Q909: How do you use Kubernetes PriorityClass?

What it is: A PriorityClass gives pods a scheduling priority value, here 1000000, applied through priorityClassName, with globalDefault off and a description marking critical workloads.

Why it is used: To ensure critical pods schedule first and are evicted last.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "High priority for critical workloads"

---
# Use in pod
priorityClassName: high-priority

Interview talking point: “Higher values win in scheduling and preemption, and since globalDefault is false a pod without priorityClassName gets no priority rather than a fallback value.”

Q910: How do you use Kubernetes RBAC?

What it is: Kubernetes RBAC here pairs a ServiceAccount with a Role granting get, list, watch on pods, and a RoleBinding attaching that Role to the account.

Why it is used: To give an application identity only the API access it needs.

# ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: myapp-sa

---
# Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myapp-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: myapp-rolebinding
subjects:
- kind: ServiceAccount
  name: myapp-sa
roleRef:
  kind: Role
  name: myapp-role
  apiGroup: rbac.authorization.k8s.io

Interview talking point: “The Role lists permissions but grants nothing on its own; the RoleBinding is what connects it to the ServiceAccount, so skipping the binding leaves the account with no access.”

Q911: How do you use Kubernetes service mesh linkerd?

What it is: Linkerd is a service mesh whose CLI installs the control plane with kubectl apply, injects proxy sidecars into a deployment manifest, and opens a viz dashboard.

Why it is used: To add traffic metrics and visibility to services without changing application code.

# Install CLI
curl -sL https://run.linkerd.io/install | sh

# Install
linkerd install | kubectl apply -f -

# Add to namespace
linkerd inject deployment.yml | kubectl apply -f -

# Dashboard
linkerd viz dashboard

Interview talking point: “linkerd inject rewrites your deployment YAML to add proxy sidecars before applying it, so you can review the diff first, and piping inject output straight to kubectl keeps the mesh opt-in per workload.”

Q912: How do you use Kubernetes ServiceMesh?

What it is: An Istio VirtualService routes traffic to subsets of a service, splitting HTTP requests 90 percent to v1 and 10 percent to v2 by weight.

Why it is used: To run canary releases and split traffic without changing application code.

# Istio VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp
  http:
  - route:
    - destination:
        host: myapp
        subset: v1
      weight: 90
    - destination:
        host: myapp
        subset: v2
      weight: 10

Interview talking point: “Weights distribute requests at the sidecar proxy layer and must total 100, so a canary grows or shrinks purely by editing weights.”

Q913: How do you use Kubernetes topology keys?

What it is: Kubernetes topology keys list routing preference from kubernetes.io/hostname up through zone and region, while pod affinity terms come in preferred and required scheduling forms.

Why it is used: To keep traffic local to a node or zone first, and to place or spread pods across failure domains deliberately.

# Service
spec:
  topologyKeys:
  - "kubernetes.io/hostname"
  - "topology.kubernetes.io/zone"
  - "topology.kubernetes.io/region"

# Pod
# PreferredDuringSchedulingIgnoredDuringExecution
# RequiredDuringSchedulingIgnoredDuringExecution

Interview talking point: “Service topologyKeys are ordered fallbacks, so traffic moves to the next domain when a local endpoint is missing, while the required affinity form blocks scheduling entirely if unsatisfied — one degrades routing, the other refuses placement.”

Q914: How do you use Kubernetes VerticalPodAutoscaler?

What it is: A VerticalPodAutoscaler adjusts container resource requests rather than replica counts, targeting a Deployment with updateMode Auto and min and max allowed CPU and memory.

Why it is used: To right-size containers that are consistently over- or under-provisioned.

apiVersion: "autoscaling.k8s.io/v1"
kind: VerticalPodAutoscaler
metadata:
  name: myapp-vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: myapp
  updatePolicy:
    updateMode: "Auto"
  resourcePolicy:
    containerPolicies:
    - containerName: myapp
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: "4"
        memory: 8Gi

Interview talking point: “VPA changes requests while HPA changes replica count, so they act on different dimensions and generally should not both autoscale on the same metric.”

Q915: How do you use Kubescape?

What it is: Kubescape is a security scanner installed by script; kubescape scan checks the cluster, can submit results to a cloud account, and host-scan checks the nodes.

Why it is used: To score cluster and node security posture and track results over time centrally.

# Install
curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

# Scan
kubescape scan

# Submit to cloud
kubescape scan --submit --account EMAIL

# Host scanner
kubescape host-scan

Interview talking point: “kubescape scan works locally, while scan with submit and an account email uploads results for trends, and host-scan shifts focus from Kubernetes objects to the underlying node configuration.”

Q916: How do you use kustomize?

What it is: Kustomize customizes Kubernetes manifests through a kustomization.yaml. It assembles resources, sets a namespace and common labels, generates ConfigMaps from literals, and overrides replica counts.

Why it is used: To vary one base manifest across several environments without copying and editing YAML by hand.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
namespace: production
commonLabels:
  app: myapp
configMapGenerator:
  - name: app-config
    literals:
      - DEBUG=false
replicas:
  - name: deployment
    count: 3

Interview talking point: “configMapGenerator with a literal such as DEBUG=false builds the ConfigMap at render time, and replicas adjusts the named deployment’s count. Kustomize modifies manifests rather than templating them, which is the main contrast with Helm.”

Continue with questions 241-1000 covering more advanced topics…

Q917: How do you use Kustomize?

What it is: Kustomize customizes base manifests without templates. A kustomization lists resources, then applies namespace, labels, generated ConfigMaps, replica counts, and JSON patches targeted by kind.

Why it is used: To keep one base manifest and vary it per environment such as production.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
  - service.yaml
namespace: production
commonLabels:
  app: myapp
configMapGenerator:
  - name: app-config
    literals:
      - DEBUG=false
replicas:
  - name: deployment
    count: 3
patches:
  - patch: |-
      - op: replace
        path: /spec/replicas
        value: 5
    target:
      kind: Deployment

Interview talking point: “Unlike Helm there is no templating language, just declarative edits, and configMapGenerator regenerates the ConfigMap with a new name hash when its literals change, which triggers pod restarts.”

Q918: How do you use Kustomize?

What it is: Kustomize customizes base manifests without templates. A base lists resources, an overlay references it and applies patches, and kubectl apply -k renders the result.

Why it is used: To maintain environment-specific variants of shared manifests.

# Base kustomization
# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml

# Overlay
# production/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../base
patches:
- patch.yaml

# Apply
kubectl apply -k production/

Interview talking point: “The overlay stores only differences from the base, so environment configs stay small and drift between environments shows up as a diff instead of a forked copy.”

Q919: How do you use Kyverno policies?

What it is: Kyverno is a Kubernetes-native policy engine that can validate, mutate, or generate resources.

Why it is used: It automates configuration changes like setting default resource requests for Pods.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-resources
spec:
  rules:
  - name: add-default-resources
    match:
      resources:
        kinds:
        - Pod
    mutate:
      patchStrategicMerge:
        spec:
          containers:
          - resources:
              requests:
                memory: "256Mi"
                cpu: "250m"

Interview talking point: “A useful distinction is that Kyverno can mutate resources at admission time, while some policy tools only validate.”

Q920: How do you use Kyverno?

What it is: Kyverno is a Kubernetes policy engine installed from its manifest; a ClusterPolicy with validationFailureAction enforce validates Pods and requires an app label.

Why it is used: To enforce standards such as required labels automatically at admission rather than in review.

# Install
kubectl create -f https://raw.githubusercontent.com/kyverno/kyverno/main/config/release/kyverno.yaml

# Policy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-labels
spec:
  validationFailureAction: enforce
  rules:
  - name: check-label
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Label 'app' is required"
      pattern:
        metadata:
          labels:
            app: "?*"

Interview talking point: “The rule matches Pod kinds and requires labels app to match the pattern shown, so a Pod missing an app label is refused at admission while validationFailureAction is set to enforce.”

Q921: How do you use Lens?

What it is: Lens is a desktop IDE for Kubernetes that connects through your kubeconfig and offers a visual resource view, management actions and an integrated terminal.

Why it is used: To give teams a graphical way to inspect clusters without deep kubectl knowledge.

# Install
# Download from lenside.com

# Connect to cluster
# Add cluster via kubeconfig

# Features
# Visual interface
# Resource management
# Terminal integration

Interview talking point: “Lens loads your kubeconfig, so cluster access and RBAC limits follow your existing credentials rather than Lens granting any extra rights.”

Q922: How do you use Linux crictl?

What it is: crictl is the command-line client for a CRI container runtime. /etc/crictl.yaml sets the runtime and image endpoints, timeout, and debug flag; then you pull images, run containers, and list them.

Why it is used: To inspect and debug containers on a Kubernetes node directly through the container runtime interface.

# Configure crictl
cat > /etc/crictl.yaml <<EOF
runtime-endpoint: unix:///var/run/dockershim.sock
image-endpoint: unix:///var/run/dockershim.sock
timeout: 10
debug: false
EOF

# Pull image
crictl pull nginx:latest

# Run container
crictl run container.json pod.json

# List
crictl ps
crictl pods

Interview talking point: “crictl is CRI aware, so it lists both containers with crictl ps and pod sandboxes with crictl pods, which plain docker ps does not show. crictl run takes container and pod JSON specs rather than just an image name.”

Q923: How do you use MicroK8s?

What it is: MicroK8s is Canonical’s snap-packaged Kubernetes; microk8s enable turns on addons such as dns, storage and ingress, and microk8s kubectl runs the bundled client.

Why it is used: To get a fast local or edge Kubernetes with addons toggled on demand.

# Install
snap install microk8s --classic

# Enable addons
microk8s enable dns storage ingress

# Check status
microk8s status

# Use kubectl
microk8s kubectl get pods

Interview talking point: “Because kubectl ships inside the snap, commands run as microk8s kubectl, which avoids version skew with an externally installed client.”

Q924: How do you use Minikube with drivers?

What it is: Minikube runs a single-node local cluster, and the driver flag chooses the backend: docker for a container or kvm2 for a virtual machine.

Why it is used: To run a disposable Kubernetes cluster on a workstation for development and testing.

# Install
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
install minikube-linux-amd64 /usr/local/bin/minikube

# Start with Docker
minikube start --driver=docker

# Start with KVM
minikube start --driver=kvm2

# Addons
minikube addons enable ingress

Interview talking point: “Switching between driver=docker and driver=kvm2 changes isolation and performance without changing cluster commands, while addons enable ingress adds an ingress controller to that same cluster.”

Q925: How do you use MLflow?

What it is: An MLflow server backed by a SQLite database with a local artifact root, plus client calls that log parameters, a metric, and a model artifact inside a run.

Why it is used: Tracks experiments so parameters, metrics, and model files stay comparable and reproducible.

# Run server
mlflow server --backend-store-uri sqlite:///mlflow.db --default-artifact-root ./artifacts

# Track
import mlflow
mlflow.set_experiment("myexperiment")
with mlflow.start_run():
    mlflow.log_param("alpha", 0.5)
    mlflow.log_metric("rmse", 0.1)
    mlflow.log_artifact("model.pkl")

Interview talking point: “The backend store holds run metadata while the artifact root holds files like model.pkl, so the two can be backed up, moved, or grown independently.”

Q926: How do you use nerdctl?

What it is: nerdctl is a Docker-style client for containerd, offering pull, run, ps, and build, and it can point at a chosen containerd socket with its address option.

Why it is used: To keep familiar Docker commands while the platform underneath is containerd.

# Like docker
nerdctl pull nginx
nerdctl run -d nginx
nerdctl ps
nerdctl build -t myimage .

# With containerd
nerdctl --address /run/containerd/containerd.sock ps

Interview talking point: “The —address flag shows the client is independent of any daemon, since it drives whatever containerd socket you name, which is not something the docker CLI offers.”

Q927: How do you use NetworkPolicies?

What it is: A NetworkPolicy selects pods and lists allowed traffic. This one lets only pods labeled app=web reach app=api on TCP port 8080.

Why it is used: To segment traffic and stop lateral movement between workloads.

# Allow specific traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 8080

Interview talking point: “podSelector names the policy’s target while from restricts the sources, and because policies are additive, applying even one policy makes unlisted ingress denied by default.”

Q928: How do you use Nocalhost?

What it is: Nocalhost CLI usage: install against a kubeconfig, add a service with a local port, enter dev mode with a dev image, and forward port 8080.

Why it is used: Enables live editing against a running Kubernetes service during development.

# Install
nh install --kubeconfig ~/.kube/config

# Add service
nh add myapp --install 8080

# Dev mode
nh dev myapp --image myapp:dev

# Forward
nh port-forward myapp 8080:8080

Interview talking point: “nh dev swaps in a dev image while nh port-forward exposes the service locally, so code changes reach the pod without a full rebuild and redeploy cycle.”

Q929: How do you use Octant?

What it is: Octant is an open source Kubernetes dashboard run locally as octant, and it can also run as a plugin inside Lens when enabled in settings.

Why it is used: To browse workloads and resource detail in a browser style interface while debugging.

# Install
# Download from GitHub releases

# Run
octant

# Or as plugin in Lens
# Enable in settings

Interview talking point: “Octant runs on your machine against the API server, so it sees only what your kubeconfig credentials allow, exactly like any other client.”

Q930: How do you use OPA Gatekeeper?

What it is: Gatekeeper applies OPA policies to Kubernetes resources: a constraint template defines privileged-container policy and a K8sPrivilegedContainer constraint matches Pod kinds against it.

Why it is used: To prevent noncompliant workloads, such as privileged pods, from being created in the cluster.

# Install
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/privileged-containers/template.yaml

# Constraint
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPrivilegedContainer
metadata:
  name: psp-privileged-container
spec:
  match:
    kinds:
    - apiGroups: [""]
      kinds: ["Pod"]

Interview talking point: “The template file defines the policy logic while the constraint resource carries the match block selecting Pod kinds, so one template can back multiple constraints, each scoped to different resources.”

Q931: How do you use Pixie?

What it is: Pixie is deployed with px deploy and driven from its px CLI: run stored scripts, list live connection streams, and look up a pod by its IP address.

Why it is used: To debug cluster traffic and pod behavior in real time without adding code-level instrumentation.

# Install
px deploy

# Use
px run script px/conn_stats

# View streams
px streams

# Get pod info
px pod 10.0.0.1

Interview talking point: “px run script px/conn_stats executes a stored script against the cluster, px streams shows live connections, and px pod 10.0.0.1 maps an address back to its pod — useful when all you have is an IP.”

Q932: How do you use pod disruption budgets?

What it is: A PodDisruptionBudget guarantees a minimum number of pods stay available during voluntary disruptions, here at least two pods matching app=myapp.

Why it is used: To keep applications available while nodes are drained or upgraded.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

Interview talking point: “A PDB covers voluntary disruptions such as node drains, not crashes or node failures, so it protects maintenance windows but says nothing about surviving a real outage.”

Q933: How do you use Pulumi Kubernetes operator?

What it is: A Pulumi Program resource pointing at a Git repository and the production stack, with destroyOnFinalDeletion set to false.

Why it is used: Runs Pulumi stacks inside the cluster so infrastructure is reconciled from Git continuously.

apiVersion: Pulumi.com/v1
kind: Program
metadata:
  name: my-stack
spec:
  stack: production
  repository:
    url: https://github.com/myorg/infra
  commit: main
  destroyOnFinalDeletion: false

Interview talking point: “destroyOnFinalDeletion false means deleting the Program object does not tear down the stack, preventing an accidental resource deletion from destroying live infrastructure.”

Q934: How do you use resource quotas?

What it is: A ResourceQuota caps total usage in a namespace, limiting CPU and memory requests and limits along with counts of pods, services, and persistent volume claims.

Why it is used: To prevent one team or namespace from consuming the whole cluster.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: myquota
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "20"
    services: "10"
    persistentvolumeclaims: "5"

Interview talking point: “The quota covers both requests and limits plus object counts, so it controls capacity and sprawl, and pods that specify no requests are rejected while a quota is active.”

Q935: How do you use Rook/Ceph in Kubernetes?

What it is: Rook runs Ceph in Kubernetes by applying its common and cluster manifests, then a PVC with storageClassName rook-ceph-block requests a block volume.

Why it is used: To give a cluster its own replicated storage layer managed as Kubernetes resources.

# Install Rook
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/ceph/common.yaml
kubectl apply -f https://raw.githubusercontent.com/rook/rook/master/cluster/examples/kubernetes/ceph/cluster.yaml

# Create PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  storageClassName: rook-ceph-block
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Interview talking point: “With Rook, storage operators are CRDs applied with kubectl, so upgrades and status follow normal Kubernetes workflows instead of external tooling.”

Q936: How do you use service catalog?

What it is: The Service Catalog provisions external services as cluster resources, and a ServiceBinding connects an instance to a secret that applications then read.

Why it is used: To make external dependencies like databases consumable through Kubernetes objects.

# Install Service Catalog
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/service-catalog/master/charts/service-catalog/templates/service-catalog-apiserver.yaml

# Provision service
# Use ServiceBinding
apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
  name: myapp-binding
spec:
  serviceInstanceRef:
    name: my-service
  secretName: myapp-secret

Interview talking point: “The binding writes credentials into a named secret, which decouples how a service is provisioned from how the application reads its connection details.”

Q937: How do you use service discovery?

What it is: Kubernetes services get DNS names such as myservice.mynamespace.svc.cluster.local from CoreDNS, while external-dns publishes records to providers like Cloudflare.

Why it is used: To let workloads find services inside the cluster and expose them to external DNS.

# CoreDNS
# Use Kubernetes DNS
# myservice.mynamespace.svc.cluster.local

# External DNS
kubectl apply -f https://github.com/kubernetes-sigs/external-dns/master/releases/download/v0.12.0/provider.yaml

# Configure
apiVersion: v1
kind: ConfigMap
metadata:
  name: external-dns
data:
  config.yaml: |
    provider: cloudflare
    source: service
    policy: sync

Interview talking point: “Cluster DNS is built in, whereas external-dns is a controller you deploy that watches services and syncs records, so publishing external names is not automatic.”

Q938: How do you use Service Mesh Interface?

What it is: The Service Mesh Interface adaptor is applied with kubectl, and a TrafficSplit resource divides traffic for a service across subsets weighted 90 and 10.

Why it is used: To keep mesh features portable by using standard traffic split APIs instead of vendor-specific resources.

# Install SMI
kubectl apply -f https://github.com/smi/smi-adaptor-istio/releases/download/v0.6.0/install.yaml

# Use traffic split
kubectl apply -f - <<EOF
apiVersion: split.smi-spec.io/v1alpha2
kind: TrafficSplit
metadata:
  name: myapp-split
spec:
  service: myapp
  subsets:
  - weight: 90
    Service: myapp-v1
  - weight: 10
    Service: myapp-v2
EOF

Interview talking point: “TrafficSplit names the root service myapp and gives weights 90 and 10 to myapp-v1 and myapp-v2, so a canary becomes a weight change rather than a redeploy.”

Q939: How do you use Skaffold?

What it is: Skaffold automates the development cycle: it builds the image, deploys the listed manifests, and can forward a deployment port to the local machine.

Why it is used: To speed up the inner loop of coding against a live cluster.

apiVersion: skaffold/v2beta26
kind: Config
build:
  artifacts:
  - image: myapp
deploy:
  kubectl:
    manifests:
    - k8s/*.yaml
portForward:
- resourceType: deployment
  resourceName: myapp
  port: 8080
  localPort: 8080

Interview talking point: “The portForward section maps deployment port 8080 to localPort 8080, so a developer reaches the in-cluster service on localhost without exposing it externally.”

Q940: How do you use Skopeo with TLS?

What it is: Skopeo inspects images in a registry without pulling them. —tls-verify=false disables certificate checking, credentials can be embedded in the reference, or an authfile can supply them.

Why it is used: To check remote image metadata and registry access from a workstation or pipeline.

# With TLS
skopeo inspect --tls-verify=false docker://example.com/image

# With credentials
skopeo inspect docker://user:pass@example.com/image

# Using config
skopeo --authfile ~/.docker/config.json inspect docker://example.com/image

Interview talking point: “Skipping tls-verify suits a private registry with a self-signed certificate, and using —authfile keeps credentials off the command line where other users could see them.”

Q941: How do you use Spinnaker?

What it is: Spinnaker defines delivery as pipeline stages; here a deployManifest stage applies a Kubernetes Deployment manifest with three replicas for the application.

Why it is used: To standardize multi-stage deployments and roll out manifests consistently across accounts and clusters.

# Pipeline
application: myapp
pipeline:
  stages:
  - name: Deploy
    type: deployManifest
    manifests:
    - manifest:
        apiVersion: apps/v1
        kind: Deployment
        spec:
          replicas: 3

Interview talking point: “The pipeline stage type deployManifest takes Kubernetes manifests directly as input, so Spinnaker orchestrates the rollout while the Deployment spec stays ordinary Kubernetes YAML.”

Q942: How do you use Tekton?

What it is: Tekton runs CI as Kubernetes resources; a TaskRun references a named task and passes parameters such as the image value for that execution.

Why it is used: To execute pipeline steps as cluster pods without standing up a separate CI server.

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: mytaskrun
spec:
  taskRef:
    name: mytask
  params:
  - name: image
    value: gcr.io/myproject/myimage

Interview talking point: “A TaskRun is one execution of a Task: taskRef name binds it to the definition while params supply runtime values like image, so the same task runs repeatedly with different inputs.”

Q943: How do you use Terraform with Kubernetes?

What it is: The Kubernetes Terraform provider reads kubeconfig, and a kubernetes_deployment resource declares replicas, selector, pod template, image, and CPU and memory requests and limits.

Why it is used: To manage cluster workloads as declarative infrastructure with plans, review, and state alongside other providers.

provider "kubernetes" {
  config_path = "~/.kube/config"
}

resource "kubernetes_deployment" "example" {
  metadata {
    name = "example"
    labels = {
      app = "example"
    }
  }

  spec {
    replicas = 3

    selector {
      match_labels = {
        app = "example"
      }
    }

    template {
      metadata {
        labels = {
          app = "example"
        }
      }

      spec {
        container {
          image = "nginx:1.21"
          name  = "nginx"

          resources {
            limits = {
              cpu    = "500m"
              memory = "128Mi"
            }
            requests = {
              cpu    = "250m"
              memory = "64Mi"
            }
          }
        }
      }
    }
  }
}

Interview talking point: “The resource nests selector match_labels and template labels under the same app key, and sets requests at 250m CPU and 64Mi against limits of 500m and 128Mi — the scheduling footprint is declared beside the image.”

Q944: How do you use Tilt?

What it is: Tilt is a local development tool configured by a Tiltfile that builds an image, applies Kubernetes YAML, and sets port forwards for a resource.

Why it is used: To get fast rebuilds and live updates while developing against a cluster.

# Tiltfile
docker_build('myapp', '.')
k8s_yaml('k8s/deployment.yaml')
k8s_resource('myapp', port_forwards=8080)

Interview talking point: “The Tiltfile is one executable config file with three calls for build, deploy, and port forward, so a single file fully describes a developer’s inner loop.”

Q945: How do you use Triton Inference Server?

What it is: Triton Inference Server started in Docker with one GPU, port 8000 published, and a mounted model repository, alongside a config.pbtxt declaring platform, max batch size, inputs, and outputs.

Why it is used: Serves models with a defined batching and tensor shape contract for clients.

# Run
docker run --gpus=1 -p 8000:8000 -v /model/repository:/models nvcr.io/nvidia/tritonserver:latest \
  --model-repository=/models

# Config
# config.pbtxt
name: "mymodel"
platform: "tensorrt_plan"
max_batch_size: 32
input [
  {
    name: "input"
    data_type: TYPE_FP32
    dims: [ -1, 3, 224, 224 ]
  }
]
output [
  {
    name: "output"
    data_type: TYPE_FP32
    dims: [ 1000 ]
  }
]

Interview talking point: “A leading minus-one in the input dims means Triton prepends the batch dimension, so clients may send variable batches up to max_batch_size 32 without editing the model config.”

Q946: How do you configure storage class for performance?

What it is: A Kubernetes StorageClass names a provisioner and parameters; this one requests pd-ssd with regional replication and WaitForFirstConsumer binding mode.

Why it is used: To make fast, replicated volumes the standard choice for workloads that request them.

# Kubernetes StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer

Interview talking point: “WaitForFirstConsumer delays provisioning until a pod is scheduled, so the volume lands in the same zone as the workload and avoids cross zone latency.”

Q947: How do you optimize Kubernetes costs?

What it is: Cost optimization sets CPU and memory requests and limits, then applies VPA to right-size pods, HPA to add replicas, and a cluster autoscaler for nodes.

Why it is used: To match spend to actual demand instead of over-provisioning.

# Use Resource Limits
resources:
  limits:
    cpu: "500m"
    memory: "512Mi"
  requests:
    cpu: "200m"
    memory: "256Mi"

# Use VPA
# Vertical Pod Autoscaler

# Use HPA
# Horizontal Pod Autoscaler

# Use cluster autoscaler
# Enable in cloud provider

Interview talking point: “Requests drive scheduling and therefore node count while limits cap usage, so an accurate request is what actually shrinks the cloud bill, not the limit alone.”

Q948: How do you optimize Kubernetes resources?

What it is: Kubernetes resource optimization through requests, limits, HPA auto-scaling, VPA recommendations, and usage monitoring.

Why it is used: Fits pods to real usage so nodes are neither wasted nor starved.

# Kubernetes resource optimization
# 1. Requests
# Set appropriately

# 2. Limits
# Configure

# 3. HPA
# Auto-scale

# 4. VPA
# Recommendations

# 5. Monitoring
# Usage

Interview talking point: “Requests drive scheduling and limits cap usage, so misaligned requests waste node capacity while tight limits invite throttling. The outline adds HPA for scaling and VPA for recommendations, which together suggest better request values.”

Q949: How do you optimize Kubernetes resources?

What it is: Kubernetes resource optimization sets appropriate requests, configures limits, uses HPA for auto-scaling, applies VPA recommendations, and monitors usage.

Why it is used: To maximize cluster efficiency while preventing resource contention.

# Requests
# Set appropriately

# Limits
# Configure

# HPA
# Auto-scale

# VPA
# Recommendations

# Monitoring
# Usage

Interview talking point: “Combining HPA/VPA with accurate requests and limits reduces waste and improves resilience under variable workload patterns.”

Q950: How do you optimize Kubernetes storage?

What it is: Kubernetes storage optimization involves choosing appropriate storage classes, configuring PVCs, enabling snapshots, using Velero for backups, and monitoring storage metrics.

Why it is used: It ensures persistent data remains available and recoverable.

# Storage classes
# Choose

# PVC
# Configure

# Snapshot
# Enable

# Backup
# Velero

# Monitoring
# Metrics

Interview talking point: “Combining snapshots with Velero backups provides both quick restores and durable off-cluster recovery options.”

Q951: How do you optimize Kubernetes?

What it is: Kubernetes optimization sets resource requests and limits, uses affinity for scheduling, chooses a CNI, defines storage classes, and autoscales with HPA and VPA.

Why it is used: To improve cluster density, placement, and responsiveness to load.

# Kubernetes optimization
# 1. Resources
# Requests/limits

# 2. Scheduling
# Affinity

# 3. Networking
# CNI

# 4. Storage
# Classes

# 5. Autoscaling
# HPA/VPA

Interview talking point: “Requests drive scheduling while limits cap usage, so mis-sizing them causes both poor packing across nodes and throttled pods at peak traffic.”

Q952: How do you optimize Kubernetes?

What it is: Kubernetes optimization tunes resources (requests/limits), scheduling with affinity, networking via CNI, storage classes, and autoscaling with HPA/VPA.

Why it is used: To improve workload utilization, performance, and reliability.

# Resources
# Requests/limits

# Scheduling
# Affinity

# Networking
# CNI

# Storage
# Classes

# Autoscaling
# HPA/VPA

Interview talking point: “Right-sizing requests/limits and autoscaling balance efficiency with headroom, while affinity and storage classes affect placement decisions.”

Q953: How do you configure API server security?

What it is: API server security involves configuring RBAC, admission controllers, TLS encryption, network access controls, and secure flags like authorization-mode and admission plugins.

Why it is used: The API server is the central control point, so hardening it prevents unauthorized access and protects all cluster operations.

# Use RBAC
# Enable admission controllers
# Use TLS for all traffic
# Limit network access
# Use API aggregation

# Secure flags
--authorization-mode=RBAC
--enable-admission-plugins=NodeRestriction
--encrypt-provider-config=encryption-config.yaml

Interview talking point: “Admission controllers like NodeRestriction work with RBAC to enforce security boundaries, preventing nodes from modifying objects that don’t belong to them.”

Q954: How do you configure Kubernetes security?

What it is: Kubernetes security layers RBAC roles bound to service accounts, pod security policies restricting privilege, network policies, and Secret objects for credentials.

Why it is used: To apply least privilege to both human users and workloads in the cluster.

# RBAC
kubectl create serviceaccount myapp
kubectl create role myapp-reader --verb=get,list --resource=pods
kubectl create rolebinding myapp-reader-binding --role=myapp-reader --serviceaccount=default:myapp

# Use service account in pod
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  serviceAccountName: myapp
  containers:
  - name: myapp
    image: nginx

# Pod Security Policy
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: RunAsAny

# Network policies
# See previous question

# Secrets
kubectl create secret generic mysecret \
  --from-literal=username=admin \
  --from-literal=password=secret

Interview talking point: “The service account named in the RoleBinding must match the namespace form default:myapp, or the pod identity simply never receives that permission.”

Q955: How do you configure secure container runtime?

What it is: Hardened runtimes include gVisor, Kata Containers and rootless Podman, where podman sets seccomp=default and no-new-privileges on the nginx container.

Why it is used: To limit what a containerized process can do even if the workload turns hostile.

# Use gVisor
# Install runsc

# Use Kata Containers
# Install kata-runtime

# Use Rootless Podman
podman run --security-opt seccomp=default --security-opt no-new-privileges nginx

Interview talking point: “no-new-privileges blocks privilege escalation through setuid binaries, and it is passed as a security option, showing runtime hardening is chosen per container run.”

Q956: How do you implement Kubernetes security?

What it is: Kubernetes security layers RBAC roles and bindings, default-deny network policies, restricted pod security standards per namespace, secrets, Trivy image scanning, and Falco runtime rules.

Why it is used: To limit the blast radius when a workload or image turns out to be compromised.

# Kubernetes security
# 1. RBAC
# Least privilege
kubectl create role pod-reader --verb=get,list --resource=pods
kubectl create rolebinding --role=pod-reader --user=dev

# 2. Network policies
# Default deny
kubectl apply -f network-policy.yaml

# 3. Pod security
# Pod security standards
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted

# 4. Secrets management
# Use Vault or AWS Secrets Manager
kubectl create secret generic mysecret \
  --from-literal=key=value

# 5. Image scanning
trivy image myimage:latest

# 6. Runtime security
# Falco
falco -r rules/myrules.yaml

# 7. API server security
# Disable anonymous auth
# Enable RBAC
# Use TLS

Interview talking point: “The pod-security label sits on the namespace, so the restricted profile is enforced by namespace scope rather than per pod, and Trivy checks images before runtime begins.”

Q957: How do you implement Kubernetes security?

What it is: Kubernetes security implementation involves configuring RBAC, applying network policies, enforcing pod security standards, using external secrets, and integrating security scanning.

Why it is used: It secures container workloads running in Kubernetes clusters.

# RBAC
# Configure

# Network policies
# Apply

# Pod security
# Standards

# Secrets
# External

# Scanning
# Integrate

Interview talking point: “Combining network policies with pod security standards creates layered defenses against both external and internal threats.”

Q958: How do you implement pod security policies?

What it is: A PodSecurityPolicy is a Kubernetes policy resource that restricts pod privileges, such as disallowing privileged containers, controlling users, and limiting host access.

Why it is used: PSPs enforce security constraints on pods to reduce the attack surface and prevent privilege escalation in multi-tenant clusters.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  seLinux:
    rule: RunAsAny
  runAsUser:
    rule: MustRunAsNonRoot
  fsGroup:
    rule: RunAsAny
  volumes:
  - 'secret'
  - 'configMap'
  hostNetwork: false
  hostPID: false
  hostIPC: false

Interview talking point: “By enforcing runAsNonRoot and dropping host access by default, PodSecurityPolicies help prevent containers from escaping to the host or gaining elevated privileges.”

Q959: How do you implement pod security?

What it is: Pod Security Standards define security levels for pods. The restricted profile shown sets a RuntimeDefault seccomp profile, forbids privilege escalation, and drops all capabilities.

Why it is used: To enforce baseline hardening on pods without writing custom policies.

# Pod Security Standards
# Restricted
apiVersion: v1
kind: Pod
metadata:
  name: restricted-pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL

Interview talking point: “readOnlyRootFilesystem, allowPrivilegeEscalation false, and drop ALL stack together to harden the container, and the seccomp profile additionally limits which syscalls the app may invoke.”

Q960: How do you implement runtime security?

What it is: Runtime security involves monitoring container behavior at runtime using tools like Falco to detect suspicious activities such as file access, process execution, or network calls.

Why it is used: Static scanning alone can’t catch malicious behavior once containers are running, making runtime detection essential for active threats.

# Use Falco
kubectl apply -f https://raw.githubusercontent.com/falcosecurity/falco/master/integrations/k8s-using-daemonset/falco-daemonset-configmap.yaml

# Rules
# Detect suspicious activities
# File access, process execution, network calls

Interview talking point: “Falco’s rule-based detection can identify anomalous runtime behavior in real time, allowing teams to respond quickly to potential container compromises.”

Q961: How do you implement service mesh security?

What it is: Service mesh security built on mTLS, authorization policies, automatic encryption, audit logging, and regular updates.

Why it is used: Encrypts and controls service-to-service traffic without changing application code.

# Service mesh security
# 1. mTLS
# Enable

# 2. Authorization
# Policies

# 3. Encryption
# Automatic

# 4. Audit
# Logging

# 5. Updates
# Regular

Interview talking point: “mTLS gives encryption plus identity between services, and authorization policies then decide what each identity may call. Audit logging records those decisions, which is what turns mesh policy into something reviewable.”

Q962: How do you implement service mesh security?

What it is: Service mesh security implementation enables mTLS, applies authorization policies, provides automatic encryption, performs audit logging, and applies regular updates.

Why it is used: To secure service-to-service communication with minimal application changes.

# mTLS
# Enable

# Authorization
# Policies

# Encryption
# Automatic

# Audit
# Logging

# Updates
# Regular

Interview talking point: “mTLS and automatic encryption provide strong defaults, while policy-driven authorization enables fine-grained access control across services.”

Q963: How do you secure cluster upgrades?

What it is: Secure cluster upgrades involve testing in staging, using canary deployments, backing up first, documenting rollback plans, monitoring during upgrades, and upgrading regularly.

Why it is used: Careful upgrade practices prevent downtime and data loss while ensuring security patches are applied promptly.

# Test in staging
# Use canary
# Backup first
# Document rollback plan
# Monitor during upgrade
# Quick rollback if issues

# Best practice
# Upgrade regularly (quarterly)
# Test applications

Interview talking point: “Having a well-tested rollback plan is critical, as even routine upgrades can introduce breaking changes that require immediate reversion.”

Q964: How do you secure container builds?

What it is: Secure container builds focus on reducing attack surface from image creation onward.

Why it is used: It prevents shipping vulnerabilities, secrets, or unnecessary tools in production images.

# Use minimal base images
# Multi-stage builds
# No secrets in images
# Scan for vulnerabilities
# Sign images

# Best practices
# Don't run as root
# Use USER directive
# Remove unnecessary tools

Interview talking point: “Multi-stage builds, minimal base images, and running as non-root are common safeguards to lock down images.”

Q965: How do you secure container orchestration?

What it is: Securing container orchestration involves using RBAC, network policies, PodSecurityPolicies, secrets management, image scanning, runtime security, and regular updates with tools like Kube-bench and Kyverno.

Why it is used: Orchestrators control all workloads, so hardening them prevents cluster-wide compromise and enforces consistent security policies.

# Use RBAC
# Network policies
# Pod security policies
# Secrets management
# Image scanning
# Runtime security
# Regular updates

# Tools
# Kube-bench
# Kubescape
# Kyverno

Interview talking point: “Tools like Kube-bench help validate cluster configurations against CIS benchmarks, identifying misconfigurations before they can be exploited.”

Q966: How do you secure container registry?

What it is: Securing a container registry involves using TLS, authentication, access control, vulnerability scanning, signed images, and regular credential rotation with tools like Harbor and Notary.

Why it is used: The registry is the source of container images, so securing it prevents the distribution and use of compromised or malicious images.

# Use TLS
# Enable authentication
# Use scanning tools
# Implement access control
# Use signed images
# Regular rotation of credentials

# Use Harbor with vulnerability scanning
# Use Notary for content trust

Interview talking point: “Content trust with Notary ensures image integrity by cryptographically verifying that images come from trusted publishers before deployment.”

Q967: How do you secure container runtime?

What it is: Securing the container runtime involves using rootless containers, dropping capabilities, read-only rootfs, no privileged mode, seccomp/AppArmor, and tools like Falco or Sysdig with isolation technologies like gVisor or Kata Containers.

Why it is used: Hardening the runtime prevents container escapes and limits the kernel attack surface available to compromised containers.

# Use rootless containers
# Drop capabilities
# Read-only rootfs
# No privileged mode
# Seccomp/AppArmor

# Runtime security
# Falco, Sysdig

# Isolation
# gVisor, Kata Containers
# User namespaces

Interview talking point: “Using user namespaces with rootless containers or sandboxed runtimes like gVisor adds strong isolation, though each approach comes with different performance trade-offs.”

Q968: How do you secure container runtime?

What it is: Securing the container runtime means restricting what containers can do on the host.

Why it is used: It prevents container escapes and limits host compromise if a container is breached.

# Use rootless
# Drop capabilities
# Read-only rootfs

# Seccomp/AppArmor
# Profile

# Runtime security
# Falco, Sysdig

# Isolation
# gVisor, Kata

Interview talking point: “Techniques like rootless containers, dropping capabilities, read-only rootfs, seccomp/AppArmor, and runtime tools like Falco add critical layers.”

Q969: How do you secure container runtime?

What it is: Securing the container runtime restricts container capabilities and host interactions.

Why it is used: It limits the impact of a compromised container on the underlying host.

# Rootless containers
# Drop capabilities
# Read-only rootfs
# No privileged mode
# Seccomp/AppArmor

# Runtime security
# Falco, Sysdig

# Isolation
# gVisor, Kata

Interview talking point: “Rootless containers, dropping all capabilities, read-only rootfs, no privileged mode, seccomp/AppArmor, and tools like Falco or Sysdig are effective controls.”

Q970: How do you secure containerized applications?

What it is: Container security uses minimal base images with no embedded secrets, non-root users, read-only root filesystems, resource limits, network policies, RBAC, and a secrets manager instead of env vars.

Why it is used: To limit what an attacker gains from a compromised container.

# Container security
# 1. Images
# Minimal base
# No secrets in images
# Scan for vulnerabilities

# 2. Runtime
# Non-root user
# Read-only root
# Resource limits

# 3. Network
# Network policies
# Service mesh

# 4. Orchestrator
# RBAC
# Pod security policies

# 5. Secrets
# Use secrets manager
# Don't use env vars

# Tools
# Trivy
# Falco
# OPA

Interview talking point: “Environment variables leak secrets through process listings and logs, so the record prefers a secrets manager, paired with Trivy for image scans and Falco for runtime detection.”

Q971: How do you secure containers in production?

What it is: Container hardening uses a read-only root filesystem, drops all Linux capabilities, runs as a non-root user, and scans images for vulnerabilities.

Why it is used: To limit the damage if a container is compromised.

# Use read-only root filesystem
securityContext:
  readOnlyRootFilesystem: true

# Drop capabilities
securityContext:
  capabilities:
    drop:
    - ALL

# Run as non-root
securityContext:
  runAsNonRoot: true
  runAsUser: 10000

# Use image scanning
trivy image nginx:latest

Interview talking point: “Dropping ALL capabilities and running as UID 10000 removes root-level kernel access, while trivy image checks known CVEs before the image is ever shipped.”

Q972: How do you secure containers?

What it is: Container hardening flags run as a non-root UID, mount read-only, block privilege escalation, drop all capabilities and add back only what is needed, plus apply AppArmor or seccomp profiles.

Why it is used: To limit what an attacker can do if a container process is compromised.

# Run as non-root
docker run -u 1000:1000 nginx

# Read-only
docker run --read-only nginx

# No new privileges
docker run --security-opt no-new-privileges:true nginx

# Drop capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

# AppArmor
docker run --security-opt apparmor=profile nginx

# Seccomp
docker run --security-opt seccomp=default nginx

Interview talking point: “cap-drop ALL followed by cap-add NET_BIND_SERVICE is the least-privilege pattern, since the process can still bind port 80 without keeping a full capability set.”

Q973: How do you secure containers?

What it is: Container hardening through a non-login daemon user, the default seccomp profile, an AppArmor profile, and dropping all capabilities then adding back only NET_BIND_SERVICE.

Why it is used: Limits what a compromised container can do on the host.

# Rootless
usermod -r -s /usr/sbin/nologin dockremap

# Seccomp
docker run --security-opt seccomp=default nginx

# AppArmor
docker run --security-opt apparmor=profile nginx

# Capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

Interview talking point: “Dropping ALL then adding a single capability is the allowlist pattern, since binding port 80 is the only privilege this nginx container actually needs.”

Q974: How do you secure containers?

What it is: Container hardening through pinned image tags, a dedicated non-root user with owned files, read-only filesystems, dropped capabilities, resource limits, and image scanning.

Why it is used: To limit what a compromised container can do and catch vulnerable images early.

# Use specific version
FROM nginx:1.25-alpine

# Create non-root user
RUN addgroup -g 1000 -S appgroup && \
    adduser -u 1000 -S appuser -G appgroup

# Set ownership
COPY --chown=appuser:appgroup . /usr/share/nginx/html

USER appuser

# Read-only filesystem
# docker run --read-only nginx

# Drop capabilities
# docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

# Limit resources
# docker run --memory=256m --cpus=0.5 nginx

# Scan images
trivy image myimage
docker scan myimage

Interview talking point: “cap-drop ALL with a single cap-add back for binding privileged ports follows least privilege, and pinning a tag like 1.25-alpine prevents surprise upgrades during rebuilds.”

Q975: How do you secure containers?

What it is: Container security covers minimal scanned images with no baked secrets, non-root and read-only runtime, resource limits, network policies, RBAC, and a secrets manager.

Why it is used: To limit what an attacker gains from compromising a container.

# Images
# Minimal base
# No secrets
# Scan for vulnerabilities

# Runtime
# Non-root user
# Read-only root
# Resource limits

# Network
# Network policies
# Service mesh

# Orchestrator
# RBAC
# Pod security

# Secrets
# Use secrets manager

Interview talking point: “The runtime choices compound: non-root plus a read-only root filesystem plus resource limits means a compromised process cannot write, escalate, or starve the node.”

Q976: How do you secure Docker containers?

What it is: Container hardening runs as a non-root user, uses a read-only root filesystem, drops all capabilities except needed ones, applies seccomp and AppArmor, and blocks privilege escalation.

Why it is used: To limit what a compromised container can do to the host.

# Run as non-root
docker run -u 1000:1000 nginx

# Read-only root filesystem
docker run --read-only nginx

# Limit capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

# Seccomp profile
docker run --security-opt seccomp=default nginx

# AppArmor profile
docker --security-opt apparmor=docker-default nginx

# No new privileges
docker run --security-opt no-new-privileges:true nginx

# Scan images
docker scan nginx

# Use rootless Docker
dockerd-rootless.sh

Interview talking point: “Dropping ALL capabilities and adding back only NET_BIND_SERVICE is the practical least-privilege pattern, so the container can still bind port 80 and nothing more.”

Q977: How do you secure Docker containers?

What it is: Container hardening runs as a non-root UID, mounts the filesystem read-only, drops all capabilities then adds back only the needed ones, and scans images for CVEs.

Why it is used: To shrink the blast radius if a container or its image is compromised.

# Run as non-root
docker run -u 1000:1000 nginx

# Read-only filesystem
docker run --read-only nginx

# Limit capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

# Disable networking
docker run --network none nginx

# Scan images
docker scan nginx
trivy image nginx

# Best practices in Dockerfile
FROM ubuntu:22.04
RUN useradd -m appuser
USER appuser

Interview talking point: “cap-drop ALL followed by cap-add NET_BIND_SERVICE keeps only the ability to bind low ports instead of leaving broad privileges. A USER directive in the Dockerfile makes non-root the default rather than just a run flag.”

Q978: How do you secure Docker containers?

What it is: Container hardening runs as a non-root uid, uses a read-only filesystem, drops all capabilities then adds back only needed ones, limits memory and CPUs, and scans images.

Why it is used: To contain a breach so an attacker inside one container gains little.

# Run as non-root
docker run -u 1000:1000 nginx

# Read-only filesystem
docker run --read-only nginx

# Limit capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE nginx

# Disable networking
docker run --network none nginx

# Resource limits
docker run --memory=256m --cpus=0.5 nginx

# Selinux/AppArmor
docker run --security-opt seccomp:default nginx

# Scan images
trivy image nginx
docker scan nginx

# Best practices
# Use specific versions
# Don't store secrets in images
# Multi-stage builds
# Minimal base images

Interview talking point: “cap-drop ALL removes every Linux capability and cap-add NET_BIND_SERVICE restores just the one needed to bind port 80 as uid 1000, a common minimal-permission pattern.”

Q979: How do you secure etcd communication?

What it is: Securing etcd communication involves using TLS certificates with a CA, server, and client certificates configured on both etcd and the API server.

Why it is used: Encrypted etcd traffic prevents eavesdropping and man-in-the-middle attacks between the control plane and the key-value store.

# Use TLS
# etcd-ca.pem
# etcd-server.pem
# etcd-client.pem

# Configure API server
# --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
# --etcd-certfile=/etc/kubernetes/pki/etcd/server.crt
# --etcd-keyfile=/etc/kubernetes/pki/etcd/server.key

Interview talking point: “Using separate client certificates for the API server ensures mutual TLS authentication, restricting which clients can establish connections to etcd.”

Q980: How do you secure etcd?

What it is: etcd security uses TLS, encryption at rest, authentication and a dedicated cluster; etcdctl snapshot save captures a backup with CA, cert and key.

Why it is used: To protect and back up the datastore holding every Kubernetes object.

# Use TLS
# Enable encryption at rest
# Use separate etcd cluster
# Enable authentication

# Backup etcd
ETCDCTL_API=3 etcdctl snapshot save backup.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key

Interview talking point: “The snapshot command sets ETCDCTL_API=3 and passes endpoint with cacert, cert and key, showing backups travel over the same TLS identity as normal traffic.”

Q981: How do you secure etcd?

What it is: Securing etcd involves using TLS for communication, enabling encryption at rest, running a separate etcd cluster, and requiring authentication with regular backups.

Why it is used: These measures protect the cluster’s key-value store that holds all Kubernetes state and sensitive configuration data.

# Use TLS for etcd
# Enable encryption at rest
# Use separate etcd cluster
# Enable authentication
# Backup regularly

Interview talking point: “Since etcd contains the entire cluster state, encrypting it at rest and using TLS is critical because a compromise of etcd means full control of the Kubernetes cluster.”

Q982: How do you secure kubelet?

What it is: Securing kubelet involves configuring its authentication and authorization settings in its config file to disable anonymous access and use webhook authorization.

Why it is used: Since kubelet exposes an API on each node, hardening it prevents unauthorized access to node-level operations and pod management.

# Configure kubelet
authentication:
  anonymous:
    enabled: false
  webhook:
    enabled: true
authorization:
  mode: Webhook

# Use Node Authorizer
# Enable NodeRestriction admission plugin

Interview talking point: “Disabling anonymous access and using Webhook mode with NodeRestriction ensures only authorized requests from the API server can interact with the kubelet.”

Q983: How do you secure Kubernetes API?

What it is: Securing the API server means running authorization-mode=RBAC, giving service accounts minimal permissions, and serving all traffic over TLS with network limits.

Why it is used: To prevent unauthorized access to the control plane, which carries full cluster power.

# Use RBAC
# Create ServiceAccount with minimal permissions

# Enable RBAC
--authorization-mode=RBAC

# Use TLS
# Ensure all traffic uses TLS

# Network policies
# Limit access to API server

Interview talking point: “RBAC works through roles bound to subjects, so the practical step is granting a ServiceAccount only the verbs and resources it truly needs.”

Q984: How do you secure Kubernetes API?

What it is: Securing the Kubernetes API involves using RBAC, limiting access, enabling TLS and audit logging, using admission controllers, avoiding public exposure, and implementing rate limiting.

Why it is used: The API is the primary entry point to the cluster, so hardening it prevents unauthorized control and data access.

# Use RBAC
# Limit access
# Use TLS
# Enable audit logging
# Use admission controllers

# Don't expose publicly
# Use VPN/bastion

# Use API aggregation
# Rate limiting

Interview talking point: “Restricting API access to VPNs or bastions and using API aggregation with rate limiting helps protect against brute force and abuse.”

Q985: How do you secure Kubernetes API?

What it is: Securing the Kubernetes API means restricting and monitoring all API requests.

Why it is used: It prevents unauthorized cluster modifications from internal or external actors.

# Use RBAC
# Limit access

# Use TLS
# Enable audit logging

# Admission controllers
# NodeRestriction

# Don't expose publicly
# Use VPN

# Rate limiting

Interview talking point: “Combining RBAC, TLS, audit logging, admission controllers like NodeRestriction, and rate limiting helps harden API access.”

Q986: How do you secure Kubernetes dashboard?

What it is: Securing the Kubernetes Dashboard involves restricting public exposure, enforcing RBAC, enabling HTTPS, using token authentication, enabling audit logs, and limiting IP access.

Why it is used: The dashboard provides broad cluster management capabilities, so hardening it prevents unauthorized administrative access.

# Don't expose publicly
# Use RBAC
# Enable HTTPS
# Use token authentication
# Enable audit logging
# Restrict IP access

# Best practice
# Use kubectl proxy or VPN

Interview talking point: “Using kubectl proxy or a VPN to access the dashboard avoids exposing it directly to the internet, significantly reducing its attack surface.”

Q987: How do you secure Kubernetes networking?

What it is: Kubernetes networking security involves using NetworkPolicies with default-deny and explicit allow rules, often combined with a service mesh for additional controls.

Why it is used: Proper network controls prevent lateral movement and restrict traffic between services to only what is necessary.

# Use NetworkPolicies
# Default deny
# Allow explicit
# Use service mesh

# Examples
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: web-to-api
spec:
  podSelector:
    matchLabels:
      app: api
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web

Interview talking point: “NetworkPolicies can be used alongside a service mesh, but they operate at different layers and together provide defense in depth for pod-to-pod communication.”

Q988: How do you secure Kubernetes networking?

What it is: Kubernetes networking security involves default-deny policies, explicit allow rules, NetworkPolicies, service mesh with mTLS, TLS for ingress, VPNs for internal access, and CNIs like Calico, Cilium, or Canal.

Why it is used: These controls encrypt and restrict network traffic to prevent eavesdropping and lateral movement between workloads.

# Default deny
# Explicit allow
# Use NetworkPolicies

# Service mesh
# mTLS everywhere

# Encryption
# TLS for ingress
# VPN for internal

# Tools
# Calico, Cilium, Canal

Interview talking point: “Choosing a CNI with advanced features like eBPF can enhance network policy enforcement and observability while maintaining performance.”

Q989: How do you secure Kubernetes networking?

What it is: Securing Kubernetes networking controls traffic flow between pods, services, and external endpoints.

Why it is used: It prevents lateral movement and limits exposure to external threats.

# Default deny
# Explicit allow
# Use NetworkPolicies

# Service mesh
# mTLS

# Encryption
# TLS for ingress

# Tools
# Calico, Cilium

Interview talking point: “Default-deny NetworkPolicies, explicit allow rules, mTLS via service mesh, TLS for ingress, and CNIs like Calico or Cilium enforce secure traffic patterns.”

Q990: How do you secure Kubernetes secrets?

What it is: Securing Kubernetes secrets means protecting sensitive data beyond simple base64 encoding.

Why it is used: It prevents unauthorized access and reduces the risk of credential leaks.

# Don't use base64 encoding alone
# Use encryption at rest

# Use external secrets
# HashiCorp Vault
# AWS Secrets Manager

# Rotate regularly
# Audit access

# Use SealedSecrets
# Use SOPS

Interview talking point: “External secret stores like Vault or AWS Secrets Manager, combined with rotation and audit logging, add critical layers of protection.”

Q991: How do you secure Kubernetes workloads?

What it is: Securing Kubernetes workloads involves configuring pod and container security contexts with runAsNonRoot, non-root users, fsGroup, disallowing privilege escalation, read-only rootfs, and dropping all capabilities.

Why it is used: These settings enforce secure defaults at the workload level, reducing the impact of container compromises.

# Pod security context
securityContext:
  runAsNonRoot: true
  runAsUser: 10000
  fsGroup: 2000

# Container security
securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
    - ALL

Interview talking point: “Dropping all capabilities and setting read-only root filesystems together form a strong baseline that prevents many common privilege escalation vectors.”

Q992: How do you secure Kubernetes workloads?

What it is: Securing Kubernetes workloads involves configuring strict Pod and container security contexts.

Why it is used: It prevents privilege escalation and limits filesystem and capability access.

# Pod security context
securityContext:
  runAsNonRoot: true
  runAsUser: 10000
  fsGroup: 2000

# Container security
securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
    - ALL

Interview talking point: “Key settings include runAsNonRoot, specific user IDs, fsGroup, allowPrivilegeEscalation false, readOnlyRootFilesystem, and dropping all capabilities.”

Q993: How do you secure Kubernetes?

What it is: Kubernetes security measures: a rolebinding granting the admin cluster role to the developers group, a network policy, secrets encryption at rest, and pod security admission.

Why it is used: Restricts what users and pods can do inside the cluster.

# RBAC
kubectl create rolebinding admin --clusterrole=admin --group=developers

# Network policies
kubectl apply -f network-policy.yaml

# Secrets encryption
# Enable encryption at rest

# Pod security
# Use PodSecurityPolicy or Admission Controller

Interview talking point: “A rolebinding maps an existing cluster role to a group, so revoking developer access is one binding change without editing the role’s rules.”

Q994: How do you secure Kubernetes?

What it is: Securing Kubernetes means RBAC least privilege, default-deny network policies, pod security standards, externally stored secrets, image scanning, Falco runtime monitoring, and regular version updates.

Why it is used: To defend every layer of the cluster from the API server down to runtime.

# Kubernetes security
# 1. RBAC
# Least privilege

# 2. Network policies
# Default deny

# 3. Pod security
# Standards

# 4. Secrets
# External

# 5. Images
# Scanning

# 6. Runtime
# Falco

# 7. Updates
# Regular

Interview talking point: “The same layering as container security recurs here, and keeping Kubernetes updated matters because API server fixes cannot be compensated for by tightening a network policy.”

Q995: How do you secure Kubernetes?

What it is: Kubernetes security involves controlling access, restricting network traffic, securing workloads, and protecting container images.

Why it is used: It prevents unauthorized access and reduces the risk of exploiting cluster resources.

# RBAC
# Least privilege

# Network policies
# Default deny

# Pod security
# Standards

# Secrets
# External

# Images
# Scanning

# Runtime
# Falco

# Updates
# Regular

Interview talking point: “A default deny network policy with least privilege RBAC creates strong boundaries between workloads and limits lateral movement.”

Q996: How do you secure storage?

What it is: Storage security involves encrypting data with LUKS or dm-crypt, implementing access controls via RBAC and ACLs, securing backups with encryption and offsite storage, and using Kubernetes CSI encryption.

Why it is used: These measures protect data confidentiality and availability while ensuring recoverability after loss or compromise.

# Encryption
# LUKS, dm-crypt

# Access control
# RBAC, ACLs

# Backups
# Encrypted backups
# Offsite storage

# Kubernetes
# CSI encryption
# Secrets encryption
# Encrypted volumes

Interview talking point: “Encrypting backups is just as critical as encrypting live volumes, as backup data often contains the same sensitive information.”

Q997: How do you secure storage?

What it is: Securing storage involves encrypting data and controlling access to volumes and backups.

Why it is used: It protects sensitive data from unauthorized access or exposure if compromised.

# Encryption
# LUKS, dm-crypt

# Access control
# RBAC, ACLs

# Backups
# Encrypted backups

# Kubernetes
# CSI encryption
# Secrets encryption

Interview talking point: “Using LUKS/dm-crypt, RBAC/ACLs, encrypted backups, Kubernetes CSI encryption, and encrypted secrets at rest are essential controls.”

Q998: How do you secure the API server?

What it is: Securing the Kubernetes API server involves controlling access and auditability.

Why it is used: It protects the control plane, which can modify any cluster resource.

# Use RBAC
# Enable TLS
# Use strong authentication

# Don't expose publicly
# Use VPN

# Enable audit logging
# Monitor access

# Use admission controllers
# Limit what can be created

Interview talking point: “RBAC, TLS, strong authentication, admission controllers, and audit logging are essential to lock down API access.”

Q999: How do you secure the API server?

What it is: Securing the Kubernetes API server requires strong authentication, authorization, and auditing.

Why it is used: It protects the control plane from unauthorized access and modifications.

# Use RBAC
# Enable TLS
# Use strong auth

# Don't expose publicly
# Use VPN

# Enable audit logging
# Monitor access

# Use admission controllers

Interview talking point: “RBAC, TLS, strong auth mechanisms, avoiding public exposure (via VPN/bastion), audit logging, and admission controllers are critical controls.”

Q1000: How do you secure the cluster?

What it is: Securing a Kubernetes cluster involves hardening both control plane and nodes.

Why it is used: It protects all workloads and prevents cluster-wide compromise.

# Use RBAC
# Network policies

# Encrypt etcd
# Enable audit logging

# Update regularly
# Use CIS benchmarks

# Monitor
# Use Falco

# Use secrets management

Interview talking point: “Key measures include RBAC, NetworkPolicies, etcd encryption, audit logging, CIS benchmarks, and runtime monitoring with Falco.”