Kubernetes Interview Questions and Answers

Kubernetes interviews test whether you can run containerized workloads reliably at scale—not recite every kubectl alias.

Expect probe differences, Service types, Pending pod debugging, and HPA with metrics-server in most Kubernetes screens.

Kubernetes does not require Docker—it needs a CRI-compatible runtime (containerd, CRI-O). Docker builds images; Kubernetes schedules and operates them.

Docker and kubernetes interview questions often start with "what problem does K8s solve that Docker alone does not?"—answer: desired state reconciliation across many nodes.

LinkedIn scenario-based guides and RisingStack-style lists emphasize spoken troubleshooting narratives—describe commands before typing them.

Use minikube, kind, or a cloud free tier—hands-on beats flashcards.

Advanced kubernetes interview questions focus on failure modes: metrics-server down during traffic spike, NetworkPolicy blocking DNS, readiness passing while app is broken.

A Docker image is the packaged, immutable artifact. A container is a running instance of that image.

Images are built in layers. When a container starts, the runtime creates a unified filesystem view from those layers and adds a thin writable layer for runtime changes.

Example:

docker build -t myapp:v1 .
docker run myapp:v1

In Kubernetes, you do not normally create containers manually. You declare an image in the Pod spec, and the kubelet asks the container runtime to pull and start it.

spec:
  containers:
  - name: api
    image: registry.example.com/myapp:v1

Important interview points:

• Image is the artifact you build and push
• Container is what actually runs
• Container filesystem changes are not permanent unless stored in a volume
• Same image can run many containers
• Kubernetes schedules Pods, and containers run inside Pods
• Container logs, writable layer, and process lifecycle are separate from the image

Common trap:

“A container is not a lightweight VM. It is an isolated process using kernel features like namespaces and cgroups.”

A strong answer is:

“An image is the immutable package made of layers. A container is a running process created from that image with its own writable layer, runtime isolation, environment, network, and mounts.”

A Dockerfile describes how to build a container image.

Common instructions:

Prefer COPY over ADD unless you specifically need ADD behavior.

A common production pattern is a multi-stage build. Build tools stay in the builder stage, and the final image contains only what is needed to run.

FROM golang:1.22 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app .

FROM gcr.io/distroless/static-debian12
COPY --from=build /app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

Good Dockerfile practices:

• Use multi-stage builds
• Keep final image small
• Run as non-root where possible
• Do not copy secrets into the image
• Use .dockerignore
• Pin base image versions or digests for production
• Put dependency download steps before copying full source to improve cache reuse
• Prefer exec form for ENTRYPOINT/CMD
• Avoid installing unnecessary packages
• Scan images for vulnerabilities in CI

CMD vs ENTRYPOINT interview angle:

Example:

ENTRYPOINT ["/app"]
CMD ["--config", "/etc/app/config.yaml"]

A strong answer is:

“A Dockerfile builds an image layer by layer. For production, I use multi-stage builds, a small runtime image, non-root user, .dockerignore, no embedded secrets, and pinned base images for reproducible Kubernetes deployments.”

Docker Compose and Kubernetes both run containerized applications, but they are used at different scales and for different workflows.

Compose example use:

• App + database + Redis locally
• Developer laptop setup
• Integration test environment
• Small internal demo stack

Kubernetes example use:

• Production deployment
• Rolling updates
• Horizontal scaling
• Self-healing through controllers
• Service discovery through cluster DNS
• Config/Secret management
• RBAC and admission policies
• Multi-node scheduling

Compose is not “bad.” It is excellent for local developer experience. But it does not replace Kubernetes for large production environments with scheduling, rollout strategy, cluster policies, and high availability requirements.

A common workflow:

Dockerfile
  → Docker Compose for local dev
  → CI builds image
  → Helm/Kustomize deploys to Kubernetes

Interview trap:

“Do not say Compose is only for beginners. Many professional teams use it for local development even when production is Kubernetes.”

A strong answer is:

“I use Compose for local multi-container development and simple test stacks. I use Kubernetes when I need production orchestration, self-healing, rolling updates, scaling, service discovery, and cluster-level policy.”

Kubernetes does not talk directly to Docker Engine in modern clusters. The kubelet talks to a container runtime through the Container Runtime Interface (CRI).

Common CRI runtimes:

Important history:

• Older Kubernetes versions used dockershim to support Docker Engine as a runtime
• Dockershim was removed in Kubernetes v1.24
• Kubernetes still runs Docker-built images because images follow OCI/container image standards
• Docker itself uses containerd internally, but Kubernetes talks to CRI-compatible runtimes

Node-level debugging:

Example node debugging:

crictl ps
crictl images
crictl logs <container-id>

Interview trap:

“Kubernetes removed Docker” does not mean Docker images stopped working. It means Kubernetes removed the in-tree dockershim runtime integration.

A strong answer is:

“The kubelet uses CRI to talk to runtimes such as containerd or CRI-O. Docker is still widely used to build images, but modern Kubernetes clusters do not depend on Docker Engine through dockershim.”

OCI stands for Open Container Initiative. OCI specifications help image builders, registries, and runtimes interoperate.

Important terms:

Examples of registries:

• Docker Hub
• Amazon ECR
• Azure Container Registry
• Google Artifact Registry
• GitHub Container Registry
• Harbor
• Quay

Tag vs digest is important in production.

Kubernetes private registry example:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  imagePullSecrets:
  - name: regcred
  containers:
  - name: api
    image: registry.example.com/team/api:v1.2.3

Digest-pinned production example:

containers:
- name: api
  image: registry.example.com/team/api:v1.2.3@sha256:abc123...

Production interview points:

• Avoid latest in production
• Use private registry credentials through imagePullSecrets or service account configuration
• Pin digests for exact rollbacks and reproducible deploys
• Scan images for vulnerabilities
• Sign images if supply-chain security is required
• Keep SBOM/provenance where required
• Use immutable tags or registry policies if supported

Common pull errors:

A strong answer is:

“OCI standards let different tools build, store, and run container images consistently. In production, I push images to a registry, avoid latest, use imagePullSecrets for private registries, and pin digests when I need exact reproducibility and rollback.”

A Kubernetes cluster has two main parts:

• Control plane — decides what should happen
• Worker nodes — run application workloads as Pods

Control plane components:

Worker node components:

High-level flow when you create a Deployment:

1. User runs kubectl apply
2. Request goes to kube-apiserver
3. API server authenticates, authorizes, admits, and stores desired state in etcd
4. Deployment controller creates/updates ReplicaSets
5. ReplicaSet controller creates Pods
6. Scheduler assigns Pods to nodes
7. Kubelet on each node asks the runtime to start containers
8. Service/CNI networking makes Pods reachable

Kubernetes is declarative. You define desired state, and controllers continuously reconcile actual state toward that desired state.

Example:

kubectl apply -f deployment.yaml

You are not directly starting containers. You are asking the Kubernetes API to store desired state. Controllers, scheduler, kubelet, CNI, and runtime do the rest.

Good troubleshooting mindset:

A strong answer is:

“Kubernetes has a control plane that stores and reconciles desired state, and worker nodes that run Pods. The API server and etcd hold the source of truth, controllers create/update objects, the scheduler places Pods, and kubelets start containers through the runtime.”

etcd is the strongly consistent key-value store used by Kubernetes to store cluster state.

It stores Kubernetes objects such as:

• Pods
• Deployments
• Services
• ConfigMaps
• Secrets
• Nodes
• RBAC objects
• Custom resources

Important properties:

If etcd loses quorum:

• Existing Pods may keep running
• New scheduling may fail
• Deployments/rollouts may not progress
• API writes may fail
• Controllers cannot persist new state

Important Secrets detail:

Kubernetes Secrets are stored in etcd. They are only base64-encoded by default, not automatically safe encryption. For stronger protection, enable encryption at rest and protect etcd backups.

Backup example concept:

ETCDCTL_API=3 etcdctl snapshot save snapshot.db

In managed Kubernetes, the cloud provider usually manages etcd. In self-managed clusters, etcd backup, restore, quorum, TLS, disk performance, and monitoring are platform-critical responsibilities.

Good SRE-level metrics:

• etcd leader changes
• fsync latency
• database size
• request latency
• quorum/member health
• disk space
• snapshot success

A strong answer is:

“etcd is Kubernetes’ source of truth. If etcd is unhealthy or loses quorum, the cluster may keep existing workloads running but cannot reliably schedule, update, or persist new state. That is why etcd backup, encryption, quorum, and monitoring are critical.”

kube-apiserver is the front door of Kubernetes.

Every major Kubernetes interaction goes through the API server:

• kubectl
• Controllers
• Scheduler
• Admission webhooks
• Operators
• CI/CD systems
• GitOps tools

The API server is responsible for:

Typical request path:

kubectl / controller / operator
  → kube-apiserver
  → authentication
  → authorization
  → admission
  → validation
  → etcd

kubectl is only a client. It does not directly create containers or modify nodes. It sends requests to the API server.

Useful interview commands:

kubectl auth can-i create pods -n dev

kubectl create deployment demo-nginx \
  --image=nginx:1.27 \
  --dry-run=client \
  -o yaml

kubectl apply --server-side -f deployment.yaml

Client dry-run is useful for generating manifests. Server-side dry-run is better when you want API server validation and admission behavior without persisting the object.

kubectl apply -f deployment.yaml --dry-run=server

Common API server related failures:

A strong answer is:

“The API server is the only supported gateway for cluster state changes. It authenticates, authorizes, admits, validates, and persists objects to etcd, while clients and controllers interact through its REST/watch API.”

The Kubernetes scheduler assigns Pods to nodes.

It watches for Pods where spec.nodeName is not set, then selects a suitable node based on resources, constraints, and scheduling policy.

Common scheduling factors:

Simple scheduling idea:

Filter nodes that cannot run the Pod
→ score remaining nodes
→ bind Pod to selected node

A Pod remains Pending when no suitable node is found or a required dependency is not ready.

Common Pending causes:

Best first command:

kubectl describe pod <pod-name> -n <namespace>

Then read the Events section.

Important distinction:

• Scheduler chooses a node
• Kubelet starts containers after the Pod is assigned
• Image pull, volume mount, and container start errors are usually kubelet/runtime phase issues, not scheduler issues

Example:

kubectl get pod -o wide

If NODE is empty, scheduling has not succeeded. If NODE is set but the Pod is not running, check kubelet/runtime/image/volume/probe events.

A strong answer is:

“The scheduler watches unscheduled Pods, filters nodes based on resources and constraints, scores suitable nodes, and binds the Pod. When a Pod is Pending, I check Events for resource, taint, affinity, topology, or PVC-related failures.”

Kubernetes controllers are control loops. They watch current cluster state, compare it with desired state, and take action to move the system closer to the desired state.

Basic control loop idea:

observe current state
→ compare with desired state
→ create/update/delete objects
→ repeat

Common controllers:

Deployment example:

1. You update the Deployment image
2. Deployment controller creates a new ReplicaSet
3. New ReplicaSet scales up new Pods
4. Old ReplicaSet scales down old Pods
5. Rollout completes if readiness checks pass

Useful rollout commands:

kubectl rollout status deployment/api -n prod

kubectl rollout history deployment/api -n prod

kubectl rollout undo deployment/api -n prod

Important ownership relationship:

Deployment
  → ReplicaSet
    → Pods

You normally edit the Deployment, not the ReplicaSet or Pods directly. If you delete a Pod managed by a ReplicaSet, the controller creates a replacement.

Different workload controllers solve different problems:

Custom controllers/operators extend the same idea for application-specific resources. For example, an operator can watch a custom resource and reconcile database clusters, certificates, backups, or Helm releases.

A strong answer is:

“Controllers are reconciliation loops. They watch desired and actual state, then create, update, or delete resources to converge. For normal apps, I change the Deployment and let ReplicaSets and Pods be managed by controllers.”

A Pod is the smallest deployable compute object in Kubernetes.

A Pod wraps one or more containers that are scheduled together on the same node and share some runtime resources.

Containers inside the same Pod share:

• Network namespace — one Pod IP; containers communicate using localhost
• Storage volumes — containers can mount the same volume
• Scheduling — all containers in the Pod run on the same node
• Lifecycle — the Pod is created, scheduled, and terminated as one unit

Most application Pods run one main container.

Multi-container Pods are used when containers must work closely together:

Example Pod:

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

Important interview point: bare Pods are rarely used for production apps because Pods are ephemeral. If a node fails or a Pod is deleted, you usually want a controller such as a Deployment, StatefulSet, DaemonSet, Job, or CronJob to create replacements.

Common Pod facts:

• A Pod gets its own IP address
• Containers in the same Pod share that IP
• Containers in different Pods communicate through Pod IPs or Services
• Pod IP can change when the Pod is recreated
• Persistent data should use volumes, not the container writable layer
• A Pod is not the same as a container; it is a wrapper around one or more containers

A strong answer is:

“A Pod is Kubernetes’ smallest schedulable unit. It gives one or more containers a shared network namespace, optional shared volumes, and a common lifecycle. For production, I usually manage Pods through controllers, not bare Pod manifests.”

A Deployment, ReplicaSet, and Pod are related, but they operate at different levels.

Ownership chain:

Deployment
  → ReplicaSet
    → Pods

You normally create a Deployment, not a ReplicaSet directly.

Example Deployment behavior:

1. You create a Deployment with replicas: 3
2. Deployment creates a ReplicaSet
3. ReplicaSet creates 3 Pods
4. If a Pod dies, ReplicaSet creates a replacement
5. If you update the image, Deployment creates a new ReplicaSet
6. Old ReplicaSet scales down while new ReplicaSet scales up

Common rollout strategies:

Rolling update example:

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

Meaning:

maxUnavailable: 0 helps keep capacity during rollout, but the rollout may stall if new Pods cannot become Ready. Always combine rollout strategy with correct readiness probes and capacity planning.

Useful commands:

kubectl rollout status deployment/api
kubectl rollout history deployment/api
kubectl rollout undo deployment/api

Common interview mistake: editing or deleting Pods directly. If a Pod is managed by a ReplicaSet, manual Pod changes are temporary. The controller will recreate or replace Pods based on the desired state.

A strong answer is:

“A Pod runs containers, a ReplicaSet keeps the desired number of Pods, and a Deployment manages ReplicaSets for rolling updates and rollback. In normal application deployments, I change the Deployment and let controllers handle Pod replacement.”

Use a StatefulSet when each Pod needs a stable identity or stable storage.

A StatefulSet provides:

Example use cases:

• Databases
• Kafka brokers
• ZooKeeper
• Elasticsearch/OpenSearch
• Redis cluster members
• Stateful queue/broker systems

Deployment vs StatefulSet:

StatefulSet Pods have predictable names:

mysql-0
mysql-1
mysql-2

With a headless Service, each Pod can get stable DNS such as:

mysql-0.mysql.default.svc.cluster.local
mysql-1.mysql.default.svc.cluster.local

Important storage point: if a StatefulSet Pod is rescheduled, Kubernetes can attach the same PVC to the replacement Pod with the same identity.

Do not use StatefulSet just because an app writes files. Many apps should store state in external databases/object storage and run as stateless Deployments.

A strong answer is:

“I use StatefulSet when Pod identity and storage must be stable across rescheduling, such as databases or brokers. For stateless APIs where replicas are interchangeable, I use Deployment.”

DaemonSet, Job, and CronJob solve different workload problems.

DaemonSet:

• Ensures each selected node runs a copy of a Pod
• Adds Pods when nodes are added
• Removes Pods when nodes are removed
• Common for node-level agents

Examples:

Fluent Bit
node-exporter
CNI agents
storage plugins
security agents

Job:

• Creates one or more Pods
• Retries failed Pods depending on backoffLimit
• Completes when the required number of successful completions is reached

CronJob:

• Creates Jobs on a schedule
• Uses cron syntax
• Good for repeated batch tasks

Example CronJob idea:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-cleanup
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: cleanup
            image: registry.example.com/cleanup:v1

Important interview points:

• Use restartPolicy: OnFailure or Never for Jobs, not Always
• Use backoffLimit to control retries
• Use concurrencyPolicy for CronJobs when overlapping runs are dangerous
• Use ttlSecondsAfterFinished if completed Job cleanup is needed
• DaemonSets may need tolerations to run on tainted nodes
• Control-plane nodes usually require explicit tolerations if you want DaemonSet Pods there

Common mistake:

Running a database migration as a bare Pod without thinking about retries, restart policy, idempotency, or whether it can run twice.

A strong answer is:

“I use DaemonSet for node-level agents, Job for run-to-completion tasks, and CronJob for scheduled Jobs. For batch work, I think carefully about restart policy, backoff, idempotency, and cleanup.”

A Pod has a high-level phase, and each container inside the Pod has a more detailed state.

Pod phases:

Container states:

Common container waiting/terminated reasons:

Restart policies:

For Deployments, restartPolicy is normally Always.

Debugging flow:

kubectl get pod <pod-name>
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous

How to read symptoms:

Important nuance: Pod phase alone is not enough. Always check container state, reason, restart count, events, and logs.

A strong answer is:

“I do not stop at the Pod phase. I check container states, reasons, restart count, events, and previous logs. CrashLoopBackOff points to app exit/probe/config issues, while ImagePullBackOff points to registry, image, or credential problems.”

A Kubernetes Service provides a stable network endpoint for a set of Pods.

Pods are ephemeral and their IPs can change. A Service gives clients a stable DNS name and virtual IP while routing traffic to matching Pods.

Service types:

Example Service:

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

Important fields:

Most common use:

A Service selector mismatch creates a Service with no backends.

Debug commands:

kubectl get svc api
kubectl get endpoints api
kubectl get endpointslice -l kubernetes.io/service-name=api
kubectl get pods -l app=api

If the Service has no endpoints, check:

• Pod labels
• Service selector
• Pod readiness
• Namespace
• Target port
• EndpointSlice objects

Important note: Services route only to ready endpoints by default. If Pods exist but are not Ready, traffic may not be sent to them.

A strong answer is:

“A Service gives stable networking for ephemeral Pods. I use ClusterIP for internal traffic, LoadBalancer or Ingress/Gateway for external access, and I always verify that Service selectors produce ready endpoints.”

Kubernetes creates DNS records for Services and Pods. CoreDNS commonly serves these records inside the cluster.

Common Service DNS formats:

Example:

my-svc.my-namespace.svc.cluster.local

From a Pod in the same namespace, short name usually works:

curl http://api

From another namespace, use namespace-qualified name:

curl http://api.dev

Headless Service:

spec:
  clusterIP: None

A headless Service does not get a normal ClusterIP. It can return individual Pod IPs, which is useful for StatefulSets and direct Pod identity.

StatefulSet DNS example:

mysql-0.mysql.default.svc.cluster.local

Common DNS troubleshooting:

kubectl get svc -n kube-system kube-dns
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl exec -it <pod> -- nslookup kubernetes.default
kubectl exec -it <pod> -- cat /etc/resolv.conf

Check:

• Service exists
• Correct namespace
• CoreDNS Pods running
• NetworkPolicy allows DNS egress
• Pod /etc/resolv.conf
• Search domains and ndots
• Service endpoints exist
• CNI connectivity to CoreDNS

NetworkPolicy gotcha:

If egress is restricted, allow DNS to CoreDNS/kube-dns on UDP and TCP 53. DNS can use TCP for large responses or retries, so allowing only UDP may cause intermittent issues.

A strong answer is:

“CoreDNS gives Services stable names inside the cluster. I test short and fully qualified names, check Service endpoints, inspect /etc/resolv.conf, and make sure NetworkPolicy allows DNS egress to kube-dns/CoreDNS on port 53.”

An Ingress manages HTTP/HTTPS routing from outside the cluster to Services inside the cluster.

Ingress can provide:

• Host-based routing
• Path-based routing
• TLS termination
• HTTP routing rules
• One external entry point for many Services

An Ingress requires an Ingress controller. Without a controller, the Ingress object exists but does not route traffic.

Common controllers:

• NGINX Ingress Controller
• Traefik
• HAProxy
• AWS Load Balancer Controller
• GCE/GKE Ingress controller
• Azure Application Gateway Ingress Controller

LoadBalancer Service vs Ingress:

Ingress example:

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

Common Ingress troubleshooting:

kubectl get ingress
kubectl describe ingress web
kubectl get ingressclass
kubectl get svc web
kubectl get endpoints web
kubectl logs -n ingress-nginx deploy/ingress-nginx-controller

Check:

• Ingress controller is installed
• ingressClassName matches the controller
• DNS points to the external address
• TLS Secret exists and matches host
• Backend Service exists
• Service has ready endpoints
• Path type and rewrite annotations are correct
• Controller-specific annotations are valid

Modern senior note: Gateway API is the newer Kubernetes API family for more expressive traffic management. Ingress is still widely used, but Gateway API is increasingly relevant for advanced routing and platform/team ownership models.

A strong answer is:

“Ingress is L7 HTTP/HTTPS routing to Services and needs an Ingress controller. I use it when I need host/path routing and TLS termination instead of creating one LoadBalancer per microservice.”

Kubernetes networking has multiple layers.

CNI plugin examples:

• Calico
• Cilium
• Flannel
• Weave Net
• Antrea
• AWS VPC CNI
• Azure CNI

CNI responsibilities:

• Allocate Pod IPs
• Set up network interfaces
• Configure routes
• Enable Pod-to-Pod connectivity
• Optionally enforce NetworkPolicy

kube-proxy responsibilities:

• Watches Services and EndpointSlices
• Programs node networking rules
• Sends Service traffic to backend Pods
• Common modes include iptables and IPVS

Some CNIs, such as Cilium, can replace kube-proxy functionality with an eBPF dataplane.

Important distinction:

Service mesh note:

A service mesh such as Istio or Linkerd adds proxies around application traffic. Sidecars affect:

• Pod CPU/memory requests
• Startup/shutdown behavior
• Probes
• mTLS
• Traffic routing
• HPA calculations if resources are not set properly

A strong answer is:

“CNI gives Pods network connectivity and IPs. kube-proxy or an eBPF replacement implements Service load balancing. CoreDNS handles names, and NetworkPolicy works only if the CNI enforces it.”

A NetworkPolicy controls allowed ingress and/or egress traffic for selected Pods.

Important baseline:

• If no NetworkPolicy selects a Pod, traffic is allowed by default
• Once a Pod is selected by an ingress policy, only allowed ingress traffic is permitted
• Once a Pod is selected by an egress policy, only allowed egress traffic is permitted
• NetworkPolicy requires CNI support; otherwise policies may not be enforced

Common rules:

Example policy allowing frontend to call API and API to resolve DNS:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53
    - protocol: TCP
      port: 53

Important DNS gotcha:

If you restrict egress and forget DNS, the app may fail even though Services and Pods are healthy.

Allow:

• UDP 53
• TCP 53
• Correct namespace/pod labels for CoreDNS/kube-dns

Another common interview gotcha: NetworkPolicy is not a firewall for all cluster traffic in every direction automatically. It applies to selected Pods and supported traffic types through the CNI implementation.

Troubleshooting checklist:

kubectl get networkpolicy -n <ns>
kubectl describe networkpolicy <name> -n <ns>
kubectl get pods --show-labels -n <ns>
kubectl get ns --show-labels

Check:

• Does the policy select the intended Pods?
• Are namespace labels correct?
• Are pod labels correct?
• Is ingress allowed on the destination?
• Is egress allowed from the source?
• Is DNS allowed?
• Does the CNI support NetworkPolicy?
• Are ports matching container/application ports?

Advanced production patterns:

• Default deny all ingress
• Default deny all egress
• Allow DNS explicitly
• Allow only required service-to-service flows
• Force external egress through gateway/proxy
• Separate policies by app/team/namespace

A strong answer is:

“NetworkPolicy starts from default allow, then restricts selected Pods. I verify both destination ingress and source egress, allow DNS explicitly, and confirm the CNI actually enforces NetworkPolicy.”

A ConfigMap stores non-sensitive configuration separately from the container image.

Use ConfigMap for:

• Feature flags
• Log levels
• App settings
• Config files
• Non-secret URLs
• Runtime toggles

Do not store passwords, API keys, tokens, or certificates in ConfigMaps. Use Secrets or an external secret manager for sensitive values.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: info
  app.properties: |
    cache.ttl=300
    feature.newCheckout=true

Common ways to consume ConfigMap:

Environment variable example:

env:
- name: LOG_LEVEL
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: LOG_LEVEL

Volume mount example:

volumes:
- name: config
  configMap:
    name: app-config

containers:
- name: app
  image: example/app:v1
  volumeMounts:
  - name: config
    mountPath: /etc/app

Important update behavior:

In production, many teams trigger a Deployment rollout when ConfigMap changes so Pods restart with known config.

Common rollout pattern:

kubectl rollout restart deployment/api

Interview mistake: saying “ConfigMap update immediately changes the app.” The mounted file may update eventually, but the application must re-read it. Environment variables require a new Pod.

A strong answer is:

“I use ConfigMap for non-secret runtime configuration. Env vars are simple but require Pod restart to change; mounted files can update eventually, but the app must reload them. For predictable production releases, I often trigger a rollout when config changes.”

A Kubernetes Secret stores sensitive data such as passwords, tokens, private keys, and certificates.

Example:

apiVersion: v1
kind: Secret
metadata:
  name: db-creds
type: Opaque
stringData:
  username: app
  password: changeme

Important security point:

Base64 is encoding, not encryption.

Secrets are stored as Kubernetes API objects. Depending on cluster configuration, they may be stored in etcd in a form that needs encryption at rest for stronger protection.

Good practices:

Secret as environment variable:

env:
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-creds
      key: password

Secret as volume:

volumes:
- name: db-creds
  secret:
    secretName: db-creds

containers:
- name: app
  volumeMounts:
  - name: db-creds
    mountPath: /etc/secrets
    readOnly: true

Volume mounts are often preferred for secrets because:

• File permissions can be controlled
• Some apps can reload files
• They avoid putting secrets directly into environment variables
• Rotation can be easier than env-based secrets

But do not overstate it: mounted Secrets can still be read by any process with filesystem access inside the container.

External secret options:

• HashiCorp Vault
• AWS Secrets Manager
• Azure Key Vault
• Google Secret Manager
• External Secrets Operator
• Secrets Store CSI Driver
• Sealed Secrets for GitOps workflows

Common interview mistake: saying Kubernetes Secrets are secure because they are base64-encoded. They need RBAC, encryption at rest, secure backup handling, and secret rotation strategy.

A strong answer is:

“Kubernetes Secrets are sensitive API objects, not magically encrypted values. I restrict RBAC, enable encryption at rest, avoid Git commits, prefer external secret managers for production, and mount only the secret keys a container actually needs.”

Kubernetes separates storage into three main objects.

A PV is the storage resource. It may be backed by NFS, EBS, Azure Disk, Ceph, vSphere, local storage, or another CSI driver.

A PVC is the application’s request for storage.

A StorageClass tells Kubernetes how to dynamically provision storage.

PVC example:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 10Gi

Access modes:

Common mapping:

Dynamic provisioning flow:

Pod references PVC
→ PVC references StorageClass
→ CSI provisioner creates PV
→ PVC binds to PV
→ Pod mounts volume

If a Pod stays Pending, check PVC status:

kubectl get pvc
kubectl describe pvc data
kubectl describe pod <pod-name>

Common storage problems:

Reclaim policy matters:

StatefulSets commonly use volumeClaimTemplates so each Pod gets its own PVC.

A strong answer is:

“A PVC is the app’s storage request, a PV is the actual storage, and a StorageClass defines dynamic provisioning. I match access mode and reclaim policy to the workload, and I debug Pending Pods by checking PVC binding and storage events.”

Kubernetes has several volume types for non-persistent or metadata-driven use cases.

emptyDir is created when a Pod is assigned to a node and deleted when the Pod is removed from that node.

Use emptyDir for:

• Scratch files
• Shared files between app and sidecar
• Temporary processing
• Buffering
• Logs consumed by sidecar

Example:

volumes:
- name: shared-logs
  emptyDir: {}

containers:
- name: app
  volumeMounts:
  - name: shared-logs
    mountPath: /var/log/app
- name: log-shipper
  volumeMounts:
  - name: shared-logs
    mountPath: /logs

Downward API exposes Pod metadata without requiring the app to call the Kubernetes API.

Environment variable example:

env:
- name: POD_NAME
  valueFrom:
    fieldRef:
      fieldPath: metadata.name
- name: POD_NAMESPACE
  valueFrom:
    fieldRef:
      fieldPath: metadata.namespace

Resource field example:

env:
- name: CPU_REQUEST
  valueFrom:
    resourceFieldRef:
      resource: requests.cpu

Projected volume example:

volumes:
- name: app-projected
  projected:
    sources:
    - configMap:
        name: app-config
    - secret:
        name: app-secret
    - downwardAPI:
        items:
        - path: pod-name
          fieldRef:
            fieldPath: metadata.name

Common interview distinctions:

A strong answer is:

“I use emptyDir for temporary files shared inside one Pod, projected volumes to combine config sources, and downward API when the app needs its own Pod metadata without calling the Kubernetes API.”

The 12-factor app model says configuration should be separated from code and injected at runtime.

Kubernetes supports this with:

Config examples:

Important shutdown behavior:

1. Pod deletion or rollout begins
2. Endpoint is removed when readiness fails/Pod terminates
3. Container receives SIGTERM
4. Kubernetes waits terminationGracePeriodSeconds
5. If still running, container receives SIGKILL

Default grace period is commonly 30 seconds unless changed.

Example:

terminationGracePeriodSeconds: 45

App responsibilities:

• Handle SIGTERM
• Stop accepting new requests
• Finish or cancel in-flight work
• Close DB connections cleanly
• Flush logs/metrics
• Exit before grace period ends

Common production additions:

• Readiness probe for traffic gating
• PreStop hook only when truly needed
• Config rollout automation
• Separate config per environment
• Secret rotation plan
• Avoid baking environment-specific values into images

Good interview distinction:

Build once, deploy many times with different runtime config.

A strong answer is:

“Kubernetes supports 12-factor apps by keeping config outside the image through ConfigMaps and Secrets, scaling with replicas/HPA, logging to stdout, and relying on fast startup plus graceful SIGTERM handling during rollouts.”

Kubernetes probes tell the kubelet how healthy a container is and whether it should receive traffic.

Example:

startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  periodSeconds: 5

How to design endpoints:

Important trap: do not put downstream database checks in liveness unless the app truly cannot recover without restart. If the DB blips, liveness may restart every Pod and make the outage worse.

Better approach:

• Liveness: shallow process health
• Readiness: dependency readiness
• Startup: slow initialization protection

Common probe mistakes:

Troubleshooting:

kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl logs <pod-name> --previous

Look for Events such as:

Liveness probe failed
Readiness probe failed
Startup probe failed

A strong answer is:

“Startup protects slow boots, readiness controls whether a Pod receives Service traffic, and liveness restarts only truly unhealthy containers. I keep liveness shallow and put dependency checks in readiness.”

Resource requests and limits control scheduling and runtime resource behavior.

Example:

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

CPU vs memory:

Requests matter because the scheduler uses them to decide where a Pod can fit.

Pod requests
→ scheduler checks node allocatable
→ Pod assigned only if resources fit

Limits matter because the runtime enforces them.

Common issues:

Quality of Service classes:

Production guidance:

• Set requests for every container, including sidecars
• Set memory limits carefully
• Avoid very low CPU limits for latency-sensitive apps
• Use metrics to tune requests
• Watch OOMKills, throttling, and node pressure
• Remember HPA resource utilization depends on requests

A strong answer is:

“Requests are for scheduling and baseline capacity; limits are runtime caps. CPU over limit is throttled, memory over limit is killed. I set requests for every container because scheduling and HPA depend on them.”

The Horizontal Pod Autoscaler adjusts replica count based on metrics.

It can scale workloads such as Deployments, ReplicaSets, and StatefulSets through the scale subresource.

Example:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

How CPU utilization HPA works conceptually:

current CPU usage / requested CPU
→ compare with target utilization
→ calculate desired replicas
→ scale target up/down

Prerequisites:

Common HPA metrics:

Common troubleshooting:

kubectl get hpa
kubectl describe hpa api
kubectl top pods
kubectl top nodes
kubectl get apiservice | grep metrics

Failure examples:

If metrics are missing, HPA cannot make normal scaling decisions from those metrics. Existing replicas continue running, but scale decisions may be skipped or degraded.

Senior point: HPA is reactive. It scales after metrics show load. For sudden spikes, use enough baseline replicas, fast startup, queue-based scaling, predictive scaling, or KEDA/custom metrics where appropriate.

A strong answer is:

“HPA watches metrics and changes replica count between min and max. CPU utilization scaling depends on container requests and metrics-server. I debug HPA by checking conditions, metrics availability, requests, pending Pods, and whether the metric actually represents user load.”

HPA and VPA solve different scaling problems.

HPA example:

More traffic
→ CPU/RPS/queue metric rises
→ HPA adds replicas

VPA example:

Pod consistently uses more memory than requested
→ VPA recommends or updates larger request

Cluster Autoscaler example:

HPA creates more Pods
→ Pods remain Pending
→ Cluster Autoscaler adds nodes

Trade-offs:

Important conflict:

Do not blindly run HPA and VPA on the same CPU/memory signal for the same workload. HPA uses utilization relative to requests. If VPA changes requests while HPA scales on CPU utilization, the two controllers can fight or create confusing behavior.

Common best practice:

• HPA for scaling replicas on traffic/load metrics
• VPA in recommendation mode for right-sizing
• VPA for workloads not horizontally scalable
• Cluster Autoscaler for node capacity
• Custom metrics for queue/RPS/latency-driven scaling

Good examples:

A strong answer is:

“HPA adds or removes Pods, VPA adjusts resource requests, and Cluster Autoscaler adds nodes. I avoid letting HPA and VPA fight over the same CPU utilization signal and usually use VPA recommendation mode for HPA-managed apps.”

Taints, tolerations, and affinity control where Pods run.

Simple rule:

Taint example:

kubectl taint nodes node1 dedicated=gpu:NoSchedule

Toleration example:

tolerations:
- key: dedicated
  operator: Equal
  value: gpu
  effect: NoSchedule

Taint effects:

Important distinction:

• A toleration does not force a Pod onto a node
• It only allows the Pod to be scheduled there
• Use node affinity/nodeSelector to attract the Pod to the desired node

Example dedicated GPU nodes:

tolerations:
- key: dedicated
  operator: Equal
  value: gpu
  effect: NoSchedule

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node-type
          operator: In
          values:
          - gpu

Node affinity examples:

Common Pending event:

node(s) had taint {dedicated: gpu}, that the pod didn't tolerate

Troubleshooting:

kubectl describe pod <pod-name>
kubectl describe node <node-name>
kubectl get nodes --show-labels

Check:

• Node taints
• Pod tolerations
• Node labels
• nodeSelector/affinity
• Required vs preferred rules
• Resource requests
• PVC zone constraints
• Topology spread constraints

Production pattern:

• Taint special nodes to reserve them
• Add tolerations only to approved workloads
• Add node affinity so workloads actually target those nodes
• Use pod anti-affinity/topology spread to avoid placing all replicas on one failure domain

A strong answer is:

“Taints repel Pods, tolerations allow Pods onto tainted nodes, and affinity attracts Pods to labeled nodes or spreads them relative to other Pods. For dedicated nodes, I usually combine taints, tolerations, and node affinity.”

Kubernetes RBAC controls who can perform which actions on which API resources.

There are four main RBAC objects:

A Role defines permissions, but it does not grant them until a binding attaches it to a subject.

Example Role:

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

Example RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev
  name: read-pods
subjects:
- kind: ServiceAccount
  name: app-reader
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Important interview details:

Common verbs:

get, list, watch, create, update, patch, delete

Good debugging commands:

kubectl auth can-i get pods -n dev
kubectl auth can-i create deployments -n dev --as=system:serviceaccount:dev:ci-deployer

Least privilege examples:

• CI deploy ServiceAccount can update Deployments in one namespace
• App ServiceAccount can read only required ConfigMaps or custom resources
• Monitoring can list/watch metrics-related resources
• Avoid giving app workloads list secrets unless truly required
• Avoid cluster-admin for pipelines and applications

Common mistake:

Giving a namespace deploy pipeline cluster-admin because one permission was missing.

Better: identify the exact API group, resource, namespace, and verb needed.

A strong answer is:

“RBAC separates permission definition from permission binding. I use Roles for namespace-scoped access, ClusterRoles for cluster-wide or reusable rules, and bind them to users/groups/ServiceAccounts with least privilege.”

A ServiceAccount gives a Pod an identity inside Kubernetes.

Every Pod runs as a ServiceAccount. If you do not specify one, Kubernetes uses the namespace’s default ServiceAccount.

Example:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-sa
  namespace: prod

Pod using a ServiceAccount:

apiVersion: v1
kind: Pod
metadata:
  name: api
spec:
  serviceAccountName: api-sa
  containers:
  - name: api
    image: registry.example.com/api:v1

Why ServiceAccounts matter:

Older clusters often used long-lived ServiceAccount tokens. Modern Kubernetes favors projected, bounded, expiring tokens.

Good production practices:

• Create a dedicated ServiceAccount per app/workload
• Avoid using the default ServiceAccount for production apps
• Bind only required RBAC permissions
• Disable token mounting if the app does not need Kubernetes API access
• Use cloud workload identity instead of static cloud keys in Secrets
• Rotate and audit credentials

Disable automount when not needed:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: no-api-access
automountServiceAccountToken: false

Pod-level override:

spec:
  automountServiceAccountToken: false

Cloud identity examples:

Interview trap:

A Kubernetes ServiceAccount is not the same as a Linux user inside the container.

The ServiceAccount controls Kubernetes API identity. Linux user settings are controlled by container image and securityContext.

A strong answer is:

“A Pod runs as a ServiceAccount for Kubernetes API identity. I use one dedicated ServiceAccount per workload, bind minimal RBAC, avoid default accounts, and prefer cloud workload identity over long-lived cloud keys stored in Secrets.”

Namespaces divide a Kubernetes cluster into logical scopes.

Use namespaces for:

• Teams
• Applications
• Environments
• Tenants
• System components
• Blast-radius control

Examples:

dev
staging
prod
team-payments
team-platform
ingress-nginx
monitoring

Namespaces provide namespacing for many Kubernetes objects:

Important point:

Namespaces are not complete security boundaries by themselves.

For real isolation, combine namespaces with:

ResourceQuota example idea:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-payments
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    pods: "50"

LimitRange example use:

• Default CPU/memory requests
• Default CPU/memory limits
• Minimum/maximum container resources
• Prevent BestEffort Pods in shared namespaces

Good namespace practices:

• Avoid running production workloads in default
• Use consistent labels
• Apply quotas for shared clusters
• Apply NetworkPolicies for sensitive namespaces
• Use separate namespaces for platform components
• Keep environment separation clear

Common mistake:

Creating dev, staging, and prod namespaces but giving everyone cluster-admin and allowing all network traffic.

That is organization, not secure multi-tenancy.

A strong answer is:

“Namespaces scope names and organize resources, but they are not hard security boundaries alone. I pair them with RBAC, quotas, NetworkPolicy, Pod Security Admission, and sometimes separate node pools or clusters.”

Kubernetes Pod Security Standards define three policy levels:

Pod Security Admission can enforce, warn, or audit these standards through namespace labels.

Example namespace labels:

metadata:
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

A securityContext controls Linux/security settings for Pods and containers.

Example hardened container:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Common hardening controls:

Pod-level example:

spec:
  securityContext:
    runAsNonRoot: true
    fsGroup: 2000

Container-level settings override or complement Pod-level settings.

Interview caveat:

Some workloads need exceptions, such as CNI, CSI, monitoring agents, or node-level security agents. Exceptions should be isolated and reviewed.

Common production approach:

• Enforce restricted for app namespaces
• Allow baseline or controlled exceptions for platform namespaces
• Use admission policies to block privileged containers
• Scan images and manifests in CI
• Avoid root containers unless justified

A strong answer is:

“I harden Pods with non-root users, dropped capabilities, no privilege escalation, read-only root filesystems, and RuntimeDefault seccomp. Pod Security Standards help enforce these controls consistently at namespace level.”

Admission control runs after authentication and authorization but before an object is persisted.

Request flow:

request
→ authentication
→ authorization
→ admission
→ validation
→ etcd

Admission can:

• Mutate an object
• Validate an object
• Reject an object
• Apply defaults
• Enforce organization policy

Webhook types:

Examples of admission policy:

• Require resource requests/limits
• Block :latest image tag
• Require approved registries
• Require labels/annotations
• Enforce non-root containers
• Require probes
• Restrict hostPath
• Block privileged containers
• Add sidecars or default labels
• Enforce image signature policy through external tools

Common policy engines:

Example interview scenario:

“A developer applies a Pod without resource requests. CI missed it. Admission policy rejects it before etcd stores it.”

Good practices:

• Test policies in audit/warn mode before enforce
• Avoid slow or unreliable webhooks
• Configure failure policy intentionally
• Monitor webhook latency and errors
• Keep policies version controlled
• Use CI policy checks before admission rejection
• Avoid mutating too much invisibly
• Document exceptions

Common failure:

failed calling webhook

Check:

kubectl get validatingwebhookconfiguration
kubectl get mutatingwebhookconfiguration
kubectl describe validatingwebhookconfiguration <name>
kubectl get pods -n <webhook-namespace>
kubectl logs -n <webhook-namespace> deploy/<webhook>

A strong answer is:

“Admission controllers enforce policy before objects are stored. I use validating policies to reject unsafe manifests, mutating policies for controlled defaults, and policy-as-code in CI plus admission so bad config is caught before production.”

Helm, Kustomize, and GitOps solve related but different deployment problems.

Helm concepts:

Common Helm commands:

helm install api ./chart -n prod
helm upgrade api ./chart -n prod -f values-prod.yaml
helm history api -n prod
helm rollback api 3 -n prod

Kustomize concepts:

base/
  deployment.yaml
  service.yaml

overlays/
  dev/
    kustomization.yaml
  prod/
    kustomization.yaml

Example:

kubectl apply -k overlays/prod

GitOps flow:

developer merges change
→ CI builds image
→ manifest/chart values updated in Git
→ GitOps controller detects desired state
→ controller reconciles cluster
→ drift is corrected or reported

Good GitOps practices:

• Git is source of truth
• Avoid manual kubectl edit in production
• Use pull requests for environment changes
• Keep secrets encrypted or externally referenced
• Pin image tags/digests intentionally
• Separate app source repo and environment config repo if needed
• Use health checks and sync status
• Roll back by Git revert or Helm rollback depending workflow

Helm vs Kustomize interview answer:

Common senior point:

Helm can be used with GitOps. Argo CD and Flux can deploy Helm charts while still using Git as the desired-state source.

A strong answer is:

“Helm packages and templates applications, Kustomize patches plain manifests, and GitOps controllers reconcile the cluster from version-controlled desired state. In production, I treat Git as source of truth and avoid manual drift.”

A Pod stuck in Pending usually means it has not been scheduled or a required dependency is not ready.

Start with Events:

kubectl describe pod <pod-name> -n <namespace>
kubectl get events -n <namespace> --sort-by='.lastTimestamp'

Then classify the issue.

Useful commands:

kubectl get pod <pod-name> -n <namespace> -o wide
kubectl describe pod <pod-name> -n <namespace>
kubectl get nodes --show-labels
kubectl describe node <node-name>
kubectl get pvc -n <namespace>
kubectl describe pvc <pvc-name> -n <namespace>
kubectl top nodes

How to reason:

NODE column empty
→ scheduling failed
→ read Events
→ classify resource / taint / affinity / volume

Important distinction:

• Pending with empty NODE usually points to scheduling or PVC binding
• Pod assigned to a node but stuck in image pull or container creation is a kubelet/runtime issue
• Image pull failures may briefly show waiting states, then become ImagePullBackOff or ErrImagePull

Common interview mistake:

Guessing resource issue without reading Events.

Better narrative:

1. Describe Pod
2. Read Events
3. Check resources/taints/affinity/PVC
4. Confirm node capacity
5. Fix the exact constraint
6. Recheck scheduling

A strong answer is:

“I start with kubectl describe pod and Events. Pending usually points to scheduling constraints such as insufficient resources, taints, affinity, or unbound PVCs, so I classify the Event before changing anything.”

CrashLoopBackOff means a container starts, exits, and Kubernetes backs off before restarting it again.

Start with:

kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> --previous

Use --previous because the current container may have already restarted.

Check termination reason:

kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.containerStatuses[*].lastState.terminated.reason}'

Common causes:

Probe-related command:

kubectl describe pod <pod-name> -n <namespace> | grep -A5 -i probe

Resource check:

kubectl top pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace> | grep -A20 -i resources

Config check:

kubectl get cm -n <namespace>
kubectl get secret -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Important interview distinctions:

Do not immediately increase limits without checking logs. If the app crashes due to missing config, more memory will not help.

A strong answer is:

“For CrashLoopBackOff, I check previous logs, describe Events, termination reason, probes, config mounts, and OOMKilled status. I separate app startup failure from probe misconfiguration and resource exhaustion.”

A Deployment rollout can get stuck when the new ReplicaSet cannot produce Ready Pods.

Start with:

kubectl rollout status deployment/<name> -n <namespace>
kubectl describe deployment <name> -n <namespace>
kubectl get rs -n <namespace>
kubectl get pods -n <namespace> -l app=<label>

Find the new ReplicaSet:

kubectl get rs -n <namespace> --sort-by=.metadata.creationTimestamp

Then inspect new Pods:

kubectl describe pod <new-pod> -n <namespace>
kubectl logs <new-pod> -n <namespace>
kubectl logs <new-pod> -n <namespace> --previous

Common rollout blockers:

Useful Deployment fields:

Rollback:

kubectl rollout undo deployment/<name> -n <namespace>

Rollback to a specific revision:

kubectl rollout history deployment/<name> -n <namespace>
kubectl rollout undo deployment/<name> -n <namespace> --to-revision=<revision>

Good production response:

1. Check whether users are impacted
2. Confirm old Pods are still serving
3. Inspect new ReplicaSet Pods
4. Roll back if impact is high
5. Fix image/config/probe/resource issue
6. Re-deploy with smaller blast radius if needed

Common interview mistake:

Looking only at the Deployment object and not the new ReplicaSet Pods.

The failing evidence is usually in the new Pods.

A strong answer is:

“For a stuck rollout, I inspect the new ReplicaSet and its Pods. Most failures are readiness, image pull, crash, capacity, or admission issues. If production traffic is at risk, I rollback first, then fix and redeploy safely.”

Use the final week to practice both concepts and live troubleshooting narration.

Docker/container basics:

• Image vs container
• Dockerfile instructions
• Multi-stage build
• Compose vs Kubernetes
• Container runtime, CRI, containerd, CRI-O
• OCI image, tag vs digest, registry pull errors

Kubernetes architecture:

• Control plane vs worker node
• API server request path
• etcd role and quorum
• Scheduler decisions
• Controllers and reconciliation
• kubelet/runtime responsibilities

Workloads:

• Pod basics and sidecars
• Deployment vs ReplicaSet vs Pod
• StatefulSet vs Deployment
• DaemonSet, Job, CronJob
• Pod phases and container states
• Rollout and rollback commands

Networking:

• ClusterIP, NodePort, LoadBalancer
• Service selector and endpoints
• CoreDNS name formats
• Ingress vs LoadBalancer
• Gateway API awareness
• CNI vs kube-proxy/eBPF
• NetworkPolicy default allow/deny behavior
• DNS egress on UDP/TCP 53

Configuration and storage:

• ConfigMap env vs mounted file behavior
• Secret security and encryption at rest
• External secret managers
• PV, PVC, StorageClass
• Access modes: RWO, RWX, ROX, RWOP
• emptyDir, projected volumes, downward API
• Graceful shutdown and SIGTERM

Resources and scaling:

• Liveness vs readiness vs startup probes
• CPU requests/limits and throttling
• Memory limits and OOMKilled
• QoS classes
• HPA prerequisites
• HPA vs VPA vs Cluster Autoscaler
• Taints, tolerations, affinity, anti-affinity

Security and platform:

• RBAC Role vs ClusterRole
• ServiceAccount and workload identity
• Namespaces with quotas and policies
• Pod Security Standards
• securityContext hardening
• Admission webhooks and policy engines
• Helm, Kustomize, and GitOps

Troubleshooting drills:

• Pod Pending
• CrashLoopBackOff
• ImagePullBackOff
• OOMKilled
• Service has no endpoints
• DNS resolution failure
• Ingress 404/502
• HPA not scaling
• Deployment rollout stuck
• PVC Pending
• NetworkPolicy blocks app traffic

Must-practice commands:

kubectl get pods -A
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns>
kubectl logs <pod> -n <ns> --previous
kubectl get events -n <ns> --sort-by='.lastTimestamp'
kubectl get deploy,rs,pod -n <ns>
kubectl rollout status deployment/<name> -n <ns>
kubectl rollout undo deployment/<name> -n <ns>
kubectl get svc,endpoints,endpointslice -n <ns>
kubectl auth can-i <verb> <resource> -n <ns>
kubectl top pods -n <ns>
kubectl get hpa -n <ns>

Scenario stories to prepare:

• A rollout failed because readiness never passed
• A Pod stayed Pending due to PVC or taints
• HPA did not scale because CPU requests were missing
• A NetworkPolicy broke DNS
• A CrashLoop was caused by missing Secret or wrong command
• A Deployment was fixed safely with rollback
• A migration from manual YAML to Helm/GitOps improved release safety

Good final close:

“I do not only know Kubernetes objects by definition. I can explain how they reconcile, how traffic flows, how security is enforced, and how to debug failures from Events, logs, rollout status, and resource conditions.”