CKAD Application Design and Build 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.

• ✓

  Create the Deployment, define the Service (NodePort type) manifest, apply the Service manifest, retrieve the NodePort from the Service, then access externally via nodeIP:NodePort.

  Why this is correct

  This is the correct order because the workload must exist before exposing it; the Service must be defined and applied to create the NodePort, then you retrieve the port number to access the application externally.

• ✗

  Define the Service manifest, retrieve the NodePort, create the Deployment, apply the Service, then access externally.

  Why it's wrong here

  This sequence attempts to retrieve the NodePort from the Service before the Service has been applied to the cluster. Retrieval (e.g., `kubectl get svc`) queries the live cluster state, and a manifest alone does not allocate a NodePort or create a Service object. Additionally, creating the Deployment only after defining the Service inverts the typical dependency: while a Service can technically be defined before its backing Pods exist, the intended workflow is to ensure the workload is running first, then expose it. The correct sequence must apply the Service before querying its allocated port.

• ✗

  Create the Deployment, apply the Service manifest, define the Service manifest, retrieve the NodePort, then access externally.

  Why it's wrong here

  Applying a manifest before defining it is nonsensical in a declarative workflow: `kubectl apply -f` requires a valid manifest file as input, and merely defining it afterward cannot retroactively create the Service. Even if you interchanged the definition and apply steps, the NodePort should only be retrieved after the apply succeeds, because the port is assigned by the control plane at creation time. This sequence also omits the logical step of checking that the Deployment's Pods are ready before exposing, but the primary flaw is the reversed define/apply ordering.

• ✗

  Create the Deployment, define the Service manifest, retrieve the NodePort, apply the Service, then access externally.

  Why it's wrong here

  This sequence correctly creates the Deployment and defines the Service manifest, but it retrieves the NodePort before applying the Service. The NodePort is not a static attribute of the manifest; it is dynamically allocated and stored in the Service's status when the Service is created in the cluster. Until `kubectl apply -f service.yaml` runs, the Service object does not exist, so any retrieval command fails or returns nothing. Only after the apply can you query the Service and obtain the `nodePort`, then construct the external URL.

Go deeper

Related to this question