1. Assessment Goal

This assessment verifies that you can model, configure and debug Kubernetes workloads that are closer to production. The focus is on workload selection, probes, lifecycle, resource management, scheduling, NetworkPolicy, DNS, Ingress or Gateway API, storage, Helm, Kustomize and systematic troubleshooting.

After the assessment it should be clear that you can:

• distinguish Deployment, StatefulSet, DaemonSet, Job and CronJob by purpose,
• classify Init Containers, Sidecar Containers and Ephemeral Containers correctly,
• separate Startup, Readiness and Liveness Probes technically,
• apply Requests, Limits, QoS, LimitRange and ResourceQuota,
• explain scheduling problems through events, node labels, taints and tolerations,
• diagnose Service, DNS, EndpointSlices and NetworkPolicies separately,
• understand Ingress and Gateway API as rule resources plus controllers,
• handle PVC, PV, StorageClass and StatefulSet at a basic level,
• review Helm and Kustomize output before applying it.

2. Prerequisites and Allowed Resources

You need:

• a lab cluster with a working CNI,
• CoreDNS,
• kubectl,
• optionally helm,
• optionally kubectl kustomize or kustomize,
• optionally a StorageClass,
• optionally an Ingress Controller or Gateway Controller.

Allowed resources:

• official Kubernetes documentation,
• your own workshop notes,
• kubectl explain, kubectl describe, kubectl logs, kubectl get events,
• local manifests created during the assessment.

Not allowed:

• production Secrets,
• changes outside the assessment namespace unless explicitly required,
• cluster-wide changes without documentation and rollback.

Recommended namespace:

export NS=exam-intermediate

3. Scenario

A team runs a small shop application in the lab. The application consists of:

• frontend: accepts HTTP requests,
• backend: provides an internal API on port 8080,
• migration: runs once before a new version,
• cleanup: runs regularly,
• data-demo: stores a small file persistently.

The application must receive controlled health checks, resource requirements, namespace boundaries, NetworkPolicies and clean diagnosis. External publication is done through Ingress or Gateway API if a controller is available. If no controller is available, this must be documented correctly.

4. Expected Submission

Submit a folder or archive with the following files:

02-intermediate-submission/
  answers.md
  architecture-decision.md
  workloads/
    frontend.yml
    backend.yml
    migration-job.yml
    cleanup-cronjob.yml
  resources/
    limitrange.yml
    resourcequota.yml
  networking/
    services.yml
    networkpolicies.yml
    ingress-or-gateway.yml
  storage/
    statefulset.yml
  packaging/
    kustomize-output.md
    helm-output.md
  troubleshooting.md
  evidence.md
  cleanup.md

If Helm, Gateway API, an Ingress Controller or a StorageClass is not available, document the limitation and provide a technically correct example manifest or a traceable alternative assessment.

5. Part A: Knowledge Questions

Answer the questions precisely and with operational context.

1. When do you use a Deployment, StatefulSet, Job and CronJob?
2. What distinguishes Init Containers, Sidecar Containers and Ephemeral Containers?
3. What is the role of Startup Probe, Readiness Probe and Liveness Probe?
4. Why can an overly aggressive Liveness Probe cause damage?
5. What effect do CPU/Memory Requests have on scheduling and HPA?
6. What is the difference between Guaranteed, Burstable and BestEffort QoS?
7. What is the role of LimitRange and ResourceQuota?
8. What is the difference between nodeSelector, affinity, taints and tolerations?
9. Why can a Pod remain Pending even if the manifest is correct?
10. How do Service, EndpointSlice, Pod readiness and DNS interact?
11. Why must DNS egress be considered explicitly in default-deny NetworkPolicies?
12. What is the difference between an Ingress resource and an Ingress Controller?
13. What roles do PV, PVC, StorageClass and CSI have?
14. Why is hostPath in a lab not automatically a production solution?
15. What do you check for PVC Pending, a Service without Endpoints and CreateContainerConfigError?

6. Part B: Workload and Architecture Decision

Create architecture-decision.md. For each requirement, describe the suitable Kubernetes resource and justify the decision.

7. Part C: Practical Tasks

Task C1: Namespace, quota and LimitRange

1. Create namespace exam-intermediate.
2. Create a LimitRange with default Requests and Limits.
3. Create a ResourceQuota for Pods, CPU and Memory.
4. Show that an oversized Pod is rejected by the API Server.

Minimum quota requirements:

pods: 10
requests.cpu: 2
requests.memory: 2Gi
limits.cpu: 4
limits.memory: 4Gi

Task C2: Frontend and backend with probes

Create two Deployments:

• frontend with image curlimages/curl:8.8.0 or a comparable safe test image,
• backend with an HTTP test server on port 8080, for example registry.k8s.io/e2e-test-images/agnhost:2.53 with netexec.

Requirements:

• meaningful CPU/Memory Requests and Limits,
• Readiness Probe for Service traffic,
• Liveness Probe for actual restart cases,
• Startup Probe if the application starts slowly,
• clear labels: app, component, environment,
• Services for frontend and backend.

Document why Readiness does not serve the same purpose as Liveness.

Task C3: Job and CronJob

Create:

• a Job migration that completes successfully once,
• a CronJob cleanup that runs hourly,
• concurrencyPolicy: Forbid for the CronJob,
• meaningful successfulJobsHistoryLimit and failedJobsHistoryLimit.

Document why a Deployment would be technically worse for this purpose.

Task C4: Check scheduling

1. Label a lab node with exam-role=apps.
2. Create a Pod or Deployment with a matching nodeSelector.
3. Create a second Pod with a non-matching nodeSelector.
4. Document the Pending events.
5. Set a taint on the labelled node.
6. Show the difference between a Pod without a toleration and a Pod with a matching toleration.
7. Cleanly roll back the node changes.

Task C5: NetworkPolicy default deny plus targeted allowances

Create NetworkPolicies with these requirements:

1. Default deny for Ingress and Egress in the namespace.
2. Allow DNS egress to CoreDNS.
3. frontend may reach backend on TCP port 8080.
4. Other egress remains blocked.
5. Document whether your CNI actually enforces NetworkPolicies.

Evidence:

kubectl get networkpolicy -n exam-intermediate
kubectl exec <frontend-pod> -n exam-intermediate -- nslookup backend
kubectl exec <frontend-pod> -n exam-intermediate -- curl -s --max-time 5 http://backend:8080/hostname

Task C6: Ingress or Gateway API

First check whether a controller is available:

kubectl get ingressclass
kubectl get gatewayclass 2>/dev/null || true

If an Ingress Controller is available:

• create an Ingress resource with hostname shop.localtest.me,
• route to the correct Service,
• document controller events and backend mapping.

If Gateway API is available:

• create or describe a Gateway/HTTPRoute model,
• document ParentRef, hostname and BackendRef.

If no controller is available:

• create an example manifest,
• explain why the resource has no practical routing effect without a controller.

Task C7: PVC and StatefulSet

1. Check available StorageClasses.
2. Create a StatefulSet data-demo with volumeClaimTemplates.
3. Write a file to /data/test.txt.
4. Delete the Pod.
5. After recreation, verify that the file still exists.
6. Document the StorageClass and the limits of the lab.

Task C8: Render Helm and Kustomize

1. Create a small Kustomize base and a dev overlay.
2. Render the overlay with kubectl kustomize.
3. Create a minimal Helm chart or use a local example chart.
4. Render the chart with helm template.
5. Compare reviewability, parameterization and error risk.

8. Part D: Troubleshooting Course

Investigate five error patterns. For each pattern document symptom, diagnosis, cause, fix and validation.

9. Grading

10. Knockout Criteria

The assessment fails regardless of point score if:

• production resources or Secrets are used,
• cluster-wide changes are left behind without documentation,
• node taints or labels are not rolled back,
• the submission contains no evidence for the hands-on steps,
• the candidate cannot explain the difference between Readiness and Liveness,
• the candidate cannot diagnose a Service without Endpoints.

11. Examiner Checklist

• Namespace, LimitRange and ResourceQuota exist and are documented.
• Frontend and backend have meaningful probes and resources.
• Job and CronJob are used for finite and scheduled work.
• Scheduling tests include node label, wrong selector, taint and toleration.
• NetworkPolicies include default deny, DNS and app allowance.
• Ingress/Gateway controller dependency is correctly classified.
• StatefulSet/PVC persistence is validated or limitation is explained.
• Helm/Kustomize output is rendered before apply.
• Troubleshooting documentation contains symptom, diagnosis, cause, fix and validation.