ced4568andClaude Sonnet 5
60fbf0c385
Pre-Phase-1 platform work, approved and tested earlier but not yet committed: - Terminal banner: "RootNode Academy Lab — node: k8s-lab", upstream KubeKosh attribution left untouched in footer/README/LICENSE. - RootNode curriculum mode: scenarios/rootnode-path.json (Foundation -> Workloads -> Networking -> Configuration -> Troubleshooting -> Real Ops -> Capstone), built from existing scenario content grouped by category, no new scenarios invented. New GET /api/curriculum/path endpoint. - Student roster + per-student progress: instructor-roster, pick-your-name login (no password), students/environments-adjacent progress table migrated to a (student_id, scenario_id) composite key so practice progress and exam sessions are isolated per student instead of one global bucket. New /api/roster, /api/login endpoints. - scenarios/data/*.json: added isolation_type metadata (shared_namespace vs ephemeral_cluster) from an audit of which scenarios execute cluster-scoped or node-level commands. This was Tier-1-isolation groundwork that got superseded same-day by the full-ephemeral-per-student architecture (see docs/LAB_ARCHITECTURE.md) — the field is kept as descriptive metadata only, per the note now in scenarios/SCHEMA.md. Not wasted: it's an accurate audit of which scenarios touch cluster-scoped resources, useful independent of isolation model. - .gitignore added (node_modules/, frontend/dist/, *.db, /data/, .env) — none existed before; without it, npm installs during testing would have landed in a commit. Known limitation still open: no frontend UI for any of this yet (login screen, roster-add form, curriculum view) — API-only. No auth on the roster-add endpoint. Co-Authored-By: Claude Sonnet 5 <[email protected]>
41 lines
1.8 KiB
JSON
41 lines
1.8 KiB
JSON
{
|
|
"id": "init-containers-mcq",
|
|
"title": "Init Containers Behaviour",
|
|
"category": "Core Concepts",
|
|
"isolation_type": "shared_namespace",
|
|
"difficulty": "Easy",
|
|
"type": "mcq",
|
|
"weight": 3,
|
|
"description": "## Init Containers Behaviour\n\nA pod spec defines two init containers (`init-db-check` and `init-config`) followed by one main app container (`web`).\n\nWhich statement **correctly** describes how Kubernetes runs these containers?",
|
|
"options": [
|
|
{
|
|
"id": "a",
|
|
"text": "All three containers start simultaneously; init containers simply have lower priority"
|
|
},
|
|
{
|
|
"id": "b",
|
|
"text": "Init containers run sequentially to completion before the main `web` container starts"
|
|
},
|
|
{
|
|
"id": "c",
|
|
"text": "The `web` container starts first, and init containers run as sidecars alongside it"
|
|
},
|
|
{
|
|
"id": "d",
|
|
"text": "Init containers cannot share volumes with the main container"
|
|
}
|
|
],
|
|
"correct_option": "b",
|
|
"explanation": "Init containers always run **sequentially** and must each exit with a success (exit code 0) before the next one starts. Only after **all** init containers complete successfully does Kubernetes start the main application containers. They can share volumes with main containers, making them ideal for setup tasks like seeding configs, waiting for dependencies, or initialising databases.",
|
|
"hints": [
|
|
{
|
|
"title": "Init container execution order",
|
|
"body": "Check `kubectl explain pod.spec.initContainers`. Each init container runs to completion before the next begins, and all must succeed before app containers start.",
|
|
"command": "kubectl explain pod.spec.initContainers"
|
|
}
|
|
],
|
|
"setup_commands": [],
|
|
"default_namespace": "default",
|
|
"teardown_commands": []
|
|
}
|