yoklainterview sim
ProgressHistory

DevOps / Cloud K8s Scheduling Resources Interview Questions

75 verified DevOps / Cloud K8s Scheduling Resources interview questions — solve with answers, learn from explanations, test yourself in a real simulation.

Try the real simulation →

Sample questions

K8s Scheduling ResourcesDifficulty 1
In a Pod's container spec, what is the core difference between resources.requests and resources.limits?
  • aBoth fields are used only by the kubelet to enforce a hard ceiling on usage at runtime.
  • brequests are used by the scheduler to find a node with capacity; limits are enforced by the kubelet at runtime.✓
  • crequests are enforced by the kubelet as a runtime ceiling; limits are only used by the scheduler.
  • drequests and limits are interchangeable fields with no functional difference.
Explanation:The scheduler reads requests to decide which node has enough reservable capacity for the Pod. limits are enforced independently by the kubelet/container runtime while the container is running, regardless of which node it landed on.
K8s Scheduling ResourcesDifficulty 2
A container's actual CPU usage tries to exceed its resources.limits.cpu value. What happens to the container?
  • aIt keeps running but its CPU usage is throttled to stay within the limit.✓
  • bThe kubelet immediately terminates the container with reason OOMKilled.
  • cThe Pod is evicted and rescheduled onto a different node right away.
  • dThe container restarts regardless of the Pod's configured restart policy.
Explanation:CPU is a compressible resource. Exceeding a CPU limit results in CFS throttling of the process, not termination — unlike memory, there is no kill mechanism for CPU overuse.
K8s Scheduling ResourcesDifficulty 1
A container's actual memory usage exceeds its resources.limits.memory value. What is the typical outcome?
  • aThe container is throttled the same way CPU overuse is throttled, without being restarted.
  • bThe Pod moves to Pending state until more memory becomes available on the node.
  • cThe container process is killed by the kernel, and its last state shows reason OOMKilled.✓
  • dThe limit is silently ignored and the container keeps consuming memory beyond it.
Explanation:Memory is a non-compressible resource. When usage crosses the container's memory limit, the kernel's OOM killer terminates the process, and kubectl describe pod reports the container's last terminated state as OOMKilled.
K8s Scheduling ResourcesDifficulty 2
You apply this Pod on a single-node cluster where the node has far less than 100Gi of allocatable memory:
apiVersion: v1
kind: Pod
metadata:
  name: big-request
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sleep", "3600"]
    resources:
      requests:
        memory: "100Gi"
        cpu: "500m"

kubectl get pod big-request shows STATUS Pending. What does the Events section of kubectl describe pod big-request most likely show?
  • aWarning ImagePullBackOff: back-off pulling image "busybox"
  • bWarning CrashLoopBackOff: back-off restarting failed container
  • cWarning FailedScheduling: 0/1 nodes are available: 1 Insufficient cpu.
  • dWarning FailedScheduling: 0/1 nodes are available: 1 Insufficient memory.✓
Explanation:The requested 100Gi of memory exceeds what the single node can offer, so the scheduler cannot place the Pod. The Events section reports a FailedScheduling warning naming the exact resource that could not be satisfied — here, memory, not CPU.
K8s Scheduling ResourcesDifficulty 2
A Pod has a single container where resources.requests and resources.limits are set to the exact same values for both CPU and memory. What QoS class does Kubernetes assign to this Pod?
  • aGuaranteed✓
  • bBurstable
  • cBestEffort
  • dReserved (a class Kubernetes uses only for control-plane Pods)
Explanation:A Pod gets the Guaranteed QoS class only when every container specifies requests equal to limits for both CPU and memory. "Reserved" is not a real Kubernetes QoS class.
K8s Scheduling ResourcesDifficulty 2
A Pod's container sets resources.requests.memory to a value lower than resources.limits.memory (and/or requests are set without matching limits on every resource). What QoS class does the Pod get?
  • aGuaranteed
  • bBurstable✓
  • cBestEffort
  • dThe Pod cannot be scheduled unless requests exactly match limits.
Explanation:When at least one container has requests set but they don't equal limits across every resource type, the Pod falls into the Burstable class — between Guaranteed (requests==limits everywhere) and BestEffort (nothing set).

By specialization

AWS 450Azure 450GCP 450Kubernetes 450Linux 450Terraform 450

By seniority

DevOps / Cloud JuniorDevOps / Cloud MidDevOps / Cloud Senior

Other fields

BackendFrontendFullstackAI EngineerDatabaseMobileSecurityQA / Test AutomationData EngineerGame DevelopmentML Engineer

Test yourself against the 3375-question DevOps / Cloud bank.

Start interview