CKA 1

✔️ Correct Answer: A

Explanation:

A. ✅ Correct Option

• Initializes the master node with required --ignore-preflight-errors=all.

• Sets up kubeconfig for kubectl to interact with the cluster.

• Properly joins the node with token, discovery hash, and ignore flag.

• Follows all steps and matches task instructions exactly.

B. ❌

• Omits --ignore-preflight-errors=all on both init and join, which violates the task constraint.

• Even though the command is syntactically correct, it doesn’t fulfill the task requirement.

C. ❌

• Includes unnecessary --pod-network-cidr=10.244.0.0/16, which was not specified in the task.

• Missing the required discovery hash in the join command.

• Violates instruction scope and is incomplete.

D. ❌

• Master init is correct.

• Node join command omits the required --ignore-preflight-errors=all.

• Includes an extra step (kubectl get nodes) on node-1, which was not requested in the task.

✔️ Correct Answer: A

Explanation:

A.

• ✅ Uses --dry-run=client -o yaml to generate the manifest safely without creating the deployment immediately.

• ✅ Allows editing the file (vim) to set replicas: 7 and add the required label app_runtime_stage=dev.

• ✅ Applies the spec file using kubectl apply and then deletes it with kubectl delete -f, satisfying the full task.

• ✅ Saves file at the correct path.

B.

• ❌ Sets label at the deployment level, but the task is asking for the label inside the spec (i.e., Pod template metadata).

• ❌ Does not use --dry-run or modify the file manually.

• ✅ Saves and deletes the deployment, but spec is not correctly edited for label inside template.metadata.labels.

C.

• ❌ Uses kubectl run, which creates a Pod, not a Deployment.

• ❌ Labels a Pod, not the Pod template in a Deployment.

• ✅ Does delete the created Pod and exports YAML, but doesn’t meet task requirements.

D.

• ✅ Generates the YAML correctly and applies it.

• ❌ Does not edit the file to change replicas to 7 or add the required label.

• ❌ Does not delete the created object, which is part of the task.

✅ Correct Answer: A

📝 Explanation of Each Option:

• A. ✅ Correct
  kubectl create ns is a valid short form for creating a namespace, and the second command specifies the pod name, image, and namespace correctly, using --restart=Never which is required when creating standalone pods with kubectl run.

• B. ❌ Incorrect
  Although the namespace is created correctly, the second command is missing the --restart=Never flag. Without it, kubectl tries to create a deployment instead of a pod.

• C. ❌ Incorrect
  --restart=Always creates a deployment, not a pod. The question specifically asks for a pod, so this is not valid.

• D. ❌ Incorrect
  While the syntax may work, it’s missing --restart=Never, and the image specification (--image nginx) is not properly formatted (missing =), which can lead to an error.

✔️ Correct Answer: A

Explanation:
The correct choice is Option A because:

1. Proper Pod Creation:

• kubectl run nginx --image=nginx --restart=Never creates a Pod, not a deployment.

• This satisfies the requirement to create a standalone Pod using the nginx image.

2. Verbosity Levels with kubectl get:

• -v=0: Minimal/default verbosity.

• -v=6: Shows API calls and some debug info.

• -v=9: Shows maximum verbosity, including HTTP requests/responses.

• These commands demonstrate how to check pod status with different verbosity levels, as the task demands.

Why Other Options Are Incorrect:

B.

• Uses kubectl create deployment, which creates a Deployment, not a standalone Pod.

• Misses the -v=9 level. Doesn’t fulfill the “create a Pod” instruction.

C.

• Omits --restart=Never, which means it defaults to creating a Deployment, not a Pod.

• Only includes one verbosity level (-v=9), missing the rest.

D.

• Correctly creates a Pod, but does not use -v flags for verbosity.

• Uses kubectl describe pods, which is not asked for in the question.

✔️ Correct Answer: A

Explanation:

A. ✅

• Correctly exposes the existing pod front-end.

• Specifies the service name (--name=front-end-service).

• Sets the type to NodePort.

• Maps the incoming port 80 to the target port 80 of the pod.

B. ❌

• kubectl create service nodeport creates a service but doesn’t automatically link to a pod unless selector labels are specified.

• No reference to the front-end pod, so traffic may not be routed.

C. ❌

• Attempts to expose a deployment, but the question specifies there is a pod, not a deployment.

• Would fail unless a deployment named front-end exists.

D. ❌

• Incorrect service type: uses LoadBalancer, but the question clearly asks for NodePort.

Correct Answer: Option A

Explanation:

• Option A meets all the requirements: it sets the deployment name as kual00201, launches 7 replicas, and uses the correct label app_runtime_stage=dev both in the selector and pod template labels.

• Option B uses a different label (app: nginx), which does not satisfy the requirement to use app_runtime_stage=dev.

• Option C launches only 5 replicas instead of 7.

• Option D uses the label app_runtime_stage=production instead of dev.

✅ Correct Answer: A

Explanation:

• A. ✅ Correct
  The correct JSON path to sort persistent volumes by their storage capacity is .spec.capacity.storage. This uses kubectl’s built-in sorting and saves the output as required.

• B. ❌ Incorrect
  .status.capacity.storage is not a valid path to sort on for persistent volumes. The capacity is specified under .spec.capacity.

• C. ❌ Incorrect
  capacity alone is not a valid JSONPath for sorting in kubectl.

• D. ❌ Incorrect
  .metadata.capacity does not exist; capacity is not part of metadata but under .spec.capacity.

✔️ Correct Answer: A

Explanation:

A. ✅

• Uses jsonpath to loop through all pods and extract both name and startTime.

• Proper newline formatting.

• Redirects output to /opt/pod-status.

• This is the most precise and script-friendly approach.

B. ❌

• kubectl get pod (singular) gets only one pod. To get all, you’d need pods.

• Also, custom-columns adds headers by default and does not format for simple scripting output.

C. ❌

• Uses describe, which is verbose and not structured output.

• grep may not guarantee correct formatting or consistent output.

D. ❌

• --output=wide doesn’t show start time.

• Includes extra data not needed and doesn’t meet the requirement.

✅ Correct Answer: A

Explanation of Each Option:

• A. ✅ Correct
  This is the correct way to run a pod with the sleep 3600 command using BusyBox.
  The --command flag tells kubectl that the following arguments should be passed as the command to the container. Without this, kubectl may treat them as arguments to the image’s default entrypoint.

• B. ❌ Incorrect
  This will result in an error or unexpected behavior because kubectl may not interpret sleep 3600 as the command without the --command flag.

• C. ❌ Incorrect
  kubectl create pod is not a valid command. The correct subcommand is kubectl run or kubectl apply with a manifest file.

• D. ❌ Incorrect
  The --command flag does not accept a string like "sleep 3600"; it expects a list of command arguments. Quoting the entire command this way won’t work properly—it treats it as a single string, which is not valid for container commands.

✅ Correct Answer: A

Explanation:
The correct choice is Option A because:

1. kubeadm init with Preflight Error Ignoring:

• Uses kubeadm init --ignore-preflight-errors=all, which is mandatory for this task.

• Ensures the control plane is initialized even if the system has unmet preflight conditions.

2. Sets Up Kubeconfig Properly:

• Commands to set up kubeconfig (mkdir, cp, chown) are essential for accessing the Kubernetes cluster using kubectl.

3. Uses Correct Join Command:

• kubeadm join on the worker node includes both the token and discovery hash and the --ignore-preflight-errors=all flag, meeting all task requirements.

4. Follows All Node and SSH Instructions:

• Executes tasks on both ik8s-master-0 and ik8s-node-0 and assumes returning to the base node (node-1), as instructed.

❌ Why Other Options Are Incorrect

🔸 Option B

• Does not include the required --ignore-preflight-errors=all on either the master or worker node.

• Violates task instruction: “Any kubeadm invocations will require the use of the –ignore-preflight-errors=all option.”

• Would result in a failed or blocked installation in environments with unmet prerequisites.

🔸 Option C

• Initializes the master node correctly with the ignore flag but misses the required token and discovery hash in the kubeadm join command.

• kubeadm join <master-ip>:6443 --ignore-preflight-errors=all is incomplete and would fail without those parameters.

🔸 Option D

• Similar to Option A but introduces an extra flag: --pod-network-cidr=10.244.0.0/16.

• While this CIDR is used with some CNI plugins like Flannel, it was not part of the instructions and could result in misconfiguration if not aligned with the CNI plugin in use.