Skip to main content
Back to Library
mastering ckad certified kubernetes application developer

Mock Exam 1 — Tasks 9–15

6 min read Chapter 78 of 87
Summary

7 weighted exam tasks: multi-container sidecar Pod, Secret...

7 weighted exam tasks: multi-container sidecar Pod, Secret from file, all three probe types, Helm install with value overrides, nodeSelector with tolerations, Job with completions and parallelism, and debugging CrashLoopBackOff.

Mock Exam 1 — Tasks 9–15

Continue from where you left off. Remember to check context and namespace at the start of every task.

Task 9 — Multi-Container Pod with Sidecar (7%)

Context: Use the default context.

Namespace: app-team1

Create a Pod named app-with-sidecar with two containers that share a volume:

Container 1 — Main application:

  • Name: app
  • Image: busybox:1.36
  • Command: sh -c "while true; do echo $(date) - Application log entry >> /var/log/app/app.log; sleep 5; done"
  • Volume mount: Mount a shared volume named log-volume at /var/log/app

Container 2 — Log sidecar:

  • Name: log-sidecar
  • Image: busybox:1.36
  • Command: sh -c "tail -f /var/log/app/app.log"
  • Volume mount: Mount the same shared volume log-volume at /var/log/app

Shared volume:

  • Name: log-volume
  • Type: emptyDir

Verification:

  • kubectl get pod app-with-sidecar -n app-team1 should show 2/2 Running
  • kubectl logs app-with-sidecar -c log-sidecar -n app-team1 should show log entries being written by the main container

Task 10 — Secret from File (4%)

Context: Use the default context.

Namespace: app-team1

Step 1: Create a file named /tmp/db-credentials.txt with the following content:

DB_HOST=mysql.database.svc
DB_PORT=3306
DB_USER=app_user
DB_PASS=Kub3rn3t3s!

Step 2: Create a Secret named db-secret from this file:

  • The key in the Secret should be db-credentials.txt
  • Use type generic

Step 3: Create a Pod named db-client with the following specifications:

  • Image: busybox:1.36
  • Command: sh -c "cat /etc/db/db-credentials.txt && sleep 3600"
  • Volume: Mount the Secret db-secret as a volume at /etc/db
  • Mount the Secret as read-only

Verification:

  • kubectl exec db-client -n app-team1 -- cat /etc/db/db-credentials.txt should display the database credentials
  • kubectl get secret db-secret -n app-team1 should show the Secret exists

Task 11 — Pod with All Three Probes (7%)

Context: Use the default context.

Namespace: monitoring

Create a Pod named probed-app with the following specifications:

  • Image: nginx:1.25
  • Container port: 80

Startup probe:

  • Type: httpGet
  • Path: /
  • Port: 80
  • failureThreshold: 30
  • periodSeconds: 10

Liveness probe:

  • Type: httpGet
  • Path: /
  • Port: 80
  • initialDelaySeconds: 0
  • periodSeconds: 10
  • failureThreshold: 3

Readiness probe:

  • Type: httpGet
  • Path: /
  • Port: 80
  • initialDelaySeconds: 0
  • periodSeconds: 5
  • failureThreshold: 3

Why three probes matter: The startup probe runs first and disables the liveness and readiness probes until it succeeds. This prevents the liveness probe from killing a slow-starting container. Once the startup probe succeeds, the liveness and readiness probes take over.

Verification:

  • kubectl get pod probed-app -n monitoring should show 1/1 Running
  • kubectl describe pod probed-app -n monitoring should show all three probes configured with the correct paths, ports, and thresholds

Task 12 — Helm Chart Management (7%)

Context: Use the default context.

Namespace: helm-ns

Step 1: Add the Bitnami Helm repository if it is not already added:

Repository URL: https://charts.bitnami.com/bitnami

Step 2: Install the bitnami/nginx chart as a release named web-release in namespace helm-ns with the following custom values:

  • replicaCount=2
  • service.type=ClusterIP

Step 3: Verify the release is deployed and the Pods are running.

Step 4: Upgrade the release to set replicaCount=4.

Step 5: Verify the upgrade. There should be 4 Pods running.

Step 6: Roll back the release to revision 1 (the original installation with 2 replicas).

Step 7: Verify the rollback. There should be 2 Pods running again.

Verification:

  • helm list -n helm-ns should show web-release at revision 3 (install → upgrade → rollback)
  • kubectl get pods -n helm-ns should show 2 running Pods after rollback

Task 13 — Node Scheduling with nodeSelector and Toleration (7%)

Context: Use the default context.

Namespace: scheduling

Preparation: Before starting this task, label a node and add a taint:

# Get a node name
NODE_NAME=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')

# Label the node
kubectl label node $NODE_NAME disktype=ssd

# Taint the node
kubectl taint nodes $NODE_NAME dedicated=special:NoSchedule

Create a Pod named ssd-worker with the following specifications:

  • Image: nginx:1.25
  • nodeSelector: disktype: ssd
  • Toleration:
    • Key: dedicated
    • Value: special
    • Effect: NoSchedule
    • Operator: Equal

Verification:

  • kubectl get pod ssd-worker -n scheduling should show 1/1 Running
  • kubectl get pod ssd-worker -n scheduling -o jsonpath='{.spec.nodeSelector}' should show {"disktype":"ssd"}
  • kubectl describe pod ssd-worker -n scheduling should show the toleration for dedicated=special:NoSchedule

Task 14 — Job with Completions and Parallelism (7%)

Context: Use the default context.

Namespace: batch-ns

Create a Job named data-processor with the following specifications:

  • Image: busybox:1.36
  • Command: sh -c "echo Processing batch item $RANDOM && sleep 5"
  • Completions: 5
  • Parallelism: 2
  • Backoff limit: 4
  • Active deadline seconds: 120
  • Restart policy: Never

Verification:

  • kubectl get job data-processor -n batch-ns should eventually show 5/5 completions
  • kubectl get pods -n batch-ns -l job-name=data-processor should show 5 completed Pods
  • At no point should more than 2 Pods be running simultaneously (parallelism=2)
  • kubectl get job data-processor -n batch-ns -o yaml should show the correct completions, parallelism, and backoff limit values

Task 15 — Debug CrashLoopBackOff (7%)

Context: Use the default context.

Namespace: app-team1

A Pod named crash-app exists in namespace app-team1 but is stuck in CrashLoopBackOff. Pre-create it with the following broken configuration:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: crash-app
  namespace: app-team1
spec:
  containers:
  - name: app
    image: busybox:1.36
    command: ["sh", "-c", "cat /config/settings.conf"]
    volumeMounts:
    - name: config-vol
      mountPath: /config
  volumes:
  - name: config-vol
    configMap:
      name: app-settings
EOF

The Pod crashes because it references a ConfigMap named app-settings that does not exist.

Your task:

  1. Investigate the Pod to identify why it is in CrashLoopBackOff
  2. Create the missing ConfigMap app-settings with the following data:
    • settings.conf containing: 
      log_level=info
max_connections=100
timeout=30
  3. Fix the Pod so that it starts, reads the config file, and completes without crashing

Hint: After creating the ConfigMap, the Pod may need to be deleted and recreated because it might be stuck in a failure loop. Also, the command cat /config/settings.conf will exit immediately, causing the container to complete and restart. You need to modify the command so the container keeps running, for example: sh -c "cat /config/settings.conf && sleep 3600".

Verification:

  • kubectl get pod crash-app -n app-team1 should show 1/1 Running
  • kubectl logs crash-app -n app-team1 should display the contents of settings.conf

This concludes Mock Exam 1. Stop your timer.

Record how many tasks you completed and calculate your score using the weight table in the chapter introduction. If you scored below 66%, review the topics you struggled with before checking the solutions in Chapter 27. If you scored above 80%, your speed and accuracy are exam-ready.