Docker and Kubernetes Interview Questions 2026
At some point almost every backend or DevOps interview drifts into "how would you deploy this," and that's usually where Docker and Kubernetes questions show up, sometimes as a dedicated round, sometimes just woven into a system design discussion. The tricky part is that a lot of people can write a working Dockerfile and apply a YAML manifest they copied from somewhere, without actually understanding what's happening underneath, and that gap tends to show up fast under interview questions.
This page covers Docker first, images, layers, volumes, networking, then moves into Kubernetes, the control plane, Pods, Deployments, Services, and the production concerns (health checks, resource limits, scaling) that separate "I've run kubectl apply" from "I actually understand how a cluster keeps things running."
Why Docker and Kubernetes Questions Come Up So Often
Containers and orchestration are close to universal at this point, almost every modern backend, regardless of language or framework, eventually gets packaged into a container and deployed somewhere that looks like Kubernetes. Interviewers use these questions to check:
- Whether you understand what a container actually is, not just that
docker runstarts one - Whether you can write an efficient, secure Dockerfile instead of just a working one
- Whether you understand how Kubernetes actually keeps a desired state running, not just the kubectl commands
- Whether you've thought about production concerns, health checks, resource limits, rolling updates, not just getting something to start locally
Who This Page Is For
- Backend and DevOps engineers interviewing for roles that mention containers or Kubernetes
- Developers who've used Docker Compose for local dev but never touched a real Kubernetes cluster
- Anyone prepping for infrastructure-adjacent rounds alongside System Design or Cloud interviews
Related Resources
Docker and Kubernetes Interview Questions and Answers (2026)
Docker Fundamentals
1. What is Docker, and how is a container actually different from a virtual machine?
Docker is a platform for building, shipping, and running applications inside containers, isolated environments that package an app together with everything it needs to run. The key difference from a VM is what's being virtualized: a VM virtualizes an entire machine, including its own full operating system kernel, which makes it heavier and slower to start. A container shares the host machine's kernel and just isolates the process, filesystem, and network at the OS level, which is why containers start in milliseconds and use a fraction of the resources a VM needs for the same job.
2. What's the difference between an image and a container?
An image is a read-only template, a packaged set of layers containing your application code, dependencies, and configuration, it's the thing you build once and can reuse. A container is a running (or stopped) instance of that image, with its own writable layer on top where any runtime changes happen. It's the same relationship as a class and an object, one image can be used to spin up any number of independent, running containers.
3. What is a container runtime, and why does Docker specifically use containerd under the hood these days?
A container runtime is the actual software responsible for running containers, pulling images, setting up namespaces and cgroups, starting and stopping the container process. Docker used to have one big monolithic daemon that did everything, but it's since been split apart, Docker now delegates the actual container execution to containerd, a separate, lighter-weight runtime that's also used directly by other systems like Kubernetes, which is part of why Kubernetes doesn't strictly need "Docker" itself anymore, just a compatible container runtime like containerd.
4. Why do people say containers are "lightweight" compared to VMs, what's actually happening at the OS level?
Because a container doesn't boot its own kernel or emulate hardware, it's just a regular process on the host, isolated using kernel features so it can't see or interfere with other processes, but it's still fundamentally running directly on the host's existing kernel. That means starting a container is basically as fast as starting any other process, no OS boot sequence involved, and you can run far more containers on a given machine than you could run full VMs, since you're not duplicating an entire OS's memory and CPU overhead for each one.
5. What are Linux namespaces and cgroups, and what role does each play in making containers work?
Namespaces provide isolation, they make a container think it has its own private view of the system, its own process list (PID namespace), its own network stack (network namespace), its own filesystem mounts (mount namespace), even though it's actually sharing the same underlying kernel as every other container on the machine. Cgroups (control groups) provide resource limiting, they let the kernel cap and account for how much CPU, memory, and I/O a given container's processes are allowed to use, which is what stops one container from starving every other container on the same host.
6. What's the difference between Docker and Docker Desktop, and why do people sometimes need the latter even though Docker itself is just a CLI/daemon?
Docker (the engine and CLI) is fundamentally a Linux technology, since it relies on Linux kernel features like namespaces and cgroups. Docker Desktop is what makes Docker usable on macOS and Windows, it runs a lightweight Linux VM in the background and gives you a GUI plus a CLI that talks to Docker running inside that VM, so from your perspective it feels native, but under the hood there's still an actual Linux kernel involved somewhere, you just don't have to manage it directly.
Dockerfiles and Images
1. What are the most important instructions in a Dockerfile, and what does each actually do?
FROM sets the base image everything else builds on top of. RUN executes a command during the build and commits the result as a new layer, used for installing dependencies. COPY copies files from your build context into the image. CMD sets the default command that runs when a container starts (but can be overridden at docker run time). ENTRYPOINT also sets the command that runs on start, but it's harder to override, typically used together with CMD supplying default arguments to it.
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
CMD ["node", "server.js"]
2. What's the actual difference between CMD and ENTRYPOINT, and why do people combine both in the same Dockerfile?
CMD provides a default command, but if you pass a command at the end of docker run, it completely replaces the CMD. ENTRYPOINT is meant to always run, and anything you pass at the end of docker run gets appended to it as arguments instead of replacing it entirely. A common pattern combines both, ENTRYPOINT sets the actual executable (say, your app's binary), and CMD supplies default arguments to it, which can still be overridden individually at runtime without needing to override the whole entrypoint.
3. What is a layer in a Docker image, and why does the order of instructions in a Dockerfile matter for build speed?
Each instruction in a Dockerfile (mainly RUN, COPY, and ADD) creates a new layer, a diff of filesystem changes stacked on top of the previous layer, and Docker caches each layer. If a layer hasn't changed (same instruction, same input files), Docker reuses the cached version instead of rebuilding it. That's why the common advice is to copy dependency manifests (like package.json) and install dependencies before copying the rest of your source code, since your source code changes far more often than your dependencies, so this ordering means dependency installation stays cached across most builds instead of re-running every single time.
4. What is a multi-stage build, and what problem does it solve?
A multi-stage build uses multiple FROM statements in one Dockerfile, where later stages can selectively copy artifacts from earlier stages, without carrying along everything those earlier stages needed. It solves the problem of bloated production images, you might need a full compiler toolchain and dev dependencies to build your app, but none of that should end up in the final image that actually runs in production, a multi-stage build lets you build in one stage and copy only the final compiled output into a clean, minimal final stage.
FROM node:20 AS build
WORKDIR /app
COPY . .
RUN npm ci && npm run build
FROM node:20-alpine
WORKDIR /app
COPY --from=build /app/dist ./dist
CMD ["node", "dist/server.js"]
5. Why is it a bad idea to run a container as root, and how do you avoid it in a Dockerfile?
By default, unless you specify otherwise, processes inside a container run as root, and if an attacker manages to break out of the container's isolation through some kernel vulnerability, running as root inside the container gives them a much more dangerous foothold than a restricted user would. You avoid it by creating a non-root user in your Dockerfile and switching to it with the USER instruction before the container's main process runs.
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser
6. What's the difference between COPY and ADD, and why do most style guides recommend COPY over ADD?
COPY does exactly one thing, copies files or directories from the build context into the image. ADD does that too, but also has extra "magic" behavior, it can automatically extract local tar archives, and it can fetch a file from a remote URL. Most style guides recommend COPY by default because ADD's extra behavior is rarely what you actually want and can introduce confusing, hard to predict results, ADD is really only worth reaching for specifically when you need its tar-extraction behavior.
Containers, Networking and Volumes
1. What's the difference between a bind mount and a named volume?
A bind mount maps a specific path on the host machine directly into the container, useful for local development where you want your code changes to reflect instantly inside a running container. A named volume is managed entirely by Docker itself, stored in a location Docker controls (not something you'd typically browse to directly), and it's the recommended option for persisting real application data, since it's portable across environments and doesn't depend on a specific host filesystem layout the way a bind mount does.
2. Why does data disappear when a container is removed, and how do volumes solve that?
A container's writable layer is tied to that specific container's lifecycle, when you remove the container, that writable layer, and anything written to it, gets deleted along with it. Volumes exist outside that lifecycle entirely, they're managed by Docker independently of any single container, so if you mount a volume into a container and the container gets removed and recreated, the volume (and the data in it) survives and can just be reattached to the new container.
3. What are the default Docker network drivers, and when would you use each?
bridge is the default, it creates a private internal network on the host that containers connect to, with Docker handling NAT so they can reach the outside world, this is the right choice for most standalone container setups. host removes network isolation entirely, the container shares the host's network stack directly, which gets you better performance but no port isolation, useful in specific performance-sensitive cases. none disables networking entirely, useful for containers that genuinely need no network access at all, like an isolated batch processing job.
4. How do two containers on the same custom network actually find and talk to each other?
Docker's embedded DNS server automatically resolves a container's name (or the service name, in Compose) to its internal IP address for any other container on the same user-defined network. That means you don't hardcode IP addresses, a web app container can just connect to http://db:5432 where db is literally the name of the database container, and Docker resolves it correctly even if the container's actual internal IP changes on restart.
5. What's the difference between EXPOSE in a Dockerfile and actually publishing a port with -p?
EXPOSE is purely documentation, it tells anyone reading the Dockerfile (and some tooling) which port the application inside the container listens on, but it doesn't actually make that port reachable from outside the container on its own. Publishing a port with docker run -p 8080:80 is what actually creates the mapping, forwarding traffic on port 8080 of the host to port 80 inside the container, without it, the container's port stays completely inaccessible from outside the container's network, even if it was EXPOSEd.
Docker Compose and Multi-Container Apps
1. What problem does Docker Compose solve that plain docker run commands don't?
Most real applications aren't a single container, they're a web app, a database, maybe a cache, all needing to be started together with the right network and environment configuration. Compose lets you define all of that in a single YAML file, services, networks, volumes, environment variables, and bring the whole stack up or down with one command, instead of remembering and typing out a long, error-prone chain of individual docker run commands with all the right flags every time.
services:
app:
build: .
ports:
- '3000:3000'
depends_on:
- db
db:
image: postgres:16
environment:
POSTGRES_PASSWORD: secret
volumes:
- db-data:/var/lib/postgresql/data
volumes:
db-data:
2. How does Compose handle the startup order between dependent services, and why isn't depends_on alone enough to guarantee a service is actually ready?
depends_on controls the order containers are started in, it makes sure the database container starts before the app container. But "started" doesn't mean "ready," a database container might be running but still initializing and not actually accepting connections yet, which can cause your app to fail on startup even though depends_on was technically satisfied. The real fix is adding an actual readiness check, either a healthcheck in the Compose file that depends_on can wait on (condition: service_healthy), or retry logic in your app itself for its initial database connection.
3. What's the difference between docker compose up and docker compose up --build?
docker compose up starts containers using existing images, if an image was already built previously, it reuses it as-is, even if your Dockerfile or source code has since changed. docker compose up --build forces Compose to rebuild the images from their Dockerfiles first before starting the containers, which you need whenever you've made changes that require a rebuild, otherwise you can end up confusedly running stale code without realizing it.
4. How would you use environment-specific Compose files, like a docker-compose.override.yml, for local dev vs production?
Compose automatically merges a base docker-compose.yml with a docker-compose.override.yml if one's present, which lets you keep common configuration in the base file and put environment-specific overrides (like mounting your local source code as a bind mount for hot-reloading in dev, or exposing extra debug ports) in the override file, without duplicating the entire configuration. For production, you'd typically use -f to explicitly specify a different, production-specific compose file instead, one without dev conveniences like bind mounts, and with production-appropriate resource limits and restart policies.
Kubernetes Fundamentals and Architecture
1. What problem does Kubernetes actually solve that Docker alone doesn't?
Docker runs individual containers on a single machine, but it doesn't solve the problem of running containers reliably across many machines, restarting them automatically if they crash, distributing load, rolling out updates without downtime, or scaling based on demand. Kubernetes is an orchestration system, it manages a cluster of machines and continuously works to keep your actual running containers matching the state you've declared you want, handling failures, scaling, and networking across the whole cluster automatically.
2. What are the main components of the Kubernetes control plane?
The API server is the front door, every interaction with the cluster, including kubectl commands, goes through it. The scheduler decides which node a new Pod should run on, based on resource availability and constraints. The controller manager runs the control loops that continuously watch the cluster's actual state and work to reconcile it with the desired state (for example, the Deployment controller notices a Pod died and creates a replacement). etcd is the cluster's database, storing the entire actual configuration and state of everything in the cluster.
3. What is a node, and what's running on it?
A node is a single machine (physical or virtual) that's part of the cluster and actually runs your workloads. Each node runs the kubelet, an agent that talks to the API server and makes sure the containers described for that node are actually running and healthy, kube-proxy, which handles the networking rules that let Services route traffic to the right Pods, and a container runtime (like containerd) that actually pulls images and runs the containers themselves.
4. What is etcd, and why is it such a critical piece of the whole cluster?
etcd is a distributed, consistent key-value store that holds the entire state of the Kubernetes cluster, every object definition, every current status, essentially the cluster's single source of truth. It's critical because literally everything else in Kubernetes, the scheduler, the controllers, the API server itself, reads from and writes to etcd to know what should be running and what actually is running, if etcd is lost or corrupted without a backup, you've effectively lost the entire cluster's configuration and state.
5. What's the difference between the desired state and the actual state in Kubernetes, and how does the control loop reconcile them?
Desired state is what you've declared should exist, "I want 3 replicas of this Pod running," typically defined in a YAML manifest you apply. Actual state is what's genuinely running in the cluster right now. Kubernetes' controllers continuously run a loop: observe the actual state, compare it to the desired state, and take action to close any gap, if a Pod crashes and actual state drops to 2 replicas while desired state says 3, the ReplicaSet controller notices and creates a new Pod to bring it back to 3, entirely automatically, without anyone manually intervening.
6. What is kubectl, and how does it actually talk to a cluster?
kubectl is the command-line tool used to interact with a Kubernetes cluster. It doesn't talk to individual nodes directly, every command goes through the cluster's API server, which authenticates the request, validates it, and either reads from or writes to etcd accordingly. kubectl knows which cluster and credentials to use based on a kubeconfig file, which is why switching between multiple clusters (like a local dev cluster and a production one) usually just means switching your active kubeconfig context.
Pods, Deployments and ReplicaSets
1. What is a Pod, and why does Kubernetes use Pods instead of just scheduling containers directly?
A Pod is the smallest deployable unit in Kubernetes, wrapping one or more containers that share the same network namespace (so they can talk to each other over localhost) and can share storage volumes. Kubernetes uses Pods instead of scheduling bare containers because some workloads genuinely need tightly coupled containers that must always be scheduled together on the same node, sharing network and storage, and the Pod abstraction gives Kubernetes a consistent unit to schedule, scale, and manage as one thing.
2. When would you actually want more than one container in a single Pod?
The most common case is a sidecar container, a helper container that supports the main application container, for example a logging agent that reads log files written by the main container through a shared volume, or a service mesh proxy that intercepts all network traffic for the main container. The key signal for "these belong in the same Pod" is that the containers are genuinely coupled, they need to scale together and always live on the same node, if two containers can reasonably run and scale independently, they almost always belong in separate Pods instead.
3. What's the difference between a Pod, a ReplicaSet, and a Deployment?
A Pod runs your actual containers, but a bare Pod created directly has no self-healing, if it dies, nothing recreates it. A ReplicaSet's job is to ensure a specified number of identical Pod replicas are running at all times, if one dies, it creates a replacement. A Deployment sits on top of a ReplicaSet and adds declarative update management, when you change a Deployment's Pod template (say, a new image version), it creates a new ReplicaSet and manages a controlled rollout from the old one to the new one, which is why in practice you almost always create Deployments, not bare ReplicaSets or Pods, directly.
4. How does a Deployment perform a rolling update, and what happens if the new version is broken?
By default, a Deployment gradually replaces old Pods with new ones, spinning up a few new Pods, waiting for them to become ready, then terminating a corresponding number of old Pods, repeating until the rollout is complete, which keeps the application available with no downtime throughout. If the new Pods keep failing (crashing, failing readiness checks), the rollout will stall since Kubernetes won't proceed to terminate more old Pods until the new ones report healthy, and you can explicitly roll back to the previous working ReplicaSet with kubectl rollout undo.
kubectl rollout status deployment/my-app
kubectl rollout undo deployment/my-app
5. What's the difference between a Deployment and a StatefulSet, and when do you actually need a StatefulSet?
A Deployment treats its Pods as interchangeable and disposable, they get random names, and any replica can be replaced by any other with no distinction. A StatefulSet gives each Pod a stable, predictable identity, a consistent name and network address that persists across restarts, plus stable, dedicated storage per Pod that follows it if it's rescheduled. You need a StatefulSet for workloads where identity and storage matter per-instance, like a database cluster, where each node needs to consistently be "the same node" with its own data across restarts, not an interchangeable replica.
6. What is a DaemonSet, and what's a real use case for one?
A DaemonSet ensures that exactly one copy of a specific Pod runs on every node in the cluster (or a selected subset of nodes), automatically adding a Pod when a new node joins and removing it when a node leaves. A real use case is a log collection agent or a monitoring/metrics agent, you genuinely want exactly one of those running on every single node to collect data from that node specifically, not a fixed number of replicas scattered arbitrarily like a regular Deployment would give you.
Services, Networking and Ingress
1. Why do Pods need a Service in front of them instead of just being accessed directly by IP?
Pods are inherently ephemeral, they can be destroyed and recreated at any time (a rolling update, a crash, a rescheduling), and every time that happens, the Pod gets a brand new IP address. A Service provides a stable, unchanging virtual IP and DNS name that sits in front of a group of Pods, automatically updating which actual Pods it routes to as they come and go, so other parts of your system never need to know or care about individual Pod IPs.
2. What's the difference between ClusterIP, NodePort, and LoadBalancer service types?
ClusterIP (the default) is only reachable from inside the cluster, used for internal communication between services. NodePort opens a specific port on every node in the cluster, making the service reachable from outside via any node's IP and that port, a fairly blunt but simple option. LoadBalancer provisions an actual external load balancer (typically through your cloud provider, like an AWS ELB or GCP Load Balancer) that routes external traffic into the cluster, which is the standard way to expose a service to the public internet in a cloud-managed cluster.
3. How does a Service actually find which Pods to route traffic to?
A Service uses a label selector, it's configured to match Pods carrying specific labels (like app: my-api), and any Pod with matching labels automatically becomes part of that Service's pool of backend targets, regardless of which Deployment or ReplicaSet created it. This is why labels are such a core concept in Kubernetes, Services (and a lot of other resources) don't reference Pods by name or identity directly, they select them dynamically based on labels.
4. What is an Ingress, and how is it different from a Service of type LoadBalancer?
A LoadBalancer service typically provisions one external load balancer per service, which gets expensive and unwieldy if you have many services that all need external HTTP access. An Ingress is a higher-level routing layer that sits in front of multiple Services, using host and path-based rules (like routing api.example.com to one service and app.example.com to another) through a single entry point, usually backed by just one actual load balancer, handled by an Ingress controller (like NGINX or Traefik) running inside the cluster.
5. What is a headless service, and when would you use one?
A headless service (created by setting clusterIP: None) skips the usual virtual IP and load balancing entirely, instead, DNS lookups against it directly return the individual IP addresses of every matching Pod. This is useful when clients need to know about and connect to specific individual Pods rather than being load-balanced to an arbitrary one, which comes up a lot with StatefulSets, like a database cluster where a client specifically needs to talk to the primary node, not just any random replica.
ConfigMaps, Secrets and Storage
1. What's the difference between a ConfigMap and a Secret, given that Secrets aren't even encrypted by default?
A ConfigMap stores non-sensitive configuration data, feature flags, URLs, general settings, as plain key-value pairs. A Secret is meant for sensitive data, passwords, tokens, keys, and it's stored base64-encoded rather than plain text, which is worth being clear about in an interview, base64 encoding is not encryption, it's trivially reversible, so a Secret by default only really protects against someone glancing at it casually, real protection requires enabling encryption at rest for etcd and tightly controlling RBAC access to Secrets.
2. How do you actually inject a ConfigMap or Secret into a Pod, environment variables vs mounted files?
Both can be exposed to a Pod either as environment variables (each key becomes an env var inside the container) or as files mounted into the container's filesystem (each key becomes a file, with the value as its content). Environment variables are simpler for a handful of individual settings, but mounted files are usually better for larger configuration (like an entire config file) and for values that might change, since a mounted ConfigMap volume can actually update inside the running container without a restart in many cases, whereas environment variables are fixed at container start.
3. What is a PersistentVolume and a PersistentVolumeClaim, and how do they relate to each other?
A PersistentVolume (PV) represents an actual piece of storage in the cluster, provisioned either manually by an admin or dynamically by a storage class, it's the real, underlying storage resource. A PersistentVolumeClaim (PVC) is a request for storage made by a Pod's owner, "I need 10GB, ReadWriteOnce," and Kubernetes binds that claim to a matching available PersistentVolume. This separation lets application developers just ask for storage they need through a PVC without needing to know or care about the specific underlying storage infrastructure details.
4. What's the difference between a PersistentVolume's access modes?
ReadWriteOnce (RWO) means the volume can be mounted as read-write by a single node at a time, common for most block storage like a cloud disk. ReadOnlyMany (ROX) means multiple nodes can mount it simultaneously, but only for reading. ReadWriteMany (RWX) means multiple nodes can mount and write to it simultaneously, which requires storage that actually supports concurrent access, like NFS, and is a much less common capability than the other two among typical cloud storage options.
5. What happens to a Pod's data on its local filesystem when the Pod restarts or gets rescheduled to a different node?
Anything written to a Pod's own container filesystem, without an attached volume, is ephemeral, it's lost the moment the Pod is deleted or recreated, exactly like a plain Docker container's writable layer. If the Pod gets rescheduled to a completely different node, that's even more clearly lost since it's not even the same physical machine anymore. This is exactly why any data that needs to survive a Pod restart, actual application data, uploaded files, database storage, has to live on an attached PersistentVolume, not the container's own local filesystem.
Scaling, Health Checks and Production Practices
1. What's the difference between a liveness probe and a readiness probe, and what happens if you only configure one?
A liveness probe checks whether a container is still functioning correctly, if it fails repeatedly, Kubernetes kills and restarts the container, since something has clearly gone wrong internally. A readiness probe checks whether a container is ready to actually receive traffic, if it fails, the Pod is removed from the Service's pool of targets (but not restarted), which matters for things like a slow startup where the app is running but not yet ready to serve requests. If you only configure a liveness probe, a Pod that's alive but not actually ready yet (still warming up, still connecting to a database) could receive real user traffic prematurely and fail those requests.
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
2. What is the Horizontal Pod Autoscaler, and what does it actually watch to decide when to scale?
The Horizontal Pod Autoscaler (HPA) automatically adjusts the number of replicas in a Deployment (or similar controller) based on observed metrics, most commonly average CPU or memory utilization across the Pods, though it can also be configured against custom metrics like request rate. It continuously checks the current metric value against a target you've set, if average CPU usage is well above target, it scales up the replica count, if it's well below, it scales back down, within min/max bounds you configure.
3. What are resource requests and limits, and why does setting them matter for scheduling and stability?
A resource request is the amount of CPU/memory a container is guaranteed to get, and it's what the scheduler actually uses to decide which node has enough capacity to place the Pod on. A resource limit is the maximum amount a container is allowed to use, it can't exceed that no matter how much load it's under. Without requests set, the scheduler has no real basis for deciding whether a node can actually fit a Pod, which can lead to overcommitted nodes, and without limits, a single misbehaving container can starve every other Pod on the same node of resources.
4. What happens when a Pod exceeds its memory limit versus its CPU limit, why are they handled differently?
If a container exceeds its memory limit, it gets OOMKilled, the kernel forcibly terminates the process, since memory genuinely can't be "throttled" the way CPU can, a process either has the memory it needs or it doesn't. If a container exceeds its CPU limit, it isn't killed, it just gets throttled, the kernel restricts how much CPU time it's allowed, slowing it down but letting it keep running. This distinction matters, a memory limit set too low causes crashes, while a CPU limit set too low just causes degraded performance without an outright failure.
5. What is a namespace in Kubernetes, and what's it actually useful for beyond just "organizing things"?
A namespace is a way to logically partition a single cluster into multiple virtual sub-clusters, resources in one namespace are isolated from another by name (you can have a my-app Deployment in both a staging and production namespace without conflict). Beyond just organization, namespaces are the boundary for applying resource quotas (limiting how much CPU/memory a whole team or environment can consume) and RBAC permissions (restricting who can access or modify resources within a specific namespace), which makes them a real access-control and resource-governance tool, not just a naming convenience.
6. How would you debug a Pod that's stuck in CrashLoopBackOff?
CrashLoopBackOff means the container keeps starting and immediately crashing, and Kubernetes is backing off, waiting progressively longer between restart attempts. Start with kubectl describe pod <name> to check recent events and the exit code/reason, then kubectl logs <pod-name> (and --previous to see logs from the crashed container instance, since the current one is likely just starting fresh with no logs yet) to see the actual error the application is throwing on startup, which is usually enough to pinpoint whether it's a config issue, a missing dependency, a failing health check, or a genuine application bug.
kubectl describe pod my-app-7d9f8c
kubectl logs my-app-7d9f8c --previous
Struggling to Find a Job? Get Specific Batch Wise job Updates ✅ Check now