1. Assessment Goal

This assessment verifies that you can design and operate Kubernetes professionally as a platform. The focus is no longer on individual manifests, but on architecture, responsibilities, upgradeability, observability, autoscaling, GitOps, multi-tenancy, operator review, backup, disaster recovery and cost management.

After the assessment it should be clear that you can:

• evaluate Managed, Self-managed and Hybrid Kubernetes objectively,
• plan cluster and node-pool architecture for multiple teams,
• treat platform add-ons as products with owners, versions, SLOs and upgrade paths,
• plan upgrades including API deprecations, CRDs, webhooks, add-ons and nodes,
• describe observability as an SLO, alert and runbook system,
• separate GitOps and CI/CD cleanly,
• model multi-tenancy using namespaces, RBAC, quotas, LimitRanges, NetworkPolicies and Pod Security,
• assess operators and CRDs operationally,
• formulate backup and disaster recovery in a testable way,
• derive cost sources and rightsizing measures transparently.

2. Prerequisites and Allowed Resources

You need:

• no complete production cluster,
• access to example manifests or a lab,
• optionally kubectl, Helm and Kustomize,
• a text environment for architecture and runbook documents.

Allowed resources:

• official Kubernetes documentation,
• workshop materials,
• your own notes,
• diagrams, tables and decision matrices.

Not allowed:

• unsupported product recommendations without risk analysis,
• blanket claims such as “managed is always better” or “namespaces are complete isolation”,
• a backup concept without a restore test,
• a GitOps concept in which CI permanently owns cluster-admin rights.

3. Scenario

An organization wants to operate Kubernetes as an internal platform for several product teams. There are three environments:

• dev,
• staging,
• production.

Context:

• 12 product teams,
• 40 to 60 microservices,
• several worker-based workloads,
• 5 stateful services with PVCs,
• regulated data in individual namespaces,
• central platform add-ons,
• GitOps as the desired-state model,
• CI/CD with image build, tests and scans,
• external DNS and certificate requirements,
• security and audit requirements,
• monthly release cycles,
• planned Kubernetes minor upgrades every quarter,
• costs must become visible per team.

The platform must be upgradeable, observable, cost-efficient, tenant-capable and recoverable.

4. Expected Submission

Submit a folder or archive with the following files:

03-professional-submission/
  answers.md
  platform-blueprint.md
  operating-model.md
  node-pool-sizing.md
  addon-matrix.md
  upgrade-runbook.md
  observability-slo.md
  autoscaling-review.md
  gitops-flow.md
  tenant-standard.md
  operator-review.md
  dr-runbook.md
  cost-review.md
  handover.md

The documents may contain tables, Mermaid diagrams, checklists and decision notes. What matters is that another person can understand the platform decisions, risks and operational paths.

5. Part A: Professional Questions

Answer the questions with reference to the scenario.

1. Which responsibilities distinguish Managed Kubernetes from Self-managed Kubernetes?
2. When is a shared cluster useful, and when is a cluster per environment or criticality more appropriate?
3. Which node pools would you separate for standard apps, CPU workers, stateful workloads and system add-ons?
4. Which add-ons belong in a platform standard, and why do they need owner, SLO and upgrade path?
5. Why is a Kubernetes upgrade a change process and not just a single command?
6. Which risks arise from API deprecations, CRDs and admission webhooks during upgrades?
7. What belongs to observability besides dashboards?
8. How are Requests, HPA, VPA, Cluster Autoscaler, KEDA and cost connected?
9. Why should CI not permanently hold broad cluster permissions?
10. Why is a namespace alone not sufficient for multi-tenancy?
11. Which risks do operators and CRDs introduce into platform operations?
12. Why is a backup without tested restore not a reliable DR concept?

6. Part B: Platform Blueprint

Create platform-blueprint.md and operating-model.md.

Task B1: Target architecture

Describe a target architecture with:

• cluster model for dev, staging and production,
• environment separation,
• availability-zone strategy,
• responsibilities for platform team, app teams, security and operations,
• Ingress/Gateway model,
• DNS and certificate model,
• basic storage and backup model,
• GitOps desired-state model,
• observability and alerting approach,
• cost labels and showback.

Task B2: Evaluate Managed, Self-managed and Hybrid

Create a decision matrix.

Derive a recommendation for the scenario. The recommendation must include trade-offs and open decisions.

Task B3: Node pools and sizing

Create node-pool-sizing.md with at least four node pools:

Consider:

• DaemonSet overhead,
• kube-reserved and system-reserved,
• rollout buffer,
• node and zone failure,
• Pod density,
• IP address space,
• cloud quotas for compute, volumes, load balancers and firewall rules,
• stop criteria for scaling.

Task B4: Add-on matrix

Create addon-matrix.md with at least these add-ons:

• CNI,
• CSI,
• CoreDNS,
• Ingress or Gateway Controller,
• Metrics Server,
• Observability stack,
• GitOps Controller,
• Policy Engine,
• Backup tool,
• cert-manager or comparable certificate model.

For each add-on document:

• purpose,
• owner,
• criticality,
• version/upgrade path,
• SLO or operational objective,
• key metrics or events,
• backup or restore relevance,
• known outage impact.

7. Part C: Operations and Lifecycle Runbooks

Task C1: Upgrade runbook

Create upgrade-runbook.md for a Kubernetes minor upgrade.

Required sections:

1. target version and current version,
2. version-skew check,
3. API-deprecation scan for manifests, Helm charts and Kustomize overlays,
4. CRD and webhook check,
5. add-on compatibility,
6. backup and restore point,
7. test cluster or staging test,
8. control-plane upgrade,
9. add-on check,
10. node-pool upgrade with cordon and drain,
11. smoke tests,
12. stop criteria,
13. recovery plan,
14. completion report.

Name at least five concrete stop criteria.

Task C2: Observability and SLO

Create observability-slo.md for the sample app checkout-api and platform components.

Document:

• Service Level Objective,
• Service Level Indicators,
• metrics,
• logs,
• traces,
• Kubernetes events,
• dashboards,
• alerts,
• runbook links,
• retention,
• on-call or escalation path.

Platform signals must include at least API Server, CoreDNS, Ingress/Gateway, Nodes, PVC/CSI and GitOps.

Task C3: Autoscaling review

Create autoscaling-review.md for a queue-based worker application.

Evaluate:

• CPU/Memory Requests,
• HPA,
• VPA,
• Cluster Autoscaler,
• Karpenter or comparable node provisioning,
• KEDA for queue length,
• flapping risk,
• cost increase,
• missing or wrong metrics,
• maximum replicas and budget limits.

8. Part D: Governance, GitOps, DR and Cost

Task D1: GitOps and CI/CD flow

Create gitops-flow.md with the following flow:

1. code commit,
2. CI: build, test, scan,
3. image push to registry,
4. digest calculation,
5. pull request for manifest change,
6. review and approval,
7. GitOps sync,
8. drift detection,
9. rollback via Git revert.

Document identities and permissions:

Task D2: Tenant standard

Create tenant-standard.md with a template for a team namespace.

Required elements:

• namespace Labels,
• owner Annotation,
• cost Label,
• ResourceQuota,
• LimitRange,
• Role and RoleBinding,
• NetworkPolicy default deny,
• Pod Security Labels,
• standard for Ingress/Gateway requests,
• exception process.

Clearly describe which controls are designed at the Professional level and which are checked or enforced more strictly at Advanced + Security level.

Task D3: Operator review

Create operator-review.md for a hypothetical database-operator.

Evaluate:

• installed CRDs,
• required ClusterRoles,
• Custom Resources,
• Conditions and Events,
• backup relevance,
• upgrade risks,
• uninstall risks,
• tenant capability,
• production stop criteria.

Task D4: Backup and disaster recovery

Create dr-runbook.md with two scenarios:

1. restore of a single namespace,
2. restore of an entire cluster.

For each scenario document:

• data classes,
• required backups,
• restore order,
• validation,
• RTO/RPO assumption,
• risks,
• evidence.

Data classes must include at least Git state, etcd, PVC data, Secrets, CRDs and external systems.

Task D5: Cost analysis

Create cost-review.md.

Starting point:

• many Pods have high Requests and low actual usage,
• unused PVCs,
• several external load balancers,
• permanently running dev workloads,
• no showback mapping per namespace.

Document:

• cost sources,
• technical measurement points,
• rightsizing recommendations,
• risks of underrequesting,
• showback model,
• prioritized action plan.

Task D6: Operations handover

Create handover.md for another operations person.

Required content:

• platform overview,
• critical add-ons,
• known SLOs,
• alerting paths,
• upgrade windows,
• backup and restore responsibility,
• top 5 runbooks,
• stop criteria,
• open risks.

9. Grading

10. Knockout Criteria

The assessment fails regardless of point score if:

• the design treats namespaces as complete isolation,
• CI is granted permanent unrestricted cluster-admin permissions,
• the backup concept has no restore test,
• there are no stop criteria for upgrades,
• no owners are assigned for critical add-ons,
• regulated data is mixed into shared production without controls or risk discussion.

11. Examiner Checklist

• Managed/Self-managed/Hybrid are evaluated with trade-offs.
• Cluster and environment separation are justified.
• Node pools cover system, standard apps, CPU workers and stateful workloads.
• Add-ons have owners, criticality, SLO/operational target and upgrade path.
• Upgrade runbook contains deprecation scan, CRD/webhook check, backup, staging and node upgrade steps.
• Observability includes metrics, logs, traces, events, alerts and runbooks.
• GitOps flow keeps CI and cluster permissions separated.
• Tenant standard includes RBAC, Quota, LimitRange, NetworkPolicy and Pod Security.
• DR runbook covers namespace and cluster restore.
• Cost review includes rightsizing, unused resources and showback.
• Handover can be used by another operations person.