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

Mock Exam 1 — Tasks 1–8

6 min read Chapter 77 of 87
Summary

8 weighted exam tasks: Pod with labels and...

8 weighted exam tasks: Pod with labels and resource requests, Deployment with rolling update, CronJob with concurrency settings, ConfigMap injection, NetworkPolicy for port 80, PVC with data persistence, debugging a broken Pod, and Service with Ingress routing.

Mock Exam 1 — Tasks 1–8

Each task begins with a context and namespace instruction. Execute that instruction before solving the task. Read every requirement carefully — missing a single field (a label, a port number, a resource limit) costs points.

Task 1 — Pod with Labels and Resource Requests (4%)

Context: Use the default context.

Namespace: app-team1

Create a Pod with the following specifications:

  • Pod name: web-frontend
  • Image: nginx:1.25-alpine
  • Labels:
    • app: frontend
    • tier: web
    • version: v1
  • Container port: 80
  • Resource requests:
    • CPU: 100m
    • Memory: 128Mi
  • Resource limits:
    • CPU: 250m
    • Memory: 256Mi

Verification: The Pod should be in Running state in namespace app-team1 with all specified labels and resource constraints visible in kubectl describe.

Task 2 — Deployment with Rolling Update (7%)

Context: Use the default context.

Namespace: app-team1

Step 1: Create a Deployment with the following specifications:

  • Deployment name: api-server
  • Image: nginx:1.24
  • Replicas: 3
  • Labels on the Deployment: app: api
  • Container port: 8080
  • Rolling update strategy:
    • maxSurge: 1
    • maxUnavailable: 0

Step 2: After the Deployment is running with 3 Ready replicas, perform a rolling update to change the image to nginx:1.25.

Step 3: Verify that the rolling update completed and all 3 Pods are running the new image.

Step 4: Record the rollout history. Verify there are at least 2 revisions.

Verification: kubectl rollout status deployment/api-server -n app-team1 should report the rollout is complete. All 3 Pods should show the nginx:1.25 image.

Task 3 — CronJob with Concurrency Settings (7%)

Context: Use the default context.

Namespace: batch-ns

Create a CronJob with the following specifications:

  • CronJob name: report-generator
  • Image: busybox:1.36
  • Schedule: Every 5 minutes (*/5 * * * *)
  • Command: sh -c "echo Generating report at $(date) && sleep 20"
  • Concurrency policy: Forbid
  • Active deadline seconds: 30 (on the Job spec, not the CronJob)
  • Successful jobs history limit: 3
  • Failed jobs history limit: 1
  • Restart policy: Never

Verification: kubectl get cronjob report-generator -n batch-ns should show the CronJob with the correct schedule. kubectl get cronjob report-generator -n batch-ns -o yaml should show the correct concurrency policy and history limits.

Task 4 — ConfigMap as Environment Variables (4%)

Context: Use the default context.

Namespace: app-team1

Step 1: Create a ConfigMap named app-config with the following key-value pairs:

  • APP_ENV=production
  • APP_LOG_LEVEL=info
  • APP_PORT=8080

Step 2: Create a Pod named config-reader using the busybox:1.36 image that:

  • Loads all keys from the app-config ConfigMap as environment variables using envFrom
  • Runs the command: sh -c "echo $APP_ENV $APP_LOG_LEVEL $APP_PORT && sleep 3600"

Verification: kubectl exec config-reader -n app-team1 -- env | grep APP_ should show all three environment variables with their correct values.

Task 5 — NetworkPolicy (7%)

Context: Use the default context.

Namespace: network-ns

An existing Deployment named backend-api is running in namespace network-ns with the label app: backend. Pre-create it before starting this task:

kubectl create deployment backend-api -n network-ns --image=nginx --replicas=2
kubectl label deployment backend-api -n network-ns app=backend --overwrite
kubectl label pods -l app=backend-api -n network-ns app=backend --overwrite

Create a NetworkPolicy named backend-netpol in namespace network-ns with the following rules:

  • Apply to Pods with label: app: backend
  • Allow ingress traffic only from:
    • Pods with label role: frontend in the same namespace
    • On port 80 (protocol TCP)
  • Deny all other ingress traffic

The NetworkPolicy should only define ingress rules. Do not add egress rules.

Verification: kubectl get networkpolicy backend-netpol -n network-ns -o yaml should show the correct pod selector, ingress rules with pod selector for role: frontend, and port 80.

Task 6 — PersistentVolumeClaim and Pod (7%)

Context: Use the default context.

Namespace: storage-ns

Step 1: Create a PersistentVolumeClaim with the following specifications:

  • PVC name: data-pvc
  • Access mode: ReadWriteOnce
  • Storage request: 1Gi
  • Storage class: Use the default storage class (do not specify storageClassName)

Step 2: Create a Pod named data-writer with the following specifications:

  • Image: busybox:1.36
  • Command: sh -c "echo 'persistent data test' > /data/output.txt && sleep 3600"
  • Volume mount: Mount the PVC data-pvc at /data

Step 3: After the Pod is running, verify the data was written:

kubectl exec data-writer -n storage-ns -- cat /data/output.txt

Expected output: persistent data test

Verification: The PVC should be in Bound state. The Pod should be Running. The file /data/output.txt should contain the expected content.

Task 7 — Debug a Broken Pod (7%)

Context: Use the default context.

Namespace: monitoring

A Pod named health-checker exists in namespace monitoring but is not running correctly. Pre-create it with the following broken configuration:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: health-checker
  namespace: monitoring
spec:
  containers:
  - name: checker
    image: ngnix:latest
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 5
EOF

This Pod has two issues that prevent it from working correctly:

  1. The image name is wrong — it should be nginx:latest, not ngnix:latest
  2. The probes target the wrong port — the container listens on port 80, but the probes check port 8080. Both probes should check port 80.

Additionally, the probe paths should be updated:

  • Liveness probe path: / (nginx returns 200 on /)
  • Readiness probe path: / (nginx returns 200 on /)

Your task: Fix the Pod so that it runs with a correct image and working liveness and readiness probes. The Pod must reach Running state with 1/1 Ready containers.

Hint: You may need to delete and recreate the Pod since Pod spec fields are immutable after creation.

Verification: kubectl get pod health-checker -n monitoring should show 1/1 Running.

Task 8 — Service and Ingress (7%)

Context: Use the default context.

Namespace: web-prod

Step 1: Create a Deployment named shop-frontend in namespace web-prod:

  • Image: nginx:1.25
  • Replicas: 2
  • Container port: 80
  • Labels on Pods: app: shop

Step 2: Create a ClusterIP Service named shop-svc that:

  • Targets Pods with label app: shop
  • Listens on port 80
  • Forwards to target port 80

Step 3: Create an Ingress named shop-ingress with the following specifications:

  • Ingress class: nginx
  • Rule:
    • Host: shop.example.com
    • Path: / with pathType Prefix
    • Backend: Service shop-svc on port 80

Verification:

  • kubectl get svc shop-svc -n web-prod should show a ClusterIP service on port 80.
  • kubectl get ingress shop-ingress -n web-prod should show the ingress with host shop.example.com and the correct backend.
  • kubectl describe ingress shop-ingress -n web-prod should show the path / routing to shop-svc:80.

Continue to Tasks 9–15 in the next section.