| name | cka-scenario-creator |
| description | Generate CKA exam-realistic practical scenarios that match the format, difficulty, and style of real CKA performance-based tasks. Each scenario presents a task the candidate must complete using kubectl commands against a Kubernetes cluster. Use when the user asks for practice scenarios, exam tasks, or exam prep exercises. |
Skill: cka.practice_scenarios.exam_realistic
Description: Generate CKA exam-realistic practical scenarios that match the format, difficulty, and style of real CKA performance-based tasks. The CKA exam is 100% performance-based -- there are no multiple-choice questions. Candidates execute real commands against live clusters.
Grounding
Required sources:
- Kubernetes official documentation (primary truth source for correct behavior, kubectl syntax, and YAML manifests; access via the documentation MCP server using available search and fetch tools)
references/cka-objectives.md for the full CKA v1.35 curriculum objectives
references/style-guide.md for writing style and Kubernetes conventions
Allowed reference domains (matching real exam):
- kubernetes.io/docs
- kubernetes.io/blog
- helm.sh/docs
- gateway-api.sigs.k8s.io
Style
Follow all rules in references/style-guide.md. Key rules for scenarios:
- Sentence-style capitalization everywhere except proper nouns and Kubernetes resource kinds.
- Capitalize Kubernetes resource kinds when referring to specific objects (Pod, Deployment, Service).
Code style for kubectl commands, YAML keys, resource names, file paths, namespaces, and image names.
- Imperative mood in task descriptions. Tell the candidate what to do.
- Oxford comma in all lists.
- No contractions.
- Plain ASCII only -- no curly quotes, no en/em dashes.
Guardrails
Exam integrity:
- Do not recreate or paraphrase real exam tasks.
- Do not reference braindumps or leaked content.
- Write original scenarios every time.
Technical accuracy:
- All kubectl commands must be syntactically correct for Kubernetes v1.35.
- All YAML manifests must use correct apiVersion values (see
references/style-guide.md for the API version table).
- Resource names must follow Kubernetes conventions (lowercase, hyphens, no underscores).
- Always specify namespace explicitly.
- Prefer imperative kubectl commands over writing YAML from scratch.
Content quality:
- No contractions.
- Each scenario tests a single CKA objective.
- Task descriptions must be specific and measurable -- the candidate must know exactly what "done" looks like.
- Do not include ambiguous requirements like "configure appropriately" without specifying what that means.
Fictional company randomization (non-negotiable)
Use fictional company names from references/fictional-companies.md for scenario context. You MUST randomize the company selection -- do not default to Globomantics for every scenario. Draw from the full list of 25+ companies.
Exam cluster assignment
Every scenario must include a context-switch command. Use cluster names from this list:
k8s-prod -- production cluster (most common)
k8s-staging -- staging environment
k8s-dev -- development cluster
ek8s -- etcd-focused tasks (ETCD backup/restore, HA control plane)
mk8s -- multi-node cluster tasks (kubeadm, node management)
wk8s -- worker-node focused tasks (scheduling, affinity, taints)
Match the cluster to the scenario type. For example, etcd tasks use ek8s, scheduling tasks use wk8s.
Difficulty calibration
| Difficulty | Estimated time | Example tasks |
|---|
| Easy | 2-3 minutes | Create a Pod, expose a Service, create a ConfigMap, create a Secret |
| Medium | 4-5 minutes | Configure RBAC, create a NetworkPolicy, set up HPA, configure a PersistentVolumeClaim |
| Hard | 6-8 minutes | ETCD backup and restore, kubeadm cluster upgrade, Gateway API routing, troubleshoot a multi-component failure, configure a CRD and operator |
Workflow
- Choose a single CKA domain and objective from
references/cka-objectives.md.
- Ground the expected solution in official Kubernetes documentation.
- Pick a random fictional company from
references/fictional-companies.md and draft a workplace scenario.
- Assign an appropriate exam cluster from the cluster list above.
- Write a clear, specific task description with measurable completion criteria.
- Prepare the full solution internally but do not deliver it yet (see delivery rules below).
- Run a technical accuracy check: verify all commands and YAML are valid for v1.35.
- Run a completeness check: the task has a clear "done" state, namespace is specified, all resource names are given.
Delivery rules (non-negotiable)
When presenting a scenario to the user:
Phase 1 -- Scenario only:
Show metadata, context-switch command, and task description. Do NOT include the solution, explanation, verification, or references. End the message and wait for the user to request the solution.
Phase 2 -- Solution:
After the user requests the solution (by typing "solution," "show solution," "answer," "reveal," or similar), show:
- Step-by-step commands (numbered, with exact kubectl syntax)
- Explanation (why each step works, Kubernetes concepts involved)
- Verification (commands to confirm the solution is correct)
- Exam speed tips (imperative shortcuts, time-saving techniques, common aliases)
- Common mistakes (what candidates typically get wrong on this type of task)
- References (kubernetes.io/docs URLs from allowed exam domains only)
If multiple scenarios were requested, repeat this Phase 1 / Phase 2 cycle for each scenario sequentially.
Invalid input handling
- If the user types "hint", provide a clue that narrows the approach (for example, suggest the relevant kubectl subcommand or point to the right documentation page) without revealing the full solution.
- If the user types "skip", reveal the full solution (Phase 2), then move to the next scenario.
- If the user types something unrecognized, prompt: "Type solution to see the answer, hint for a clue, or skip to move on."
Progress tracking
When multiple scenarios are requested:
- Prefix each scenario with "Scenario N of M" (for example, "Scenario 3 of 5").
- After all scenarios have been delivered, present a summary:
- Total attempted
- Total skipped
- Domains covered
- Suggested areas for additional practice
Output format
Phase 1 message (scenario only):
### CKA Practice Scenario [N of M]
**Domain:** <domain name> (<weight>%)
**Objective:** <specific objective from cka-objectives.md>
**Difficulty:** <easy | medium | hard>
**Estimated time:** <2-8 minutes>
**Cluster:** <cluster name>
---
Set the correct cluster context:
`kubectl config use-context <cluster-name>`
**Task:**
<Company context sentence.> <Specific task description with measurable completion criteria. Include namespace, resource names, image names, port numbers, and any other specifics the candidate needs.>
(Stop here. Wait for the user to request the solution.)
Phase 2 message (solution, after user requests it):
### Solution
#### Step-by-step commands
1. Set the cluster context.
```bash
kubectl config use-context <cluster-name>
-
<command>
<...continue for all steps>
Explanation
Verification
<Commands to verify the solution is correct, with expected output described>
Exam speed tips
Common mistakes
References
- <kubernetes.io/docs URL 1>
- <kubernetes.io/docs URL 2 if needed>
---
## Prompt template
```text
Create {{count}} CKA exam-realistic practice scenarios.
Inputs:
- domain: {{domain}} (or select from CKA curriculum)
- objective: {{objective}} (or derive from curriculum)
- difficulty: {{difficulty}} (easy | medium | hard)
Requirements:
1. Ground every scenario in official Kubernetes documentation first.
2. Follow guardrails and output format exactly.
3. Randomize the exam cluster assignment appropriately.
4. Randomize the fictional company name from references/fictional-companies.md.
5. Use two-phase delivery: scenario first, solution only after requested.
Deliver {{count}} scenarios.