Bird
Raised Fist0
Kubernetesdevops~20 mins

Quality of Service classes (Guaranteed, Burstable, BestEffort) in Kubernetes - Practice Problems & Coding Challenges

Choose your learning style10 modes available
Challenge - 5 Problems
🎖️
Kubernetes QoS Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
🧠 Conceptual
intermediate
1:30remaining
Understanding Kubernetes QoS Classes

Which Quality of Service (QoS) class in Kubernetes guarantees that a pod will never be evicted due to resource contention?

ABestEffort
BBurstable
CGuaranteed
DNone of the above
Attempts:
2 left
💡 Hint

Think about which class requires both requests and limits to be set equally.

💻 Command Output
intermediate
1:30remaining
Identifying QoS Class from Pod Description

Given the following pod YAML snippet, what is the QoS class assigned to this pod?

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "100Mi"
        cpu: "100m"
      limits:
        memory: "200Mi"
        cpu: "200m"
ABurstable
BGuaranteed
CBestEffort
DNo QoS class assigned
Attempts:
2 left
💡 Hint

Check if requests and limits are equal for all resources.

❓ Configuration
advanced
1:30remaining
Configuring a Pod for BestEffort QoS Class

Which pod resource configuration will result in the pod being assigned the BestEffort QoS class?

AContainers have no resource requests or limits defined
BContainers have resource requests but no limits
CContainers have resource limits but no requests
DContainers have equal resource requests and limits
Attempts:
2 left
💡 Hint

BestEffort pods do not reserve any resources.

❓ Troubleshoot
advanced
1:30remaining
Pod Eviction Behavior Under Resource Pressure

You notice that a pod with resource requests and limits set differently is evicted during node resource pressure. What is the most likely QoS class of this pod?

ABestEffort
BGuaranteed
CNo QoS class
DBurstable
Attempts:
2 left
💡 Hint

Recall eviction priority order based on QoS classes.

🔀 Workflow
expert
2:00remaining
Determining QoS Class Using kubectl

You want to check the QoS class of a running pod named web-server. Which kubectl command will show this information directly?

Akubectl describe pod web-server | grep QoS
Bkubectl get pod web-server -o jsonpath='{.status.qosClass}'
Ckubectl get pod web-server --show-labels
Dkubectl logs web-server | grep QoS
Attempts:
2 left
💡 Hint

Look for a command that extracts the QoS class from pod status.

Practice

(1/5)
1. Which Kubernetes Quality of Service (QoS) class guarantees that a pod will always get the resources it requests?
easy
A. Burstable
B. Guaranteed
C. BestEffort
D. Reserved

Solution

  1. Step 1: Understand QoS classes in Kubernetes

    There are three main QoS classes: Guaranteed, Burstable, and BestEffort. Guaranteed means the pod has resource requests equal to limits.
  2. Step 2: Identify which class ensures resource guarantees

    Guaranteed pods always get the resources they request because requests and limits match exactly.
  3. Final Answer:

    Guaranteed -> Option B
  4. Quick Check:

    Guaranteed = full resource guarantee [OK]
Hint: Guaranteed means requests equal limits, so full resource guarantee [OK]
Common Mistakes:
  • Confusing Burstable with Guaranteed
  • Thinking BestEffort has resource guarantees
  • Assuming Reserved is a QoS class
2. Which of the following pod resource specifications will result in a Burstable QoS class?
easy
A. resources:\n requests:\n cpu: '200m'\n memory: '128Mi'\n limits:\n cpu: '500m'\n memory: '256Mi'
B. resources:\n requests:\n cpu: '500m'\n memory: '256Mi'\n limits:\n cpu: '500m'\n memory: '256Mi'
C. resources:\n requests:\n cpu: '0'\n memory: '0'\n limits:\n cpu: '0'\n memory: '0'
D. resources: {}

Solution

  1. Step 1: Review resource requests and limits for QoS classes

    Guaranteed requires requests equal to limits. Burstable requires requests less than limits. BestEffort has no requests or limits.
  2. Step 2: Match the given specs to Burstable

    resources:\n requests:\n cpu: '200m'\n memory: '128Mi'\n limits:\n cpu: '500m'\n memory: '256Mi' has requests less than limits, so it is Burstable.
  3. Final Answer:

    requests less than limits -> Option A
  4. Quick Check:

    Burstable = requests < limits [OK]
Hint: Burstable means requests less than limits, not equal [OK]
Common Mistakes:
  • Choosing equal requests and limits as Burstable
  • Assuming empty resources means Burstable
  • Confusing zero requests with BestEffort
3. Given this pod spec snippet, what QoS class will Kubernetes assign?
resources:
  requests:
    cpu: '100m'
    memory: '128Mi'
  limits:
    cpu: '100m'
    memory: '128Mi'
medium
A. Burstable
B. BestEffort
C. null
D. Guaranteed

Solution

  1. Step 1: Compare requests and limits in the pod spec

    Requests and limits for both CPU and memory are equal (100m CPU and 128Mi memory).
  2. Step 2: Determine QoS class based on equality

    When requests equal limits for all resources, Kubernetes assigns Guaranteed QoS.
  3. Final Answer:

    Guaranteed -> Option D
  4. Quick Check:

    Requests = Limits means Guaranteed [OK]
Hint: Equal requests and limits means Guaranteed QoS [OK]
Common Mistakes:
  • Choosing Burstable when requests equal limits
  • Thinking BestEffort applies with resource specs
  • Selecting null as a QoS class
4. Given this pod spec snippet, what QoS class will Kubernetes assign?
resources:
  requests:
    cpu: '0'
    memory: '0'
medium
A. BestEffort
B. Burstable
C. Guaranteed
D. It will cause a syntax error

Solution

  1. Step 1: Analyze the resource specification

    Requests are set to cpu: '0' and memory: '0', with no limits defined.
  2. Step 2: Apply QoS classification rules

    Requests are specified but zero values are treated as no requests. No limits are defined. This qualifies as BestEffort, since no resource requests or limits are effectively set.
  3. Final Answer:

    BestEffort -> Option A
  4. Quick Check:

    No requests or limits means BestEffort [OK]
Hint: Zero requests with no limits -> BestEffort (not Burstable) [OK]
Common Mistakes:
  • Thinking it causes a syntax error
  • Assuming zero requests means BestEffort
  • Believing it qualifies as Guaranteed
5. You want to ensure a pod gets guaranteed CPU and memory resources but also allow it to burst beyond the requested amount when available. Which resource configuration and QoS class combination achieves this?
hard
A. Set no requests or limits; QoS class BestEffort
B. Set requests equal to limits; QoS class Guaranteed
C. Set requests less than limits; QoS class Burstable
D. Set limits less than requests; QoS class Burstable

Solution

  1. Step 1: Understand resource guarantees and bursting

    Guaranteed QoS requires requests equal to limits, which means no bursting beyond limits. Burstable allows requests less than limits, enabling bursting.
  2. Step 2: Match configuration to desired behavior

    Setting requests less than limits gives minimum guaranteed resources with ability to burst, which is Burstable QoS.
  3. Final Answer:

    Set requests less than limits; QoS class Burstable -> Option C
  4. Quick Check:

    Burstable = guaranteed minimum + burst capacity [OK]
Hint: Burstable = requests less than limits for bursting [OK]
Common Mistakes:
  • Choosing Guaranteed which disallows bursting
  • Setting limits less than requests (invalid)
  • Assuming BestEffort provides guarantees
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard