Challenge Types

Every Kubeasy challenge has a type that defines the nature of the problem. Understanding the type helps you know what kind of thinking is required before you even start.

There are four challenge types: fix, operate, improve, and migrate.

Fix

A fix challenge starts with a broken setup. Something that was (or should be) working isn't. Your job is to diagnose the root cause and repair it.

This is the most common challenge type and the closest to real-world on-call incidents. The initial state is intentionally broken — resources exist, but something is misconfigured, missing, or wrong.

What you'll do:

• Investigate the cluster state with kubectl get, kubectl describe, kubectl logs
• Identify the failure mode (crash, misconfiguration, missing permission, etc.)
• Apply the fix directly to the cluster
• Validate that everything is now healthy

Example scenarios:

• A pod keeps OOMKilled because its memory limit is too low
• A deployment never becomes ready because the liveness probe path is wrong
• An application can't reach a service because a NetworkPolicy blocks egress

Operate

An operate challenge starts with a running infrastructure. You don't need to fix anything — you need to execute a specific operational task to move forward.

This type tests hands-on operational skills: rolling out updates, scaling workloads, draining nodes, managing lifecycle events.

What you'll do:

• Read the objective to understand the operational goal
• Execute the required task using kubectl or other standard tools
• Validate that the operation completed successfully

Example scenarios:

• Perform a rolling update with zero downtime
• Drain a node before maintenance without disrupting running workloads
• Scale a deployment in response to increased load

Improve

An improve challenge starts with a working application that isn't production-ready. You need to strengthen its reliability, security, or observability without breaking what already works.

This type tests depth of knowledge: adding resource limits, hardening RBAC, setting up probes, enabling network policies.

What you'll do:

• Assess the current setup and identify what's missing or insufficient
• Apply the improvements incrementally
• Validate that the application remains healthy and the improvements are in place

Example scenarios:

• Add resource requests and limits to an unguarded deployment
• Enable a liveness probe on an application that currently has none
• Restrict a ServiceAccount's permissions to the minimum required

Migrate

A migrate challenge starts with a working but outdated or suboptimal configuration. You need to transition it to a new setup — without breaking what already works.

This type tests your understanding of Kubernetes evolution: version migrations, configuration improvements, and adopting new patterns.

What you'll do:

• Understand the current setup and why it needs to change
• Apply the migration without downtime or regressions
• Validate that the new configuration meets the objectives

Example scenarios:

• Migrate from a Deployment using a deprecated API version to the current one
• Replace hard-coded environment variables with references to a Secret
• Switch from a ClusterIP service to a LoadBalancer with proper annotations

Comparison

Tips for all types

• Read the challenge description carefully — it describes symptoms or requirements, not the solution
• Use kubectl describe and kubectl events to understand what Kubernetes is seeing
• The validation doesn't care how you achieve it, only that the outcome passes — there are often multiple valid solutions