XK0-006 Automation, Orchestration, and Scripting Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  metadata.replicas

  Why it's wrong here

  metadata holds identifying fields such as name, namespace and labels, not replica counts, so the API server rejects replicas there as an unknown field. Metadata is where you would legitimately set labels and annotations for selection and organisation, which makes it tempting when hunting for a field that controls pod behaviour.

• ✗

  spec.template.replicas

  Why it's wrong here

  Placing replicas under spec.template nests it inside the pod template, where the API server rejects it as an unknown field; replica count belongs at spec.replicas, one level above the template. The template block is genuinely for pod-level settings such as container images and labels, so it is tempting when scanning for where pods are defined.

• ✗

  spec.containers.replicas

  Why it's wrong here

  spec.containers is an array of container definitions inside the pod template, holding image, ports and resources; replicas is not a valid container key, so the manifest fails validation. Container-level fields are tempting because they configure the running workload, but replica count is a Deployment-level concern, set at spec.replicas.

• ✓

  spec.replicas

  Why this is correct

  The replicas field sits under the Deployment's spec, declaring the desired pod count that the ReplicaSet controller continuously reconciles. Setting spec.replicas to the required number satisfies the stem's demand for specifying how many identical pods run concurrently.