Kubernetes Interview Questions & Answers

Unless you explicitly ask for something else, a new Service defaults to ClusterIP, meaning it only gets an internal address reachable from inside the cluster. You have to specifically choose NodePort, LoadBalancer, or ExternalName if you want it reachable differently.

A CPU 'request' isn't a cap, it's a reservation: it tells the scheduler 'guarantee this container half a CPU core when deciding which node to place it on'. It's a completely separate setting from a CPU 'limit', which is what actually caps how much CPU the container is allowed to use once running.

Kubernetes only keeps a limited number of old ReplicaSets per revisionHistoryLimit (default 10). If the last known-good revision has already aged out, undo has nothing valid to restore and can effectively re-apply the current broken state.

kubectl apply reads whatever's described in a YAML file and either creates it (if it doesn't exist) or updates it (if it does), which is exactly the 'point at this file and make the cluster match it' behavior you want for deploying from app.yaml.

A rolling update waits for new pods to pass their readiness probe before continuing to replace old ones. A pod stuck at Running-but-not-Ready halts the whole rollout, since the Deployment controller won't take down more old pods than the strategy allows.

'Ephemeral volume' is really just the general idea of 'storage whose life is tied to the Pod's life', and emptyDir is one specific way to implement that idea. Other kinds like CSI ephemeral, configMap, and secret volumes are also ephemeral volumes, so emptyDir isn't a separate, competing thing, it's one member of that same family.

When you need to see what a container has actually printed out (its stdout/stderr), kubectl logs is the direct route to that output, rather than describe (which shows events and status) or exec (which runs a command inside the container instead of reading its own logs).

A Pod only shows as Pending BEFORE it's been scheduled onto a node, and everything else in this list (not enough resources, no matching node, an unbound volume claim) are all things that block scheduling itself. An image pull failure happens AFTER a Pod is already scheduled onto a node, which is why it shows up as ImagePullBackOff instead, not Pending.

Locking down a container properly usually takes more than one setting: runAsNonRoot stops it from running as root, capabilities.drop: ["ALL"] strips away extra Linux permissions it doesn't need, and allowPrivilegeEscalation: false stops it from gaining MORE privileges than it started with. Using all of these together, not just one, is what actually hardens the container.

Building images is Docker's job, not Kubernetes', and hardware monitoring and DNS management are unrelated, separate systems entirely. `kubectl` is the command-line client that talks to a cluster's API server, letting you create, inspect, update, and delete Kubernetes resources like Pods and Services.