Practise
Labs
Exercises to replay on your own machine, graded on the real state of the system rather than on the commands you typed. They prepare 8 certifications, from RHCSA to CKS. Everything is free and account-free: the catalogues are public repositories, and grading runs on your machine.
Start in four commandsEvery command
- 404 labs graded on the state of your machine
- 250 hours of practice to replay at home
- 227 on a virtual machine real systems, not containers
- 204 attested* by the author; 200 still await their record
Install DSOXLab, then run any lab The CLI installs the catalogue, prepares the environment, gives you the brief and then runs the validation tests. It needs no administrator rights, and Python 3.11 is enough.
-
01
Install the CLI
With uv or pipx, in your user account.
uv tool install dsoxlab # or: pipx install dsoxlab -
02
Add a catalogue
The exact command sits at the top of each catalogue below.
dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training -
03
Check your machine
Missing memory or hypervisor: reported before Terraform fails on you.
dsoxlab doctor -
04
Run, then grade
start prepares and opens a session; check runs the tests and computes the score.
dsoxlab start l1-first-terminaldsoxlab check l1-first-terminal
What the catalogue labels mean Two labels appear on every card. They tell you what your machine needs, and how far the author has tested the lab.
Shell or virtual machine
227 of the 404 labs provision real virtual machines: no container will prove that you can repair a systemd service or write an SELinux rule. The rest only need a shell, and dsoxlab doctor reports what your machine is missing before the first run.
Attested, to re-attest, or not yet
204 labs carry the attested mark: the author played each one end to end and scored it both ways, zero before the work and one hundred after, and it has not changed since. 87 were modified after that record: they run, but are still to re-attest. 113 still await their record, and this page says so rather than making the same promise everywhere. This attestation covers the lab, never your own results, which this site cannot verify.
* An attestation holds for the versions of the tool and its dependencies installed on the day of the record. An upgrade, of the tool itself, an image, a collection or the CLI, can break a lab that used to pass: labs are therefore replayed regularly, and any modified lab goes back to “to re-attest” until its next record.
Understand a labThe English documentationThe certifications prepared
The search box takes a command, a skill or a certification acronym: typing selinux or CKA narrows the list down to what concerns you. Every lab is written in English. The companion guides are being translated, and a link says when one is still French only.
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/linux-dsoxlab-training
Fundamentals
20
-
Guided lab to re-attest 15m · beginner · shell
First steps in the terminal
Run basic commands (whoami, pwd, hostname, date) and capture the output in a file.
dsoxlab start l1-first-terminalRHCSALFCS Companion guide
-
Guided lab to re-attest 20m · beginner · shell
Map Linux: kernel, distribution and key directories
Explore what Linux is made of: run real commands on your own system to discover the kernel, your distribution and the role of /etc, /var/log and /proc. Fill in a knowledge map.
dsoxlab start l1-discover-linux-mapRHCSALFCS Companion guide
-
Guided lab to re-attest 15m · beginner · shell
Choose your reference Linux distribution
Compare Debian/Ubuntu and RHEL-based distributions, understand the criteria for choosing between them, and document your choice for three practical scenarios.
dsoxlab start l1-choose-distroRHCSALFCS Companion guide
-
Guided lab to re-attest 15m · beginner · shell
Identify your Linux machine
Run commands to collect your system's hostname, distribution, kernel version and IP address. Produce a machine identity card stored in vm-info.txt.
dsoxlab start l1-prepare-vmRHCSALFCS Companion guide
-
Guided lab to re-attest 20m · beginner · shell
Read and decode a command
Decompose 5 Linux commands into their command/options/arguments parts and fix 3 broken commands.
dsoxlab start l1-read-a-commandRHCSALFCS Companion guide
-
Guided lab to re-attest 20m · beginner · shell
Get help from the command line
Use man, --help, and apropos to find the right command options without searching the web.
dsoxlab start l1-get-helpRHCSALFCS Companion guide
-
Guided lab to re-attest 20m · beginner · shell
Linux filesystem hierarchy (FHS)
Match the standard Linux directories to their roles and classify files by location.
dsoxlab start l1-linux-filesystemRHCSALFCS Companion guide
-
Guided lab to re-attest 30m · beginner · shell
Navigate the filesystem
Use cd, ls, mkdir, cp, mv, rm to build a target directory tree from scratch.
dsoxlab start l1-navigate-filesystemRHCSALFCS Companion guide
-
Guided lab to re-attest 25m · beginner · shell
Absolute and relative paths
Copy a file using an absolute path and a relative path, then solve 5 path navigation puzzles.
dsoxlab start l1-paths-absolute-relativeRHCSALFCS Companion guide
-
Guided lab to re-attest 20m · beginner · shell
Redirect streams and chain commands with pipes
Redirect stdout and stderr, merge them, and chain commands with pipes to produce exact artifacts.
dsoxlab start l1-redirections-pipesRHCSA Companion guide
-
Guided lab to re-attest 25m · beginner · shell
Filter a log with grep and regular expressions
Use grep with anchors, character classes, invert-match and count to extract exact facts from an access log.
dsoxlab start l1-grep-regexRHCSALFCS Companion guide
-
Guided lab to re-attest 30m · beginner · shell
Transform and aggregate text with cut, sort, uniq, sed and awk
Slice columns, deduplicate, count occurrences, sum a field and rewrite a delimiter to turn a raw record file into exact facts.
dsoxlab start l1-text-processingRHCSALFCS Companion guide
-
Guided lab to re-attest 25m · beginner · shell
Locate files with find by name, size and permissions
Extract a project tree and use find to list files by name pattern, by size and by exact permissions, producing the results into files that are checked against the real tree.
dsoxlab start l1-find-filesRHCSALFCS Companion guide
-
Guided lab to re-attest 25m · beginner · shell
Archive, compress and selectively extract with tar, gzip and bzip2
Create gzip and bzip2 tarballs, list their contents, and extract a single member into a target directory.
dsoxlab start l1-tar-archivesRHCSA Companion guide
-
Guided lab to re-attest 25m · beginner · shell
Set exact file permissions with chmod (octal and symbolic)
Give each file the right owner/group/other bits: a private secret, an executable script, a group-readable note and a private directory.
dsoxlab start l1-permissions-ugoRHCSALFCS Companion guide
-
Guided lab to re-attest 25m · beginner · shell
Create hard and symbolic links and tell them apart
Make a hard link that shares the inode, a symbolic link that points by path, and a symlink to a directory, proven by inode, link count and link target.
dsoxlab start l1-links-hard-symRHCSA Companion guide
-
Guided lab to re-attest 35m · beginner · shell
Write a first Bash script: variables, a loop and a condition
Write rapport.sh that reads a status file passed as an argument, counts UP/DOWN with a loop, prints them, and exits non-zero when any host is down.
dsoxlab start l1-bash-scriptRHCSALFCS Companion guide
-
Guided lab to re-attest 30m · beginner · shell
Initialize a Git repo: commit, history and a branch
Create a repository, make two commits tracking real files, and open a feature branch, proven by inspecting the repository state itself.
dsoxlab start l1-git-basics -
Guided lab to re-attest 25m · beginner · shell
Environment variables: export, PATH and a sourced env file
Write env.sh that, when sourced, exports variables, reuses one in another, and prepends a bin directory to PATH, proven by sourcing it in a subshell.
dsoxlab start l1-env-profilesLFCS Companion guide
-
Guided lab to re-attest 25m · beginner · shell
Inspect a TLS certificate with openssl
Read a delivered X.509 certificate: extract its subject, validity dates, SHA-256 fingerprint and public key with openssl x509.
dsoxlab start l1-ssl-certificates
Operating and maintaining
18
-
Guided lab to re-attest 25m · intermediate · virtual machines
Add and manage swap space
Create a secure swap file, activate it, make it persistent in /etc/fstab and tune vm.swappiness.
dsoxlab start l2-swap-managementRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Mount a filesystem persistently by UUID in /etc/fstab
Mount a pre-formatted extra disk at /srv/data through /etc/fstab, referenced by UUID (not device name) so it survives a reboot, and prove the line with mount -a AND findmnt --verify.
dsoxlab start l2-fstab-persist-uuidRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Create GPT partitions on a disk with parted
Put a GPT label on the spare disk and carve two partitions (512 MiB and 1 GiB), then make the kernel re-read the table.
dsoxlab start l2-partition-gptRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Create and label an XFS filesystem, then mount it
Format a prepared partition as XFS with a label, create a mount point and mount it, proven by the filesystem type, its label and the active mount.
dsoxlab start l2-filesystem-create-xfsRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Diagnose a full filesystem and reclaim space
A filesystem is full. Find the culprit with df/du, remove the junk without deleting the legitimate data, and bring usage back down.
dsoxlab start l2-disk-space-troubleshootRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Tune a mount for performance with noatime (persistently)
A read-heavy filesystem wastes I/O writing access times. Add the noatime mount option, make it active and persistent in /etc/fstab.
dsoxlab start l2-storage-performance -
Guided lab to re-attest 25m · intermediate · virtual machines
Extend a logical volume and prove the mount survives a reboot
Extend an LVM logical volume, grow the XFS filesystem, and make the mount persistent via /etc/fstab by UUID.
dsoxlab start l2-lvm-extend-persistRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 30m · intermediate · virtual machines
Mount an NFS export persistently from a server
A second host exports an NFS share. Mount it on the client at /mnt/nfs, make it persistent in /etc/fstab with _netdev so it survives a reboot.
dsoxlab start l2-nfs-mount-persist -
Guided lab to re-attest 30m · intermediate · virtual machines
Mount a filesystem on demand with autofs
Configure autofs so that accessing /autofs/data mounts the spare disk automatically, and unmounts it after idle, a master map plus a mount map.
dsoxlab start l2-autofs-ondemand -
Guided lab to re-attest 30m · intermediate · virtual machines
Build a software RAID 1 with mdadm
Assemble two disks into a redundant RAID 1 array with mdadm, format and mount it, and make it persistent.
dsoxlab start l2-raid-mdadm -
Guided lab to re-attest 30m · intermediate · virtual machines
Encrypt a disk with LUKS
Encrypt a block device with LUKS2, open it, put a filesystem on it, mount it and make it unlock at boot via crypttab.
dsoxlab start l2-luks-encryptionRHCSA Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Create a local account with exact UID, shell and groups
Onboard a user with a specific UID, home, login shell, a primary group and a supplementary group, the RHCSA account-creation drill.
dsoxlab start l2-user-lifecycleRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Enforce password aging and complexity policy
Set per-account password aging with chage, the system default max age in login.defs, and a minimum password length via pwquality.
dsoxlab start l2-password-policyRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Delegate limited sudo rights with a sudoers drop-in
Grant the operators group password-less sudo for systemctl only, via a validated /etc/sudoers.d drop-in, least privilege, not full root.
dsoxlab start l2-sudo-delegationRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Grant fine-grained access with POSIX ACLs
Go beyond ugo: give one user rw on a file and a group rx on a directory, with a default ACL so new files inherit it, using setfacl/getfacl.
dsoxlab start l2-acl-posixRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Set up a collaborative directory with the set-GID bit
Give a shared directory the devteam group and the set-GID bit so files created inside inherit the group, proven by the directory mode and a member's new file.
dsoxlab start l2-collaborative-setgidRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Install, remove and query packages with dnf
Bring the machine to a target software state: install a needed package, remove an unwanted one, and confirm with dnf/rpm queries.
dsoxlab start l2-package-managementRHCSA Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Configure a dnf repository with a .repo file
Add a software repository under /etc/yum.repos.d: an id, a baseurl, enabled and GPG-checked, then confirm dnf sees it.
dsoxlab start l2-repo-configureRHCSA Companion guide (French)
Services and troubleshooting
14
-
Guided lab to re-attest 15m · beginner · virtual machines
Set the default systemd boot target
A server has no business booting into a graphical target. Set the default to multi-user.target and confirm it.
dsoxlab start l3-boot-targetRHCSALFCS Companion guide
-
Guided lab to re-attest 20m · intermediate · virtual machines
Add a persistent kernel boot parameter
Add a kernel command-line parameter to the current kernel with grubby and to /etc/default/grub for future kernels, so it survives reboots and updates, proven by grubby and the grub config.
dsoxlab start l3-grub-kernel-argsRHCSA Companion guide (French)
-
Guided lab to re-attest 30m · intermediate · virtual machines
Create and enable a systemd service unit
Wrap a program in a systemd .service unit, start it and enable it at boot, proven by the service being active, enabled and doing its job.
dsoxlab start l3-service-create-unitRHCSALFCS Companion guide
-
Guided lab to re-attest 30m · intermediate · virtual machines
Diagnose and fix a systemd service stuck in a crash loop
A systemd service keeps restarting because of a missing config file. Use systemctl + journalctl to find the root cause and fix it permanently.
dsoxlab start l3-service-diagnoseRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Make the systemd journal persistent across reboots
By default logs vanish on reboot. Enable persistent journald storage so /var/log/journal keeps history, proven by config, directory and a real journal file.
dsoxlab start l3-journald-persistRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Schedule a recurring job with cron
Run /usr/local/bin/report.sh every day at 02:30 through a cron entry, proven by the actual schedule the cron daemon will honour.
dsoxlab start l3-scheduling-cronRHCSALFCS Companion guide
-
Guided lab to re-attest 15m · intermediate · virtual machines
Schedule a one-shot job with at
Queue a command to run once at a later time with at, and prove it is scheduled, the one-off counterpart to cron.
dsoxlab start l3-scheduling-atRHCSALFCS Companion guide
-
Guided lab to re-attest 25m · intermediate · virtual machines
Schedule a recurring job with a systemd timer
Create a .service and its .timer (OnCalendar), enable it, and prove it is active and persistent, the systemd way to schedule recurring work.
dsoxlab start l3-scheduling-timersRHCSALFCS Companion guide
-
Guided lab to re-attest 25m · intermediate · virtual machines
Set per-user resource limits (open files) with limits.d
Give the appuser account a higher open-files limit via /etc/security/limits.d, proven by the effective ulimit in a real login session.
dsoxlab start l3-app-constraintsLFCS Companion guide
-
Guided lab to re-attest 20m · intermediate · virtual machines
Harden kernel parameters persistently with sysctl.d
Disable IP forwarding and ICMP redirects via /etc/sysctl.d, applied now and surviving reboot, proven by the live sysctl values.
dsoxlab start l3-sysctl-persistRHCSA Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Lower a service's scheduling priority with Nice
A batch worker hogs the CPU. Give its service a nice value of 10 so it yields to interactive work, proven by the live process priority and the unit config.
dsoxlab start l3-process-signals-priorityLFCS Companion guide
-
Guided lab to re-attest 20m · intermediate · virtual machines
Apply a tuned performance profile
Switch the active tuned profile to throughput-performance and make it stick, proven by the active profile the tuned daemon reports.
dsoxlab start l3-tuned-profileRHCSA Companion guide
-
Guided lab to re-attest 25m · intermediate · virtual machines
Recover a read-only mount caused by a broken fstab
A bad /etc/fstab option left /srv/data mounted read-only. Fix the entry, remount read-write, and make mount -a clean again.
dsoxlab start l3-fs-readonly-recoverRHCSALFCS Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Repair a broken sshd config before it locks you out
A drop-in left an invalid directive: sshd -t fails, so the next reload or reboot would kill remote access. Fix the config, keep root login disabled, and reload cleanly.
dsoxlab start l3-ssh-access-recoveryRHCSALFCS Companion guide (French)
Network, security and containers
15
-
Guided lab to re-attest 15m · beginner · virtual machines
Synchronize the clock with chrony and set the timezone, persistently
Enable and start chronyd, turn NTP on and set the timezone to Europe/Paris, surviving reboot, proven by the live service state and timedatectl.
dsoxlab start l4-ntp-syncRHCSA Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Configure a persistent static IPv4 with NetworkManager
Create a NetworkManager connection with a static IPv4 (manual method) that survives reboot, proven by the on-disk profile and the live address.
dsoxlab start l4-network-static-persistRHCSA Companion guide
-
Guided lab to re-attest 25m · intermediate · virtual machines
Diagnose and restore a down network connection
A NetworkManager connection is configured but stays down and won't auto-start. Diagnose it, bring it up, and make it auto-connect, proven by the live state and autoconnect flag.
dsoxlab start l4-network-troubleshootRHCSA Companion guide
-
Guided lab to re-attest 20m · intermediate · virtual machines
Open a firewalld service permanently
Allow the http service through firewalld so it holds now and after reload/reboot, proven by the runtime and permanent service lists, without ever closing ssh.
dsoxlab start l4-firewall-persistRHCSA Companion guide (French)
-
Guided lab to re-attest 20m · intermediate · virtual machines
Set up hardened key-based SSH access for a service user
Give the deploy user key-based SSH login with correct ownership and permissions (.ssh 700, authorized_keys 600, owned by the user), the classic trap that silently breaks key auth.
dsoxlab start l4-ssh-key-auth-hardenRHCSA Companion guide
-
Guided lab to re-attest 20m · intermediate · virtual machines
Run a detached container with Podman
Pull an image and run a named container detached, and prove it is up, the Podman basics for RHCSA containers.
dsoxlab start l4-podman-basicRHCSA Companion guide (French)
-
Guided lab to re-attest 30m · advanced · virtual machines
Run a container as a systemd service with Quadlet (boot-persistent)
Define a Quadlet .container unit so a container starts at boot under systemd, proven by the active service, the running container and the on-disk unit.
dsoxlab start l4-podman-systemd-persistRHCSA Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Manage container images: pull, tag, save and inspect
Pull an image from a registry, tag it, save it to an archive and inspect that archive with skopeo, the image-management skills for RHCSA containers.
dsoxlab start l4-podman-imagesRHCSA Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Allow a service with SELinux: persistent boolean and labeled port
Turn on an SELinux boolean persistently and label a non-standard port so a service is allowed under enforcing SELinux, proven by getsebool and semanage port.
dsoxlab start l4-selinux-boolean-portRHCSA Companion guide (French)
-
Guided lab to re-attest 25m · intermediate · virtual machines
Fix a file's SELinux context, persistently
Give a custom web directory the httpd_sys_content_t type with semanage fcontext + restorecon so it survives a relabel/reboot, proven by ls -Z and the fcontext rule.
dsoxlab start l4-selinux-context-fixRHCSA Companion guide (French)
-
Guided lab to re-attest 30m · advanced · virtual machines
Diagnose an SELinux denial (AVC) and fix it the right way
A web file has the wrong SELinux label so httpd is denied (403). Read the AVC in the audit log and restore the context, without disabling SELinux. Proven by the live context and a 200 response.
dsoxlab start l4-selinux-diagnose-avcRHCSA Companion guide (French)
-
Guided lab to re-attest 35m · advanced · virtual machines
Set up persistent NAT port forwarding with nftables
Enable IP forwarding and add an nftables nat table (DNAT port forward + masquerade) that survives reboot, proven by the live ruleset, sysctl and persistence files.
dsoxlab start l4-nat-portforwardRHCSA Companion guide (French)
-
Guided lab to re-attest 40m · advanced · virtual machines
Authenticate Linux against an LDAP directory with SSSD
Configure SSSD on the client so a directory user (alice) resolves and can log in, against a 389 Directory Server, proven by getent, id and the active authselect profile.
dsoxlab start l4-ldap-integrationRHCSA Companion guide (French)
-
Guided lab to re-attest 30m · advanced · virtual machines
Load-balance a web backend with HAProxy
Configure HAProxy on the front host to reverse-proxy and load-balance to a backend web server, persistently, proven by a request through the proxy returning the backend's page.
dsoxlab start l4-reverse-proxy-lb -
Guided lab to re-attest 30m · advanced · virtual machines
Aggregate links: an active-backup bond under a bridge with nmcli
Build an active-backup bond over two slave interfaces and put a bridge on top, persistently with NetworkManager, proven by the bonding state and the bridge port.
dsoxlab start l4-bridge-bondingLFCS Companion guide
eBPF: trace and harden (going further)
3
-
Guided lab 25m · intermediate · virtual machines
Unmask a mystery process with eBPF tracing tools
A hidden process writes to a hidden file every few seconds. Install the BCC (or bpftrace) tracing tools, observe the kernel's openat and execve calls, then name the program and the file, proven by comparing your answer with the host's ground truth.
dsoxlab start ebpf-tracer-bcc -
Guided lab 25m · intermediate · virtual machines
Harden eBPF with sysctl: block unprivileged users and make it stick across reboots
An audit found eBPF wide open: unprivileged users may call bpf() and the JIT compiler is not hardened. Set kernel.unprivileged_bpf_disabled and net.core.bpf_jit_harden to 2, make both survive a reload of the sysctl configuration despite a forgotten debug file, and prove with a real bpf() call as an unprivileged user that the kernel now refuses.
dsoxlab start ebpf-durcir-sysctl -
Guided lab 25m · intermediate · virtual machines
Inventory the loaded eBPF programs with bpftool and stop the service that carries one
A service with a harmless name loads an eBPF program into the kernel. List the programs with bpftool, find which process and which systemd service carry the unknown one, name its type, then stop the service and keep it from coming back, without touching the programs systemd loads.
dsoxlab start ebpf-inventaire-bpftool
Debian and Ubuntu variants
6
-
Guided lab to re-attest 20m · intermediate · virtual machines
Manage Debian packages with apt and dpkg
Install a package with apt, pin it with a hold so updates skip it, and identify which package owns a file, the Debian package-management skills for LFCS.
dsoxlab start lfcs-package-apt -
Guided lab to re-attest 20m · intermediate · virtual machines
Open a service through the firewall with ufw
Allow the http service and enable ufw so it filters at boot, without ever locking out SSH, the Debian firewall counterpart to firewalld, proven by ufw status.
dsoxlab start lfcs-firewall-ufw -
Guided lab to re-attest 20m · intermediate · virtual machines
Manage an AppArmor profile: switch it to complain mode
Put a loaded AppArmor profile into complain (learning) mode with aa-complain and prove it with aa-status, the Debian mandatory-access-control counterpart to SELinux.
dsoxlab start lfcs-apparmor -
Guided lab to re-attest 25m · intermediate · virtual machines
Configure a static IP and route with netplan
Declare a static IPv4 address and a static route in a netplan file and apply it on a dedicated interface, the Debian/Ubuntu network configuration, proven by the live address and route.
dsoxlab start lfcs-netplan-staticLFCS Companion guide
-
Guided lab to re-attest 30m · intermediate · virtual machines
Enable XFS user quotas and enforce a limit
Format a dedicated disk as XFS, mount it with user quotas enabled persistently, and enforce a block quota on a user, proven by the live quota state and the enforced limit.
dsoxlab start lfcs-storage-quotas -
Guided lab to re-attest 30m · intermediate · virtual machines
Mount an SMB/CIFS share persistently and safely
A second host serves an SMB share. Mount it on the client, make it persistent in /etc/fstab with _netdev, and keep the password out of the world-readable fstab by using a 0600 credentials file.
dsoxlab start lfcs-mount-cifs
Exam-condition drills
9
-
Challenge to re-attest pass 70% 20m · intermediate · virtual machines
Drill, essential commands under exam conditions
5 tasks, 100 points, 20 minutes, no hints: find by size, build a frequency report, links, ownership and permissions, and split stdout from stderr. Playable on RHEL or Debian, the skills are identical.
dsoxlab start drill-essential-commandsRHCSALFCS Companion guide (French)
-
Challenge to re-attest pass 70% 20m · intermediate · virtual machines
Drill, users, groups and delegation under exam conditions
5 tasks, 100 points, 20 minutes, no hints: create an account to exact specs, enforce password aging, build a collaborative directory, delegate sudo narrowly, and lock a departing account. Playable on RHEL or Debian, user management is identical.
dsoxlab start drill-users-groupsRHCSALFCS Companion guide (French)
-
Challenge to re-attest pass 70% 25m · intermediate · virtual machines
Drill, systemd units, timers and scheduling under exam conditions
5 tasks, 100 points, 25 minutes, no hints: write a service unit with a restart policy, schedule a weekly timer, add a cron job, fix the default boot target, and mask a service for good. Playable on RHEL or Debian, systemd is systemd.
dsoxlab start drill-systemdRHCSALFCS Companion guide
-
Challenge to re-attest pass 70% 25m · advanced · virtual machines
Drill, partitions, LVM and swap under exam conditions
5 tasks, 100 points, 25 minutes, no hints: partition a disk in GPT, build an LVM stack, mount by UUID persistently, add swap, and extend a logical volume online. Playable on RHEL or Debian, parted, LVM and XFS are identical.
dsoxlab start drill-storageRHCSALFCS Companion guide (French)
-
Challenge to re-attest pass 70% 20m · intermediate · virtual machines
Drill, package management under exam conditions
5 tasks, 100 points, 20 minutes, no hints: install a package, freeze it against upgrades, find which package owns a file, list what a package installed, and remove one. The objective is shared by RHCSA and LFCS, only the tool changes (dnf or apt), and you use your distribution's.
dsoxlab start drill-packagesRHCSALFCS Companion guide (French)
-
Challenge to re-attest pass 70% 20m · intermediate · virtual machines
Drill, firewall under exam conditions
5 tasks, 100 points, 20 minutes, no hints: bring the firewall up, open two ports so they survive a reload, keep SSH alive, and explicitly reject a port. The objective is shared by RHCSA and LFCS, only the tool changes (firewalld or ufw).
dsoxlab start drill-firewallRHCSALFCS Companion guide (French)
-
Challenge to re-attest pass 70% 20m · advanced · virtual machines
Drill, SELinux under exam conditions
4 tasks, 100 points, 20 minutes, no hints: put SELinux back in enforcing for good, fix a file context so it survives a relabel, flip a boolean persistently, and label a non-standard port. RHCSA only, Debian uses AppArmor, see drill-apparmor.
dsoxlab start drill-selinuxRHCSA Companion guide (French)
-
Challenge to re-attest pass 70% 15m · intermediate · virtual machines
Drill, AppArmor under exam conditions
4 tasks, 100 points, 15 minutes, no hints: confirm AppArmor is up, put one profile in complain, and bring two others back to enforce. LFCS only, RHEL uses SELinux, see drill-selinux.
dsoxlab start drill-apparmor -
Challenge to re-attest pass 70% 20m · advanced · virtual machines
Drill, static networking under exam conditions
4 tasks, 100 points, 20 minutes, no hints: a static address, a static route and an MTU on a dedicated interface, plus local name resolution. The objective is shared by RHCSA and LFCS, only the tool changes (nmcli or netplan).
dsoxlab start drill-networkRHCSALFCS Companion guide
Capstones
4
-
Mock exam to re-attest pass 80% 90m · advanced · virtual machines
Put a server into production: one mission, nine deliverables, one reboot
A fresh VM, a delivered application, and one mission: put it into service. Storage on LVM, service account, application on port 8080, SELinux port label and context, permanent firewall rule, persistent journal, hardened SSH, scheduled backup. Nothing is scored on the commands typed: every test reads observable state, and the last one reboots the machine and checks again. What does not survive the reboot scores zero.
dsoxlab start capstone-mise-en-productionRHCSALFCS Companion guide (French)
-
Mock exam to re-attest pass 80% 45m · advanced · virtual machines
Broken server: the site is down, the symptom tells you nothing
A working internal site stops answering. The setup injects ONE fault among six, drawn at random, and never says which: stopped service, wrong port, closed firewall, SELinux context, docroot permissions, listening on loopback only. You diagnose, you repair, and the repair must survive a reboot. Scored purely on observable state, with three checks that reject the sledgehammer fixes: SELinux must stay enforcing, firewalld must stay running, and the docroot must not become world-writable.
dsoxlab start capstone-serveur-casseRHCSA Companion guide (French)
-
Mock exam to re-attest pass 70% 180m · advanced · virtual machines
RHCSA EX200 mock exam, 20 tasks across 2 VMs
Performance-based RHCSA mock exam covering 10 RHCSA domains: storage (LVM, swap, NFS client), shell scripting, networking (static IP, firewalld), users/groups, ACLs, services (systemd units, timers, time client), SELinux (modes, contexts, booleans, port labels), software (DNF, Flatpak), boot recovery (rd.break root reset). 20 tasks scored on 100 points across 2 VMs (server + client). 70/100 to pass. No hints.
dsoxlab start rhcsa-mock-examRHCSA Companion guide (French)
-
Mock exam to re-attest pass 70% 120m · advanced · virtual machines
LFCS mock exam, 17 tasks on Ubuntu 24.04
Performance-based LFCS mock exam mapped task by task onto the published objectives of the 5 official domains: Essential Commands (20%: Git, service troubleshooting, disk space, SSL), Operations Deployment (25%), Users and Groups (10%: accounts and ACLs), Networking (25%), Storage (20%: LVM, automount, swap). 17 tasks scored on 100 points on a single Ubuntu VM. 70/100 to pass. No hints.
dsoxlab start lfcs-mock-exam
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/ansible-training
Preparing the environment
1
-
Guided lab 25m · beginner · virtual machines
Prepare Ansible managed nodes
Converge the 5 managed node prerequisites (Python 3, SSH, NOPASSWD sudo, chrony, SELinux) with an idempotent bootstrap playbook.
dsoxlab start bootstrap-prepare-managed-nodes
Discovering Ansible
4
-
Guided lab 25m · beginner · virtual machines
Declarative vs imperative: why Ansible does not drift
Compare a Bash script that drifts on every run with a playbook that converges, and prove idempotence with changed=0 on the second pass.
dsoxlab start decouvrir-declaratif-vs-imperatif -
Guided lab 20m · beginner · shell
Ansible installation: verify your control node
Identify your install method, check the 8 binaries on PATH, the modules reachable via ansible-doc and the collections the repo relies on.
dsoxlab start decouvrir-installation-ansible -
Guided lab 30m · beginner · virtual machines
ansible.cfg: precedence and critical options
Write a project ansible.cfg, check the active config with ansible-config dump, override an option by environment variable and enable a callback.
dsoxlab start decouvrir-configuration-ansible -
Guided lab 20m · beginner · shell
Ansible CLI: the 8 everyday commands
Chain ad-hoc runs, ansible-doc, ansible-config, ansible-inventory, ansible-galaxy, ansible-vault and ansible-lint across the lab.
dsoxlab start decouvrir-prise-en-main-cli
First steps
2
-
Guided lab 30m · beginner · virtual machines
First playbook: install nginx on the webservers
Write a 5-task playbook (dnf, systemd, firewalld), read the PLAY RECAP, capture output with register and check idempotence on the second pass.
dsoxlab start premiers-pas-premier-playbook -
Guided lab 45m · beginner · virtual machines
First steps with ansible-vault
Encrypt a secrets file with ansible-vault, consume it through vars_files and protect output with no_log and a 0600 .vault_password.
dsoxlab start premiers-pas-ansible-vault
Writing Ansible code
28
-
Guided lab 40m · intermediate · virtual machines
Plays and tasks: anatomy and execution order
Structure a play with pre_tasks, tasks, post_tasks and handlers, then prove the real execution order with timestamped marker files.
dsoxlab start ecrire-code-plays-et-tasks -
Guided lab 35m · intermediate · virtual machines
handlers: the restart-on-config-change pattern
Notify several handlers, decouple them with listen, force meta: flush_handlers and pair validate so an invalid config is never applied.
dsoxlab start ecrire-code-handlers -
Guided lab 40m · intermediate · virtual machines
tags: target or skip a subset of tasks
Set tags, target with --tags and exclude with --skip-tags, inspect the plan via --list-tasks and use the special always and never tags.
dsoxlab start ecrire-code-tags -
Guided lab 45m · intermediate · virtual machines
check mode and diff: dry-run and change preview
Run a playbook with --check --diff, spot the modules that do not support check, force check_mode: false and diagnose a false changed positive.
dsoxlab start ecrire-code-checkmode-diff -
Guided lab 40m · beginner · virtual machines
Variables: declaration and scope
Declare variables with vars and vars_files, override them with --extra-vars and diagnose an unexpected value caused by YAML typing.
dsoxlab start ecrire-code-variables-base -
Guided lab 40m · intermediate · virtual machines
Collection types: lists, dicts, nested structures
Declare lists and lists of dicts in YAML, loop over them with loop_control: label, filter with when and reach nested fields.
dsoxlab start ecrire-code-types-collections -
Guided lab 40m · intermediate · virtual machines
facts and magic vars: ansible_facts, hostvars
Read system facts, use inventory_hostname, groups and hostvars, then cut the collection cost with gather_subset.
dsoxlab start ecrire-code-facts-magic-vars -
Guided lab 40m · intermediate · virtual machines
Custom facts: facts.d and ansible_local
Drop an INI custom fact then an executable script returning JSON into /etc/ansible/facts.d, and read them back through ansible_local.
dsoxlab start ecrire-code-custom-facts -
Guided lab 55m · advanced · virtual machines
Variable precedence: the 22 levels
Stack the same variable at several levels to demonstrate which one wins, from role defaults up to --extra-vars.
dsoxlab start ecrire-code-precedence-variables -
Guided lab 40m · intermediate · virtual machines
register and set_fact: capture and create variables
Capture module output with register, reuse it in when and loop, create a runtime fact and persist it with cacheable: true.
dsoxlab start ecrire-code-register-set-fact -
Guided lab 50m · advanced · virtual machines
Parallelism: forks, serial, throttle, strategy
Tell forks from serial, run a rolling update with serial: 1, compare the linear and free strategies and rate-limit a single task with throttle.
dsoxlab start ecrire-code-parallelisme-strategies -
Guided lab 45m · advanced · virtual machines
async and poll: long tasks without blocking SSH
Detach a long task with async + poll: 0, collect its result via async_status, poll actively with until and diagnose an orphaned job.
dsoxlab start ecrire-code-async-poll -
Guided lab 45m · advanced · virtual machines
Delegation: delegate_to, run_once, local_action
Redirect a task to another host, run it only once in a multi-host play and target the control node with local_action.
dsoxlab start ecrire-code-delegation -
Guided lab 40m · intermediate · virtual machines
lookups: fetch external data at runtime
Read a file, an environment variable or a command output on the control node, generate a password and tell lookup from query.
dsoxlab start ecrire-code-lookups -
Guided lab 45m · intermediate · virtual machines
Jinja2: interpolation, logic and whitespace
Interpolate variables, loop and branch inside a template, then kill stray blank lines with whitespace control.
dsoxlab start ecrire-code-jinja2-base -
Guided lab 45m · intermediate · virtual machines
Essential Jinja2 filters: default, combine, selectattr
Handle missing variables with default, work on lists, filter a list of dicts with selectattr and map, merge dicts with combine.
dsoxlab start ecrire-code-filtres-jinja-essentiels -
Guided lab 40m · intermediate · virtual machines
when conditions: operators and Jinja tests
Gate a task on a fact, combine several conditions, test whether a variable is defined and diagnose a when that matches wrongly.
dsoxlab start ecrire-code-conditions-when -
Guided lab 40m · intermediate · virtual machines
loop: iterate over lists and dicts
Loop over a list and a list of dicts, keep console output readable with loop_control: label, iterate a dict with dict2items.
dsoxlab start ecrire-code-boucles-loop -
Guided lab 45m · intermediate · virtual machines
Legacy with_* loops: migrating to loop
Recognise with_items, with_dict and with_subelements, migrate them to loop plus Jinja2 filters and automate it with ansible-lint --fix.
dsoxlab start ecrire-code-boucles-with-deprecated -
Guided lab 40m · intermediate · virtual machines
block, rescue, always: try/catch/finally
Group tasks in a block, catch the error with rescue to roll back, guarantee cleanup with always and read ansible_failed_task.
dsoxlab start ecrire-code-block-rescue-always -
Guided lab 40m · intermediate · virtual machines
failed_when and changed_when: redefine success and change
Neutralise changed on read-only commands, define changed_when from output and accept some return codes as success.
dsoxlab start ecrire-code-failed-when-changed-when -
Guided lab 40m · intermediate · virtual machines
ignore_errors: legitimate use vs anti-pattern
Measure the effect of ignore_errors on the PLAY RECAP, spot its few legitimate cases and prefer failed_when or block/rescue.
dsoxlab start ecrire-code-ignore-errors -
Guided lab 50m · advanced · virtual machines
any_errors_fatal: stop the play on the first error
Enable any_errors_fatal on a multi-host play, compare it with the default and with max_fail_percentage, and combine it with serial.
dsoxlab start ecrire-code-any-errors-fatal -
Guided lab 50m · advanced · virtual machines
Advanced Jinja2 filters: regex, b64, password_hash
Extract with regex_search, encode to base64, hash a password with sha512, query JSON with json_query and handle IPs and CIDRs.
dsoxlab start ecrire-code-filtres-jinja-avances -
Guided lab 40m · intermediate · virtual machines
Jinja2 tests: is defined, is mapping, is sequence
Test a variable's definition and type, match a regex with is match and is search, and combine those tests in when and in {% if %}.
dsoxlab start ecrire-code-tests-jinja -
Guided lab 45m · intermediate · virtual machines
template module: validate, backup, whitespace
Render a config from a Jinja2 template, reject invalid syntax with validate, back up the previous file and set mode, owner and group.
dsoxlab start ecrire-code-module-template -
Guided lab 40m · intermediate · virtual machines
lineinfile vs template: which module when
Arbitrate between lineinfile, blockinfile and template, combine base plus overrides and diagnose a lineinfile that stacks for lack of a regexp.
dsoxlab start ecrire-code-lineinfile-vs-template -
Guided lab 45m · advanced · virtual machines
import vs include: static or dynamic
Choose between import_* parsed at start and include_* resolved at runtime, and observe how tags and when behave differently in each case.
dsoxlab start ecrire-code-import-include
File modules
7
-
Guided lab 35m · beginner · virtual machines
copy module: transfer files and inline content
Transfer a file with src: or write inline content with content:, mastering mode, owner, backup and validate.
dsoxlab start modules-fichiers-copy -
Guided lab 30m · beginner · virtual machines
file module: states, permissions and symlinks
Manage the state of a file or directory (directory, absent, link, hard, touch), recursive permissions and symbolic links.
dsoxlab start modules-fichiers-file -
Guided lab 30m · beginner · virtual machines
blockinfile module: idempotent multi-line block
Insert and maintain a multi-line block in an existing file with custom markers, insertafter/insertbefore and idempotence.
dsoxlab start modules-fichiers-blockinfile -
Guided lab 25m · beginner · virtual machines
lineinfile module: edit a line in an existing file
Add, replace by regexp or remove a line in a config file, using backrefs and syntax validation before the write.
dsoxlab start modules-fichiers-lineinfile -
Guided lab 35m · intermediate · virtual machines
replace module: substitute a pattern in a file
Substitute a regex pattern throughout a file, scope it with before/after, and preserve parts of it with capture groups.
dsoxlab start modules-fichiers-replace -
Guided lab 35m · beginner · virtual machines
fetch module: retrieve files from managed nodes
Collect logs and configs from managed nodes to the control node, per-host tree or flat mode with inventory_hostname.
dsoxlab start modules-fichiers-fetch -
Guided lab 30m · beginner · virtual machines
archive and unarchive modules: compress and extract
Create a tar.gz archive on the managed node and extract local, remote or already-present tarballs idempotently with creates.
dsoxlab start modules-fichiers-archive-unarchive
Package modules
3
-
Guided lab 30m · beginner · virtual machines
package module: distro-agnostic installation
Install and remove packages without depending on the distro package manager, weighing state: present against state: latest.
dsoxlab start modules-paquets-package -
Guided lab 45m · advanced · virtual machines
dnf module: enablerepo, security, exclude, autoremove
Enable a repo on the fly, patch CVEs only, exclude the kernel from a bulk upgrade and clean up orphaned dependencies.
dsoxlab start modules-paquets-dnf-options -
Guided lab 35m · intermediate · virtual machines
yum_repository module: declare an RPM repository
Declare a yum/dnf repository with gpgcheck, import its GPG key via rpm_key, and disable a repo without removing it.
dsoxlab start modules-paquets-yum-repository
Service modules
2
-
Guided lab 35m · beginner · virtual machines
systemd_service module: manage systemd services
Start, enable, reload and mask services, drop a custom unit file with daemon_reload, and notify a service from a handler.
dsoxlab start modules-services-systemd -
Guided lab 30m · beginner · virtual machines
cron module: schedule idempotent jobs
Schedule idempotent cron jobs via a user crontab or /etc/cron.d, with environment variables and clean disabling.
dsoxlab start modules-services-cron
User modules
4
-
Guided lab 35m · beginner · virtual machines
user module: create, modify and remove accounts
Create accounts with home, shell and secondary groups, hash a password, force a specific UID, and remove an account with its home.
dsoxlab start modules-utilisateurs-user -
Guided lab 30m · beginner · virtual machines
group module: manage Linux groups
Create groups with a forced GID, tell system groups from user groups, and order group creation before the users that reference it.
dsoxlab start modules-utilisateurs-group -
Guided lab 35m · beginner · virtual machines
authorized_key module: user SSH keys
Provision public SSH keys, force an exclusive list, restrict a key with key_options, and handle several users with subelements.
dsoxlab start modules-utilisateurs-authorized-key -
Guided lab 50m · advanced · virtual machines
sudoers module: manage sudo rights safely
Create rules under /etc/sudoers.d/ with automatic visudo validation, limit allowed commands, and handle nopassword on a group.
dsoxlab start modules-utilisateurs-sudoers
RHEL modules
7
-
Guided lab 30m · beginner · virtual machines
firewalld module: manage the RHEL firewall
Allow predefined services and custom ports per zone, with the permanent + immediate trap and the firewall reload.
dsoxlab start modules-rhel-firewalld -
Guided lab 40m · intermediate · virtual machines
sysctl module: persisted kernel parameters
Change kernel parameters (ip_forward, tcp_syncookies, swappiness) with immediate effect and persistence through /etc/sysctl.d/.
dsoxlab start modules-rhel-sysctl -
Guided lab 55m · advanced · virtual machines
selinux module: modes, booleans and contexts
Switch SELinux to enforcing, flip a boolean persistently, and set a custom context with sefcontext followed by restorecon.
dsoxlab start modules-rhel-selinux -
Guided lab 45m · intermediate · virtual machines
mount module: manage fstab and mount points
Handle the 5 mount states, mount a loop device, set noatime/nodev/nosuid options, and make a mount survive a reboot.
dsoxlab start modules-rhel-mount -
Guided lab 35m · intermediate · virtual machines
parted module: create a disk partition
Create aligned MBR or GPT partitions idempotently, set flags (lvm, boot, esp), and inspect the existing partition table.
dsoxlab start modules-rhel-parted -
Guided lab 35m · intermediate · virtual machines
filesystem module: create a filesystem
Format partitions as ext4 and xfs, pick the right fstype for the use case, and force a rebuild with force: true.
dsoxlab start modules-rhel-filesystem -
Guided lab 50m · advanced · virtual machines
LVM: chaining lvg, lvol, filesystem and mount
Build a PV, VG and LV on a spare disk, format it, mount it through fstab, and grow it online with resizefs.
dsoxlab start modules-rhel-lvm-storage
Network modules
2
-
Guided lab 35m · beginner · virtual machines
get_url module: download a file over HTTP/HTTPS
Download a file onto the managed node idempotently, check its integrity with a sha256 checksum, and authenticate the request.
dsoxlab start modules-reseau-get-url -
Guided lab 50m · advanced · virtual machines
uri module: REST API calls
Call a REST API with GET/POST and a JSON body, accept several status_code values, and loop a healthcheck with until/retries.
dsoxlab start modules-reseau-uri
Diagnostic modules
4
-
Guided lab 30m · beginner · virtual machines
stat module: inspect files and directories
Check existence, type, size, mode and checksum of a file without modifying it, to drive conditional logic.
dsoxlab start modules-diagnostic-stat -
Guided lab 30m · beginner · virtual machines
find module: multi-file search
Search files by glob, regex, age, size and type, then chain loop and file for a targeted, idempotent cleanup.
dsoxlab start modules-diagnostic-find -
Guided lab 40m · intermediate · virtual machines
assert and fail modules: defensive validation
Validate prerequisites at the start of a play, customize fail_msg and success_msg, and fail explicitly on an error branch.
dsoxlab start modules-diagnostic-assert-fail -
Guided lab 35m · intermediate · virtual machines
wait_for and pause modules: synchronization
Wait for a TCP port to open or close, for a file or a regex to appear, and add a timed or interactive pause.
dsoxlab start modules-diagnostic-wait-for-pause
Inventories
4
-
Guided lab 40m · beginner · virtual machines
Write a static inventory from scratch: groups, children and group vars
Author an Ansible static inventory by hand: declare host groups, a parent group with children, and group variables, then prove the resolved inventory with ansible-inventory and ansible -m ping.
dsoxlab start inventaires-statiques -
Guided lab 30m · beginner · virtual machines
group_vars and host_vars: structured inventory variables
Spread inventory variables across all, group and host levels, then check the resolved value with ansible-inventory --host.
dsoxlab start inventaires-group-vars-host-vars -
Guided lab 35m · intermediate · virtual machines
Host patterns: wildcards and the :, & and ! operators
Target exactly the hosts you want with --limit and the union, intersection and exclusion operators, without touching the playbook.
dsoxlab start inventaires-patterns-hotes -
Guided lab 35m · intermediate · virtual machines
Dynamic KVM inventory with community.libvirt
Discover libvirt VMs automatically through the inventory plugin, build Jinja groups and keyed_groups, with no manual inventory.
dsoxlab start inventaires-dynamique-kvm
Roles
7
-
Guided lab 45m · beginner · virtual machines
Create your first role with ansible-galaxy role init
Scaffold a webserver role, fill in tasks, defaults, handlers and meta, then call it from a playbook with roles:.
dsoxlab start roles-creer-premier-role -
Guided lab 35m · intermediate · virtual machines
Role variables: defaults/ vs vars/ and precedence
Split variables between defaults/ (overridable) and vars/ (internal), wire them into tasks and a Jinja2 template, then verify precedence.
dsoxlab start roles-variables-defaults-vars -
Guided lab 40m · intermediate · virtual machines
Role handlers and meta: notify and galaxy_info
Write several handlers (service and non-service), trigger them with notify, choose between restarted and reloaded, then complete meta/main.yml for Galaxy.
dsoxlab start roles-handlers-meta -
Guided lab 50m · intermediate · virtual machines
argument_specs: validate a role's input variables
Write meta/argument_specs.yml to type, constrain and document input variables, then watch an invalid input get rejected automatically.
dsoxlab start roles-argument-specs -
Guided lab 50m · intermediate · virtual machines
Consume a role: roles:, import_role, include_role
Call the same role three different ways and choose between static and dynamic, especially once a when: is involved.
dsoxlab start roles-consommer-role -
Guided lab 45m · intermediate · virtual machines
Role dependencies via meta/main.yml
Chain roles with dependencies:, pass them variables, control execution order and dodge the diamond trap with allow_duplicates.
dsoxlab start roles-dependencies -
Guided lab 1h · advanced · virtual machines
RHEL system roles: converge time synchronisation with timesync
Consume a vendor role from linux-system-roles: drive chronyd on db1.lab through timesync variables, never writing chrony.conf by hand.
dsoxlab start roles-system-roles
Testing with Molecule
4
-
Guided lab 45m · advanced · shell
Molecule: anatomy of a test scenario
Read a molecule/default/ scenario: molecule.yml, converge.yml, verify.yml, driver, platforms, verifier, then run the full cycle.
dsoxlab start molecule-introduction -
Guided lab 35m · intermediate · shell
Molecule: enrich a scenario beyond the defaults
Add prepare.yml and requirements.yml, tune instances through host_vars, define a test_sequence including idempotence and enable profile_tasks.
dsoxlab start molecule-installation-config -
Guided lab 45m · advanced · shell
Molecule: build a users role test-first
Write verify.yml and argument_specs.yml before a single task, then iterate on converge until green and refactor without breaking the tests.
dsoxlab start molecule-tdd-cycle -
Guided lab 45m · advanced · shell
Molecule: test a role across distributions
Extend the Molecule matrix to three distributions, load vars/<os_family>.yml and absorb package and path gaps with the package module.
dsoxlab start molecule-scenarios-multi-distro
Python tests and linting
3
-
Guided lab 40m · advanced · shell
Molecule + testinfra: Python assertions on a role
Switch the verifier to testinfra, write assertions with the host fixture, parametrize cases, and weigh it against verify.yml.
dsoxlab start tests-testinfra -
Guided lab 40m · advanced · shell
tox: test a role against several ansible-core versions
Write a tox.ini that pins one ansible-core version per environment and runs molecule test across the whole matrix in a single command.
dsoxlab start tests-tox-multiversion -
Guided lab 40m · advanced · shell
ansible-lint production profile with pre-commit
Configure .ansible-lint on the production profile plus a strict .yamllint, then wire both into pre-commit with a secret-leak hook.
dsoxlab start tests-ansible-lint-production
Continuous integration
2
-
Guided lab 40m · advanced · shell
GitHub Actions: CI workflow for a role
Write a lint + molecule workflow with a distro x ansible-core matrix, pip caching, least-privilege permissions and persist-credentials disabled.
dsoxlab start ci-github-actions -
Guided lab 40m · advanced · shell
GitLab CI: parallel:matrix pipeline for a role
Write a .gitlab-ci.yml with lint, test and release stages, spread the matrix with parallel:matrix and restrict Galaxy publishing to Git tags via rules:.
dsoxlab start ci-gitlab
Galaxy and publishing
4
-
Guided lab 20m · beginner · shell
ansible-galaxy CLI: init, install, list, build, publish
Init a role and a collection, install from Galaxy or Git, list what is present, build a tarball and publish it with an API token.
dsoxlab start galaxy-ansible-galaxy-cli -
Guided lab 30m · intermediate · shell
Install roles and collections from Galaxy or Git
Write a requirements.yml mixing Galaxy roles, Git sources and collections, pin every version and vendor a role into the project for reproducible installs.
dsoxlab start galaxy-installer-roles -
Guided lab 40m · advanced · shell
Audit a Galaxy role before adopting it
Score a third-party role on six axes (maintainer, quality, security, tests), spot the anti-patterns and decide: adopt, fork or reject.
dsoxlab start galaxy-auditer-role-existant -
Guided lab 35m · advanced · shell
Version and publish a role: semver, Git tags, Galaxy
Apply semver to a role, keep a CHANGELOG.md, cut an annotated Git tag and automate Galaxy publishing from CI.
dsoxlab start galaxy-versionner-publier
Ansible Vault
7
-
Guided lab 35m · beginner · virtual machines
Ansible Vault: encrypt your first secrets file
Encrypt a YAML file with ansible-vault, view it, edit it, consume it from a playbook, then rekey and decrypt it.
dsoxlab start vault-introduction -
Guided lab 45m · intermediate · virtual machines
encrypt_string vs whole-file encryption
Encrypt a single value with encrypt_string, mix it with plaintext variables via the !vault tag, and choose between inline and whole-file.
dsoxlab start vault-chiffrer-fichier-variable -
Guided lab 45m · intermediate · virtual machines
Multiple vault-ids: isolate dev, staging and prod
Encrypt each environment with a labelled vault-id, decrypt several vault-ids in a single run and lay out group_vars per environment.
dsoxlab start vault-id-multiples -
Guided lab 50m · intermediate · virtual machines
Mixed playbooks: main.yml plus vault.yml per group
Split public variables from secrets inside each group_vars, adopt the vault_* convention, and confirm Ansible merges both files transparently.
dsoxlab start vault-playbooks-mixtes -
Guided lab 50m · intermediate · virtual machines
Vault inside a role: plaintext defaults, encrypted vars
Expose public variables in defaults/main.yml pointing to vault_* values in an encrypted vars/main.yml, and override them from the playbook.
dsoxlab start vault-dans-roles -
Guided lab 50m · advanced · shell
Fetch secrets from HashiCorp Vault or OpenBao
Start a local Vault, store a secret in it, read it from Ansible with community.hashi_vault, and compare token, AppRole and JWT authentication.
dsoxlab start vault-integration-hashicorp -
Guided lab 40m · intermediate · shell
Fetch secrets from Passbolt
Start a local Passbolt CE, authenticate with an OpenPGP key, read a secret from Ansible and compare the Passbolt model with HashiCorp Vault.
dsoxlab start vault-integration-passbolt
Execution environments
5
-
Guided lab 40m · intermediate · shell
First run inside an Execution Environment
Pull an EE image with Podman, set it as the default in ansible-navigator.yml, run a playbook inside it and compare with a plain ansible-playbook run.
dsoxlab start ee-hello -
Guided lab 30m · intermediate · shell
Inspect an Execution Environment and pick the right one
List an EE's contents with ansible-navigator, compare community-ansible-dev-tools, awx-ee and community-ee-minimal, then pick one per use case.
dsoxlab start ee-inspection -
Guided lab 55m · advanced · shell
Build a custom EE with ansible-builder v3
Write a v3 execution-environment.yml, pin ansible-core and dependencies, build with Podman, test the image and push it to a private registry.
dsoxlab start ee-builder-custom -
Guided lab 55m · advanced · shell
CI/CD pipeline for Execution Environments
Build an EE in CI, scan it with Trivy in blocking mode, sign it with keyless cosign and publish it, with SHA-pinned actions and least-privilege permissions.
dsoxlab start ee-ci-pipeline -
Guided lab 40m · advanced · shell
Debug a broken Execution Environment
Diagnose an EE that builds cleanly yet ships empty: forgotten schema version, missing collection or PyPI version, then fix it and verify.
dsoxlab start ee-debug
Troubleshooting
3
-
Guided lab 40m · intermediate · virtual machines
Verbosity levels and callback plugins
Pick the -v level that matches the symptom, enable profile_tasks and YAML output (callback_result_format), and see what a missing no_log leaks.
dsoxlab start troubleshooting-verbosite -
Guided lab 50m · advanced · virtual machines
Interactive debugger: debugger: on_failed
Enable the debugger on failure, inspect task, task_vars and result in the REPL, patch arguments on the fly then replay the task with redo.
dsoxlab start troubleshooting-debugger -
Guided lab 50m · advanced · virtual machines
Fix broken idempotence and tune performance
Make a shell task idempotent with creates or changed_when, measure a baseline with profile_tasks, then enable pipelining, forks and ControlPersist.
dsoxlab start troubleshooting-idempotence-perfs
Collections
6
-
Guided lab 50m · advanced · virtual machines
Explore Ansible collections: FQCN and structure
List and inspect installed collections, read a galaxy.yml, walk the plugins/roles/playbooks layout and track down a module by its FQCN.
dsoxlab start collections-decouvrir -
Guided lab 45m · advanced · virtual machines
Automation content navigator: discover a module in a collection and use it
Use ansible-navigator to find a module inside an installed collection, apply it to produce a verifiable kernel state on db1.lab, and validate an inventory with ansible-navigator inventory.
dsoxlab start collections-navigator -
Guided lab 45m · intermediate · virtual machines
requirements.yml: multi-source install with GPG signatures
Declare four sources in a requirements.yml, pin every version, check integrity with collection verify and target several Galaxy servers.
dsoxlab start collections-requirements -
Guided lab 55m · advanced · shell
Build your own collection with a custom Python module
Init a collection, fill in galaxy.yml and meta/runtime.yml, add a role and a documented Python module, then build the tarball.
dsoxlab start collections-creer-custom -
Guided lab 45m · advanced · shell
CI matrix for a collection: ansible-core x Python
Cross ansible-core and Python versions in a matrix, run ansible-test sanity and units in containers, and pin every action by SHA.
dsoxlab start collections-ci-tests -
Guided lab 1h · advanced · virtual machines
Migrate a standalone role to a collection
Move a role and its custom module into a collection, set up plugin_routing.redirect, and check the old name still works with a warning.
dsoxlab start collections-migration-role
Advanced practices
2
-
Guided lab 25m · beginner · shell
Version your playbooks with Git
Initialize a Git repository for your playbooks, track and commit them, then push to a local bare remote: the exact EX294 gesture, with no forge to set up.
dsoxlab start pratiques-versionner-git -
Guided lab 50m · advanced · virtual machines
ansible-pull: GitOps and Edge pattern
Run ansible-pull against a Git repository, schedule it with cron or a systemd timer, bootstrap it from cloud-init, then choose push or pull per use case.
dsoxlab start pratiques-ansible-pull-gitops
RHCE EX294 exam
2
-
Capstone 4h · advanced · virtual machines
RHCE EX294 mock exam: 19 tasks in 4 hours
Work through 19 timed tasks covering inventories, variables, vault, files, packages, services, roles, error handling, rolling waves, delegation, tags, scheduled jobs, custom facts and content collections, each validated by pytest.
dsoxlab start rhce-mock-ex294 -
Capstone 4h · advanced · virtual machines
Mock RHCE EX294 #2
A second full timed EX294 mock: the same 19 categories as mock #1, but every concrete value differs (Apache/valkey stack, different users, LVM layout, ports, SELinux boolean, cron schedule, collection), so nothing can be copied from memory. Each task is proven by pytest.
dsoxlab start rhce-mock-ex294-2
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/terraform-dsoxlab-training
Discover Terraform
8
-
Guided lab 30m · beginner · shell
Prove that Terraform has a memory
A beginner believes Terraform re-reads the `.tf` files and queries the infrastructure on every command, the state being an accessory cache. Take that idea apart on a purely local configuration: prove a second apply changes nothing, that drift caused outside Terraform is detected without losing the identity of the untouched resources, that data merely read is not a managed resource, and that an object nobody declared stays invisible.
dsoxlab start getting-started-terraform-overviewTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Prove idempotence where the imperative script diverges
A provisioning script is provided, and it diverges as soon as you replay it: a new identifier every time, a report that piles up instead of being replaced. Reach the same result in Terraform, then establish by the plan that a second pass is a non-event, and repair an external drift without touching your code.
dsoxlab start getting-started-declarative-vs-imperativeTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Prove Terraform / OpenTofu compatibility, and where it stops
"The two tools are compatible" is repeated everywhere and checked by nobody. Make a configuration portable by declaring the source and version constraint of every provider, then establish by the structured state that both binaries read the same state, resolve the same versions on two different registries, and that the lock file is exactly where portability stops.
dsoxlab start getting-started-terraform-vs-opentofuTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Pin the CLI version and lock the providers
Installing the binary proves almost nothing. Constrain the CLI version from the configuration itself, pin the three providers, make an impossible constraint refuse to run, and prove the lock file rules: wipe `.terraform/`, re-init, and the resolved versions must not move.
dsoxlab start getting-started-install-terraformTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Make fmt, validate and the outputs agree
Three faults are planted: a file outside canonical format, an orphan reference that fails `validate`, and missing outputs. Fix all three without changing what the configuration produces, then prove an expression recomputes outside the state.
dsoxlab start getting-started-cli-terraformTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Read a plan before applying it
An already applied configuration must change. Before touching anything, say which of its resources will be updated in place and which will be destroyed then recreated. The human-facing plan announces both in the same block of text: the only reliable reading is the actions field of the plan converted to JSON. Then apply exactly the plan you read, from a saved plan file.
dsoxlab start getting-started-terraform-workflowTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
What Terraform manages, and what it merely reads
One word separates the two kinds of block: `resource` creates and manages, `data` reads. Prove it in the `mode` field of state, then observe the two consequences: a `destroy` does not touch what it did not create, and a data source is re-read on every plan.
dsoxlab start getting-started-providers-resources-data-sourcesTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Split a monolith without moving the plan
File names have no functional effect: Terraform reads every `.tf` as one document. Split a monolith into six thematic files and prove, by comparing two JSON plans, that nothing changed. Then observe which value source wins.
dsoxlab start getting-started-terraform-project-structureTF-ASSOCIATE Companion guide (French)
First infrastructures
7
-
Guided lab 30m · beginner · shell
First infrastructure: the full cycle, proven
Run the Terraform cycle on a REAL resource rather than reciting it, and learn on the way that `~> 0.8` does not forbid `0.9.x`: the pessimistic operator increments the rightmost component, and the 0.9 branch rewrote the resource schema.
dsoxlab start first-infra-first-infrastructureTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Variables, locals and the real precedence order
Four rungs, checked in order: `default`, `TF_VAR_`, `terraform.tfvars`, `*.auto.tfvars`, `-var`. The decisive one is the second: a values file BEATS the environment variable, the rank almost everyone places too high.
dsoxlab start first-infra-variables-outputsTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
The dependency Terraform cannot guess
Terraform builds its graph from the REFERENCES it finds in expressions. Nine times out of ten a hand-written `depends_on` signals a missing reference. This lab is about the tenth: a block that consumes a variable and references nothing, where Terraform is free to act in the wrong order.
dsoxlab start first-infra-virtual-networkTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Update in place or replacement: read it in the plan
On a virtual machine, some attributes change in place and others destroy then recreate the machine. The plan says which, before the apply, provided you know where to look. Then verify the plan told the truth, by applying it.
dsoxlab start first-infra-vm-libvirtTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Produce an Ansible inventory from the state
Terraform knows what it created; Ansible must know it too. Build the bridge, and make it RELIABLE rather than merely functional: a typed variable, addresses computed by an HCL function, a serialised file, and an inventory that disappears with the fleet it describes.
dsoxlab start first-infra-ansibleTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Resume after a failed apply, without redoing the work
An apply that fails halfway leaves a PARTIAL state. It is not an accident to wipe: it is the starting point of the repair. Fix the cause in the configuration, and prove the already created resources kept their identifiers.
dsoxlab start first-infra-debug-applyTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · beginner · shell
Destroying cleanly, and the four things it covers
Destroying is not one operation. Observe four that do not resemble each other: the global destroy a guard can REFUSE, the targeted destroy, the removal of a resource FROM THE CODE, and the full destroy that empties the state without deleting its file.
dsoxlab start first-infra-clean-destroyTF-ASSOCIATE Companion guide (French)
Writing Terraform code
24
-
Guided lab 35m · intermediate · shell
Explicit source and provider alias
Declare providers correctly: an explicit source address that resolves to registry.terraform.io/hashicorp/random, a second configuration of the same provider distinguished by an alias, and a resource wired to it with provider =. Proven by version -json and the plan JSON provider_config. Associate 5b.
dsoxlab start write-code-providersTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Read a resource's lifecycle in the plan
Build four resources ordered only by references, then prove in the plan JSON the four lifecycle operations: update in place, replace, create before destroy, and destroy. Pro objective 1c.
dsoxlab start write-code-declare-resourcesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Variables typing, validation and precedence
Type variables correctly and master their traps: a map of objects with optional() defaults, a validation rule that rejects before any provider, an explicit null that falls back to the default with nullable=false, the real source precedence (auto.tfvars over TF_VAR_, -var above all), and sensitive as a display mask, not a state protection. Associate 2e plus 2f.
dsoxlab start write-code-variablesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
The secret the output does not hide
Master the real output block: a type constraint (object), sensitivity propagation (an output referencing a secret must be sensitive, and sensitive is only a display mask, cleartext stays in state, -json and -raw), nonsensitive() to expose a hash deliberately, and a precondition that fails the plan. Associate 2e plus 2f.
dsoxlab start write-code-outputsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
The local that is not resolved at plan time
Centralize expressions in locals blocks: normalize with HCL functions, keep a ternary typed, generate a list with a for expression, derive from a resource attribute (known after apply), and inherit a variable's sensitivity. Pro objective 2c.
dsoxlab start write-code-localsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
When exactly does Terraform read a data source?
Build three data sources whose read timing is deliberate: one read during the plan, one deferred to the apply because the resource it depends on is changing, and one carrying an explicit depends_on that does NOT defer it. Prove each case in the plan JSON. Pro objective 2b.
dsoxlab start write-code-data-sourcesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
What expressions really compute
Write correct Terraform expressions: reference a managed resource with no prefix, know that == does not convert types (so 3 is not "3") while arithmetic does, respect operator precedence, and use null to omit an argument rather than an empty string. Associate 2e.
dsoxlab start write-code-expressionsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Compose values with HCL functions
Deduplicate a collection for for_each, handle out-of-range element(), lookup() fallback, ceil() rounding, template escaping and a provider-defined function. Pro objective 2c.
dsoxlab start write-code-functionsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
Provider-defined functions
Use functions exposed by a provider with the provider:: syntax. Pro objectives 2c and 5a.
dsoxlab start write-code-provider-defined-functionsTF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
The configuration that refuses absurd values
Compute values with conditional expressions, then place each guard at the right level: validation, precondition, postcondition and check block. Pro objective 2a.
dsoxlab start write-code-conditionalsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
Custom conditions: precondition, postcondition and check blocks
Validate a configuration with the language features designed for it. Pro objective 2a.
dsoxlab start write-code-validation-check-preconditionsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
count indexes by position, and the position lies
Choose count or for_each per resource and prove it: index a set by name with for_each, migrate a count resource to for_each with no destroy using moved blocks, keep count for interchangeable copies, and expose a conditional resource with one(). Associate objective 4b plus the Professional moved migration.
dsoxlab start write-code-countTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Add an instance without destroying the others
Migrate count to for_each with moved blocks on an already applied configuration, then add a service proving zero destruction. Pro objective 2d.
dsoxlab start write-code-for-eachTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Transform a catalog with for expressions
Derive four collections from a single map of servers with for expressions: a filtered tuple, an object grouped by role with the ellipsis, a flattened two-level cross, and a filtered for_each. Avoid the splat-on-a-map trap. Pro objective 2c.
dsoxlab start write-code-for-loopsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Generate blocks, and know when not to
Generate cloudinit parts with a dynamic block filtered in for_each and named from the key, keep the fixed part literal, and hit the wall: a lifecycle meta-argument block cannot be generated by dynamic. Pro objective 2d.
dsoxlab start write-code-dynamic-blocksTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
depends_on belongs only where a reference cannot go
Remove a redundant depends_on that a reference already covers, replace a hardcoded path with a reference, keep the one depends_on nothing else can express, and prove the graph in the plan JSON. Pro objective 2d.
dsoxlab start write-code-depends-onTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
The lifecycle block decides the order, not you
Set create_before_destroy and watch its propagation go down to dependencies, hit the documented limit of prevent_destroy, scope ignore_changes to a single attribute, trigger a replacement from a bare value through terraform_data, and reject an invalid input at plan time. Pro objective 2d.
dsoxlab start write-code-lifecycleTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 25m · intermediate · shell
The typo that breaks nothing
Two tfvars traps: an undeclared variable in a .tfvars is only a warning, so the real variable silently stays at its default (fix the typo), and terraform.tfvars.json outranks terraform.tfvars (a distinct precedence level). Associate 3c.
dsoxlab start write-code-tfvars-filesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
Version constraints and the lock file
Write correct version constraints: a literal required_version (the terraform block accepts no variable), an exact provider pin that resolves to that version, and the pessimistic ~> that allows 3.x but not 4.0. Proven by version -json and the h1 hashes of the lock file. Associate 3a.
dsoxlab start write-code-version-constraintsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 40m · intermediate · shell
The config that works but no CI accepts
Take a working but non-conforming config and make it CI-ready: pass terraform fmt, fix the orphan reference that breaks validate, rename resources to snake_case, type and describe variables and outputs, mark the token sensitive, type the number output (1.15), and write a .gitignore that excludes state but keeps the lock file. Associate 2a plus 2e.
dsoxlab start write-code-style-guideTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
When sensitivity breaks for_each
A side effect of sensitive rarely taught: a sensitive value cannot be a for_each key (Invalid for_each argument), so you must iterate over a non-sensitive set. The contaminated resource attribute is flagged in sensitive_values, and a hash is exposed with nonsensitive(). Professional 2f.
dsoxlab start write-code-sensitive-data-sensitive-valuesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 35m · intermediate · shell
The value that never touches the state
Declare an ephemeral value that is generated during the run but never written to the state or plan: the ephemeral block (random 3.7+), the contrast with a persisted random_password, exposing it safely at the root with ephemeralasnull(), and the two errors it triggers when leaked. Professional 2f.
dsoxlab start write-code-sensitive-data-ephemeral-valuesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
Write-only arguments: a secret that never lands in the state
Send a secret to the provider without ever persisting it in the Terraform state, using write-only arguments against a local AWS emulator.
dsoxlab start write-code-sensitive-data-write-only-argumentsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
Read secrets from Vault
Fetch secrets from HashiCorp Vault with the vault provider and consume them without freezing them in clear text in the state. Pro objective 2f.
dsoxlab start write-code-sensitive-data-vault-secretsTF-PROFESSIONAL Companion guide (French)
Terraform state
10
-
Guided lab 30m · intermediate · shell
Take over a secret already in service, without regenerating it
A plain `apply` would draw a new password. Attach the existing one through an `import` block, then observe that the secret sits in clear text in the state while being marked `sensitive_attributes`: masking is a display, not encryption.
dsoxlab start state-understand-stateTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
Migrate the state without breaking its lineage
A backend block accepts no named value. Move from an implicit local backend to a parameterised one through partial configuration and `-backend-config`, and prove the state migrated rather than being recreated: same `lineage`, both resources still managed.
dsoxlab start state-backendsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
State locking, what it really blocks
Measure the exact scope of the state lock on a local backend, and state what enables it on S3.
dsoxlab start state-state-lockingTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
terraform state list, the address is the identity
Find the address of an instance when all you know is its real identifier, and count managed resources without being caught by a module.
dsoxlab start state-terraform-state-listTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
terraform state show, and what the summary hides
Extraire du state une valeur sensible et des attributs nuls, que la sortie humaine de state show caviarde ou omet.
dsoxlab start state-terraform-state-showTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
terraform state mv and the moved block, refactor without destroying
Reattach three existing objects to their new addresses, imperatively then declaratively, and prove nothing was recreated.
dsoxlab start state-terraform-state-mvTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · intermediate · shell
terraform state rm and the removed block, stop managing without destroying
Take two resources out of the state without deleting the files, and learn why a removed block destroys unless you write destroy = false.
dsoxlab start state-terraform-state-rmTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 40m · intermediate · shell
The removed block: bequeath an infrastructure without destroying it
Take resources out of the state deciding for each whether the real object survives, and find where the removed block gives up. Pro objectives 1e and 4c.
dsoxlab start state-removed-blockTF-PROFESSIONAL Companion guide (French)
-
Guided lab 40m · intermediate · shell
Restore an amputated state: pick the right backup, prove nothing was recreated
A state rm went wrong and the backup was overwritten. Three candidate backups, one restorable, compared by lineage and serial, then pushed without touching the real files.
dsoxlab start state-backup-restore-stateTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 40m · intermediate · shell
Diagnose a drift and adopt an orphan resource, without losing its value
Prove a drift with a saved refresh-only plan, reconcile it, then adopt a pre-existing token with an import block, without Terraform regenerating it.
dsoxlab start state-diagnose-stateTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
Terraform modules
9
-
Guided lab 45m · intermediate · shell
A reusable module configures no provider of its own
Empty a child module of its provider configuration, have it declare the aliased configuration it expects, pass that configuration from the root, and instantiate the module three times with a single for_each.
dsoxlab start modules-create-modulesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Refactor a monolith into the standard module structure
Split a single .tf file into the official layout, add a nested module called by relative path, a standalone example, and prove that override.tf is the one file name with a functional effect.
dsoxlab start modules-module-structureTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
A module interface is a contract, not just types
Make an object attribute optional, refuse an explicit null, reject an out-of-range value, gate an output behind a precondition, and re-export a secret without breaking the plan.
dsoxlab start modules-module-variables-outputsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
A local module is read in place, not installed
Wire two root projects onto one shared local module, and prove from modules.json which folder each call really reads: relative path versus absolute path.
dsoxlab start modules-module-localTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
A registry module is downloaded, versioned, and never locked
Pin a registry module, resolve a flexible constraint, and prove from modules.json and the plan JSON which version got installed: the lock file never covers a module.
dsoxlab start modules-module-registryTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Publish and consume module versions with Git tags
Publish three versions of a shared module, then consume them from three projects: an immutable reference, a minor tag and a major tag, with no version argument in sight.
dsoxlab start modules-version-modulesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Prove a module with terraform test, mutations included
Write the .tftest.hcl suite of a module, covering its default, its options and its refusal of an invalid input: every behaviour is checked by mutating the module.
dsoxlab start modules-test-moduleTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Make a module composable, and prove it from the plan JSON
Strip a legacy module of its own provider configuration, invert its dependency and document it, then read the proof in provider_config and module_calls.
dsoxlab start modules-module-best-practicesTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · intermediate · shell
Refactor a copy-pasted project without destroying anything
Extract two copy-pasted resources into a typed module called once, and prove from the state identifiers that nothing was destroyed on the way.
dsoxlab start modules-module-anti-patternsTF-ASSOCIATETF-PROFESSIONAL Companion guide (French)
Environments
7
-
Guided lab 40m · advanced · shell
Split a monolithic configuration, and prove the plan did not move
Split an eighty-line main.tf into the official file layout, then prove by comparing two plans that nothing changed: a green validate proves nothing here.
dsoxlab start environments-organize-terraform-repoTF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · advanced · shell
Two roots, two states, one shared module
Wire two root configurations onto one shared module with a partial backend, then prove by destroying dev that prod never moved.
dsoxlab start environments-separate-environmentsTF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · advanced · shell
Which value wins, and how to prove it
Serve three environments from one configuration, restore the guard rail a stray terraform.tfvars had silenced, and prove which source wins from the plan JSON.
dsoxlab start environments-per-environment-variablesTF-ASSOCIATE Companion guide (French)
-
Guided lab 45m · advanced · shell
One directory, three states that never see each other
Drive three state instances from a single configuration through terraform.workspace, then retire an inherited workspace without leaving an orphan behind.
dsoxlab start environments-workspaceTF-ASSOCIATE Companion guide (French)
-
Guided lab 50m · advanced · shell
Workspaces or separate configurations, and what the split costs
Decide which parts still belong in workspaces, split the rest into two root configurations, and wire their dependency through terraform_remote_state without duplicating a value.
dsoxlab start environments-when-to-use-workspacesTF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · advanced · shell
Split a monorepo into two stacks that talk to each other
Re-export a nested module output at the root, consume it from a downstream stack through terraform_remote_state, and keep the platform secret out of the shared state.
dsoxlab start environments-monorepo-vs-repo-per-stackTF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · advanced · shell
Run Terraform in automation (CI/CD)
Build a non-interactive Terraform chain judged on exit codes alone, then record what a saved plan really freezes, what a lock does, and where a secret leaks.
dsoxlab start environments-terraform-in-automationTF-PROFESSIONAL Companion guide (French)
Terraform on AWS, via Floci
6
-
Guided lab 40m · intermediate · shell
AWS provider: authentication, endpoints and default tags
Configure a pinned AWS provider so it authenticates against a local API emulator, then prove the instance really runs.
dsoxlab start aws-provider-aws-first-ec2TF-ASSOCIATE Companion guide (French)
-
Guided lab 45m · intermediate · shell
Security group: dedicated rules, for_each and a deterministic subnet
Build a security group whose rules are all dedicated resources, factor the ingress rules with for_each, and place an instance in a subnet designated by its tag.
dsoxlab start aws-sg-subnet-instanceTF-ASSOCIATE Companion guide (French)
-
Guided lab 30m · advanced · shell
Compose the IAM chain, and name its two policies correctly
`aws_iam_policy_document` is a LOCAL data source: it queries nothing, it builds JSON. Compose the policy, role, instance profile and instance chain, and prove in the structured state that the trust policy and the permissions take two distinct paths to the role.
dsoxlab start aws-iam-role-policy-instance-profileTF-PROFESSIONAL Companion guide (French)
-
Guided lab 50m · advanced · shell
A remote state, locked, and read by another stack
Repair a trapped backend block, make the S3 lock actually effective, and have a second configuration consume the outputs without copying a single value.
dsoxlab start aws-backend-s3-remote-stateTF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · advanced · shell
Read a replacement in the plan, before it happens
An ASG referencing `version = "$Latest"` never triggers an instance refresh, and a `create_before_destroy` placed on the launch template protects nothing. Read both truths in the plan converted to JSON, without ever calling AWS.
dsoxlab start aws-launch-template-autoscalingTF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · advanced · shell
Import, moved and drift: the three traps a tutorial never shows
Bring an EC2 instance created outside Terraform under its control, change its logical address without the real object being recreated, then reconcile a drift by ACCEPTING reality rather than overwriting it.
dsoxlab start aws-import-moved-driftTF-PROFESSIONAL Companion guide (French)
HCP Terraform
8
-
Guided lab 35m · advanced · shell
The run workflow: played in two steps, then qualified
A run is a plan, then an apply of THAT plan. Reproduce it locally with saved plans, see what a stale plan and a frozen variable refuse, then qualify six described runs and put the eleven stages back in the order the documentation gives.
dsoxlab start hcp-terraform-hcp-terraform-overviewTF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · advanced · shell
Workspaces: one word, two meanings, two attachment strategies
A CLI workspace is one more state in the same directory; an HCP Terraform workspace is a unit of execution with its own variables, permissions and history. Repair two `cloud` blocks, attach one by name and the other by tags, and establish what `terraform validate` does not catch.
dsoxlab start hcp-terraform-hcp-workspacesTF-PROFESSIONAL Companion guide (French)
-
Guided lab 35m · advanced · shell
The stream a run sends back, and the three ways to start one
What a CLI receives from a remote run is the structured stream `terraform apply -json` also produces locally. Record it, analyse it in HCL, two `change_summary` messages, only one of which says what happened, and establish what each of the three workflows allows.
dsoxlab start hcp-terraform-remote-runsTF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · advanced · shell
Fifteen precedence levels, and one inversion
Among priority variable sets the broadest scope wins, whereas among normal sets it is the narrowest. Build the complete fifteen-level table, then resolve cases the tests generate and that no case-by-case answer can handle.
dsoxlab start hcp-terraform-variable-setsTF-PROFESSIONAL Companion guide (French)
-
Guided lab 35m · advanced · shell
Credentials: neither in the code, nor in the state
`sensitive` hides a value from the screen, and the state holds it in clear text all the same. Take the provider's keys out of the configuration, replace a token carried in a tag with its fingerprint, and establish how dynamic credentials work.
dsoxlab start hcp-terraform-shared-credentialsTF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · advanced · shell
Permissions add up, they do not override
A permission set at the organization level can beat one set on the workspace, and the reverse is also true: the most permissive wins, never the most specific. Write the rule that computes six teams' effective access, and establish two scales that are not the same.
dsoxlab start hcp-terraform-projects-teamsTF-PROFESSIONAL Companion guide (French)
-
Guided lab 30m · advanced · shell
Policy as code: what blocks a run, and who can override it
A `hard-mandatory` is not unbypassable: the policy set setting decides, crossed with the user's permission. Qualify seven runs, establish the levels of the three frameworks, and write a rule that refuses a non-compliant plan and accepts the compliant one.
dsoxlab start hcp-terraform-policy-as-codeTF-PROFESSIONAL Companion guide (French)
-
Guided lab 45m · advanced · shell
The first remote run, for real (optional, needs an account)
The only lab in the catalog that needs an HCP Terraform account. Provision the platform with the `tfe` provider, project, workspace, settings, a sensitive variable, attach a configuration with a `cloud` block, and watch a run execute on HashiCorp's infrastructure.
dsoxlab start hcp-terraform-premier-run-distantTF-PROFESSIONAL Companion guide (French)
Associate certification (004)
2
-
Guided lab 30m · advanced · shell
The commands the exam expects, done rather than recited
Eight gestures a candidate must be able to perform: `validate`, `fmt`, the precedence cascade, `moved`, `import`, `removed` without destroying, `-replace`, and what `sensitive` really protects. Exit codes are recorded as they happen: they cannot be reconstructed afterwards.
dsoxlab start certifications-associate-essential-commandsTF-ASSOCIATE Companion guide (French)
-
Capstone 4h · advanced · shell
Associate 004: mock exam
Associate 004 mock exam, validated by pytest.
dsoxlab start certifications-associate-mock-004TF-ASSOCIATE Companion guide (French)
Professional certification
7
-
Capstone 4h · advanced · shell
Pro · Objective 1: resource lifecycle, import and drift reconciliation
Import into state an EC2 instance created outside Terraform (aws cli on Floci), then detect and reconcile a drift. Exam objective 1.
dsoxlab start certifications-professional-capstone1-resource-lifecycleTF-PROFESSIONAL Companion guide (French)
-
Capstone 4h · advanced · shell
Pro · Objective 2: dynamic configuration and troubleshooting
Data sources, HCL functions, meta-arguments (count/for_each/dynamic), complex types, sensitive data and Vault. Exam objective 2.
dsoxlab start certifications-professional-capstone2-dynamic-configTF-PROFESSIONAL Companion guide (French)
-
Capstone 4h · advanced · shell
Pro · Objective 3: collaborative workflows
Remote state (S3 backend on Floci), version constraints, workflow in automation and data sharing via terraform_remote_state. Exam objective 3.
dsoxlab start certifications-professional-capstone3-collaborative-workflowsTF-PROFESSIONAL Companion guide (French)
-
Capstone 4h · advanced · shell
Pro · Objective 4: create, maintain and use modules
Create a module, consume it, refactor and version it; refactor a flat configuration into modules. Exam objective 4.
dsoxlab start certifications-professional-capstone4-modulesTF-PROFESSIONAL Companion guide (French)
-
Capstone 4h · advanced · shell
Pro · Objective 5: configure and use providers
Plugin architecture, aliasing, versioning/sourcing/upgrades, authentication and provider error troubleshooting (on Floci). Exam objective 5.
dsoxlab start certifications-professional-capstone5-providersTF-PROFESSIONAL Companion guide (French)
-
Challenge 45m · advanced · shell
Pro · Objective 6: HCP Terraform, where the sub-objectives cross
Objective 6 is assessed by multiple choice, and needs no account. Six situations that each cross two sub-objectives, a `cloud` block to write, and a secret that must not reach the state. Six situations, six different outcomes: no constant answer passes.
dsoxlab start certifications-professional-capstone6-hcpTF-PROFESSIONAL Companion guide (French)
-
Capstone 4h · advanced · shell
Pro · Integrative mock exam: the six objectives in one sitting
A rehearsal, not a lesson: six tasks, one per objective, to be played in one go once the six capstones are done. Drift reconciliation, dynamic configuration, two states that talk, a module that recreates nothing, two configurations of one provider, and a twelve-question HCP paper scored per sub-objective.
dsoxlab start certifications-professional-mock-proTF-PROFESSIONAL Companion guide (French)
Level exams
3
-
Capstone 45m · intermediate · shell
Level A exam: write and provision a demo environment
A product team needs a demo environment described by a machine catalog. Write the Terraform that builds it on libvirt, lets it evolve without breakage, protects the critical machine and delivers an application secret that never lands in the state. Graded on the real state.
dsoxlab start level-exams-write-provision -
Capstone 1h30 · advanced · shell
Level B exam: take over the operation of a platform
A platform in service has suffered an incident overnight. Put production back on its feet without recreating any machine, separate dev from prod, and ship a delivery chain that runs without a human. Graded on the real state.
dsoxlab start level-exams-operate-state -
Capstone 2h · advanced · shell
Level C exam: turn copy-pasted code into a versioned module
Two teams copy-pasted the same machine configuration. Turn it into a tested module published in a local Git repository, release a minor then a major version, and have both teams consume it, one pinned to content, the other following releases, without recreating the machines already in service. Graded on the real state.
dsoxlab start level-exams-modularize
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/kubernetes-dsoxlab-training
CKA, Certified Kubernetes Administrator
25
-
Guided lab 10m · intermediate · virtual machines
Place a static Pod on a worker, without going through the API
Run a Pod that the worker's kubelet manages on its own, from a manifest dropped on the node, and see it appear in the API under its mirror name. The file must sit where the kubelet's own configuration says, and the worker's runtime must really be running the container.
dsoxlab start cka-static-pod -
Guided lab 10m · beginner · virtual machines
An agent on every node, including the control plane
Deploy a DaemonSet that places an agent on every node of the cluster, including the control plane, protected by its taint. The tests count one Pod per node, check that the taint is still there and that the agent runs on it anyway, and read its logs to prove that it is doing its job.
dsoxlab start cka-daemonset-all-nodes -
Guided lab 15m · intermediate · virtual machines
Give an application an identity: ServiceAccount, Role, RoleBinding
An application refuses to start because its ServiceAccount does not exist. Create it, grant it the right to read the Pods of its namespace and nothing else, then prove from inside the Pod, with its own token, that listing goes through and that deleting, reading Secrets or looking elsewhere are denied.
dsoxlab start cka-rbac-serviceaccount -
Guided lab 10m · intermediate · virtual machines
Reserve a node: taint, toleration and nodeSelector
Reserve the worker for production with a taint and a label, then place a Pod that must go there, toleration and nodeSelector, and a Pod that must not. The tests read the node, the actual placement of each Pod and the declared mechanisms: a Pod pinned with nodeName bypasses the taint and does not pass.
dsoxlab start cka-taints-tolerations-placement -
Guided lab 15m · intermediate · virtual machines
Placing with nodeAffinity: required constraint and preference
Place a Deployment with a required node affinity on a label that accepts several values, add a weighted preference to it, then unblock a Pod that is waiting for a node which does not exist yet, by setting the label it demands. The tests read the node labels, the declared affinities and the actual node of every Pod.
dsoxlab start cka-node-affinity -
Guided lab 15m · intermediate · virtual machines
Isolate the database: only the backend gets in
Write the NetworkPolicy that lets nothing into the database but the backend of its own namespace, on its port. The tests attempt the connections: the one that must go through, the frontend one that must be blocked, the one from a Pod with the right label but in another namespace, and they check that the database can still reach out.
dsoxlab start cka-networkpolicy-isolate-db -
Guided lab 20m · intermediate · virtual machines
Route two applications on a single host, and prove each gets its own
Two applications, one hostname, and no rule saying which is which. Route by path, and prove it the only way that counts: each path answers with its own application's name, and an undeclared path answers with neither.
dsoxlab start cka-ingress-path-routing -
Guided lab 25m · advanced · virtual machines
Route with the Gateway API, and watch the Gateway report itself programmed
Same two applications, same single hostname, and the successor to Ingress. Declare a Gateway, attach a route to it, and prove the routing: each path answers with its own application's name, an undeclared path answers with neither.
dsoxlab start cka-gateway-api-httproute -
Guided lab 15m · intermediate · virtual machines
A persistent volume: PersistentVolume, PersistentVolumeClaim and a Pod that writes
On a cluster with no dynamic provisioning, create a PersistentVolume on a node's disk, claim it with a PersistentVolumeClaim, mount it in a Pod that writes to it. The tests read the volume, the binding, the mount, the file inside the Pod, then the same file on the node's disk: that is where persistence is proven.
dsoxlab start cka-pv-pvc-storageclass -
Guided lab 25m · intermediate · virtual machines
Get a volume no administrator created, and follow what becomes of it
A claim stuck in Pending because nobody prepared a volume by hand. Let the cluster provision it on demand, then observe what the class decides when the claim disappears: the volume goes with it.
dsoxlab start cka-storageclass-provisionnement-dynamique -
Guided lab 15m · intermediate · virtual machines
Roll back a stuck rollout, then ship the right version
An update went out with a wrong image name and the rollout is stuck. Go back to the revision that worked through the Deployment history, then ship the correct image with a change cause. The tests read the ReplicaSets and their revision numbers: they tell the story of what happened, and a Deployment recreated from scratch tells no story at all.
dsoxlab start cka-deployment-rollout-rollback -
Guided lab 15m · intermediate · virtual machines
Drain a worker for maintenance, without cutting the service
Protect an application with a PodDisruptionBudget, take the worker out of scheduling, evict it while respecting that budget and the DaemonSets, then put it back in service and record the operation. The tests prove that the Pods really were recreated elsewhere, that the node came back, and that the CNI DaemonSet did not move.
dsoxlab start cka-node-drain-cordon -
Guided lab 20m · intermediate · virtual machines
Scale out automatically with a HorizontalPodAutoscaler
Put an HPA on a Deployment, generate load, watch the replica count go up, then cut the load. The tests read the HPA, its current metrics, and the rescale event the controller emitted: an HPA that has never rescaled is not a validated HPA.
dsoxlab start cka-hpa-autoscaling -
Guided lab 25m · intermediate · virtual machines
Cap a namespace without blocking those who forget to declare themselves
A namespace with no ceiling and no defaults: one team can take the whole cluster, and a Pod with no requests is scheduled blind. Set both, and prove each: a Pod asking too much is refused, a Pod asking nothing is accepted and completed.
dsoxlab start cka-resourcequota-limitrangeCKACKAD Companion guide (French)
-
Guided lab 10m · beginner · virtual machines
Get a Pod out of ImagePullBackOff
A Pod does not start because its image will not download. Read the runtime's exact message in the events, fix the image reference, and prove that the server answers.
dsoxlab start cka-troubleshoot-imagepullbackoff -
Guided lab 15m · intermediate · virtual machines
Get a Deployment out of CrashLoopBackOff
The Pods of a Deployment have been restarting in a loop since the last release. Read what the process said before it died, work out what it is missing, fix the Deployment, and prove the application serves again.
dsoxlab start cka-troubleshoot-crashloopbackoff -
Guided lab 15m · intermediate · virtual machines
Get inside a container with no shell using kubectl debug
A Pod whose image contains no shell offers nothing to kubectl exec. Attach an ephemeral container to it that shares its processes, reach the node's filesystem through a debug Pod, and leave proof of it.
dsoxlab start cka-kubectl-debug -
Guided lab 10m · intermediate · virtual machines
Restore the cluster's DNS resolution
No Pod resolves a service name any more. Find out why the cluster DNS has stopped answering, put it back in service, and prove that a client Pod resolves and reaches a Service by its name again.
dsoxlab start cka-troubleshoot-dns -
Guided lab 15m · advanced · virtual machines
Restore traffic to a Service
A Service no longer serves its Pods: wrong selector, wrong port, and a network policy that closes everything. Set the Service straight, reopen exactly what is needed without removing the security policy, and prove that a client reaches the Service by its name.
dsoxlab start cka-troubleshoot-networking -
Guided lab 15m · advanced · virtual machines
Bring a NotReady node back into the cluster
A worker has gone NotReady, and the application reserved for it is degraded. Find out on the node why it no longer talks to the control plane, put its agent back in service for good, and prove that the application is back.
dsoxlab start cka-troubleshoot-node-notready -
Guided lab 15m · advanced · virtual machines
Repair a kubelet that refuses to start
A worker's kubelet stops as soon as it is launched, and the node is NotReady. Read in the journal what it holds against its configuration, fix the file without breaking anything else, and prove that the node and its application are back.
dsoxlab start cka-troubleshoot-kubelet -
Guided lab 15m · advanced · virtual machines
Bring the API server back into service
kubectl no longer answers: the control plane's API server exits with an error at startup. With no API, diagnose on the node, in the containers and in the kubelet journal, fix the static manifest, and prove the API answers without having weakened its authorization.
dsoxlab start cka-troubleshoot-apiserver -
Guided lab 25m · advanced · virtual machines
Back up etcd, then restore the cluster from a snapshot
A namespace has disappeared. Take a fresh backup of the current state first, then restore the cluster from yesterday evening's snapshot, without stopping the wrong component and without leaving the API server on a stale cache. The tests prove that etcd runs on a data directory produced during the lab, that the objects come back with their original UID, and that what was written after the backup is gone.
dsoxlab start cka-etcd-backup-restore -
Guided lab 40m · advanced · virtual machines
Upgrade a cluster one minor version, without interrupting what runs on it
A cluster one minor version behind, an application that must keep serving, and the upgrade to run: the control plane first, then the node, each with its own command. The tests read the versions and check nothing was left drained.
dsoxlab start cka-kubeadm-upgrade -
Mock exam pass 66% 45m · advanced · virtual machines
Capstone: bring the portal back, with nobody left to ask
A namespace handed over by a team that is gone, a portal that answers nothing, and no ticket saying why. Three independent faults to find, two requirements that were never met, and a single measure of success: the portal answers on every node of the cluster.
dsoxlab start cka-capstone-portail
CKAD, Certified Kubernetes Application Developer
20
-
Guided lab 10m · beginner · virtual machines
A two-container Pod, with budgets, labels and an annotation
Write by hand a Pod with two containers, each with its own requests and limits, with labels and an annotation, and prove from inside each container that the memory limit is the one the kernel enforces.
dsoxlab start ckad-pod-resources-labels -
Guided lab 15m · beginner · virtual machines
Inject configuration and secrets into a Pod
Give an application its configuration through environment variables and through a mounted file, and its credentials through a Secret, without ever writing a password in the Pod manifest. Prove, from inside the container, that everything arrived.
dsoxlab start ckad-configmap-secret-injection -
Guided lab 20m · intermediate · virtual machines
Take a password out of a manifest, without the application noticing
A password sits in plain sight inside a Deployment manifest, which anyone who can read the manifest can read too. Move it into a Secret, inject it both as an environment variable and as a mounted file, and keep the application running.
dsoxlab start ckad-secret-injection-protection -
Guided lab 15m · beginner · virtual machines
Three probes on one Pod: startup, liveness, readiness
Fit an application with all three probes, with settings that make sense: a slow start tolerated, liveness watched, traffic that only arrives once the Pod is ready. Prove the probes act: the Pod is Ready only because they answer.
dsoxlab start ckad-probes-all-types -
Guided lab 15m · intermediate · virtual machines
Wait for a dependency with an init container
Keep an application from starting before the Service it depends on answers, with an init container that waits. Watch the Pod held in Init, put the dependency in place, and see the application start on its own.
dsoxlab start ckad-init-container -
Guided lab 15m · intermediate · virtual machines
A native sidecar that tails the application logs
Have a second container read the logs an application writes to a file, with a native sidecar, declared as an init container with restartPolicy Always, and a shared volume. Prove that the sidecar really does pass the lines on.
dsoxlab start ckad-multi-container-sidecar -
Guided lab 20m · intermediate · virtual machines
Let one container read what another writes, and nothing else
Two containers in one Pod, one writing and one reading, and nothing shared between them. Give them a volume whose lifetime is the Pod's, and prove it both ways: what is written inside the volume crosses, what is written beside it does not.
dsoxlab start ckad-volumes-partage-entre-conteneurs -
Guided lab 10m · beginner · virtual machines
Expose a Deployment through a ClusterIP Service
Deploy three replicas of a server and expose them through an internal Service. Prove from a client that the Service answers under its name, and that it really spreads the requests across the three Pods.
dsoxlab start ckad-expose-service -
Guided lab 15m · intermediate · virtual machines
Harden a Pod with a securityContext
Run a web server with no privilege: non-root user, no escalation, read-only root filesystem, every capability dropped. And still give it somewhere to write where it needs to, otherwise it will not start. Prove, from the inside, that the confinement holds and that the application serves.
dsoxlab start ckad-security-context-hardened -
Guided lab 15m · intermediate · virtual machines
Grant read-only access to Pods with RBAC
Let a user read the Pods of a namespace and their logs, and nothing more: no creating, no deleting, no looking into the other namespaces. Prove both sides with kubectl auth can-i, what is allowed and what stays denied.
dsoxlab start ckad-rbac-role-rolebinding -
Guided lab 20m · intermediate · virtual machines
Partition three tiers with ingress and egress NetworkPolicy
Frontend, backend, database: allow only the intended flows, in both directions, DNS included, and forbid everything else. Prove every rule with a real connection, the one that goes through and the one that is blocked.
dsoxlab start ckad-networkpolicy-ingress-egress -
Guided lab 15m · intermediate · virtual machines
Tune a rolling update: maxSurge and maxUnavailable
Constrain the way a Deployment replaces its Pods, never more than two extra ones nor more than one unavailable, then trigger an image update and prove it went all the way through: old revision down to zero, new one complete.
dsoxlab start ckad-rolling-update-strategy -
Guided lab 15m · intermediate · virtual machines
Switch traffic from one version to the other: blue-green
Run two versions of an application side by side, then switch all the traffic from one to the other by changing a Service selector. Prove the switch from a client: every request reaches the new version, none the old one.
dsoxlab start ckad-blue-green-deployment -
Guided lab 20m · intermediate · virtual machines
One Kustomize base and two overlays, dev and prod
Describe an application only once, in a Kustomize base, and deploy it into two namespaces with overlays that change the replica count, prefix the names and add an environment label. Prove that both environments are running and look alike.
dsoxlab start ckad-kustomize-overlays -
Guided lab 15m · intermediate · virtual machines
Install, upgrade and roll back with Helm 4
Deploy a chart with Helm, upgrade it with new values, then go back to the first revision. Prove through the release history and the state of the Deployment that the three operations took place, in that order.
dsoxlab start ckad-helm-install-upgrade -
Guided lab 15m · beginner · virtual machines
A Job with parallel completions, and a CronJob
Run a workload four times, two at a time, with a Job, and prove that the runs really did overlap. Then schedule a cleanup every five minutes with a CronJob that keeps a bounded history.
dsoxlab start ckad-job-cronjob -
Guided lab 10m · advanced · virtual machines
Resize a Pod in place, without restarting it
Raise the CPU and the memory of a running Pod, without recreating it and without restarting its container, through the resize subresource. Prove that the kernel applies the new limit and that the container stayed the same.
dsoxlab start ckad-in-place-pod-vertical-scaling -
Guided lab 10m · beginner · virtual machines
A Pod blocked by a ConfigMap that does not exist
A Pod does not start and says nothing in its logs, because it has no container yet: its events are the ones that talk. Read the cause, create the missing resource with the expected content, and prove that the application serves.
dsoxlab start ckad-troubleshoot-missing-configmap -
Guided lab 15m · intermediate · virtual machines
Three Pods in CrashLoopBackOff, three causes
Three Pods restart in a loop for three different reasons: a command that does not exist, a missing environment variable, a memory limit set too low. Read for each one what kills it, fix it, and prove that all three hold.
dsoxlab start ckad-troubleshoot-crashloop -
Mock exam pass 66% 45m · advanced · virtual machines
Capstone: ship the shop, from the specification alone
A full delivery, given as a specification rather than a walkthrough. Six requirements to satisfy in one namespace: configuration, secret, probes, identity, exposure and isolation. Nothing says which object to create, and the last test checks the only thing that matters: a frontend Pod reaches the shop, and a Pod that is not one does not.
dsoxlab start ckad-capstone-boutique
CKS, Certified Kubernetes Security Specialist
19
-
Guided lab 25m · advanced · virtual machines
Confine a Pod with an AppArmor profile
Load an AppArmor profile on the node, apply it to a container through the securityContext field, and prove that the confinement holds by watching a write the profile forbids fail.
dsoxlab start cks-apparmor-confiner-un-pod -
Guided lab 25m · advanced · virtual machines
Deny a system call to a container, and prove it from the inside
A container that may call anything the kernel offers. Write a seccomp profile that refuses one family of system calls, apply it, and prove the confinement holds: the forbidden call fails from inside, and everything else still works.
dsoxlab start cks-seccomp-profile -
Guided lab 15m · intermediate · virtual machines
Reject a privileged Pod at admission, with Pod Security Admission
A namespace that accepts anything, including a Pod that shares the host's PID namespace and runs as root. Turn on the restricted standard so the cluster refuses it at admission, and prove the refusal without creating anything: a server-side dry run goes through admission and writes nothing.
dsoxlab start cks-pod-security-admission -
Guided lab 20m · intermediate · virtual machines
Take over a privileged Pod in production, without stopping its work
A Pod runs with the host's process namespace, as root, privileged, from a floating tag. Rebuild it without any of that, and prove the difference where it is visible: from inside, the container no longer sees the host.
dsoxlab start cks-secure-existing-pod -
Guided lab 20m · intermediate · virtual machines
Make a container immutable without bringing it down
A running Deployment can still be written to from the inside. Make its root filesystem read-only, drop every capability, forbid escalation, and keep the application serving: nginx needs a few writable paths, and finding them is the exercise.
dsoxlab start cks-security-context-immutable -
Guided lab 25m · advanced · virtual machines
Isolate a Pod from the host kernel, and prove it by reading its version
The node offers a second container runtime that runs an application kernel of its own. Put a Pod inside it, and prove the isolation the only way that cannot be faked: from inside, the kernel version is no longer the node's.
dsoxlab start cks-runtime-sandbox-gvisor -
Guided lab 15m · intermediate · virtual machines
Pin an image by digest, and prove the tag is not enough
A Deployment that trusts a mutable tag. Pin it to the immutable digest of the image it actually runs, and prove the pin holds: the declared digest must match what the runtime resolved, not just look like one.
dsoxlab start cks-image-pinned-digest -
Guided lab 30m · advanced · virtual machines
Have the cluster itself reject an unpinned image, with no webhook
A namespace accepts any image, tag and all. Make the API server refuse the ones that are not pinned by digest, with a policy it evaluates itself: no webhook, no controller, nothing to keep running.
dsoxlab start cks-validating-admission-policy -
Guided lab 25m · intermediate · virtual machines
Replace an image riddled with flaws, and prove it with a second scan
A Deployment runs an image three years old. Scan it, pick a replacement, and prove the choice: the test scans both and demands strictly fewer critical findings than the original, which no fixed threshold could measure honestly.
dsoxlab start cks-image-scanning-trivy -
Guided lab 30m · advanced · virtual machines
Sign an image, and prove the signature by having another one refused
A local registry holds two images, neither signed. Sign one with cosign, publish the public key, and prove the chain works: the same key must accept the signed image and refuse the other. A verification that accepts everything proves nothing.
dsoxlab start cks-cosign-verify-image -
Guided lab 20m · intermediate · virtual machines
Fix a Dockerfile static analysis refuses, without changing the application
A Dockerfile that builds and runs, and that static analysis rejects on five counts. Fix them all without changing what the image does, and prove it by running the analysis again: the five findings must be gone by their identifiers, not by a count that a new rule would break.
dsoxlab start cks-dockerfile-static-analysis -
Guided lab 20m · intermediate · virtual machines
Take cluster-admin away from a service account, without stopping its work
A ServiceAccount holds cluster-admin because it was quicker. Take that power back and give it exactly what its application needs, no more. The proof is not the manifest: it is what the API server answers when that account asks.
dsoxlab start cks-rbac-least-privilege -
Guided lab 25m · advanced · virtual machines
Close the API server profiler, without closing the API
The API server exposes its Go profiler to anyone who can reach it, and a kubeadm cluster leaves it on. Close it and raise the TLS floor, then prove both halves: the profiler answers 404, and the cluster still works.
dsoxlab start cks-api-server-hardening -
Guided lab 25m · advanced · virtual machines
Record who reads Secrets, and only the metadata of everything else
The cluster keeps no trace of who reads what. Give the API server an audit policy with two levels, full bodies for Secrets and metadata for everything else, and prove it works by reading the log the cluster has just written.
dsoxlab start cks-audit-log-policy -
Guided lab 20m · intermediate · virtual machines
Deny everything, then reopen the strict minimum, DNS included
A namespace where everything talks to everything. Close it completely in both directions, then reopen exactly two things: the one flow the application needs, and name resolution, which a default-deny egress breaks in a way nothing warns you about.
dsoxlab start cks-networkpolicy-default-deny -
Guided lab 30m · advanced · virtual machines
Require mTLS in a mesh, and prove it with a client left outside
A service mesh accepts plain traffic from anyone, inside the mesh or out. Require mutual TLS, and prove it the only way that counts: a Pod with a sidecar still reaches the service, a Pod without one no longer does.
dsoxlab start cks-istio-mtls-lockdown -
Guided lab 25m · intermediate · virtual machines
Serve a site over HTTPS with its own certificate, not the controller's
The site already answers over HTTPS, which is exactly the trap: the Ingress controller serves its own default certificate to anyone who asks. Terminate TLS with a certificate that actually names the host.
dsoxlab start cks-ingress-tls -
Guided lab 30m · advanced · virtual machines
Bring down a CIS audit count, and prove it with a second audit
kube-bench audits the control plane against the CIS benchmark and fails ten checks on a stock kubeadm cluster. Fix the three that share one cause, then prove it the only honest way: run the audit again and count.
dsoxlab start cks-cis-benchmark-remediate -
Mock exam pass 66% 45m · advanced · virtual machines
Capstone: open an enclave for a team you do not trust
An outside team needs room in your cluster. Give them one that stays safe even if they are not: the cluster itself must refuse what they should not deploy, their identity must be able to do almost nothing, and nothing outside the enclave may reach what runs inside it.
dsoxlab start cks-capstone-enclave
GitHub Actions
GitHub Actions
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/github-actions-training
Writing your first workflow
1
-
Guided lab 30m · beginner · shell
First workflow: the tests run on every push, and a broken test turns the pipeline red
A small Python library with nine tests that nobody runs before merging. Write the workflow that runs them on every push and pull request, with minimal permissions and pinned actions, and prove it by breaking a test.
dsoxlab start fondations-premier-workflow
Python, automation
Python, automation
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/python-dsoxlab-training
Automation: a security tool, step by step
7
-
Guided lab 30m · beginner · shell
Read a scanner report: count the vulnerabilities by severity
A scanner exports its findings as JSON and nobody reads the file. Write version 1 of security_check.py: it reads the report, prints how many findings there are per severity, and refuses a missing file or broken JSON in one clear line, with exit code 2.
dsoxlab start automatisation-lire-un-rapport -
Guided lab 40m · beginner · shell
Query the OSV API: what is known about each package of the report
The report says which findings the scanner saw; the OSV database says what is known about each package. Add --osv to security_check.py: one request per package, a maximum delay, and an API outage reported in one line with exit code 2, never a hang or a traceback.
dsoxlab start automatisation-interroger-osv -
Guided lab 40m · intermediate · shell
Read a real Trivy report: nested results, missing keys and duplicates
Trivy does not export a flat list: it nests vulnerabilities under each scanned target, omits the key when a target is clean, and repeats a flaw found in two files. Teach security_check.py to read this real format and count each vulnerability once.
dsoxlab start automatisation-rapport-trivy -
Guided lab 40m · intermediate · shell
An exit code a pipeline can act on: --fail-on with Click
A pipeline does not read what a tool prints, it reads its exit code. Move security_check.py to Click and add --fail-on: 0 when nothing reaches the threshold, 1 when it is reached, 2 for unusable input. Three codes a CI job can tell apart.
dsoxlab start automatisation-code-de-sortie -
Guided lab 45m · intermediate · shell
Test your own tool: a pytest suite that catches four real bugs
A tool that decides whether a pipeline stops must not change behaviour unnoticed. Write the pytest suite of security_check.py. It is graded on what it catches: it must pass on the correct tool and fail on four mutants, each carrying one realistic bug.
dsoxlab start automatisation-tester-son-outil -
Guided lab 40m · intermediate · shell
A security gate in the pipeline: security_check.py in GitHub Actions
The tool is finished and tested; now it must guard the branch. Write the GitHub Actions workflow that runs the tool's tests, then applies the CRITICAL threshold to the scanner report, on every push and pull request, with read-only permissions and pinned actions. act plays it locally.
dsoxlab start automatisation-dans-la-ci -
Guided lab 45m · intermediate · shell
Read an SBOM: cross a CycloneDX inventory with the OSV database
An SBOM lists what you ship, not what is vulnerable in it. Teach security_check.py to read a real CycloneDX SBOM produced by syft, query OSV for each PyPI component, turn every known vulnerability into a finding with the severity of its GitHub advisory, and apply the same threshold.
dsoxlab start automatisation-lire-un-sbom
DevSecOps, the notes-api common thread
DevSecOps, the notes-api common thread
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/devsecops-dsoxlab-training
The notes-api common thread, V0 to V11
13
-
Guided lab 30m · beginner · shell
V0, a minimal pipeline: notes-api tested on every push
The common thread of the DevSecOps course starts here. notes-api, a small Flask service, has tests but no pipeline. Write the GitHub Actions workflow that installs the locked dependencies and runs the tests on every push and pull request. act plays it locally.
dsoxlab start capstone-v00-pipeline-minimal -
Guided lab 40m · beginner · shell
V1, a threat model: STRIDE on notes-api, checked by the pipeline
notes-api now has a pipeline, but nobody wrote down what can go wrong. Write its STRIDE threat model, confront it with the real routes of the code, and make the pipeline refuse a model left incomplete. The SQL injection the code carries must be named, and stay open until the next version fixes it.
dsoxlab start capstone-v01-modele-de-menace -
Guided lab 50m · intermediate · shell
V2, blocking secret scanning and SAST: two gates, and the injection fixed
notes-api's threat model names a SQL injection that is still open. Add two blocking gates to the pipeline, a secret scanner and a static analysis, then fix the injection they would stop, prove the fix with a regression test, and update the threat model. An injected secret or a new concatenated query must turn the pipeline red.
dsoxlab start capstone-v02-secrets-et-sast -
Guided lab 45m · intermediate · shell
V3, dependency scanning and triage: fix what can be fixed, date what cannot
notes-api's lock carries eight known vulnerabilities, and its pipeline sees none of them. Add a blocking dependency scan, upgrade the packages that have a fixed version, and triage the one that has no fix: a written reason and an expiry date in osv-scanner.toml. The vulnerable lock, or an expired exception, must turn the pipeline red.
dsoxlab start capstone-v03-sca-et-triage -
Guided lab 50m · intermediate · shell
V4, an identity without a secret: OIDC instead of a stored key
notes-api is published by a deploy job that holds a long-lived AWS access key in the repository secrets. Replace it with an OIDC exchange: only the deploy job may request a token, only a push on main deploys, and the role's trust policy accepts a token from main of acme/notes-api and nothing else. The IAM user and its key leave the infrastructure code.
dsoxlab start capstone-v04-identite-sans-secret -
Guided lab 50m · intermediate · shell
V5, a hardened pipeline: workflows audited, pull requests contained
A new workflow welcomes each pull request: it runs on pull_request_target, checks out the proposed code and runs it with a write token, and pastes the title into a shell script. Add an audit of every workflow to the pipeline, zizmor for security and actionlint for syntax, both blocking; rewrite the welcome workflow so it executes nothing from the pull request; and require the security team's review on the workflows, the infrastructure and the security decisions with CODEOWNERS.
dsoxlab start capstone-v05-pipeline-durci -
Guided lab 60m · intermediate · shell
V6, the image and the infrastructure: what you ship besides the code
notes-api ships an image that runs as root, built from an unpinned base with versions copied by hand, and an infrastructure that opens SSH to the world and leaves its buckets without a public access block. Add a blocking Trivy analysis of the configuration and of the built image to the pipeline, then harden the Dockerfile (pinned base, locked dependencies, no dev tools, unprivileged user) and the Terraform until the gates pass.
dsoxlab start capstone-v06-image-et-iac -
Guided lab 55m · intermediate · shell
V7, SBOM and provenance: know what ships, prove where it comes from
notes-api publishes an archive that nobody can trace: no inventory of what the image carries, no proof of which pipeline built it. Produce the SBOM of the built image and confront it with uv.lock using the team's tool, so that a package installed outside the lock turns the pipeline red; attest the provenance of the published archive from the deploy job; and write the check that refuses to deploy an archive not built by ci.yml from main.
dsoxlab start capstone-v07-sbom-et-provenance -
Guided lab 50m · advanced · shell
V8, admission: the cluster refuses what the platform did not sign
notes-api now runs in a Kubernetes cluster, and the cluster starts any image a manifest names. Write the Kyverno admission policies of the notes-api namespace: only images from the internal registry, signed with the platform key, are admitted; an unsigned image, an image signed with another key, or an image from another registry is refused, a Deployment included, without blocking the rest of the cluster.
dsoxlab start capstone-v08-admission-signee -
Guided lab 50m · advanced · shell
V9, a contained runtime: restricted pods and closed network
notes-api runs in its namespace with default settings: a process that may escalate its privileges, keeps its capabilities, mounts an API token, and a pod that can reach any other pod. Enforce the restricted Pod Security Standard on the namespace, harden the Deployment until it passes it, and write the network policies that only let the ingress controller in and DNS out. The checks build your image and measure the real traffic.
dsoxlab start capstone-v09-runtime-cloisonne -
Guided lab to re-attest 50m · advanced · virtual machines
V9b, runtime detection: Falco watches notes-api on a real machine
V9 closed the pod; it does not say when someone gets in anyway. On an Ubuntu machine, notes-api runs in Docker under Falco, with its modern eBPF probe. Write the Falco rules of notes-api: a shell opened in its container, and a write into its code, must each raise an alert that names the container and the command; the application's normal activity and a shell in another container must raise none. The rules must survive a restart.
dsoxlab start capstone-v09b-detection-falco -
Guided lab 50m · advanced · shell
V10, VEX and dated exceptions: every accepted finding is written down
The team raises the bar to MEDIUM. Three configuration findings come up, and pip 25.0.1 of the base image carries vulnerabilities that the scanners of the released images keep reporting. Fix what can be fixed, remove pip from the image, accept the rest as dated exceptions with their reason, and publish a VEX document that tells the operators of the previous releases that pip does not affect notes-api. An expired exception turns the pipeline red again.
dsoxlab start capstone-v10-vex-et-exceptions -
Guided lab 60m · advanced · shell
V11, measuring reliability: an SLO that pages, a runbook, the DORA metrics
notes-api is secured end to end, but nothing tells the team it is down before its users do. Write the availability SLO as a Prometheus alert that pages when the error budget burns 14.4 times too fast, with its unit tests; the runbook the alert links to; and the script that computes the four DORA metrics from the deployment and incident journals. The pipeline checks the alert and recomputes the metrics on every pull request.
dsoxlab start capstone-v11-slo-et-dora
Cloud, practising without an account
Cloud, practising without an account
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/cloud-dsoxlab-training
Practising without an account
1
-
Challenge 45m · intermediate · shell
Challenge 1: an architecture on a tight budget
An environment is already deployed on the feint emulator, drawn at random. Read it with the official scw CLI, cost it on the dated price grid provided, say whether it fits the budget and name what is billed for nothing. No procedure: graded on the estimate, recomputed from the real state.
dsoxlab start pratiquer-challenge-budget-contraint
Bootstrapping a machine
1
-
Guided lab 30m · beginner · shell
A first clean VM: booted by cloud-init, with no public address
Write the user-data of a first machine, boot an Incus virtual machine with it on a private network, and prove from the machine itself that the user, the packages and the file came from cloud-init alone. Then destroy it.
dsoxlab start amorcer-premiere-vm-propre
Cloud networking
2
-
Guided lab 40m · intermediate · shell
Private network, and first instances with no public address: scw on Feint
With the official scw CLI plugged into the feint emulator, build a regional VPC and Private Network, two instances with no public IP in two zones, one private NIC per zone, and a Public Gateway that pushes the default route. Graded on the state feint holds, never on the commands typed.
dsoxlab start reseau-prive-scaleway -
Guided lab 45m · intermediate · shell
Private network, and first instances with no public address: octl on Feint
With the official octl CLI plugged into the feint emulator, build a regional Net with one subnet per Subregion, two VMs with no public IP in two Subregions, an Internet Service, a NAT Service and the two route tables that send private traffic out through the NAT. Graded on the state feint holds.
dsoxlab start reseau-prive-outscale
CI/CD, the model before the tool
CI/CD, the model before the tool
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/cicd-dsoxlab-training
A first CI, for Development for Ops
1
-
Guided lab 30m · beginner · virtual machines
certcheck's CI: six stages, a red run, a fix
Read the pipeline provided with certcheck, a small Python tool: fetch the code, prepare Python, install the dependencies, check quality, run the tests, build the package. Repair main, which is red at the quality stage, then make a test fail and the formatting fail in a pull request, read each red run, reproduce it locally and fix it.
dsoxlab start ci-certcheck
The model before the tool
3
-
Guided lab 30m · beginner · virtual machines
Stages in the repository, a pipeline that orchestrates them
Run lint, tests and build as make targets, write the pipeline that only calls them on a push to main and on a pull request, watch it go green, then red on a broken test, and reproduce the failure locally.
dsoxlab start etapes-et-declencheurs -
Guided lab 30m · beginner · virtual machines
Build once, publish, find it again by its digest
Publish the artifact the pipeline has just built and tested to the forge registry, on a version tag only, with a dedicated token kept as a secret; then find the published version again and check it by its SHA-256 digest.
dsoxlab start artefacts -
Guided lab 35m · beginner · virtual machines
Promote the same artifact from staging to production, then roll back
Write the on-demand deployment pipeline, deploy a published version to staging, promote the very same artifact to production without rebuilding it, then roll production back to the previous version; each environment keeps its own configuration.
dsoxlab start environnements-promotion
Level exam
1
-
Challenge 60m · intermediate · virtual machines
Level exam: repair a broken delivery chain
A repository whose pipeline lies: a failing test is ignored, the steps cannot be replayed locally, a secret leaks into the logs, every branch publishes, and deployment rebuilds the artifact. Make the chain honest and green, publish a corrected version, promote the very same artifact to production, and list the risks you found.
dsoxlab start level-exams-chaine
Development for Ops
Development for Ops
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/dev-pour-ops-dsoxlab-training
The common thread: read, modify, test and review a small tool
6
-
Guided lab 25m · beginner · shell
Read and modify a small Python script: the inherited certcheck
A small inherited Python script checks certificate expiry every night, and nobody on the team wrote it. Say what it does, find its inputs and the function that decides, read what it prints and its exit code, then make two simple changes: an inclusive threshold, and an expired status.
dsoxlab start lire-du-code -
Guided lab 20m · beginner · shell
Understand a Python tool, then modify it: certcheck and its contract
certcheck has become a Python project: a package in src layout, declared in pyproject.toml, run by bin/certcheck. Find where the command is declared, where the decision lives, which file cron runs and which exit codes it returns, then close two gaps with its contract: read the threshold from CERTCHECK_DAYS, and write errors on stderr.
dsoxlab start script-en-outil -
Guided lab 25m · beginner · shell
Dependencies: certcheck installs elsewhere too
A colleague moved certcheck to the cryptography and requests libraries, installed them by hand in his virtual environment, and declared nothing: "works on my machine". Step by step: declare both dependencies, pin their versions, note the Python version, and prove that a fresh environment installs the tool from the project files alone. Needs network access to PyPI.
dsoxlab start dependances-reproductibles -
Guided lab 20m · beginner · shell
Use the tests: a red test, read, fixed, and one more test
certcheck has four tests, and one of them is red. Run the suite, read which test fails and what its assertion compares, fix the code (not the test), run it again until green, then add one test by copying a model: it must catch a new bug that the four tests let through.
dsoxlab start tester-une-automatisation -
Guided lab 25m · beginner · shell
Debug step by step: the certificate certcheck cannot read
A ticket says certcheck reports vpn-01 as unreadable while openssl reads its certificate fine. Guided step by step: reproduce the bug with a test that fails, look at the faulty value with print or pdb, fix it without breaking the rest of the contract, keep the test, and write down what you saw, the cause and the fix.
dsoxlab start deboguer -
Guided lab 25m · beginner · shell
Review a pull request: four defects in certcheck #42
A colleague proposes pull request #42 on certcheck: purging old reports and notifying the chat. Its tests are green. Read the diff as it would be merged, find at least three of its four defects (swallowed error, printed secret, dangerous path, missing test), comment each with a concrete fix, decide, then version a ruff configuration and make ruff check pass.
dsoxlab start relire-une-automatisation
Going further
3
-
Guided lab 30m · beginner · shell
Call an API with requests: certcheck opens its ticket
certcheck must open a ticket on the forge when certificates are due. Step by step, with the requests library declared and pinned in the project: the token in the Authorization header and never in the URL, a timeout on each request, an HTTP error turned into exit code 3 with a clear message, the ticket created with the right title, and no duplicate when it is already open. Graded on the requests received by a fake forge.
dsoxlab start appeler-une-api -
Guided lab 25m · beginner · shell
Ship a tool: certcheck 1.0.0, versioned and installable
certcheck declares its dependencies; it now has to be shipped, without publishing anything. Step by step: version 1.0.0 written once in pyproject.toml and shown by --version, a CHANGELOG section for 1.0.0, a Git tag v1.0.0, then proof that a fresh environment installs the tool, from the working directory and from a clone of the tag. Needs network access to PyPI.
dsoxlab start livrer-un-outil -
Mock exam pass 70% 60m · intermediate · shell
Challenge: take over an operations tool
You inherit certcheck.sh, a Bash script that counts a missing certificate as "0 days" and always exits 0, its written contract, and a colleague's pull request to review. Replace it with the Python project whose skeleton is provided (pyproject.toml, uv.lock, a package under src/ with functions to write): an implementation that honours the contract, its own pytest suite that catches the inherited bug, an installable package, a version recorded in the CHANGELOG and tagged in Git, and the review. Graded on the contract with hidden tests, without hints.
dsoxlab start level-exams-outil
Level exams
1
-
Mock exam pass 70% 45m · beginner · shell
Exam: step in on a small operations tool
A small Python operations tool, a recent change that introduced a defect, and a red CI run. Clone the repository, read the code and say what it does, read the CI log to find the failing step, find the file holding the defect, make a limited fix, then get the tests, the quality checks and the CI steps back to green. Graded as a black box, without hints.
dsoxlab start level-exams-intervenir
MLOps, reproduce, ship and operate a model
MLOps, reproduce, ship and operate a model
Add this catalogue dsoxlab catalog add https://github.com/stephrobert/mlops-dsoxlab-training
Level 1: reproduce
6
-
Guided lab 30m · beginner · shell
Make a training run reproducible
A colleague's training script gives different metrics on every run, and nobody knows which library versions it needs. Find where the variation comes from, pin it, and prove it: two trainings give the same metrics. Graded on the real state of the project (versioned files, lock, data fingerprint, metrics), never on the commands typed.
dsoxlab start m1-projet-reproductible -
Guided lab 40m · beginner · shell
Get back the exact version of a dataset
The dataset was regenerated last week and nobody kept the previous one: the model trained on it can no longer be rebuilt. Put the data under DVC with an S3 remote (Garage), keep two versions, and prove a clean clone gets the exact bytes back, in any version. Graded on the Git repository, the bucket content and file fingerprints, never on the commands typed.
dsoxlab start m1-dvc-donnees -
Guided lab 40m · intermediate · shell
Replay a training with a DVC pipeline
Data generation and training are two scripts run by hand, in an order nobody wrote down. Describe them as a DVC pipeline, replay it on a clean clone and get the same metrics, then check that changing one parameter only replays the stage it touches. Graded on dvc.yaml, the bucket, the metrics and what DVC really reruns, never on the commands typed.
dsoxlab start m1-dvc-pipeline -
Guided lab 40m · intermediate · shell
Find which run produced a model with an MLflow server
A training script keeps no trace of its attempts. Plug it into an MLflow server backed by PostgreSQL and the S3 bucket of the stack, log parameters, metrics, the model, the Git commit and the data fingerprint, then find the run that produced the model of a given version. Graded on the runs stored on the server, the model files in the bucket and the rows in PostgreSQL, never on the commands typed.
dsoxlab start m1-mlflow-serveur -
Guided lab 35m · intermediate · shell
Designate a model by alias in the MLflow registry
Two trainings leave two models identified by opaque ids. Register them in the MLflow registry, point the aliases champion and challenger at the right versions, then load a model by alias with no path in the code. Graded on the versions and aliases held by the server, their lineage back to the runs, and a script that really loads the model, never on the commands typed.
dsoxlab start m1-registre-alias -
Guided lab 40m · intermediate · shell
Refuse a worse model and broken data with pytest
A model is promoted because its metric looks fine, on data nobody checked. Write a pytest suite that checks the data (schema, bounds) and the model (a metric threshold read from a versioned file, a comparison with the champion), and that fails on a broken dataset and on a worse model. Graded by replaying your suite on datasets and models the check builds itself, never on the commands typed.
dsoxlab start m1-tests-modele
Level exams
1
-
Challenge pass 70% 45m · intermediate · shell
Exam: make a model reproducible and traceable
You receive the starting repository of the thread: a data generator, a training script and its parameters, and nothing else. Deliver a model anyone can rebuild and trace: versioned data in the S3 store, a pipeline that replays to the same metric on a fresh clone, a run on the MLflow server that carries the commit and the data fingerprint, the model registered with the alias challenger, and a pytest suite that refuses the two broken datasets provided, a model above the metric threshold and a candidate worse than the champion. Graded as a black box on the state of the repository and of the servers, without hints.
dsoxlab start e1-reproduire
No lab matches this search.