1. Assessment Goal

This assessment verifies that you can classify Kubernetes fundamentals reliably and roll out simple workloads in a controlled way. The focus is on basic terminology, the Kubernetes object model, kubectl, namespaces, Pods, Deployments, ReplicaSets, Services, Labels, Selectors, ConfigMaps, Secrets, Rollouts and initial troubleshooting.

After the assessment it should be clear that you can:

• explain the purpose of Kubernetes and the desired-state principle,
• classify central cluster components correctly,
• read and create simple YAML manifests,
• deploy resources in a dedicated namespace,
• connect Services to Pods via Labels and Selectors,
• use logs, events and rollout status for diagnosis,
• systematically investigate simple errors such as wrong image, wrong selector and CrashLoopBackOff,
• document and clean up lab resources properly.

2. Prerequisites and Allowed Resources

You need:

• a safe Kubernetes lab cluster, for example kind, minikube, k3d or a provided lab environment,
• kubectl,
• write permissions in your own namespace,
• a shell and a text editor.

Allowed resources:

• the official Kubernetes documentation,
• your own workshop notes,
• kubectl explain, kubectl api-resources, kubectl describe, kubectl logs and kubectl get events.

Not allowed:

• production cluster contexts,
• real credentials, tokens or private keys,
• ready-made model solutions from previous assessments,
• changes outside the assessment namespace.

Recommended namespace:

export NS=exam-fundamentals

3. Scenario

A team wants to run a very simple internal web application on Kubernetes. The application should consist of a Deployment with two replicas and should be reachable internally through a ClusterIP Service. Part of the configuration must be provided through a ConfigMap and an example Secret.

The cluster is a lab cluster. The goal is not production-grade high availability, but correct basic handling, understandable manifests and clean diagnosis.

4. Expected Submission

Submit a folder or archive with the following files:

01-fundamentals-submission/
  answers.md
  namespace.yml
  deployment.yml
  service.yml
  configmap.yml
  secret.yml
  evidence.md
  cleanup.md

answers.md contains the answers to the knowledge questions and the manifest analysis.
evidence.md contains relevant outputs or concise summaries of kubectl get, describe, logs, events and rollout status.
cleanup.md contains the cleanup procedure.

5. Part A: Knowledge Questions

Answer the questions precisely. A good answer names the purpose, the relevant resource or component, a typical source of errors and at least one validation option.

1. What is the purpose of Kubernetes, and what does declarative desired state mean?
2. What is the role of the API Server?
3. Why is etcd critical for a Kubernetes cluster?
4. What roles do the Scheduler, Controller Manager and kubelet have?
5. What is the difference between a Pod, ReplicaSet and Deployment?
6. Why are Pods rarely created directly in normal operations?
7. How does a Service find its Pods?
8. What is the difference between a Label and an Annotation?
9. What is a Namespace, and which security boundary does it not replace?
10. What are ConfigMaps used for, and what are Secrets used for?
11. Why is Base64 in Kubernetes Secrets not encryption?
12. Which commands do you use first for ImagePullBackOff, CrashLoopBackOff and a Service without Endpoints?

6. Part B: Manifest Analysis

Analyze the following manifest in writing.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: exam-fundamentals
  labels:
    app: web
    tier: frontend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
        tier: frontend
    spec:
      containers:
        - name: nginx
          image: nginx:1.27
          ports:
            - containerPort: 80

Answer:

1. Which API group and version are used?
2. Which resource is created?
3. Where is the desired state defined?
4. Which Labels does the Deployment receive, and which Labels do the Pods receive?
5. What role does spec.selector.matchLabels play?
6. Why must the Selector and Pod Template Labels match?
7. Which resource does the Deployment create indirectly?
8. How would you check whether the rollout was successful?

7. Part C: Practical Task

Task C1: Prepare the namespace

1. Check the active context.
2. Create the namespace exam-fundamentals.
3. Set the namespace for the current context or consistently use -n exam-fundamentals.
4. Document the cluster name, node count and client version.

Expected evidence:

kubectl config current-context
kubectl get nodes -o wide
kubectl get namespace exam-fundamentals

Task C2: Roll out the Deployment

Create deployment.yml for a web application with these requirements:

• resource: Deployment
• name: web
• namespace: exam-fundamentals
• image: nginx:1.27
• replicas: 2
• labels: app=web, tier=frontend, environment=exam
• container port: 80

Apply the manifest and check it:

kubectl apply --dry-run=server -f deployment.yml
kubectl apply -f deployment.yml
kubectl rollout status deployment/web -n exam-fundamentals
kubectl get deployment,replicaset,pod -n exam-fundamentals

Task C3: Create the Service

Create service.yml with these requirements:

• resource: Service
• name: web
• type: ClusterIP
• selector: app=web
• port: 80
• targetPort: 80

Check Service, Endpoints and EndpointSlices.

kubectl get svc,endpoints,endpointslices -n exam-fundamentals
kubectl describe svc web -n exam-fundamentals

Task C4: Mount ConfigMap and Secret

Create a ConfigMap web-config with:

APP_MODE=exam
WELCOME_TEXT=Hello from the Fundamentals assessment

Create a Secret web-secret with stringData:

DEMO_PASSWORD=not-a-real-secret

Extend the Deployment so that:

• APP_MODE is available as an environment variable inside the container,
• the Secret is mounted read-only as a file under /etc/demo-secret.

Important: Do not use a real password or real token.

Task C5: Rollout, scaling and rollback

1. Scale the Deployment to three replicas.
2. Change the image to nginx:1.26.
3. Check rollout status and rollout history.
4. Perform a rollback.
5. Document which image is active after the rollback.

Suitable commands:

kubectl scale deployment/web --replicas=3 -n exam-fundamentals
kubectl set image deployment/web nginx=nginx:1.26 -n exam-fundamentals
kubectl rollout status deployment/web -n exam-fundamentals
kubectl rollout history deployment/web -n exam-fundamentals
kubectl rollout undo deployment/web -n exam-fundamentals

8. Part D: Diagnosis and Short Operations Note

Task D1: Service without Endpoints

Intentionally change the Service selector to a wrong value, for example:

selector:
  app: wrong-web

Document:

• symptom,
• diagnosis command,
• cause,
• fix,
• validation after the fix.

Task D2: Explain error patterns

Briefly explain the diagnosis and most likely cause for each case:

Task D3: Operations note

Create a short operations note in evidence.md containing:

• context and namespace,
• applied manifests,
• created resources,
• most important validation commands,
• detected error and fix,
• cleanup path.

9. Grading

Grading scale:

10. Knockout Criteria

The assessment is considered failed regardless of points if one of the following applies:

• a production context is used or modified,
• real credentials, tokens or private keys are committed or submitted,
• resources are created outside the assessment namespace without approval,
• the candidate cannot explain the submitted manifests,
• no cleanup path is provided.

11. Examiner Checklist

• The candidate checked the context before working.
• All manifests use namespace exam-fundamentals.
• The Deployment has two or three replicas depending on task stage.
• The Service selects the correct Pods through app=web.
• ConfigMap and Secret are mounted or referenced correctly.
• Rollout, image change and rollback were validated.
• The diagnosis of the broken Service selector is technically correct.
• No real Secrets are present.
• Cleanup is complete and reproducible.