In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
Move learners from installing Docker Engine to operating containers with controlled images, bounded resources, durable data, understood Linux storage, reliable mounts, and intentional file permissions.
In plain words: Big idea: Move learners from installing Docker Engine to operating containers with controlled images, bounded resources, durable data, understood Linux storage, reliab…
Objective
Module Objectives
In plain words: This is what done looks like for the class.
By the end of Classes 27–33, learners can:
In plain words: Big idea: By the end of Classes 27–33, learners can:
Trace a request from the Docker CLI through the daemon and runtime.
distinguish image tags from immutable digests and record provenance evidence.
Control container lifecycle, signals, restart behavior, CPU, memory, and PID limits.
Select named volumes or bind mounts based on ownership, portability, backup, and security needs.
Explain the disk → partition → filesystem → mount hierarchy without experimenting on a physical disk.
Stage and validate an fstab entry using UUIDs without altering boot configuration.
Diagnose container file-access failures using UID, GID, mode bits, ACLs, and mount properties.
Back up, verify, restore, and roll back the state created in the module labs.
In plain words: Make a safety copy first so a mistake does not erase your work.
Learn
Required Reading
In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
Linux lsblk: https://man7.org/linux/man-pages/man8/lsblk.8.html
Linux findmnt: https://man7.org/linux/man-pages/man8/findmnt.8.html
Linux fstab: https://man7.org/linux/man-pages/man5/fstab.5.html
Linux ACLs: https://man7.org/linux/man-pages/man5/acl.5.html
In plain words: Big idea: - Docker images: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/
- Docker image digests: https://docs.docker.com/dhi/core-co…
Hands-on
Homework / Lab
In plain words: This is the hands-on part. Follow the numbered steps and keep notes of what you saw.
Create an operator evidence folder containing:
In plain words: Big idea: Create an operator evidence folder containing:
An image inventory with tag, image ID, labels, and digest when available.
A container inspection showing explicit memory and PID limits.
A named-volume backup archive and a verified restore.
A read-only block-device and mount inventory.
A staged fstab entry that passes available syntax verification.
A numeric UID/GID permission test with expected success and expected denial.
A one-page rollback plan covering every state-changing exercise.
In plain words: Make a safety copy first so a mistake does not erase your work.
Do not include secrets, registry tokens, private image names, public IP addresses, or host-specific personal paths.
In plain words: Big idea: Do not include secrets, registry tokens, private image names, public IP addresses, or host-specific personal paths.
Check yourself
Module Quiz
In plain words: Answer from memory first. Then check yourself.
Target: 10/12 correct. Missed objectives route to remediation before a second attempt.
In plain words: Big idea: Target: 10/12 correct.
Why is a Docker tag insufficient as immutable provenance evidence?
What does an image digest identify?
Why should containers receive explicit resource limits in a shared homelab?
What is the operational difference between docker stop and docker kill with its default signal?
When is a named volume normally preferable to a bind mount?
What additional host exposure does a bind mount create?
Put these in order: mount, disk, filesystem, partition.
Why is filesystem free space not the same as physical-disk health?
Why are UUID-based fstab entries often safer than /dev/sdX names?
What should be done before running mount -a against production fstab changes?
Why can a container process receive Permission denied even when the path exists?
What problem can a default ACL solve?
In plain words: A session id lets you resume the same AI conversation later, like continuing a chat instead of starting over.
Learn
Answer Key
In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
Tags are mutable references and can be reassigned to different manifests.
A digest identifies content through a cryptographic hash of the referenced manifest.
Limits prevent one workload from exhausting memory, CPU scheduling, or process capacity needed by others.
stop requests graceful termination and later forces termination; default kill sends immediate SIGKILL.
When Docker-managed, portable persistent storage is desired without coupling to a specific host path.
The container can access the selected host path, subject to mount mode and kernel enforcement; a bad path or broad mount increases host-data risk.
Disk → partition → filesystem → mount.
Free space describes filesystem allocation; disk health concerns the underlying device and its error/failure signals.
UUIDs identify the intended filesystem more consistently when kernel device names change.
Back up the current file, stage the edit, validate syntax and targets, and plan recovery for a boot or mount failure.
The process UID/GID, mode bits, ACL, mount flags, or security policy may not permit the requested operation.
It automatically grants defined permissions to new children created inside a directory.
In plain words: A health check asks “are you really ready?” not just “did the process start?”
Learn
Module Project
In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
Durable Container Storage Blueprint
Design a small self-hosted service with one stateless container and one persistent data location. Deliver:
An image provenance record containing registry, repository, tag, digest policy, and update policy.
A Compose-style service design with explicit memory and PID limits.
A decision record choosing a named volume or bind mount.
A backup and restore procedure with a verification hash.
A host storage map from device to filesystem to mountpoint.
A staged UUID-based mount entry if host-managed storage is used.
A numeric UID/GID and ACL plan.
Security boundaries, monitoring signals, failure modes, and rollback steps.
The project may use a disposable VM or remain a reviewed design. Do not expose a new service publicly as part of the assessment.
In plain words: A session id lets you resume the same AI conversation later, like continuing a chat instead of starting over.
Learn
Module Exam
In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
Part A: Concepts (30 points)
Explain tag versus digest and the provenance consequence. (10)
Explain writable layer versus persistent mount. (10)
Explain UID/GID evaluation for a bind-mounted path. (10)
In plain words: Big idea: - Explain tag versus digest and the provenance consequence.
Part B: Diagnosis (30 points)
Given a container that restarts, exceeds memory, and cannot write to /config, identify evidence commands, likely causes, and a safe repair sequence.
In plain words: Big idea: Given a container that restarts, exceeds memory, and cannot write to this setting, identify evidence commands, likely causes, and a safe repair sequence.
Part C: Practical evidence (40 points)
Image inspection and recorded identity: 8
Bounded container configuration: 8
Volume backup and verified restore: 8
Staged mount validation: 8
Permission and rollback evidence: 8
In plain words: Make a safety copy first so a mistake does not erase your work.
Learn
Passing Criteria and Rubric
In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
Pass: at least 80/100 overall.
Safety gate: no credit for a practical step that targets an unverified physical disk, edits live fstab without staging, exposes the Docker socket, or uses a broad destructive deletion.
Mastery: at least 80%, completed project evidence, successful Feynman explanation, and all rollback questions answered.
In plain words: Big idea: - Pass: at least 80/100 overall.
Learn
Remediation
In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
Missed skill
Return to
Required retry evidence
Image identity/provenance
Class 28
Explain tag vs digest using one inspected image
Lifecycle/resources
Class 29
Interpret one bounded container inspection
Persistent storage
Class 30
Restore and hash-check one named-volume backup
Disk/filesystem model
Class 31
Label a disk/partition/filesystem/mount diagram
Mount persistence
Class 32
Validate a staged UUID entry without editing /etc/fstab
Permissions
Class 33
Predict and verify one allowed and one denied write
In plain words: Read this block, then try the next action. If you feel stuck, tap What this means.
After remediation, retake only the affected quiz objectives, then repeat the integrated explanation below.
In plain words: Big idea: After remediation, retake only the affected quiz objectives, then repeat the integrated explanation below.
Teach it back
Feynman teach-back: required
In plain words: If you cannot explain it simply, you do not own it yet. This section is required for mastery.
More detail: Weak spots are gold: restudy that part and rewrite.
Explain to a new homelab operator how an approved image becomes a bounded container whose data survives replacement on a known filesystem and remains writable only to the intended numeric identity. Use plain language and include one failure and rollback example.
Answers save in this browser (localStorage). Completing all five fields is part of the mastery unlock.
Reflect
Course Reflection
In plain words: Name what you learned, where you struggled, and how it connects backward and forward.
Which hidden dependency, image identity, resources, storage, mounts, or permissions, was easiest to overlook?
Which verification step would have prevented a failure you have previously experienced?
What will you standardize in future Compose files?