Kubernetes Quiz

policyTypes defaults based on which rule types are present in the spec. A NetworkPolicy with only ingress rules and no explicit policyTypes only restricts ingress - egress from those pods is untouched.

A Role by itself only defines a list of possible permissions, it doesn't tell you who actually HAS them, that's a separate RoleBinding. describe role shows you the rules on the Role itself, while auth can-i --list --as=<user> tells you what's actually, effectively granted to a specific person or service account, so checking both gives you the complete picture.

metrics-server samples periodically (commonly every 15-60s), so a brief spike that crosses the cgroup memory limit and gets OOM-killed can easily happen between two samples, leaving no trace in the metrics you can see afterward.

Node affinity lets you constrain which nodes a pod CAN be scheduled on based on node labels, which is exactly the "prefer or require these nodes" use case. Taints work in the opposite direction: they repel pods away from nodes unless the pod has a matching toleration, so tainting every non-SSD node would technically work but is far more invasive than just labeling the SSD nodes and using affinity. A PodDisruptionBudget only limits voluntary disruptions during maintenance and has nothing to do with initial scheduling.

Pod-to-Pod traffic and Node IP assignment are handled elsewhere, and secrets have their own dedicated object entirely. An Ingress sits at the cluster's edge and routes incoming external HTTP/HTTPS traffic to the right internal Service based on rules you define, like which hostname or URL path was requested, something a plain Service can't do on its own.

TLS Secrets referenced by an Ingress must live in the same namespace as the Ingress itself. If the Secret isn't found there, most controllers silently serve their built-in default certificate instead of erroring.

A Node is a machine, and a Cluster is a group of Nodes, both much bigger units than what gets deployed. A Container is close, but Kubernetes doesn't actually deploy bare containers, it always wraps one or more containers together in a Pod, making the Pod the smallest thing Kubernetes actually schedules and manages.

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.

When multiple NetworkPolicy resources select the same pod, their rules are combined as a union, not an intersection. A pod ends up allowing everything any applicable policy permits.

Storage, scheduling, and image registries are all handled by other things entirely, none of them are a Service's job. Because Pod IPs constantly change as Pods come and go, a Service's whole purpose is to give a stable name and address that always routes to whichever matching Pods happen to be running right now.