Practice Test Geeks(SRE) Site Reliability Engineering Foundation Certification Practice Test
← All SRE Flashcard Decks

Kubernetes and Container Orchestration Flashcards

6 cards from real SRE practice questions. Tap to flip, then mark Knew It or Still Learning — missed cards come back until you master them.

Read the first 6 Kubernetes and Container Orchestration flashcards as text

  1. What is the purpose of Kubernetes resource requests and limits, and what happens when a container exceeds its CPU limit?

    Answer: Requests are used for scheduling decisions (the minimum guaranteed resources); limits cap usage. A container that exceeds its CPU limit is throttled (not killed), while exceeding memory limits causes OOMKill

    CPU limits cause throttling (reduced CPU time) not termination. Memory limits cause OOMKill. Requests inform the scheduler about the minimum resources needed for a pod to be placed on a node.

  2. What is a Kubernetes StatefulSet, and when should it be used instead of a Deployment?

    Answer: A StatefulSet provides stable network identifiers and persistent storage for each pod, making it appropriate for stateful applications like databases that require ordered deployment and stable hostnames

    StatefulSets provide stable, unique pod identifiers (pod-0, pod-1), stable DNS names, and ordered rolling updates — critical for databases and clustered applications that rely on stable member identities.

  3. What is a Kubernetes NetworkPolicy, and what is the default behavior if no NetworkPolicy exists in a namespace?

    Answer: NetworkPolicies are firewall rules for pods; by default (no NetworkPolicy), all pods can communicate freely with all other pods in the cluster — the default is allow-all

    By default, Kubernetes allows all pod-to-pod communication across all namespaces (open network). NetworkPolicies selectively restrict this by defining ingress/egress rules — but require a CNI plugin that supports them (e.g., Calico, Cilium) to take effect.

  4. What is the Kubernetes Operator pattern, and what problem does it solve?

    Answer: Operators encode the knowledge of running a complex stateful application (e.g., a database) as code, automating tasks like provisioning, scaling, backups, and failure recovery that would otherwise require manual expertise

    The Operator pattern extends the Kubernetes API with custom resources and controllers that automate the lifecycle management of complex applications, encoding the operational expertise of a human administrator into software.

  5. A Kubernetes node is marked as 'NotReady.' What is the MOST likely impact on pods running on that node?

    Answer: After the node remains NotReady beyond the pod eviction timeout (default 5 minutes), the pods are evicted and rescheduled on healthy nodes, subject to pod disruption budgets

    Kubernetes does not immediately evict pods from a NotReady node — it waits for the configured toleration seconds (default: 5 minutes for node.kubernetes.io/not-ready) before evicting and rescheduling pods, providing a buffer for transient node issues.

  6. What is the role of etcd in a Kubernetes cluster, and why is it critical to its reliability?

    Answer: etcd is the distributed key-value store that persists all cluster state (pod specs, ConfigMaps, Secrets, RBAC policies, etc.); if etcd is unavailable, the API server cannot function and the cluster cannot be managed

    etcd is Kubernetes' single source of truth — every object definition, configuration, and status is persisted in etcd. Loss of etcd quorum means no cluster state changes can be made, and restoring from backup may be the only recovery option.