nerdexam
Linux_Foundation

CKAD · Question #10

Please complete the following: Update the app deployment in the kdpd00202 namespace with a maxSurge of 5% and a maxUnavailable of 25%. Perform a rolling update of the web1 deployment, changing the…

The exam requires the test-taker to execute specific kubectl commands in a web terminal to manage Kubernetes deployments, including modifying rolling update strategies, updating container images, and rolling back deployments.

Submitted by noor.lb· May 4, 2026Application Deployment

Question

Please complete the following:
  • Update the app deployment in the kdpd00202 namespace with a maxSurge of 5% and a maxUnavailable of 25%.
  • Perform a rolling update of the web1 deployment, changing the lfccncl/ngmx image version to 1.13
  • Roll back the app deployment to the previous version

Exhibit

CKAD question #10 exhibit

Explanation

The exam requires the test-taker to execute specific kubectl commands in a web terminal to manage Kubernetes deployments, including modifying rolling update strategies, updating container images, and rolling back deployments.

Approach. The correct approach involves typing the following kubectl commands sequentially into the provided web terminal:

  1. Update the app deployment's rolling update strategy:

    • Command: kubectl edit deployment app -n kdpd00202
    • Interaction: This command will open the YAML definition of the app deployment in the kdpd00202 namespace using a text editor (e.g., vi/vim). The test-taker must navigate to the spec.strategy section. If strategy or rollingUpdate blocks are not present, they need to be added. Under spec.strategy.rollingUpdate, add or modify the following lines:
      spec:
        strategy:
          type: RollingUpdate
          rollingUpdate:
            maxSurge: 5%
            maxUnavailable: 25%
      
      After making these changes, save and exit the editor (e.g., :wq in vim).
    • Reasoning: kubectl edit allows for direct, interactive modification of live Kubernetes objects. Modifying maxSurge and maxUnavailable under spec.strategy.rollingUpdate directly controls how a rolling update behaves, ensuring a specific percentage of new pods can be created above the desired count and how many old pods can be unavailable during the update.
  2. Perform a rolling update of web1 deployment with a new image version:

    • Command: kubectl set image deployment/web1 web1=lfccncl/ngmx:1.13
    • Interaction: Type this command directly into the terminal and press Enter.
    • Reasoning: kubectl set image is the most direct and idiomatic command to perform a rolling update by changing the container image. deployment/web1 targets the specific deployment. web1=lfccncl/ngmx:1.13 specifies that the container named web1 within that deployment should have its image updated to lfccncl/ngmx:1.13. (It's assumed the container running lfccncl/ngmx image is named web1. If not, the container's actual name should be used, e.g., <container-name>=lfccncl/ngmx:1.13). This command automatically initiates a rolling update.
  3. Roll back the app deployment to the previous version:

    • Command: kubectl rollout undo deployment/app -n kdpd00202
    • Interaction: Type this command directly into the terminal and press Enter.
    • Reasoning: kubectl rollout undo is the command used to revert a deployment to its immediately preceding revision. deployment/app specifies the target deployment, and -n kdpd00202 ensures the rollback happens in the correct namespace (assuming it refers to the same app deployment from task 1).

Common mistakes.

  • common_mistake. Common mistakes include:
  • Incorrect kubectl commands or syntax: Forgetting deployment/ prefix or typos in deployment names, image names, or percentages (e.g., 5 instead of 5%).
  • Not specifying the namespace (-n kdpd00202): Tasks 1 and 3 explicitly mention the kdpd00202 namespace. If the current kubectl context's namespace is different, omitting -n will lead to the command failing with 'deployment not found' or incorrectly modifying a deployment in the default namespace.
  • Modifying the image directly via kubectl edit for Task 2: While technically possible, kubectl set image is the more precise and recommended command for image updates, as it explicitly signals an image change that should trigger a new rollout revision.
  • Using kubectl apply -f with a manually generated YAML file for Task 1: This is a more cumbersome and error-prone approach for interactive changes compared to kubectl edit, which directly pulls and pushes the live object's definition.
  • Not knowing the container name for kubectl set image: If the container running the lfccncl/ngmx image inside the web1 deployment is not named web1, the command kubectl set image deployment/web1 web1=lfccncl/ngmx:1.13 would fail. The test-taker might need to first use kubectl describe deployment web1 or kubectl get deployment web1 -o yaml to identify the correct container name.
  • Attempting to apply the nginx_resources.yml from the exhibit images: The exhibit images show an example file and commands unrelated to the actual tasks. Applying or modifying that nginx_resources.yml would be irrelevant to solving the problem.

Concept tested. The core concepts tested are Kubernetes Deployment management, including:

  • Understanding and configuring rolling update strategies (maxSurge, maxUnavailable).
  • Performing rolling updates by updating container images within a Deployment.
  • Rolling back a Deployment to a previous revision.
  • Proficiency with kubectl commands (kubectl edit, kubectl set image, kubectl rollout undo).
  • Understanding of Kubernetes object definitions (specifically Deployment YAML structure).
  • Awareness of Kubernetes namespaces and how to specify them in kubectl commands.

Topics

#Deployments#Rolling Updates#Rollbacks#Deployment Strategy

Community Discussion

No community discussion yet for this question.

Full CKAD Practice