FreeExam
A closed notebook, a blank card, and a pencil on a wooden desk.

Kubernetes operations

20 cards

Scheduling failures, rollout capacity, probes, service routing, storage, and safe diagnosis of stuck workloads.

Card 1 of 20

Front. Pending. A pod stays Pending although some nodes show low CPU use. What should be checked first?

These cards are original study material. They are not questions from a named employer or a live hiring loop.

All 20 cards in this deck

  1. 1.Pending

    A pod stays Pending although some nodes show low CPU use. What should be checked first?

    Scheduler events and requested resources, node selectors, taints, affinity, and volume constraints. Scheduling uses declared constraints and reservations, not just instantaneous utilization.

  2. 2.Request Limit

    Why can a pod fit at scheduling time yet later be throttled?

    CPU requests guide placement while limits can cap runtime CPU consumption. Inspect both and measure throttling before changing replica count.

  3. 3.Startup Probe

    A slow-starting application repeatedly fails liveness before initialization finishes. What probe change fits?

    Use a startup probe with a realistic initialization budget so liveness does not kill healthy startup work. Avoid simply making all failure detection indefinitely slow.

  4. 4.Readiness Dependency

    Why can making readiness depend on every downstream service worsen a shared outage?

    All replicas may become unready simultaneously, removing useful degraded service. Define readiness around the traffic the instance can safely handle and test dependency-failure behavior.

  5. 5.Crashloop

    What does CrashLoopBackOff identify, and what does it not explain?

    It indicates repeated container failures with restart backoff. Inspect prior-container logs, exit reasons, events, and configuration to find the actual failure.

  6. 6.Imagepull

    Why should ImagePullBackOff investigation distinguish authentication, image identity, and network reachability?

    They require different fixes. Inspect event details, registry credentials, digest or tag existence, DNS, and egress rather than repeatedly restarting the pod.

  7. 7.Pdb Boundary

    Does a PodDisruptionBudget guarantee availability during node crashes or Deployment rollouts?

    No. It constrains supported voluntary eviction operations. Involuntary failures and workload-controller rollout behavior need separate capacity and rollout controls.

  8. 8.Pdb Drain

    A node drain is blocked by a disruption budget. What should be established before overriding it?

    Which availability requirement would be violated and whether replacement capacity can become ready. Fix scheduling or capacity first when possible; bypassing the budget removes its protection.

  9. 9.Surge Capacity

    Why can a rolling update stall when maxSurge permits extra pods?

    The cluster may lack resources or quota for the surge, or replacements may never become ready. Budget rollout headroom and inspect events rather than assuming the setting creates capacity.

  10. 10.Service Empty

    A Service exists but has no usable backends. What should be compared?

    Its selector, matching pod labels, readiness, EndpointSlices, and target ports. A Service object alone does not establish a route to a functioning application.

  11. 11.Port Mismatch

    Pods answer on port 8080 but the Service fails. Which port distinction matters?

    The Service's exposed port and targetPort are different concepts. Verify targetPort resolves to the actual container listener and test from the same network context as callers.

  12. 12.Networkpolicy

    A default-deny egress policy breaks an otherwise unchanged application. What common dependency is easily missed?

    DNS access, along with required service and external destinations. Policies need the actual dependency paths, and enforcement depends on the network implementation.

  13. 13.Config Env

    Why does updating a ConfigMap not change a running process's environment variables?

    Environment values are established when the container starts. Roll out new pods or use a supported reloadable configuration mechanism; do not assume all ConfigMap consumption modes behave alike.

  14. 14.Secret Rotation

    What must be verified after rotating a mounted credential?

    That the application rereads and successfully uses it, existing connections behave as intended, and the old credential can be revoked. Updating an object does not prove end-to-end rotation.

  15. 15.Pvc Pending

    What evidence helps diagnose a PersistentVolumeClaim that remains Pending?

    StorageClass, provisioner events, topology, access mode, capacity, and binding mode. Some claims intentionally wait for a consuming pod before selecting storage placement.

  16. 16.Statefulset Boundary

    Does a StatefulSet make a database replicated and safely fail over?

    No. It provides stable workload identity and storage association. Database replication, quorum, fencing, backup, and recovery remain application-level responsibilities.

  17. 17.Finalizer

    A resource is stuck terminating. Why is deleting its finalizer potentially unsafe?

    The finalizer may guard cleanup of external resources. Inspect the owning controller and pending cleanup; removing it can leave orphaned infrastructure or violate deletion invariants.

  18. 18.Termination Budget

    Why does a long preStop hook leave less time for the application's shutdown handler?

    The pod's termination grace period includes hook execution. Budget hook and application draining together and verify behavior when the deadline expires.

  19. 19.Hpa Denominator

    Why can changing CPU requests alter CPU-utilization-based autoscaling without changing workload CPU usage?

    Utilization is measured relative to requests. A different denominator changes the scaling signal; choose requests and scaling targets together using observed workload behavior.

  20. 20.Debug Sequence

    What should be captured before deleting a failing pod to see if it recovers?

    Events, current and previous logs, exit reasons, resource usage, and relevant configuration identity. A restart may restore service while erasing the evidence needed to prevent recurrence.