Docker & Kubernetes for Interviews

Master the fundamentals of containerization — from writing Dockerfiles to managing images, volumes, and container networking.

• Image vs container — image is immutable template/blueprint, container is running ephemeral instance

• Dockerfile instructions — FROM, RUN, COPY, CMD, EXPOSE, WORKDIR and their execution order

• CMD vs ENTRYPOINT — CMD provides default args easily overridden, ENTRYPOINT is the fixed main executable

• docker build and docker run — building images from Dockerfiles and running containers with port mapping

• Port mapping — -p hostPort:containerPort exposes container services to the host machine

• Docker volumes — persistent storage that survives container deletion, managed by Docker

• Bind mounts — maps host directory directly into container, ideal for development hot reloading

• Volumes vs bind mounts — Docker-managed volumes preferred for production, bind mounts for local dev

• Networking modes — bridge (default isolated network), host (shared host network), none (no network)

• Image lifecycle — docker images, docker rmi, tagging with versions, pushing to registries

Understand how Kubernetes automates deployment, scaling, and management of containerized workloads at scale.

• Control plane components — kube-apiserver, etcd, kube-scheduler, kube-controller-manager

• Pod — smallest deployable unit in Kubernetes, contains one or more containers

• Deployment — manages ReplicaSets, enables declarative updates, rolling updates, and rollbacks

• Deployment vs StatefulSet — stateless interchangeable pods vs stateful pods with stable identity and storage

• StatefulSet use cases — databases, message queues, distributed systems requiring stable network identity

• kubectl apply — creates or updates resources from YAML manifest files

• Scaling pods — kubectl scale deployment name --replicas=N adjusts replica count on demand

• Namespaces — logical isolation for resource organization, multi-tenancy, and environment separation

• Persistent Volumes — storage abstraction layer for stateful application data

• Pod naming — Deployments use random names, StatefulSets use predictable ordered names (db-0, db-1)

Master how traffic flows inside and outside a Kubernetes cluster — from service types and DNS to Ingress and NetworkPolicies.

• Kubernetes networking principle — every pod gets a unique IP, pods communicate without NAT

• ClusterIP — internal-only service, default type, used for inter-service communication within cluster

• NodePort — exposes service on each node's static port (30000-32767), suitable for on-prem or testing

• LoadBalancer — provisions cloud provider load balancer for production external traffic

• Service type selection — ClusterIP for internal, NodePort for testing, LoadBalancer for production external

• Ingress — routes HTTP/HTTPS traffic, handles SSL termination and name-based virtual hosting

• Ingress advantage — one Ingress routes to multiple services, reduces cloud load balancer costs

• DNS service discovery — pods reach services via service-name.namespace.svc.cluster.local

• NetworkPolicy — controls ingress/egress traffic between pods using label selectors

• Headless service — ClusterIP set to None, returns pod IPs directly for stateful app clients

Manage application configuration and sensitive data securely in Kubernetes — and understand the critical difference between ConfigMaps and Secrets.

• ConfigMap purpose — stores non-sensitive config as plain text key-value pairs (app settings, URLs)

• Secret purpose — stores sensitive data (passwords, API keys, certificates) in base64 encoded form

• ConfigMap vs Secret — plain text and visible in describe vs base64 encoded and redacted in describe

• Base64 is not encryption — anyone with cluster access can decode Secrets, enable encryption at rest

• Consuming ConfigMaps — inject as environment variables, command arguments, or volume-mounted files

• Consuming Secrets — referenced via valueFrom.secretKeyRef to inject into pod environment variables

• Mount as volume — makes ConfigMap or Secret data available as files inside the pod filesystem

• Secret best practices — encrypt at rest, use RBAC, rotate regularly, consider external managers

• External secret managers — HashiCorp Vault, AWS Secrets Manager for production-grade security

Build production-ready Kubernetes operations — automated scaling, resource management, centralized logging, and metrics-driven observability.

• Horizontal Pod Autoscaler (HPA) — automatically scales pod replicas based on CPU, memory, or custom metrics

• Vertical vs horizontal scaling — vertical adds resources to existing pods, horizontal adds more replicas

• Resource requests — guaranteed resources used by the scheduler to place pods on appropriate nodes

• Resource limits — maximum resources a pod can consume, CPU throttled and memory causes OOMKill at limit

• Requests vs limits best practice — set requests for minimum needs, limits higher to allow bursting

• Metrics Server — collects resource usage from kubelets, required for HPA and kubectl top to work

• kubectl logs — retrieves container stdout/stderr for debugging running or recently stopped pods

• Centralized logging — EFK (Elasticsearch, Fluentd, Kibana) or ELK stack for cluster-wide log aggregation

• Fluentd DaemonSet — runs on every node to collect and forward logs to centralized storage

• Prometheus and Grafana — Prometheus scrapes and stores time-series metrics, Grafana visualizes dashboards