A machine you can safely break, and how to get it back

This lesson maps to no 220-1202 objective. CompTIA does not examine "build a lab", and nothing in it will be asked of you. It exists because the labs attached to objectives 1.1, 1.2, 1.3, 2.1, 2.2, 3.1, 3.3 and 4.3 all ask you to do something to a machine that a machine in use should never have done to it — repartition it, break its bootloader, change its permissions until sharing stops working, or let something hostile run on it. It also states this course's safety rules once, in one place, so that every later lab can point at them instead of restating half of them.

Why this matters

Every other course in this library opens by telling you to build a virtual machine, and this one does too — but for the opposite reason to the course that sits beside it.

Core 1 is the hardware exam, and its constraint is that its faults cannot be virtualised: you cannot simulate a sagging power supply or a bent pin. Core 2 inverts that completely. Almost everything here runs perfectly well in a virtual machine, which is exactly the danger. The work in this course involves deliberately breaking an operating system, deliberately misconfiguring permissions, and deliberately letting something suspicious run — and every one of those is fine on a machine nobody needs and catastrophic on the machine holding your coursework.

So this lesson is about the disposable machine, the snapshot that makes a mistake free, the isolation that keeps an experiment inside the box, and the rules about test samples that this course will not bend.

The lesson

Why this course needs a disposable machine and Core 1 needed a bench

The distinction is worth making precisely, because it decides what each lab in this course is allowed to ask of you.

Core 1's labs need parts. A multimeter reading, a cable that charges but does not carry data, the feel of seating memory correctly — none of that exists inside a hypervisor, so that course is built around a bench and a retired desktop.

This course needs the opposite: a full, ordinary, expendable operating system installation. You need to be able to delete a partition, corrupt a boot configuration, deny yourself access to your own folder, install something questionable, and then have all of it be as though it never happened. A physical machine can do that, but each cycle costs an hour of reinstallation. A virtual machine does it in fifteen seconds.

What you need, concretely, is one host machine with enough memory to run a guest — 8 GB is workable and 16 GB is comfortable — a hypervisor, and installation media. Everything else in this course is a setting.

The one exception worth flagging now: mobile work in objectives 3.2 and 3.3 genuinely wants a phone, and a phone cannot be snapshotted. That is why the lesson on provisioning and resets has no hands-on lab attached to it, and why its applied lab asks you to plan a reset rather than perform one.

Snapshots, checkpoints and the restore that makes an experiment repeatable

A snapshot is the single most important feature of a hypervisor for study purposes, and it changes what you are willing to try.

The pattern that makes this course work:

1. Build the guest, install the operating system, apply updates, install the tools you use. This is the expensive hour and you do it once.
2. Shut the guest down cleanly and take a snapshot. Name it something honest — clean-baseline-after-updates, not snapshot1.
3. Do the experiment. Break whatever the lab asks you to break.
4. Revert to the snapshot. The guest returns to step 2 exactly, in seconds.

Two practical notes. Take snapshots powered off where you can: a snapshot of a running machine also captures memory, which makes it larger and slower to revert, and for study purposes you want the clean cold start anyway. And treat snapshots as scaffolding rather than storage — a chain of thirty snapshots on a laptop's disk performs badly and is easy to get lost in. Two or three named points is plenty.

This is also the place to say plainly what a snapshot is not. It is not a backup. It lives on the same disk, in the same file set, under the same host; a failed drive or a deleted virtual machine takes every snapshot with it. That distinction comes back as an examinable point in the backup objective, and it is easier to remember once you have relied on one.

Network isolation: host-only networking, and what still leaks out of it

Some of the work in this course involves software you would rather not have talking to your network. The control is isolation, and it is worth understanding what each network mode actually does.

• NAT — the guest reaches the internet through the host. Convenient, and the wrong choice for anything you distrust, because outbound access is exactly what a hostile program wants.
• Bridged — the guest appears on your real network as its own device. This is the most exposed mode and the one to avoid for this kind of work.
• Host-only — the guest can talk to the host and to other guests on the same host-only network, and to nothing else. This is the mode for experiments.
• Internal / isolated — like host-only, but without the host either. Two guests can talk to each other and nothing else, which is useful for practising the networking side of the security objectives.

What still leaks out of host-only is worth stating honestly, because "isolated" is a word that invites over-confidence. Shared folders, drag-and-drop, the clipboard and USB pass-through all cross the boundary and are usually enabled by default. Turn them off before the guest does anything you do not trust. The hypervisor itself is software with vulnerabilities, so isolation is a strong control and not a perfect one — which is the argument for the next section's rule rather than an argument against isolation.

Handling test samples safely: EICAR, never live malware, and why the rule holds

This course will not ask you to handle live malicious software, and if any lab in it appears to, the lab has a mistake in it.

The reason is not squeamishness. Handling a real sample safely requires controls that do not exist on a home machine: a dedicated host, a network that is physically separate, and a way of destroying the environment afterwards that does not depend on the environment being honest about its own state. A home hypervisor on a working laptop is not that, and a course that told beginners otherwise would be teaching an unsafe habit at the exact moment they are most likely to trust it.

What the labs use instead:

• The EICAR test file. A short, published, completely harmless string that every antivirus product is required to detect. It proves your protection is running and that its alerting works, which is what the lab is actually about. It does nothing at all if nothing scans it.
• Simulated symptoms. A startup entry you created, a scheduled task you wrote, a browser extension you installed yourself. The removal procedure is identical, and it is the procedure being examined.
• Written scenarios. For anything whose realistic version would be dangerous or unlawful, the lab describes the situation and asks for your decision and your reasoning, which is what the exam does too.

The rule in one line: never obtain, download or run real malicious software to study it. There is nothing in this exam that requires it, and the first professional instinct the security objectives teach is that the technician who finds something hostile stops and reports rather than investigates.

The safety rules this course assumes from here, stated once in one place

These are stated once here and referred to from every lab after. They are short, and none of them is optional.

• Never experiment on a machine that holds anything you need. Not your coursework machine, not the family computer, not a work laptop. If the only machine available is one that matters, the answer is a virtual machine on it, not a careful attitude.
• Snapshot before, revert after. An experiment you cannot undo is not an experiment, it is a change.
• Isolate anything you do not trust, and turn off shared folders, the clipboard and USB pass-through before you start.
• No live malicious software, ever, for the reasons above.
• Back up before anything destructive on real hardware — repartitioning, a clean installation, a firmware update. The backup objective at the end of this course explains how to do that properly; until then, copy the files somewhere else and check you can open them.
• Do not test on other people's data. Permissions and encryption labs use files you created. A lab that involved somebody else's documents would be teaching a habit that ends careers.
• Write down what you changed. Every lab asks for this, and the reason is the operational procedures objective: a change you cannot describe is a change you cannot reverse.

Where a lab in this course involves any of the above, its Environment section says so explicitly, and a lab that asks you to do something these rules forbid is a lab with a mistake in it.