Create a deployment spec file that will: Launch 7 replicas of the nginx Image with the labelapp_runtime_stage=dev Deployment name: kual00201 Save a copy of this spec file to…

Question

Explanation

Kubernetes Deployment Spec - Exam Explanation

Overall Goal

This task tests whether you can declaratively define a Kubernetes Deployment, save the manifest as a file, apply it to the cluster, and then clean up after yourself. The key skill being tested is understanding the relationship between a YAML spec, kubectl apply, and resource lifecycle management.

Why This Approach Is Correct

Kubernetes resources are best managed declaratively (via spec files) rather than imperatively (via ad-hoc kubectl run commands). Saving the spec to a file is both a task requirement and a real-world best practice - it's how GitOps and CI/CD pipelines work.

Step-by-Step Breakdown

Step 1 - Create the output directory (if it doesn't exist)

mkdir -p /opt/KUAL00201

Why: The spec must be saved to /opt/KUAL00201/. If the directory doesn't exist, the file write will fail. The -p flag silently succeeds if it already exists.

Step 2 - Generate the Deployment manifest

You can either write it from scratch or use kubectl to generate a dry-run template:

kubectl create deployment kual00201 \
  --image=nginx \
  --replicas=7 \
  --dry-run=client \
  -o yaml > /opt/KUAL00201/spec_deployment.yaml

Why --dry-run=client -o yaml: This generates the manifest without creating anything in the cluster yet, giving you a valid YAML template to edit and save.

What the resulting YAML must contain:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kual00201
  labels:
    app_runtime_stage: dev      # <-- required label on the Deployment
spec:
  replicas: 7
  selector:
    matchLabels:
      app_runtime_stage: dev    # <-- must match the Pod template labels
  template:
    metadata:
      labels:
        app_runtime_stage: dev  # <-- required label on each Pod
    spec:
      containers:
      - name: nginx
        image: nginx

Critical detail - labels appear in THREE places:

The selector and template.metadata.labels must match exactly or Kubernetes will reject the Deployment with a validation error.

Step 3 - Apply the spec to the cluster

kubectl apply -f /opt/KUAL00201/spec_deployment.yaml

Why: The question says to create the deployment, which means it must actually exist in the cluster - not just as a file. This step materializes the 7 nginx Pods.

Why apply over create: apply is idempotent (safe to re-run), while kubectl create will error if the resource already exists.

Step 4 - Verify the deployment

kubectl get deployment kual00201
kubectl get pods -l app_runtime_stage=dev

Why: Confirm all 7 replicas are running and the label selector is working before the task is considered complete. In an exam, partial credit may depend on a healthy deployment.

Step 5 - Clean up the Kubernetes objects

kubectl delete deployment kual00201

Why: The question explicitly requires cleaning up any API objects created. The file at /opt/KUAL00201/spec_deployment.yaml is not a Kubernetes API object - it lives on the filesystem, so you do not delete it. Only the in-cluster Deployment (and its managed Pods/ReplicaSet) must be deleted.

What gets cascade-deleted automatically: When you delete the Deployment, Kubernetes automatically deletes its ReplicaSet and all 7 Pods. You don't need to delete them manually.

What Goes Wrong If Steps Are Skipped

Memory Tip

Think of the label requirement as the "3-layer sandwich":

Deployment metadata → selector → Pod template

All three layers must have the same label for Kubernetes to "hold the sandwich together." Miss any layer and the resource either fails or leaks Pods.

For the cleanup rule, remember: "delete the cluster object, keep the file." The question asks you to save a copy precisely because it should survive the cleanup.

No community discussion yet for this question.