The distribution and kernel are part of the material
Commands, package names and the location of configuration differ between distributions. Even within the same family of systems, a new release can bring a different version of systemd, the firewall or the kernel. The training programme should specify the exact system and version, and the base image must match the materials.
If the sessions cover general administration, you can deliberately compare two systems, but that requires separate instructions and time to discuss the differences. A random mix of Ubuntu, Debian and company systems is not such a comparison. It usually makes it harder to run the exercises and check the results.
The scope of sudo should follow from the exercises
A participant learning to work with files, processes and pipes does not need full administrator rights. When managing services, packages, users or network rules, access through sudo becomes part of the task. You can grant full privileges on a private VM or restrict them to specific commands.
Each person should work on their own account. A shared user makes it harder to analyse command history, file permissions and processes. Separate workstations also prevent a situation where one person changing the firewall or removing a package stops the whole group's work.
An exercise should link a command to an observable state
An instruction to “start the service” is more valuable when the participant checks the process, the port, the log and the behaviour after a restart. The same goes for permissions: changing a file's mode should lead to an access attempt from another account, rather than ending with the output of chmod.
Useful scenarios include diagnosing a service that is not working, analysing disk usage, working with logs, configuring a scheduled job and restricting access to a directory. Each of them has an initial state, a symptom, sources of information and a criterion for the fix. The participant learns to connect pieces of information instead of memorising individual commands.
The lab network should be predictable
Exercises on DNS, routing, SSH or the firewall require an explicit topology. Addresses, host names and permitted connections should stay fixed for the duration of the sessions. If the participant is going to change network rules, they must be able to restore access from a panel or a console that does not depend on the interface being configured.
Internet traffic can be limited to package repositories and documentation. Not every workshop needs open outbound access. A local mirror or package cache improves repeatability and reduces the impact of the connection, especially when the whole group installs the same dependencies at the same moment.
Logs and system time must work before the start
Diagnosis relies on chronology, so the machines should have synchronised time. The material must match the way the system records logs, for example in the systemd journal or in traditional files. The participant should know where to look for a service's messages and how to narrow them down to the right period.
Do not prepare perfectly clean logs with a single error. A realistic system contains informational messages and events unrelated to the task. At the same time, the noise must not be so great that the solution depends on guessing the author's intentions.
A snapshot leaves room for bolder attempts
Changing the boot configuration, firewall rules or the partition table can make further connection impossible. On a private VM, this is a controlled part of learning, provided there is a proven way to recover. A snapshot before a risky stage, or recreating the machine from the base image, shortens the way back to the session.
A reset should not replace diagnosis. First, the participant gathers information, describes the cause and proposes a fix. Restoring the state is appropriate when the fix goes beyond the scope, or when the workstation needs to start the next exercise from an identical point.
Ready-made VMs separate learning the system from the company device
The participant's laptop can be used solely to connect through a browser or SSH. The tools, services and permissions are in the lab, so the training does not require changing local system policies. The instructor can check the image once and then replicate it for the group.
The approach described here corresponds to the model of virtual machines for IT training. Parameters, access and administrative scope are chosen to fit the programme. The goal is not maximum freedom for its own sake, but a safe place where the effects of commands are real and reversible.