← All KCNA Flashcard Decks

Pod Management & Scheduling Flashcards

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

Read the first 7 Pod Management & Scheduling flashcards as text
  1. Which field enables a Pod to run as a specific user ID at the container level?

    Answer: securityContext.runAsUser

    Setting `securityContext.runAsUser` in a container spec makes the container process run as the specified UID.

  2. What is the role of the `scheduler.alpha.kubernetes.io/node` annotation on a Pod?

    Answer: It manually assigns the pod to a specific node, bypassing the scheduler

    Setting `nodeName` (or the legacy node annotation) bypasses the scheduler entirely and directly binds the pod to the named node.

  3. A readiness probe failing on a pod causes which behavior?

    Answer: The pod's IP is removed from the Service's Endpoints, stopping traffic

    A failing readiness probe removes the pod from Service endpoints so no traffic is routed to it, without killing the container.

  4. Which Kubernetes concept allows a pod to request exclusive access to a GPU or custom device on a node?

    Answer: Device Plugins and resource limits with extended resources

    Device Plugins expose custom resources (like `nvidia.com/gpu`) that pods can request via `resources.limits` in their container spec.

  5. What happens to pods managed by a ReplicaSet when you manually delete one of them?

    Answer: The ReplicaSet controller creates a replacement pod to maintain the desired replica count

    The ReplicaSet controller continuously reconciles actual vs desired state and immediately creates a new pod to replace the deleted one.

  6. Which field in a Pod spec prevents a pod from being scheduled on a node that already runs a pod with a matching label?

    Answer: affinity.podAntiAffinity

    `podAntiAffinity` rules repel a pod from nodes that already host pods matching the specified label selector.

  7. In Kubernetes, what is a 'sidecar container' pattern?

    Answer: An auxiliary container in the same Pod that extends or supports the main application container

    A sidecar is a co-located container in the same pod that provides supporting functionality like logging, proxying, or config sync alongside the main app.