LFCS 5 🐧 Building a Lab with Containers
A virtual machine is not the only way to build an LFCS practice lab. Containers offer a lighter alternative: faster to start, smaller on disk, and easier to reset. But containers are not virtual machines. They share the host kernel, they have no init system by default, and they cannot practice kernel-level tasks like RAID, LVM on real block devices, or boot-time persistence. This chapter covers what containers can and cannot do for LFCS preparation, the options for building a container-based lab, and the tasks that still require a VM.
Key point: Containers are excellent for practicing command-line tasks: users and groups, file permissions, package management, service configuration, scripting, and text processing. They cannot practice tasks that require the kernel, block devices, kernel modules, boot loaders, or systemd as PID 1 unless the container is run with special privileges. For the storage and networking domains, a VM is necessary. The best lab uses both: containers for daily command practice and a VM for kernel and storage tasks.
Why containers are an option
The speed problem. A virtual machine takes minutes to boot and consumes gigabytes of disk. A container takes seconds to start and consumes tens of megabytes. For daily practice where the system is reset frequently, the difference is significant. Starting a container, practicing a task, and removing it takes less time than restoring a VM snapshot .
The reset problem. A container’s filesystem is ephemeral. Removing the container and starting a new one from the same image returns the system to a clean state. There is no snapshot to manage and no waiting for a restore. The reset is instant.
The command problem. Most of the Essential Commands and Users and Groups domains are command-line tasks: useradd, chmod, chown, grep, find, tar, systemctl (in some containers). These tasks work the same way in a container as in a VM. The commands are the same, and the results are the same.
The systemd problem. Many containers do not run systemd. They run a single process as PID 1, and systemctl is not available. This limits the Operations Deployment domain, which includes service management. Running a container with systemd as PID 1 requires special configuration: the container must run with --privileged or with the specific capabilities and mount points that systemd needs . This is possible but adds complexity.
The kernel problem. Containers share the host kernel. They cannot load kernel modules, modify kernel parameters, or create real block devices. The Storage domain requires LVM and RAID on real block devices. The Operations domain includes kernel parameters. These tasks cannot be practiced in a standard container. They require a VM.
The cost problem. Containers are free. Docker and Podman are free. Images are free. A container-based lab costs nothing beyond the host machine. A cloud VM costs money per hour. A local VM is free after the initial setup, but it requires the host to have the resources.
a. Container options for LFCS practice
Several container-based options exist for LFCS preparation.
Podman or Docker with a base image. The simplest container lab is a container running Ubuntu or CentOS from the official image. The container starts with a shell, and the practice commands are typed inside. The filesystem is ephemeral; removing and recreating the container resets it.
docker run -it --name lfcs-practice ubuntu:24.04 bash
# Inside the container:
apt update && apt install -y vim curl
useradd -m alice
id aliceThe container has no systemd, so systemctl is not available. It has no real block devices, so LVM and RAID cannot be practiced. But users, groups, permissions, file operations, package management, and text processing all work.
KillerCoda. KillerCoda is a free platform that provides browser-based Linux environments and scenarios. It is associated with killer.sh, the LFCS exam simulator . The scenarios cover command-line tasks, and the environments are containers. KillerCoda is useful for practicing individual commands and short exercises without setting up a local lab.
KodeKloud. KodeKloud provides interactive labs for the LFCS and other certifications. The labs are browser-based and cover the exam domains. They are not free, but they provide structured practice with feedback . KodeKloud’s LFCS course includes labs that run in containers and cover the tasks in the exam objectives.
A custom practice image. A Dockerfile can build a practice image with the tools pre-installed: vim, curl, git, systemd (for containers that support it), and the packages needed for the domains. The image is built once and used for every practice session.
FROM ubuntu:24.04
RUN apt update && apt install -y \
vim curl git cron sudo \
&& rm -rf /var/lib/apt/lists/*
RUN useradd -m -s /bin/bash student && \
echo "student:password" | chpasswd && \
usermod -aG sudo student
USER student
WORKDIR /home/studentThe image includes the tools that the command-line tasks require. It does not include systemd or block device support, so the tasks that need those must be practiced in a VM.
LFCS practice tool. An interactive LFCS practice tool with 83+ Docker scenarios has been published. It runs in Docker and provides hands-on scenarios for the exam domains . The scenarios are graded, and the environment is container-based.
b. What containers can and cannot practice
The distinction between what a container can practice and what it cannot is determined by what the container shares with the host and what it isolates.
| Domain | Container | VM |
|---|---|---|
| Essential Commands | Yes | Yes |
| Users and Groups | Yes | Yes |
| Package management | Yes | Yes |
| Service management (systemd) | Limited | Yes |
| Kernel parameters | No | Yes |
| LVM | No | Yes |
| RAID | No | Yes |
| Filesystem creation (loop devices) | Limited | Yes |
| Swap | Limited | Yes |
| Networking (basic) | Yes | Yes |
| Networking (bridge, bonding) | No | Yes |
| Firewall (ufw, firewalld) | Limited | Yes |
| Boot persistence | No | Yes |
| SELinux/AppArmor | Limited | Yes |
Essential Commands are almost entirely command-line tasks. Finding files, archiving, text processing, Git operations, and basic scripting work in a container. The only limitation is service creation, which requires systemd.
Users and Groups are fully supported. useradd, usermod, groupadd, chage, passwd, sudo, and ACLs all work in a container.
Storage is the domain that containers cannot handle. LVM, RAID, and filesystem creation on real block devices require the kernel and the block layer. A container with loop devices can practice some filesystem operations, but the tasks in the exam use real or virtual block devices, and the practice should match.
Networking is partially supported. Basic configuration, ip commands, ss, ping, dig, and SSH work in a container. Bridge, bonding, and static routing require kernel network interfaces that a container cannot create. The firewall tools are available but may not function fully without the kernel’s netfilter.
Operations Deployment is partially supported. Process management, job scheduling with cron, package management, and Git work. Kernel parameters, service management with systemd, virtual machines, and SELinux require a VM.
Boot persistence cannot be practiced in a container. There is no boot process. A change that would need to survive a reboot in a VM has no equivalent in a container. The persistence testing that is essential for the exam must be done in a VM.
c. Combining containers and VMs
The most effective lab uses both. Containers are for daily command practice. A VM is for the tasks that require the kernel, block devices, and systemd.
Daily command practice. Start a container, practice useradd, chmod, grep, find, tar, sed, awk, Git commands, and file operations. Remove the container and start again. The practice is fast, and the environment is clean.
Weekly VM practice. Boot the VM, practice LVM, RAID, service creation, kernel parameters, firewall configuration, and persistence testing. Restore the snapshot when done. The VM practice is less frequent but covers the domains that containers cannot.
Exam rehearsal. Use the killer.sh simulator for full exam rehearsal. The simulator environment is not a container or a VM that you control; it is a purpose-built exam environment. It is the closest thing to the real exam and should be used after the domains are covered .
The combined routine. Monday through Friday: 30 minutes of container practice on command-line tasks. Saturday: 2 hours of VM practice on storage, networking, and services. Sunday: review and weak-area practice. The routine covers all domains without requiring the VM to be booted every day.
A container can also be used inside the VM. The VM provides the kernel and the block devices; the container provides a clean, disposable environment for command practice. This is useful when the VM’s filesystem has been modified by previous practice and the command practice should start from a clean state without restoring the VM snapshot.
Complete Example Session
# ============================================
# PART 1: START A PRACTICE CONTAINER
# ============================================
docker run -it --name lfcs ubuntu:24.04 bash# ============================================
# PART 2: INSTALL TOOLS
# ============================================
apt update && apt install -y vim curl git sudo cron# ============================================
# PART 3: USER PRACTICE
# ============================================
useradd -m -s /bin/bash -u 1500 alice
id alice
passwd alice
usermod -aG sudo alice# ============================================
# PART 4: PERMISSION PRACTICE
# ============================================
touch file.txt
chmod 644 file.txt
chown alice:alice file.txt
ls -la file.txt# ============================================
# PART 5: TEXT PROCESSING
# ============================================
echo "hello world" > test.txt
grep "world" test.txt
sed 's/world/there/' test.txt
awk '{print $1}' test.txt# ============================================
# PART 6: ARCHIVE
# ============================================
tar -czpf backup.tar.gz /etc
tar -tzf backup.tar.gz | head# ============================================
# PART 7: GIT PRACTICE
# ============================================
git init myrepo
cd myrepo
echo "content" > file.txt
git add .
git commit -m "Initial commit"
git log# ============================================
# PART 8: CRON PRACTICE
# ============================================
crontab -e
# Add: 0 2 * * * /usr/bin/backup.sh
crontab -l# ============================================
# PART 9: CLEAN UP CONTAINER
# ============================================
exit
docker rm lfcs# ============================================
# PART 10: START FRESH
# ============================================
docker run -it --name lfcs ubuntu:24.04 bash
# Clean environment, no leftover stateThe ten parts covered starting a container, installing tools, user practice, permission practice, text processing, archiving, Git practice, cron practice, cleanup, and starting fresh.
Quick Reference
Container Options
| Option | Type | Cost | Best For |
|---|---|---|---|
| Podman/Docker | Local container | Free | Daily command practice |
| KillerCoda | Browser scenarios | Free | Short exercises |
| KodeKloud | Interactive labs | Subscription | Structured practice |
| LFCS practice tool | Docker scenarios | Free | Graded scenarios |
| Custom image | Local container | Free | Pre-configured practice |
Domain Support
| Domain | Container | VM |
|---|---|---|
| Essential Commands | Yes | Yes |
| Users and Groups | Yes | Yes |
| Package management | Yes | Yes |
| Service management | Limited | Yes |
| Kernel parameters | No | Yes |
| LVM/RAID | No | Yes |
| Filesystem creation | Limited | Yes |
| Networking (basic) | Yes | Yes |
| Networking (bridge) | No | Yes |
| Boot persistence | No | Yes |
Combined Lab Routine
| Day | Focus | Tool |
|---|---|---|
| Mon–Fri | Command practice | Container |
| Saturday | Storage, services | VM |
| Sunday | Review, weak areas | Both |
| Exam prep | Full rehearsal | killer.sh |
Container Limitations
| Limitation | Reason |
|---|---|
| No systemd | Container runs one process |
| No block devices | Shares host kernel |
| No kernel modules | Cannot modify kernel |
| No boot process | No init |
| No bridge/bonding | No kernel network interfaces |
Best Practices
✅ Do This:
# Use containers for daily command practice
docker run -it ubuntu:24.04 bash # ✅
# Install the tools you need
apt update && apt install -y vim curl git cron sudo # ✅
# Practice users, groups, permissions, text processing
useradd, chmod, grep, sed, awk, tar # ✅
# Remove and recreate the container for a clean state
docker rm lfcs && docker run -it --name lfcs ubuntu:24.04 bash # ✅
# Use a VM for storage, services, and persistence
LVM, RAID, systemd, kernel parameters # ✅
# Use killer.sh for exam rehearsal
After the domains are covered # ✅
# Combine container and VM practice
Containers daily, VM weekly # ✅❌ Don’t Do This:
# Don't try to practice LVM in a standard container
pvcreate /dev/sdb # no /dev/sdb # ❌
# Don't try to load kernel modules
modprobe # no permission in container # ❌
# Don't expect systemctl to work
systemctl start nginx # no systemd # ❌
# Don't practice boot persistence
# Containers have no boot process # ❌
# Don't rely on containers alone
Storage and services need a VM # ⚠️
# Don't forget to install the tools
The base image is minimal # ❌
# Don't use a container for the final rehearsal
Use killer.sh # ⚠️Common Pitfalls
| Pitfall | Why It Happens | Fix |
|---|---|---|
systemctl not found | No systemd in container | Use a VM |
| No block devices | Container shares kernel | Use a VM |
modprobe fails | No kernel module access | Use a VM |
| Changes not persistent | Container filesystem ephemeral | Use a VM for persistence |
| Firewall commands fail | Limited netfilter access | Use a VM |
| Tools not installed | Minimal base image | apt install the tools |
| Practice not graded | No feedback | Use graded scenarios |
Real-World Examples
1. Start a Container
docker run -it --name lfcs ubuntu:24.04 bash2. Install Tools
apt update && apt install -y vim curl git sudo cron3. Create a User
useradd -m -s /bin/bash -u 1500 alice
id alice4. Set Permissions
chmod 755 script.sh
chown alice:alice script.sh5. Search Files
grep -r "error" /var/log/
find /etc -name "*.conf"6. Archive
tar -czpf backup.tar.gz /etc7. Git
git init && git add . && git commit -m "Initial"8. Cron
echo "0 2 * * * /usr/bin/backup.sh" | crontab -
crontab -l9. Clean Up
exit
docker rm lfcs10. Start Fresh
docker run -it --name lfcs ubuntu:24.04 bashVisual
Container vs VM for LFCS
┌─────────────────────────────────────────────────────────────┐
│ CONTAINER │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ Command-line tasks │ │
│ │ Users and Groups │ │
│ │ File permissions │ │
│ │ Text processing │ │
│ │ Package management │ │
│ │ Git operations │ │
│ │ Cron │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Fast. Free. Ephemeral. No kernel. │
│ │
├─────────────────────────────────────────────────────────────┤
│ │
│ VM │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LVM, RAID, filesystems │ │
│ │ Systemd services │ │
│ │ Kernel parameters │ │
│ │ Firewall (ufw, firewalld) │ │
│ │ Bridge, bonding, routing │ │
│ │ Boot persistence │ │
│ │ SELinux/AppArmor │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ Slower. Resource-heavy. Full kernel. │
│ │
└─────────────────────────────────────────────────────────────┘Combined Lab Workflow
┌─────────────────────────────────────────────────────────────┐
│ MONDAY - FRIDAY │
│ Container: 30 min command practice │
│ useradd, chmod, grep, find, tar, sed, awk, git │
│ │
│ SATURDAY │
│ VM: 2 hours storage, services, networking │
│ LVM, RAID, systemd, firewall, persistence │
│ │
│ SUNDAY │
│ Review: weak areas │
│ │
│ WEEK BEFORE EXAM │
│ killer.sh: full rehearsal │
│ │
└─────────────────────────────────────────────────────────────┘Container Reset
┌─────────────────────────────────────────────────────────────┐
│ START CONTAINER │
│ │ │
│ ▼ │
│ PRACTICE │
│ │ │
│ ▼ │
│ EXIT │
│ │ │
│ ▼ │
│ docker rm lfcs │
│ │ │
│ ▼ │
│ docker run -it --name lfcs ubuntu:24.04 bash │
│ │ │
│ ▼ │
│ CLEAN ENVIRONMENT │
│ │
│ Reset is instant. No snapshot to restore. │
│ │
└─────────────────────────────────────────────────────────────┘When to Use Which
┌─────────────────────────────────────────────────────────────┐
│ TASK TYPE CONTAINER VM │
│ │
│ useradd, usermod ✓ ✓ │
│ chmod, chown ✓ ✓ │
│ grep, find, sed, awk ✓ ✓ │
│ tar, gzip ✓ ✓ │
│ git ✓ ✓ │
│ cron ✓ ✓ │
│ systemctl ✗ ✓ │
│ pvcreate, lvcreate ✗ ✓ │
│ mdadm ✗ ✓ │
│ sysctl ✗ ✓ │
│ ufw, firewall-cmd Limited ✓ │
│ reboot persistence ✗ ✓ │
│ │
└─────────────────────────────────────────────────────────────┘Summary
| Item | Value |
|---|---|
| Container use | Command-line tasks |
| VM use | Storage, services, kernel, persistence |
| Container speed | Seconds to start |
| VM speed | Minutes to boot |
| Container reset | Remove and recreate |
| VM reset | Snapshot restore |
| Container cost | Free |
| VM cost | Free (local) |
| Best combination | Both |
Key takeaways:
- Containers are lighter and faster than VMs. They start in seconds, consume tens of megabytes, and reset instantly. For daily command-line practice, they are more efficient than booting a VM.
- Containers can practice Essential Commands and Users and Groups fully. User management, permissions, text processing, archiving, Git, and cron all work in a container.
- Containers cannot practice kernel-level tasks. LVM, RAID, kernel parameters, systemd services, bridge networking, and boot persistence require a VM. The container shares the host kernel and has no init system.
- The best lab combines both. Use containers for daily command practice and a VM for the tasks that require the kernel and block devices. The combination covers all five domains.
- KillerCoda and KodeKloud provide browser-based practice. KillerCoda is free and associated with killer.sh. KodeKloud is a subscription with structured labs. Both are container-based.
- An LFCS practice tool with 83+ Docker scenarios exists. It provides graded, container-based scenarios for the exam domains.
- Exam rehearsal requires the killer.sh simulator. It is included with the exam purchase and provides 2 sessions of 36 hours each. Use it after the domains are covered, not as a substitute for the lab.
Remember: Containers and VMs are not competitors for the LFCS lab. They are complements. Containers are for the command-line tasks that make up most of the Essential Commands and Users and Groups domains. They are fast, free, and ephemeral. A VM is for the tasks that need the kernel: LVM, RAID, systemd, kernel parameters, firewall, and boot persistence. The best preparation uses both. Practice commands daily in a container. Practice storage and services weekly in a VM. Rehearse for the exam with the simulator. The lab is where the knowledge becomes skill, and the skill is what the exam tests.
Stop using slow, ad-bloated tool sites! 🤮
🔎 Search “KandZ Tools” on Google to use many professional utilities for free.
KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)
⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free
🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!