Expected measurement table: voltage readings should fall within ±2% of the supply setting (5V, 9V, 12V). Measured resistances should fall within the tolerance indicated by the colour code (typically ±5% for a gold 4th band).

Expected calculation for step 5: if the circuit uses a 220Ω resistor powered at 9V, the theoretical expected current is I = U/R = 9/220 ≈ 0.041 A (41 mA). The deviation between the calculated resistance (R = measured U / measured I) and the resistance shown directly by the multimeter should remain below 5%.

Sources of error to mention: internal resistance of the multimeter in ammeter mode, resistor tolerance itself, contact quality on the breadboard, drift of the lab supply if unregulated.

Example dataset (to adapt to the actually distributed datasheets): 5 server models with rated powers of 350W, 450W, 550W, 650W and 800W. For 2 units of each (10 servers): total power = 2 × (350+450+550+650+800) = 2 × 2800 = 5600 W = 5.6 kW.

Conversion to kVA: S = P / cos φ = 5.6 / 0.95 ≈ 5.89 kVA.

Comparison with the PDU (3.68 kVA): a single 3.68 kVA PDU is insufficient. At least 2 PDUs are required (5.89 / 3.68 ≈ 1.6, rounded up to 2 for capacity, which also conveniently provides redundancy).

With a 20% safety margin: load to cover = 5.89 × 1.2 ≈ 7.07 kVA, confirming the need for 2 PDUs and prompting a check of balanced load distribution between them.

Method for calculating available three-phase capacity: P = U × I × √3 × cos φ = 400 × 63 × 1.732 × 0.95 ≈ 41.4 kVA available on the site's incoming supply.

Example distribution (to adapt to the provided dataset): if each rack requires about 6 kVA after the safety margin (consistent with Exercise 2), 3 racks represent about 18 kVA — comfortably within the 41.4 kVA available, leaving a healthy margin for future expansion.

Expected sizing sheet: a table with one row per rack (active power, apparent power, required PDUs), a total row, and an explicit conclusion on compatibility with the site's incoming supply and the remaining margin for future growth.

Example decimal-to-binary conversion (156): 156÷2=78 remainder 0; 78÷2=39 remainder 0; 39÷2=19 remainder 1; 19÷2=9 remainder 1; 9÷2=4 remainder 1; 4÷2=2 remainder 0; 2÷2=1 remainder 0; 1÷2=0 remainder 1. Reading the remainders bottom to top: 10011100.

Verification: 10011100 = 128+16+8+4 = 156. ✓

Example decimal-to-hexadecimal conversion (500): 500÷16=31 remainder 4; 31÷16=1 remainder 15(F); 1÷16=0 remainder 1. Reading bottom to top: 0x1F4.

Example binary addition (1011 + 0110): column by column from right to left with carry: 1+0=1; 1+1=10 (write 0, carry 1); 0+1+1(carry)=10 (write 0, carry 1); 1+0+1(carry)=10 (write 0, carry 1) → result 10001 (=17 in decimal, verification: 11+6=17 ✓).

Full example — address 192.168.1.10 / 24:

Binary conversion: 192=11000000, 168=10101000, 1=00000001, 10=00001010.
Mask /24 = 11111111.11111111.11111111.00000000 = 255.255.255.0.

Network address (logical AND of address/mask): 192.168.1.0.
Broadcast address: 192.168.1.255.
Number of usable addresses: 2^8 - 2 = 254 addresses (256 possible, minus the network address and the broadcast address).

Example with a /28 mask: 2^4 - 2 = 14 usable addresses only, which concretely illustrates the direct impact of the mask choice on subnet size — an essential point for the DHCP module later in the programme.

Example — breaking down #1A5FA8: 1A (hex) = 26 (decimal), 5F (hex) = 95 (decimal), A8 (hex) = 168 (decimal). RGB(26, 95, 168) — a deep blue commonly used in technical brand guidelines.

Example — reconstructing from RGB(212, 175, 55): 212 → D4 (hex), 175 → AF (hex), 55 → 37 (hex). Final code: #D4AF37 (a gold colour).

Example function to simplify: F = A.B + A.NOT(B) + NOT(A).B

Via Boolean algebra: A.B + A.NOT(B) = A.(B+NOT(B)) = A.1 = A. So F = A + NOT(A).B. By distributivity: A + NOT(A).B = (A+NOT(A)).(A+B) = 1.(A+B) = A + B.

Via Karnaugh map (2 variables A, B): the 3 cells equal to 1 (AB=11, AB=10, AB=01) form a grouping that reads directly as A + B — an identical result, validating the method both ways.

Teaching point to emphasise: the Karnaugh map becomes notably faster than Boolean algebra as soon as the number of variables increases (3 or 4 variables) — this is why it is favoured in industrial practice.

Truth table: H=0,S=0 → FA=1 (not peak hour, no vehicle on B, A stays green by default); H=0,S=1 → FA=0 (not peak hour BUT a vehicle is detected on B, so we yield); H=1,S=0 → FA=1; H=1,S=1 → FA=1 (absolute priority to A during peak hour, even with a vehicle on B).

Simplified function: FA = H + NOT(S), which literally reads as "light A is green if it is peak hour, or if no vehicle is detected on B".

Logic diagram: an OR gate with H as a direct input and NOT(S) (so a NOT inverter upstream on signal S), output FA.

Physical build: 1 inverter (74LS04) to generate NOT(S), 1 OR gate (74LS32) to combine H and NOT(S). Simple wiring using 2 integrated circuits, validated by testing all 4 switch combinations and observing the output LED.

Expected validation grid: the 4 tested combinations must give exactly the results from the Exercise 2 truth table (FA=1,0,1,1 for H,S = 00,01,10,11). Any discrepancy should be explained by a wiring or component fault, never by a logic error if the Exercise 2 simplification was correctly validated.

Most common faults to anticipate: a reversed power pin on the integrated circuit (Vcc/GND), a missing or miscalibrated LED protection resistor, a poor breadboard contact.

Expected program for step 3 (button → LED): in the loop() function, read the button pin's state with digitalRead(), then use a structure such as if (buttonState == HIGH) { digitalWrite(ledPin, HIGH); } else { digitalWrite(ledPin, LOW); }.

Expected program for step 5 (sensor → automatic LED): read the sensor value with analogRead() (a value between 0 and 1023), then compare it to a threshold (e.g. 400) with if (sensorValue < 400) { digitalWrite(ledPin, HIGH); }.

Marking point: check that each pair correctly identified the direction of the sensor's variation (value increasing or decreasing with darkness, which depends on the voltage-divider wiring used).

Expected justification for step 1: an Arduino pin typically supplies a maximum current of 20-40 mA, insufficient for most DC motors, which require several hundred mA. The relay allows a low driving current to control a fully electrically separate power circuit.

Expected program for step 4: a structure similar to Exercise 1 (sensor reading + condition + action), but using digitalWrite() on the relay pin instead of an LED — demonstrating that the same programming logic applies to any actuator.

Specification validation checklist: the list of inputs/outputs must be complete and unambiguous (each sensor and actuator has a clearly defined role), the transition conditions must cover all cases (including failure cases), and the wiring diagram must be consistent with the Arduino pins actually available.

Common mistake to correct: forgetting to specify behaviour on failure or timeout (for example, what happens if the keypad sequence is never completed?). This is an opportunity to recall that the Week 3 truth table must cover ALL possible combinations, not just the success case.

Criterion 1 — Functional compliance (40%): does the system meet the full brief, including failure cases?

Criterion 2 — Wiring and integration quality (20%): clean build, reliable connections, no loose contact during the demonstration.

Criterion 3 — Code quality (20%): readable, commented, structured code (no unnecessary repetition, clear variable names).

Criterion 4 — Documentation and oral presentation (20%): ability to clearly explain technical choices and difficulties encountered.

Reassembly check grid: the workstation must boot without an error beep (or with the normal sequence beep depending on the motherboard), the BIOS/UEFI must display the correct amount of RAM and the expected CPU model, storage must be detected.

Common faults to anticipate and their diagnosis: no boot = check the main power connector and the CPU connector on the motherboard; RAM not detected = check that the modules are properly seated in the DIMM slots; repeated boot beep = usually a poorly seated RAM module (check the manufacturer's beep code in the motherboard's documentation).

Expected compatibility checks: the CPU socket must exactly match the motherboard's, the RAM type and frequency must be supported by the motherboard (verifiable in its documentation), the CPU power connector (often 4 or 8 pins) must be present on the supplied power supply.

Expected estimated power calculation: sum the typical consumptions (CPU ~65-95W, motherboard and peripherals ~30-50W, storage ~5-10W per drive) and check the total stays below 70-80% of the power supply's rated capacity, in line with the safety margin covered in Week 1.

Critical safety check before any operation: ask each pair to explicitly confirm, before any destructive command, the exact identifier of the test disk (e.g. /dev/sdb, not /dev/sda which could potentially hold the system). This is the most dangerous possible mistake at this stage of training.

Expected result after formatting: each partition should appear mounted with the requested filesystem (verifiable with the mount command or lsblk -f), and the total space across the 3 partitions should match the disk size minus a small overhead from each filesystem's metadata.

Expected dd command (example): dd if=/dev/sdb of=/mnt/external/disk_image.img bs=4M status=progress — the bs=4M option speeds up the transfer compared to the default block size, and status=progress allows tracking the operation's progress, an important point to highlight for large images.

Restore validation: after restoring, compare the checksum (md5sum or sha256sum) of the restored disk with that of the source image — an exact match validates a bit-for-bit restoration.

Central teaching point of this week: stress that a disk image is only useful if it has been tested through a restore at least once — a backup that has never been restored is not a reliable backup, it is merely an assumption.

Partitioning check points: the root partition (/) must have enough space for the system and applications (typically a minimum of 20 GB for training use), a swap partition is recommended even with a comfortable amount of RAM, for handling hibernation and load spikes.

Expected network check: after installation, the distribution's appropriate network diagnostic command should show an active interface with an IP address consistent with the classroom's network.

Methodological note: the exact names of package management commands (apt, dnf, pacman depending on the distribution) must be adapted by the instructor to the distribution actually used in class.

Example permission to decode: rwxr-xr-- reads as owner=read/write/execute (rwx=7 in octal), group=read/execute (r-x=5), others=read only (r--=4), giving chmod 754 — a direct and explicit link with the octal conversion covered in Week 2.

Expected example of chained commands: a command combining file search, content filtering and redirection to a results file, explaining the role of each successive pipe.

Expected structure of the custom unit file: a [Unit] section describing the service, a [Service] section specifying the command to run and the service type, an [Install] section specifying the desired automatic startup level.

Expected diagnosis method for the induced failure exercise: check the service's status to see the error code, then check the service's detailed logs to identify the precise error message, which should point directly to the cause of the introduced fault.

Expected check for the shared folder: the group's members should have read/write access, other users none — practical test by logging in with an account outside the group to confirm access is denied.

Expected diagram for the write-up: a simple table or diagram cross-referencing users, group membership, and effective permissions on each folder created during the exercise.

Expected structure of the backup script: a shebang on the first line, a variable defining the source folder and the destination folder, a conditional check for the source folder's existence, a compression command with a timestamp in the generated file's name, a confirmation or error message in the output.

Point of attention for cron scheduling: check that the script has the necessary execution permissions and that the paths used in the script are absolute (cron does not run within the same directory context as an interactive session).

Expected structure of the monitoring script: retrieving the current value (disk percentage, CPU load, memory usage) via the appropriate system commands, comparing it against a threshold defined as a variable, writing a timestamped alert line to a dedicated log file if the threshold is exceeded.

Central teaching point: stress that this basic script-based monitoring approach is a pedagogical starting point — in a real production environment, dedicated monitoring tools (to be chosen based on what is maintained and relevant at the time of teaching) offer far more comprehensive features (history, dashboards, multi-channel alerts).

Checking IIS installation: open a browser on the same machine and navigate to http://localhost — the IIS welcome page should appear, confirming the role is active and the service is listening on port 80.

Expected PowerShell commands: Get-Service to list services, Stop-Service and Start-Service (or Restart-Service) with the IIS service name to restart it. Point out the consistency with the service management covered in Week 9 under Linux (systemctl) — same concept, different syntax.

Central teaching point: stress the conceptual consistency between Linux and Windows — service management, automation scripts, output redirection — so trainees see both systems as two implementations of the same conceptual model, not two incompatible worlds.

Expected PowerShell script structure: same logic as the Week 10 shell script (variable, condition, action, message), simply with PowerShell syntax (cmdlets, named parameters, basic error handling with try/catch).

Expected NTFS permissions check: use the Security tab in a folder's properties to display a given account's effective permissions — the "effective permission" takes into account inheritance and group membership, not just explicitly visible first-level permissions.

Expected Security log trace: denied access attempts generate an event with a specific ID (to be identified on the version in use) in the Security log — this exercise anchors the importance of logs for security diagnosis and auditing.

Suggested problems for the diagnosis exercise: missing NTFS permission for a group (observable with Get-Acl); share permission more restrictive than the NTFS permission (effective permission is always the most restrictive of the two); misconfigured service with an unsatisfied dependency (visible in the System log).

Post-installation hypervisor check: the web interface should be accessible from a client machine via the IP address configured during installation, on the default port. The node should appear as operational in the dashboard.

Snapshot restore verification: the deleted file should be present again after restoring — this is the concrete demonstration that the snapshot captured the state prior to the deletion. Stress the difference from an external backup: if the hypervisor itself fails, the snapshot becomes inaccessible.

Expected overcommitment result: with light overcommitment (10-20% beyond physical RAM), the hypervisor uses memory ballooning or swap — VMs keep running but with measurable performance degradation. With heavy overcommitment, the risk of VM crashes increases sharply.

Clone verification: both instances must have different identifiers (IP if DHCP, hostname if reconfigured) — an unreconfigured clone can cause network conflicts, an important point to highlight.

Expected failover test results: the node failure detection delay is typically a few seconds to a few minutes depending on the cluster configuration (heartbeat timeout). The VM must restart automatically on the surviving node, with an effective RTO corresponding to this detection delay plus the VM's boot time.

Teaching point on RPO: in a failure scenario without shared storage, data not saved since the last snapshot or backup is lost — the RPO is directly tied to backup frequency, not to HA configuration alone.

Expected backup plan: the document must explicitly state the RPO (what is the maximum data loss if a restore is needed, based on backup frequency), the RTO (how long a full restore takes, measured during the exercise), and the total backup retention duration.

Critical point of caution: before disabling password authentication, always verify that key-based login works from a separate open session — if the key is misconfigured and the active session is closed, the server becomes locked out. This is the most common and most costly mistake at this stage.

Expected audit result: a clear list distinguishing necessary services (keep), useful but non-critical services (evaluate), and unnecessary services (disable) based on the server's expected role.

Expected comparison table: SSH Linux ↔ RDP/WinRM Windows (secure remote access), iptables/nftables Linux ↔ Windows Defender Firewall (network filtering), apt/dnf Linux ↔ Windows Update (updates), journalctl Linux ↔ Event Viewer Windows (logs) — the logic is identical in both cases.

Criterion 1 — Functional compliance (35%): all specification items are deployed and operational.

Criterion 2 — Security (25%): hardening effectively applied, firewall correctly configured, no unnecessary service open.

Criterion 3 — Service continuity (20%): automated backups operational, restoration tested and documented, realistic RPO/RTO.

Criterion 4 — Documentation and presentation (20%): clear and complete document, controlled live demonstration, ability to explain technical choices.

Sample questions to assess genuine understanding: "If this server was attacked tonight and your SSH was compromised, what would your first action be?"; "Your daily backup has been silently failing for 3 days — how do you detect it?"; "Your Linux VM is suddenly consuming 100% CPU — how do you diagnose it?"

Discriminating criterion between memorisation and understanding: a trainee who understands can answer an unfamiliar situation by reasoning from principles. A trainee who has memorised can only answer situations already encountered in exactly the same form.

Example subnetting (/24 divided into 4 /26 subnets):
Subnet 1: 192.168.10.0/26 (hosts .1 to .62, broadcast .63)
Subnet 2: 192.168.10.64/26 (hosts .65 to .126, broadcast .127)
Subnet 3: 192.168.10.128/26 (hosts .129 to .190, broadcast .191)
Subnet 4: 192.168.10.192/26 (hosts .193 to .254, broadcast .255)

Expected layer-by-layer diagnosis method: layer 1 (physical cable/connector), layer 2 (ARP table, MAC address), layer 3 (ping, IP address, mask, gateway), layer 4 (netstat/ss, port open or not).

Expected diagram: the path of an HTTP packet should show the 4 layers active in practice (HTTP Application → TCP Transport → IP Network → Ethernet Data Link), with the corresponding addresses and ports at each layer, and the transformation into a physical signal at the cable level.

Expected segmentation result: machines in VLAN 10 can ping each other, but a ping from a VLAN 10 machine to a VLAN 20 machine must fail — VLAN segmentation correctly isolates groups at layer 2.

Common mistake: trunk port not correctly configured between the two switches (forgetting to allow the VLANs on the trunk) — results in a machine being able to reach machines in the same VLAN on the same switch, but not those in the same VLAN on the remote switch.

Key teaching point: VLAN segmentation on the hypervisor reproduces exactly the same principles as physical segmentation on a real switch — VMs "see" their network the same way a physical machine sees its VLAN. This is the concrete demonstration that virtualising network resources (Week 13) follows exactly the same rules as the physical network.

Expected inter-VLAN configuration: the router has one sub-interface per VLAN (with the corresponding 802.1Q tag and an IP address in each VLAN subnet), the trunk port of the switch connected to the router allows all VLANs. Machines in each VLAN use the corresponding router sub-interface IP address as their gateway.

Fundamental point to anchor: on a multi-router network, the source and destination IP addresses of a packet never change throughout its journey — only the Ethernet frame's MAC addresses change at each hop (they identify the local link, not the global path). This is the central conceptual difference between layer 2 (local addressing) and layer 3 (global addressing).

DHCP relay verification: a client in VLAN 20 must receive an address from the VLAN 20 pool configured on the DHCP server, even if the DHCP server is physically in VLAN 10 — the relay forwards the Discover across the VLAN boundary.

Common mistake: forgetting to configure the gateway (routers option) in the DHCP pool — the client receives an address but cannot communicate beyond its subnet.

DHCP fields to identify in Wireshark: CHADDR = client's MAC address, yiaddr = proposed/assigned IP address, siaddr = server's IP address, option 3 = gateway, option 6 = DNS servers, option 51 = lease duration.

Working resolution check: from a client VM configured with the training DNS server, a query on an internal zone name must return the correct address, and a query on an internet name must also resolve via the forwarder.

Preparation for Active Directory: the internal zone must be configured to accept dynamic updates, which will allow the domain controller (Week 22) to automatically register its SRV records during installation.

Central teaching point of this week: by the end of this exercise, the complete infrastructure is in place — segmented VLANs (Week 18), inter-VLAN routing (Week 19), automatic address distribution with gateway and DNS via DHCP (Week 20), local and external name resolution operational (Week 21). This is the infrastructure on which Active Directory will be installed in Week 22.

Checking SRV records: in the domain's DNS zone, verify the existence of _ldap._tcp, _kerberos._tcp and _kpasswd._tcp records in the _tcp subfolder — their presence confirms the DC registered correctly and clients will be able to locate it.

Common mistake: the Windows server's DNS points to an external server instead of itself (or the Week 21 DNS server) — the DC installation fails or the SRV records are not created in the correct zone.

Teaching point on delegation: control delegation in AD applies the principle of least privilege (Week 15) at directory scale — a helpdesk can reset passwords without being a domain administrator, reducing the exposure surface if the helpdesk account is compromised.

Expected behaviour for the network drive GPO: a user in the Technical OU sees the network drive automatically mapped at login on any domain-joined machine. A user in another OU does not see this drive — the security filter or OU scope guarantees isolation.

Interpreting the gpresult report: the report lists applied GPOs (with their origin OU) and denied GPOs (with the reason for denial) — it is the first-line diagnostic tool for any GPO not being applied issue.

Expected diagnosis method: 1) check the GPO is linked to the correct OU (GPMC console), 2) check the security filter (the user's group must have Read and Apply rights), 3) force a GPO refresh on the client machine, 4) re-run gpresult to confirm.

DNS resolution check: from a client machine on the same network, resolve the site's name via the Week 21 DNS — the response must return the web server's IP address. Without this step, the browser cannot find the server by name.

Common Virtual Hosts mistake: forgetting to create a separate DNS record for each Virtual Host — both domain names must resolve to the same server IP, but each must have its own A record in the DNS zone.

Error codes and their causes: 403 Forbidden = file or directory permissions prevent the web server from reading it (check UNIX permissions, link with Week 8); 502 Bad Gateway = the backend application service (PHP-FPM or equivalent) is not running or not listening on the right socket; expired certificate = recreate the self-signed certificate or extend its validity period.

Example expected JOIN query: if the database contains a "users" table and an "orders" table linked by a foreign key, the query SELECT u.name, o.product FROM users u INNER JOIN orders o ON u.id = o.user_id returns user/order pairs — demonstrating that data from two tables can be combined without duplication.

Restore verification: compare the row count in each table before and after restoration — they must be identical.

Expected backup script: calling the DBMS dump tool with connection credentials, redirecting output to a timestamped file, cleaning up files older than 7 days — same structure as the Week 10 backup script applied here to SQL data.

Expected audit report structure: for each vulnerability — affected system, problem description, criticality level, potential impact, precise corrective recommendation. An audit report without a concrete recommendation is useless.

Typical vulnerabilities to find in the training infrastructure: SSH still on the default port if missed in Week 15, missing updates on a VM not touched for several weeks, local administrator account with a weak password on a machine not joined to the domain, database server (Week 25) with its port accessible from outside the internal network.

Criterion 1 — Architecture completeness (25%): all components are present, operational and documented — from the physical layer (Week 6) up to the application services (Weeks 24-25).

Criterion 2 — Coherence and integration (25%): components articulate logically — DNS (Week 21) feeds AD (Week 22), VLANs (Week 18) align with GPOs (Week 23), backups (Week 14) cover all critical VMs.

Criterion 3 — Applied security (25%): Week 15 and Week 26 principles are genuinely implemented, not just mentioned — the audit report proves actual verification.

Criterion 4 — Critical perspective (25%): the trainee accurately identifies what works, what is missing, and what they would do differently with more time or resources.

Discriminating questions: "If your single domain controller fails at 8am on a Monday morning, what happens to the 50 users arriving at the office?"; "Your web server now serves personal data — what are the first three security measures you would add?"; "A colleague tells you ping no longer works between two VMs — where do you start?"

What this defence validates: not memorising commands — that is available to anyone with a search engine. What it validates is the ability to reason about a complex system, identify the relevant layer, propose a structured diagnostic method, and make justified decisions under uncertainty.