Linux Foundation Certified Kubernetes Administrator (CKA) Program - CKA FREE EXAM DUMPS QUESTIONS & ANSWERS

Persistent Volume
A persistent volume is a piece of storage in a Kubernetes cluster. PersistentVolumes are a cluster-level resource like nodes, which don't belong to any namespace. It is provisioned by the administrator and has a particular file size. This way, a developer deploying their app on Kubernetes need not know the underlying infrastructure. When the developer needs a certain amount of persistent storage for their application, the system administrator configures the cluster so that they consume the PersistentVolume provisioned in an easy way.
Creating Persistent Volume
kind: PersistentVolume
apiVersion: v1
metadata:
name:app-data
spec:
capacity: # defines the capacity of PV we are creating
storage: 2Gi #the amount of storage we are tying to claim
accessModes: # defines the rights of the volume we are creating
- ReadWriteMany
hostPath:
path: "/srv/app-data" # path to which we are creating the volume
Challenge
* Create a Persistent Volume named app-data, with access mode ReadWriteMany, storage classname shared, 2Gi of storage capacity and the host path /srv/app-data.

2. Save the file and create the persistent volume.
Image for post

3. View the persistent volume.

* Our persistent volume status is available meaning it is available and it has not been mounted yet. This status will change when we mount the persistentVolume to a persistentVolumeClaim.
PersistentVolumeClaim
In a real ecosystem, a system admin will create the PersistentVolume then a developer will create a PersistentVolumeClaim which will be referenced in a pod. A PersistentVolumeClaim is created by specifying the minimum size and the access mode they require from the persistentVolume.
Challenge
* Create a Persistent Volume Claim that requests the Persistent Volume we had created above. The claim should request 2Gi. Ensure that the Persistent Volume Claim has the same storageClassName as the persistentVolume you had previously created.
kind: PersistentVolume
apiVersion: v1
metadata:
name:app-data
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 2Gi
storageClassName: shared
2. Save and create the pvc
njerry191@cloudshell:~ (extreme-clone-2654111)$ kubect1 create -f app-data.yaml persistentvolumeclaim/app-data created
3. View the pvc
Image for post

4. Let's see what has changed in the pv we had initially created.
Image for post

Our status has now changed from available to bound.
5. Create a new pod named myapp with image nginx that will be used to Mount the Persistent Volume Claim with the path /var/app/config.
Mounting a Claim
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
name: app-data
spec:
volumes:
- name:congigpvc
persistenVolumeClaim:
claimName: app-data
containers:
- image: nginx
name: app
volumeMounts:
- mountPath: "/srv/app-data "
name: configpvc

Task Summary
* SSH into cka000054
* Install a CNI plugin that supports NetworkPolicies
* Two CNI options provided:
* Flannel v0.26.1 (# does NOT support NetworkPolicies)
* Calico v3.28.2 # (does support NetworkPolicies)
# Decision Point: Which CNI to choose?
# Choose Calico, because only Calico supports enforcing NetworkPolicies natively. Flannel does not.
# Step-by-Step Solution
1## SSH into the correct node
ssh cka000054
## Required. Skipping this results in zero score.
2## Install Calico CNI (v3.28.2)
Use the official manifest provided:
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/tigera-operator.yaml This installs the Calico Operator, which then deploys the full Calico CNI stack.
3## Wait for Calico components to come up
Check the pods in tigera-operator and calico-system namespaces:
kubectl get pods -n tigera-operator
kubectl get pods -n calico-system
# You should see pods like:
* calico-kube-controllers
* calico-node
* calico-typha
* tigera-operator
Wait for all to be in Running state.
# (Optional) 4## Confirm CNI is enforcing NetworkPolicies
You can check:
kubectl get crds | grep networkpolicy
You should see:
* networkpolicies.crd.projectcalico.org
* This confirms Calico's CRDs are installed for policy enforcement.
Final Command Summary
ssh cka000054
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/tigera-operator.yaml kubectl get pods -n tigera-operator kubectl get pods -n calico-system kubectl get crds | grep networkpolicy

kubectl run nginx --image=nginx --restart=Never --env=var1=value1
# then
kubectl exec -it nginx -- env
# or
kubectl exec -it nginx -- sh -c 'echo $var1'
# or
kubectl describe po nginx | grep value1

Task Summary
* SSH into the correct node: cka000049
* Find the highest existing user-defined PriorityClass
* Create a new PriorityClass high-priority with a value one less
* Patch Deployment busybox-logger (in namespace priority) to use this new PriorityClass Step-by-Step Solution
1## SSH into the correct node
bash
CopyEdit
ssh cka000049
## Skipping this = zero score
2## Find the highest existing user-defined PriorityClass
Run:
bash
CopyEdit
kubectl get priorityclasses.scheduling.k8s.io
Example output:
vbnet
CopyEdit
NAME VALUE GLOBALDEFAULT AGE
default-low 1000 false 10d
mid-tier 2000 false 7d
critical-pods 1000000 true 30d
Exclude system-defined classes like system-* and the default global one (e.g., critical-pods).
Let's assume the highest user-defined value is 2000.
So your new class should be:
* Value = 1999
3## Create the high-priority PriorityClass
Create a file called high-priority.yaml:
cat <<EOF > high-priority.yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1999
globalDefault: false
description: "High priority class for user workloads"
EOF
Apply it:
kubectl apply -f high-priority.yaml
4## Patch the busybox-logger deployment
Now patch the existing Deployment in the priority namespace:
kubectl patch deployment busybox-logger -n priority \
--type='merge' \
-p '{"spec": {"template": {"spec": {"priorityClassName": "high-priority"}}}}'
5## Verify your work
Confirm the patch was applied:
kubectl get deployment busybox-logger -n priority -o jsonpath='{.spec.template.spec.priorityClassName}'
# You should see:
high-priority
Also, confirm the class exists:
kubectl get priorityclass high-priority
Final Command Summary
ssh cka000049
kubectl get priorityclass
# Create the new PriorityClass
cat <<EOF > high-priority.yaml
apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1999
globalDefault: false
description: "High priority class for user workloads"
EOF
kubectl apply -f high-priority.yaml
# Patch the deployment
kubectl patch deployment busybox-logger -n priority \
--type='merge' \
-p '{"spec": {"template": {"spec": {"priorityClassName": "high-priority"}}}}'
# Verify
kubectl get deployment busybox-logger -n priority -o jsonpath='{.spec.template.spec.priorityClassName}' kubectl get priorityclass high-priority

Solution:
kubectl get deployment
kubectl scale deployment.apps/presentation --replicas=6

SOLUTION:
[student@node-1] > ssh ek8s
kubectl cordon ek8s-node-1
kubectl drain ek8s-node-1 --delete-local-data --ignore-daemonsets --force

Task Summary
* SSH into the correct node: cka000037
* Modify existing deployment synergy-leverager
* Add a sidecar container:
* Name: sidecar
* Image: busybox:stable
* Command:
/bin/sh -c "tail -n+1 -f /var/log/synergy-leverager.log"
* Use a shared volume mounted at /var/log
* Don't touch existing container config except adding volume mount
Step-by-Step Solution
1## SSH into the correct node
ssh cka000037
## Skipping this will result in a zero score.
2## Edit the deployment
kubectl edit deployment synergy-leverager
This opens the deployment YAML in your default editor (vi or similar).
3## Modify the spec as follows
# Inside the spec.template.spec, do these 3 things:
# A. Define a shared volume
Add under volumes: (at the same level as containers):
volumes:
- name: log-volume
emptyDir: {}
# B. Add volume mount to the existing container
Locate the existing container under containers: and add this:
volumeMounts:
- name: log-volume
mountPath: /var/log
# Do not change any other configuration for this container.
# C. Add the sidecar container
Still inside containers:, add the new container definition after the first one:
- name: sidecar
image: busybox:stable
command:
- /bin/sh
- -c
- "tail -n+1 -f /var/log/synergy-leverager.log"
volumeMounts:
- name: log-volume
mountPath: /var/log
spec:
containers:
- name: main-container
image: your-existing-image
volumeMounts:
- name: log-volume
mountPath: /var/log
- name: sidecar
image: busybox:stable
command:
- /bin/sh
- -c
- "tail -n+1 -f /var/log/synergy-leverager.log"
volumeMounts:
- name: log-volume
mountPath: /var/log
volumes:
- name: log-volume
emptyDir: {}
Save and exit
If using vi or vim, type:
bash
CopyEdit
wq
5## Verify
Check the updated pods:
kubectl get pods -l app=synergy-leverager
Pick a pod name and describe it:
kubectl describe pod <pod-name>
Confirm:
* 2 containers running (main-container + sidecar)
* Volume mounted at /var/log
ssh cka000037
kubectl edit deployment synergy-leverager
# Modify as explained above
kubectl get pods -l app=synergy-leverager
kubectl describe pod <pod-name>