The technical brief should follow from the workshop programme
A list of tools is only the beginning. For each exercise you need to specify the operating system, the exact runtime and library versions, the services, data, permissions and how the result will be confirmed. The order of the stages matters too, because it affects the state left behind on the machine.
The brief covers the number of participants, the date, the access period, the connection method, network requirements and how materials will be delivered. If the environment includes several nodes or a shared service, the topology should be described separately. Any ambiguity at this stage comes back later as a gap between what the instructor expected and the configuration that was built.
The base image must pass a test run from a participant account
The operating system, tools and starting data are installed on a single VM. The instructor runs through all the material, but should do so with ordinary user permissions. An administrator account may hide problems with a directory, a port, a token or access to a service.
The test also covers restarting the machine and its services. A configuration that only works in the session of the person who built the image is not ready to be replicated. Once accepted, the image is given a version number, and only then are the group's workstations created.
A separate VM stops participants affecting one another
Each person can change files, packages, processes and local data without disrupting anyone else's work. This matters for administration, containers, databases and application testing. Shared components such as a registry, a Git repository or a materials server should have their own access rules and planned capacity.
Not every scenario needs a full VM per person. A shared cluster with separate namespaces may be enough for selected Kubernetes exercises, and separate schemas for learning SQL. You do, however, need to state explicitly which resources remain shared and what a participant must not change.
Browser access reduces local requirements
A graphical desktop can run over HTTPS in an up-to-date browser. The participant does not install a remote desktop client or any training tools on their laptop. For terminal-based sessions, SSH is the alternative. Both methods lead to resources running in the cloud.
Before the session, you need to check the connection from the target network, the keyboard layout, clipboard behaviour and signing in again after a break. A corporate proxy or address filtering may need to be agreed in advance. It is best to discover this during a short participant test, not in the first minutes of the workshop.
Materials should be available on the workstation
The repository, data files and instructions can be placed in the image or in a shared directory. The originals stay read-only, and results go into private directories. The participant does not have to move attachments from their local e-mail into the remote session.
The version of the materials should match the version of the image. If a starting file changes after the instructor's test, the scenario needs to be checked again. Exercise data should not come straight from production unless the company has carried out a proper anonymisation process and approved its use.
The dress rehearsal also covers failure
Besides the main path, it is worth stopping a service, dropping a session and restoring a selected VM. The instructor checks what information is needed for diagnosis and how long it takes to get back to work. The instructor panel can show the status of workstations and make it possible to help, but the procedure must also be understandable without it.
A reset should restore a known state without changing the other participants' machines. A snapshot is useful for system-level changes, and a versioned bootstrap for recreating services and data. The method you choose depends on what the participant is allowed to modify.
A temporary environment needs an exit plan
Before the end, participants export their code, reports or configuration. The organiser revokes temporary accounts and decides which materials should remain available. After the agreed date, the machines are shut down and the data deleted according to the agreed rule.
The environment preparation process at Klasa w chmurze covers the specification, building the base configuration, handing over access and shutting everything down after the booking period. In the scenarios you can compare topologies for Kubernetes, Docker, databases, automation, testing and application development.