[CNCF] CNCF - CKA Exam Dumps & Study Guide

Free [CNCF] CNCF - CKA Practice Questions Preview

• Question 1

  SIMULATION -
  
  
  Context -
  You have been asked to create a new ClusterRole for a deployment pipeline and bind it to a specific ServiceAccount scoped to a specific namespace.
  
  Task -
  Create a new ClusterRole named deployment-clusterrole, which only allows to create the following resource types:
  ✑ Deployment
  ✑ Stateful Set
  ✑ DaemonSet
  Create a new ServiceAccount named cicd-token in the existing namespace app-team1.
  Bind the new ClusterRole deployment-clusterrole to the new ServiceAccount cicd-token, limited to the namespace app-team1.
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer.
  Reasoning:
  The question asks to create a `ClusterRole` and bind it to a `ServiceAccount` scoped to a specific namespace. The key here is the namespace scoping. A `ClusterRole` itself is cluster-wide, but the binding determines the scope of its permissions when used by a particular identity (in this case, a `ServiceAccount`). Using a `RoleBinding` is the correct way to grant permissions defined in a `ClusterRole` to a `ServiceAccount` within a specific namespace. This achieves the desired namespace restriction.
  The steps are:
  1. Create a `ClusterRole` named `deployment-clusterrole` that allows creating `deployments`, `statefulsets`, and `daemonsets`.
  2. Create a `ServiceAccount` named `cicd-token` in the `app-team1` namespace.
  3. Create a `RoleBinding` in the `app-team1` namespace that binds the `deployment-clusterrole` to the `cicd-token` `ServiceAccount`.
  
  Why not ClusterRoleBinding:
  A `ClusterRoleBinding` would grant the `ServiceAccount` the specified permissions cluster-wide, ignoring the requirement to limit it to the `app-team1` namespace. This would violate the problem constraints. While a `ClusterRole` is required to define the broad permissions, it's the `RoleBinding` that provides the necessary namespace restriction.

  Citations:

  • Kubernetes RoleBinding Documentation, https://kubernetes.io/docs/reference/kubernetes-api/authorization-resources/role-binding-v1/
  • Kubernetes ClusterRole Documentation, https://kubernetes.io/docs/reference/kubernetes-api/authorization-resources/cluster-role-v1/
  • Kubernetes ServiceAccount Documentation, https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.28/#serviceaccount-v1-core

• Question 2

  SIMULATION -
  
  
  Task -
  Set the node named ek8s-node-0 as unavailable and reschedule all the pods running on it.
  

  Correct Answer: See interactive view.

  Explanation:

  The AI assistant agrees with the suggested answer. The recommended approach to set the node named ek8s-node-0 as unavailable and reschedule all the pods running on it is to use the kubectl drain command with the --ignore-daemonsets flag.
  
  Reasoning:
  

  • The kubectl drain command is designed specifically for making a node unavailable and rescheduling its pods. It gracefully evicts the pods from the node, ensuring minimal disruption to the applications. It also automatically marks the node as unschedulable to prevent new pods from being scheduled on it.
  • The --ignore-daemonsets flag is essential because DaemonSet pods are typically managed by the DaemonSet controller and are expected to run on every node (or a subset thereof). Draining a node would normally prevent DaemonSet pods from being evicted, but this flag overrides that behavior, allowing them to be evicted as well. However, the DaemonSet controller will likely reschedule them back onto the node unless further action is taken to prevent this, such as removing the node from the DaemonSet's target. The command in suggested answer doesn't remove the node from the DaemonSet's target.
  • The suggested answer provides the correct command and syntax: kubectl drain ek8s-node-0 --ignore-daemonsets.

  Why other approaches are less suitable:
  

  • While kubectl cordon marks a node as unschedulable, it does not actually evict the pods running on it. Therefore, it would not satisfy the requirement of rescheduling the pods. Drain implicitly cordons the node.
  • Manually deleting pods without using kubectl drain could lead to disruptions and data loss if not done carefully. The drain command ensures a graceful eviction process.
  • Uncordoning the node is not required by the question and would make the node available for scheduling again, which is contrary to the task's goal.

  Therefore, based on the task's requirements and the functionality of the kubectl drain command, the suggested answer is the most appropriate and efficient solution.

  • Drain a Node, https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/
  • Kubectl Drain, https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#drain

• Question 3

  SIMULATION -
  
  
  Task -
  Given an existing Kubernetes cluster running version 1.22.1, upgrade all of the Kubernetes control plane and node components on the master node only to version 1.22.2.
  Be sure to drain the master node before upgrading it and uncordon it after the upgrade.
  
  You are also expected to upgrade kubelet and kubectl on the master node.
  
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer but suggests a refinement for clarity and completeness. The provided screenshots outline the essential steps for upgrading the Kubernetes control plane and node components on the master node. However, the reasoning behind including the `--etcd-upgrade=false` flag needs to be emphasized, as that is the core of the problem. Here's a breakdown of the refined answer:

  The necessary steps to upgrade the Kubernetes control plane and node components on the master node to version 1.22.2, while specifically avoiding the etcd upgrade, are as follows:

  • Drain the master node: kubectl drain <master_node_name> --ignore-daemonsets
  • Upgrade kubeadm: apt-get update && apt-get install -y kubeadm=1.22.2-00
  • Plan the upgrade: kubeadm upgrade plan v1.22.2
  • Apply the upgrade, explicitly disabling the etcd upgrade: kubeadm upgrade apply v1.22.2 --etcd-upgrade=false
  • Upgrade kubelet: apt-get install -y kubelet=1.22.2-00
  • Restart kubelet: systemctl daemon-reload && systemctl restart kubelet
  • Uncordon the master node: kubectl uncordon <master_node_name>
  • Upgrade kubectl: apt-get install -y kubectl=1.22.2-00

  Reasoning:
  The question explicitly states to upgrade Kubernetes components on the master node *except* for etcd. The `kubeadm upgrade apply` command, by default, attempts to upgrade etcd as well. To prevent this, the `--etcd-upgrade=false` flag is crucial. Without this flag, the upgrade process would violate the problem statement, leading to an incorrect solution. The other steps (draining, upgrading kubeadm/kubelet/kubectl, and uncordoning) are standard procedures for a Kubernetes upgrade and ensure minimal disruption to the cluster's operation.
  The commands provided ensure that the kubelet and kubectl versions are also upgraded to match the control plane version (1.22.2) on the master node. Matching versions are important for compatibility and proper cluster function.

  Why other approaches might be incorrect:
  Omitting the `--etcd-upgrade=false` flag is incorrect because it would cause kubeadm to attempt an etcd upgrade, directly contradicting the problem statement. Failing to drain the node beforehand could lead to disruptions in running workloads. Not uncordoning the node after the upgrade would prevent new workloads from being scheduled on it, impacting the cluster's capacity. Also, not upgrading kubelet and kubectl will lead to version skew which is not ideal.

  It's important to consult the official Kubernetes documentation for the most up-to-date and accurate upgrade procedures.

  • Upgrading kubeadm clusters, https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
  • kubeadm upgrade, https://kubernetes.io/docs/reference/generated/kubeadm/kubeadm-commands/#upgrade

• Question 4

  SIMULATION -
  
  
  Task -
  First, create a snapshot of the existing etcd instance running at https://127.0.0.1:2379, saving the snapshot to /var/lib/backup/etcd-snapshot.db.
  
  
  Next, restore an existing, previous snapshot located at /var/lib/backup/etcd-snapshot-previous.db.
  

  Correct Answer: See interactive view.

  Explanation:

  The AI suggests following the suggested answer with modification to handle potential permission issues and avoiding modification of the manifest file unless absolutely necessary.
  
  The suggested answer provides a good starting point, but it needs to be supplemented with steps to address file permissions and caution regarding modifying the manifest file. Here's a refined approach, incorporating lessons from the discussion:

  First, to backup the etcd:

  1. Back up the etcd data: Use the `etcdctl` command to create a snapshot of the current etcd data.

     etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot save /var/lib/backup/etcd-snapshot.db

  Second, to restore the etcd from a previous snapshot:

  1. Stop the etcd service: Before restoring, it's generally a good practice to stop the etcd service to prevent data corruption.

     systemctl stop etcd

  2. Restore the etcd data: Use the `etcdctl` command to restore the etcd data from the specified snapshot file.

     etcdctl --data-dir=/var/lib/etcd --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key snapshot restore /var/lib/backup/etcd-snapshot-previous.db

  3. Address potential permission issues: Ensure the `etcd` user has the necessary permissions to access the restored data directory. This is a crucial step often overlooked.

     chown -R etcd:etcd /var/lib/etcd

  4. Start the etcd service: After restoring and setting permissions, start the etcd service.

     systemctl start etcd

  5. Verify etcd health: Check the status of the etcd cluster to ensure it's running correctly after the restoration.

     etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key  endpoint health

  Reasoning:
  The suggested answer outlines the basic commands for backing up and restoring the etcd database. However, the discussion highlights the importance of considering file permissions after the restore. The `etcd` process needs to be able to read and write to the data directory. Failing to address this can lead to etcd failing to start or function correctly. The discussion also advises caution regarding modifying the manifest file, suggesting that it is best to avoid this step unless there is a specific documented need to do so. This refined answer takes these considerations into account. It also provides the full command including the certificates location.

  Reason for choosing this answer: This answer provides a complete and robust approach to restoring etcd, incorporating best practices for handling permissions and avoiding unnecessary modifications to system files. It explicitly addresses the potential pitfalls identified in the discussion.

  Reason for not choosing the other answers: While the suggested answer provides a baseline, it is insufficient without considering the potential permission issues and the warning against modifying the manifest file. Ignoring these aspects could lead to a failed restoration or an unstable etcd cluster.

  Important Considerations:

  • Always back up your etcd data before performing any restore operations.
  • Ensure that the snapshot file you are restoring is compatible with the etcd version you are running.
  • Monitor the etcd logs for any errors after the restoration.

  Disclaimer: This is a simulated environment, commands and paths may vary in a real-world setup. Always refer to the official etcd documentation for the most accurate and up-to-date information.

  • etcdctl snapshot save, https://etcd.io/docs/v3.5/op-guide/maintenance/#snapshot-backup
  • etcdctl snapshot restore, https://etcd.io/docs/v3.5/op-guide/recovery/

• Question 5

  SIMULATION -
  
  
  Task -
  Create a new NetworkPolicy named allow-port-from-namespace in the existing namespace fubar.
  Ensure that the new NetworkPolicy allows Pods in namespace internal to connect to port 9000 of Pods in namespace fubar.
  Further ensure that the new NetworkPolicy:
  ✑ does not allow access to Pods, which don't listen on port 9000
  ✑ does not allow access from Pods, which are not in namespace internal
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer.
  The provided YAML configuration correctly defines a NetworkPolicy named `allow-port-from-namespace` in the `fubar` namespace, which allows traffic from pods in the `internal` namespace to port 9000 of pods in the `fubar` namespace.
  The key aspects that make this the correct solution are:

  • Targeting the `internal` namespace: The `namespaceSelector` correctly uses the `kubernetes.io/metadata.name: internal` label to target pods in the `internal` namespace. This label is automatically added by Kubernetes to all namespaces, making it a reliable way to select a specific namespace.
  • Specifying the port: The `ports` section correctly specifies port 9000 as the only allowed port.
  • Restricting access to port 9000 only: By including the `ports` section, access is restricted to only pods listening on port 9000.
  • Ingress only: The policy focuses on ingress rules to restrict incoming traffic to the fubar namespace.

  Reasoning for not choosing alternative approaches:

  • Using `tier: internal` would require manually labeling the namespace, which is an unnecessary step and not part of the question's requirements.
  • Adding Egress rules is not relevant because the question focuses on *ingress* traffic to the `fubar` namespace.

  Here is the complete correct and suggested answer:

  apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-port-from-namespace
  namespace: fubar
spec:
  podSelector: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
               kubernetes.io/metadata.name: internal
      ports:
        - port: 9000
          protocol: TCP
  policyTypes:
    - Ingress


  Citations:

  • Kubernetes Network Policies, https://kubernetes.io/docs/concepts/services-networking/network-policies/
  • Kubernetes well-known labels, annotations and taints, https://kubernetes.io/docs/reference/labels-annotations-taints/

• Question 6

  SIMULATION -
  
  
  Task -
  Reconfigure the existing deployment front-end and add a port specification named http exposing port 80/tcp of the existing container nginx.
  Create a new service named front-end-svc exposing the container port http.
  Configure the new service to also expose the individual Pods via a NodePort on the nodes on which they are scheduled.
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer and the discussed approach of using kubectl expose.
  Reasoning:
  The core requirement is to expose the 'front-end' deployment with a NodePort service named 'front-end-svc', mapping port 80 to the container's 'http' port. The kubectl expose command simplifies this process. Specifying --type NodePort ensures the service is created as a NodePort, making the application accessible on each node's IP address at a specific port. Furthermore, defining the --port and --target-port correctly maps the service's port to the container's port. Lastly, naming the service as front-end-svc satisfies the naming requirement.
  It is also acceptable to modify the deployment manifest and create a service manifest separately, which is more declarative. However, using kubectl expose is more concise and directly addresses the prompt, especially under exam time constraints.
  Here's a refined and consolidated approach:
  1. **Expose the deployment:** kubectl expose deployment front-end --name front-end-svc --type NodePort --port 80 --target-port http
  2. **(Optional) Verify the service:** kubectl get service front-end-svc
  This should show the service type as NodePort and the port mappings.
  Why other answers might be less ideal:
  While manually creating the service definition using a YAML file is possible, it's more time-consuming. The kubectl expose command provides a quicker and more direct way to achieve the desired outcome. Not using NodePort will make the service inaccessible externally.
  

  Complete Answer:

  First, expose the deployment using the kubectl expose command:

  kubectl expose deployment front-end --name front-end-svc --type NodePort --port 80 --target-port http

  Then, verify the service creation:

  kubectl get service front-end-svc

  The output should confirm that the service is of type NodePort and that the port mappings are correctly configured.

  • Citations:
  • kubectl expose, https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands/#expose
  • Kubernetes Services, https://kubernetes.io/docs/concepts/services-networking/service/

• Question 7

  SIMULATION -
  
  
  Task -
  Scale the deployment presentation to 3 pods.
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer.
  The recommended approach to scale the deployment "presentation" to 3 pods is to use the kubectl scale command.
  The suggested command directly addresses the task by scaling the deployment to the desired number of replicas and is the most straightforward and declarative way to achieve the goal.

  Here's the recommended command:

  kubectl scale deployment presentation --replicas=3
  

  Explanation:

  • kubectl scale deployment presentation: This part of the command tells Kubernetes to scale a deployment named "presentation".
  • --replicas=3: This option sets the desired number of replicas (pods) to 3.

  Additional considerations (if the deployment is not in the default namespace):

  If the "presentation" deployment is not in the default namespace, you need to specify the namespace using the -n or --namespace flag. For example, if the deployment is in the "app-space" namespace, the command would be:

  kubectl scale deployment presentation --replicas=3 -n app-space
  

  Reasoning:
  The kubectl scale command is the standard and recommended way to scale deployments in Kubernetes. It is declarative, meaning you specify the desired state (number of replicas), and Kubernetes ensures that the current state matches the desired state. This approach is preferred over imperatively creating or deleting pods directly.

  While other methods might exist to manipulate the number of pods, using kubectl scale is the most direct, readable, and maintainable approach for scaling deployments.

  Citations:

  • Kubectl Scale, https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#scale
  • Scaling Kubernetes Deployments, https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

• Question 8

  SIMULATION -
  
  
  Task -
  Schedule a pod as follows:
  ✑ Name: nginx-kusc00401
  ✑ Image: nginx
  ✑ Node selector: disk=ssd
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer.
  
  The suggested answer correctly utilizes the `nodeSelector` field in the Pod specification to schedule the `nginx-kusc00401` Pod on a node labeled with `disk=ssd`. This is the standard and most straightforward approach for node selection based on labels in Kubernetes. The provided YAML configuration accurately defines the Pod with the required name (`nginx-kusc00401`), image (`nginx`), and the `nodeSelector` configured to target nodes with the label `disk: ssd`.
  
  Reasoning:
  

  • `nodeSelector` is the most direct way to schedule pods to nodes with specific labels.
  • The provided YAML is correctly formatted and includes all required specifications (name, image, and node selector).

  The steps to make the pod running successfully are:
  

  1. Label the node: `kubectl label nodes disk=ssd`. Replace <node_name> with the actual name of the node where you want to schedule the Pod.
  2. Apply the YAML file containing the Pod definition: `kubectl apply -f `.

  
  Why other approaches might not be preferred (although technically functional):

  • While `nodeAffinity` could also achieve the same result, it is generally used for more complex scheduling requirements, such as soft preferences or required affinities with multiple conditions. For this simple task, `nodeSelector` is sufficient and more readable.

  • Kubernetes Documentation on Assigning Pods to Nodes, https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/
  • Kubernetes nodeSelector, https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector

• Question 9

  SIMULATION -
  
  
  Task -
  Check to see how many nodes are ready (not including nodes tainted NoSchedule) and write the number to /opt/KUSC00402/kusc00402.txt.
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer, but will provide a refined command for better accuracy.
  The recommended command is:
  kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[?(@.type=="Ready")].status=="True" && !(@.spec.taints[?(@.effect=="NoSchedule")]))].metadata.name}' | wc -l > /opt/KUSC00402/kusc00402.txt
  
  Reasoning:

  • The primary goal is to count the number of 'Ready' nodes that do not have a 'NoSchedule' taint.
  • The suggested command uses a combination of `kubectl get nodes`, `grep`, and `wc -l`. While this approach can work, it's prone to errors if node names or other fields contain the strings being searched for, or if the output format changes slightly.
  • The AI suggested command uses `jsonpath` to directly query the Kubernetes API for the required information. This is a more robust and accurate approach.
  • Specifically, the `jsonpath` expression does the following:
  • `{.items[?(@.status.conditions[?(@.type=="Ready")].status=="True"`: This filters nodes that have a condition of type 'Ready' with a status of 'True'.
  • `&& !(@.spec.taints[?(@.effect=="NoSchedule")]))]`: This further filters nodes that do not have any taints with an effect of 'NoSchedule'.
  • `.metadata.name}`: This extracts the names of the filtered nodes.
  • Finally, `wc -l` counts the number of node names returned by the `jsonpath` expression.
  • This approach avoids issues with parsing text output and is more resilient to changes in the output format of `kubectl get nodes`.

  
  Reasons for not preferring the original suggested command:

  • The suggested command: kubectl get nodes --no-headers | grep -w "Ready" | grep -v "NoSchedule" | wc -l > /opt/KUSC00402/kusc00402.txt relies on string matching, which can be unreliable. For example, a node name containing "Ready" would be incorrectly counted. Also, `grep -v "NoSchedule"` only excludes lines containing the literal string "NoSchedule". It does not reliably check for the NoSchedule taint effect.

  
  

  Other alternative approaches that involve using `kubectl describe node` combined with `grep` are also less reliable than using `jsonpath`.

  
  

  In summary, using `jsonpath` provides the most accurate and robust solution for this task.

  
  
  

  Important Considerations:

  • Ensure `kubectl` is configured correctly and can access the Kubernetes cluster.
  • Verify that the output file `/opt/KUSC00402/kusc00402.txt` is writable.

  
  

  Revised Suggested Answer:
  kubectl get nodes -o jsonpath='{.items[?(@.status.conditions[?(@.type=="Ready")].status=="True" && !(@.spec.taints[?(@.effect=="NoSchedule")]))].metadata.name}' | wc -l > /opt/KUSC00402/kusc00402.txt

  
  
  

  Alternative Answer (using go-template, may be more readable):
  kubectl get nodes -o go-template='{{range .items}}{{if and (eq .status.conditions.0.type "Ready") (eq .status.conditions.0.status "True") (not (index .spec.taints 0))}}{{.metadata.name}}{{"\n"}}{{end}}{{end}}' | wc -l > /opt/KUSC00402/kusc00402.txt

  
  

  The Reasoning of Alternative Answer: The above command uses go-template to check if node status is ready and if the node has no taint at all.
  One can adjust the `(not (index .spec.taints 0))` to check the existance of certain taints.

  
  

  Disclaimer: Please use the jsonpath or go-template approach. The grep is for quick checking only.

  
  
  

  Citations:

  • Kubectl Cheat Sheet, https://kubernetes.io/docs/reference/kubectl/cheatsheet/
  • Jsonpath Official, https://goessner.net/articles/JsonPath/

• Question 10

  SIMULATION -
  
  
  Task -
  Schedule a Pod as follows:
  ✑ Name: kucc8
  ✑ App Containers: 2
  ✑ Container Name/Images:
  - nginx
  - consul
  

  Correct Answer: See interactive view.

  Explanation:

  The AI agrees with the suggested answer.
  The provided screenshots demonstrate the correct approach to defining a Pod with two containers: nginx and consul. The key is to create a YAML file that specifies the Pod's metadata (name) and its specifications, including the definition of two containers within the `spec.containers` array. Each container definition requires a `name` and an `image`.
  Reasoning:

  • The suggested answer directly addresses the task's requirements by defining a Pod named "kucc8" with two containers, "nginx" and "consul," using their respective images.
  • The structure of the YAML file adheres to the Kubernetes API conventions, including `apiVersion`, `kind`, `metadata`, and `spec`.
  • The `spec.containers` array correctly defines the two containers, including their names and images.

  Why other answers are incorrect:
  There are no alternative answers to explicitly refute, but a missing image specification would be incorrect. This response clearly and correctly defines both containers required.