Homelab Architect for Cert Practice prompts

Act as a homelab mentor. Design a practice lab for a certification.

Certification: <CERT> (e.g. CCNA, RHCSA, CKA, AWS SAA)
Hardware I have: <RAM, CPU, DISK — or "just a laptop">
Monthly budget: <e.g. 0€ / 10€ / 30€>
Goal: pass the exam AND have something real to show.

Deliver:
1. The leanest setup that covers the exam's hands-on objectives — name the specific tools (e.g. VirtualBox, Proxmox, GNS3, kind, cloud free tier) and why.
2. What runs locally vs what should run on a cloud free tier, with the cost risk of each.
3. A 4-stage build order, from "first thing to install" to "exam-realistic environment".
4. The one mistake most people make with a <CERT> homelab and how to avoid it.

Keep it within my budget and hardware. If my hardware genuinely can't do it, say so and give the cheapest cloud alternative.

Create a set of hands-on lab exercises for one exam objective.

Certification: <CERT>
Objective to drill: <SPECIFIC_OBJECTIVE> (e.g. "configure OSPF", "manage LVM storage", "set up an Ingress")
My current level on it: <NEW | SHAKY | NEED_SPEED>

Produce 5 exercises, easy to exam-hard, each with:
- A task stated the way the exam would state it (terse, outcome-based — not a tutorial).
- The success criterion: how I verify it actually worked.
- A time budget a competent candidate should hit.
- A hidden "hint" line I can choose to read only if stuck.

Do NOT include the solution commands — I learn by doing, not reading. End with one "break it and fix it" exercise that mimics a real troubleshooting question.

My homelab setup is broken. Walk me through it like a patient senior engineer — teach, don't just hand me the fix.

What I was trying to do: <GOAL>
Environment: <OS, TOOL, VERSIONS>
What I expected vs what happened: <SYMPTOM>
Error output (no secrets/IPs): <PASTE_SANITISED_OUTPUT>
What I've already tried: <STEPS>

Respond in this order:
1. The most likely root cause, in one sentence, and how the symptom points to it.
2. A diagnostic command or check to confirm it BEFORE changing anything.
3. The fix — and what it actually does, so I'd recognise this class of problem next time.
4. The exam-relevant lesson: if a <CERT> question hit this scenario, what would it be testing?

If there isn't enough information, tell me exactly what to collect.

Help me turn a homelab build into a credible portfolio project.

What I built: <DESCRIBE_THE_LAB_OR_SETUP>
Cert / role it supports: <CERT_AND_TARGET_ROLE>
Where it'll live: <GITHUB | BLOG | BOTH>

Produce:
1. A project framing — the problem it 'solves', stated like a real-world scenario rather than "I followed a tutorial".
2. A README outline: overview, architecture (with an ASCII diagram), how-to-run, what I learned, what I'd improve.
3. Three resume bullet points derived from it — action verb, concrete tech, outcome — honest, no inflation.
4. Two questions an interviewer could ask about this project, with a one-line answer each.

Keep it truthful to what I actually built. If it's too thin to be a portfolio piece, tell me what to add first.

Help me pick the right tool for my homelab — decisively, not a feature dump.

Decision: <OPTION_A> vs <OPTION_B> (e.g. VirtualBox vs Proxmox, GNS3 vs CML, kind vs minikube, local VM vs cloud free tier)
What I'm using it for: <CERT_OR_OBJECTIVE>
My constraints: <HARDWARE, BUDGET, OS, TIME>

Give me:
1. A one-line verdict for MY constraints — pick one, don't fence-sit.
2. The 3 trade-offs that actually matter here (ignore the rest).
3. The situation in which the OTHER option would have been the right call.
4. The hidden cost of the option you recommend (setup time, RAM, licence, learning curve).

If both are overkill for what I need, say so and name the simpler third option.