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]>
35 lines
1.1 KiB
JSON
35 lines
1.1 KiB
JSON
{
|
|
"id": "cks-mcq-image-footprint",
|
|
"title": "Minimizing Image Footprint",
|
|
"category": "Supply Chain Security",
|
|
"isolation_type": "shared_namespace",
|
|
"difficulty": "Easy",
|
|
"type": "mcq",
|
|
"weight": 2,
|
|
"description": "Why is it highly recommended in the CKS exam to use base images like **Alpine Linux** or **Distroless** for your containerized applications?",
|
|
"options": [
|
|
{
|
|
"id": "a",
|
|
"text": "They automatically encrypt data at rest"
|
|
},
|
|
{
|
|
"id": "b",
|
|
"text": "They have a significantly reduced attack surface with fewer packages"
|
|
},
|
|
{
|
|
"id": "c",
|
|
"text": "They automatically configure NetworkPolicies for the pod"
|
|
},
|
|
{
|
|
"id": "d",
|
|
"text": "They guarantee that the container will not run as root"
|
|
}
|
|
],
|
|
"correct_option": "b",
|
|
"explanation": "Minimal images like Alpine or Distroless contain only the bare minimum files and dependencies needed to run the application. This drastically reduces the attack surface and the number of potential CVEs.",
|
|
"hints": [],
|
|
"setup_commands": [],
|
|
"default_namespace": "default",
|
|
"teardown_commands": []
|
|
}
|