An enterprise lab you cannot actually build, and what to build instead

This lesson maps to no CAS-005 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.4, 1.7, 2.1, 2.4, 2.5, 3.1, 3.2, 3.4, 4.1 and 4.3 all need somewhere to run — and on this exam, unlike every other one in this series, the thing being examined is an organisation rather than a machine.

Why this matters

Every earlier course in this library had a lab you could actually build. Linux+ needs two virtual machines. Network+ needs three and a switch you can simulate. Cloud+ needs a free-tier account and a spending alarm. In each case the lab is a smaller copy of the real thing, and the skills transfer directly.

SecurityX breaks that. Its subject is an enterprise: multiple sites, multiple cloud providers, an identity provider, thousands of assets, a configuration management database, a risk register, third-party suppliers, an audit programme, and a security operations centre watching all of it. You cannot build that at home, you cannot rent it, and no amount of enthusiasm closes the gap. A candidate who tries will spend six weeks assembling infrastructure and learn very little that the exam asks about.

The honest response is to change what the lab is for. This exam tests judgement about design and governance far more than it tests configuration. Roughly half of domain 1 is assessed on paper — documents, registers, matrices, assessments — and paper costs nothing to produce. So the lab here has two halves: a small technical environment that is just big enough to make architectural questions concrete, and a set of written artefacts that are the real deliverable.

There is a second reason to read this lesson even if you never build anything. The artefacts below are the ones a scenario question will describe. Having written a risk register yourself is the difference between recognising a well-formed risk entry and guessing.

The lesson

Why this exam's environment is an organisation, not a machine, and cannot be reproduced

Read the four domains and ask what each one's questions actually operate on.

Governance, risk and compliance operates on an organisation: its documents, its risk appetite, its suppliers, its obligations. Security architecture operates on an estate: several environments, the boundaries between them, and the decisions that put a workload on one side or the other. Security engineering is closest to something you can touch, but even there the questions are about programmes — automating patching across thousands of hosts, running vulnerability management as a process. Security operations operates on a stream of telemetry produced by all of it.

None of those has a meaningful single-machine version. You can install a SIEM, but a SIEM with two log sources cannot teach you correlation, tuning or baselining, which are the things domain 4 examines. You can write a firewall rule, but the exam is not asking about the rule; it is asking whether segmentation or microsegmentation is the right answer for a described estate.

So the trap is a lab that is technically impressive and pedagogically empty: a rack of virtual machines that lets you practise administration while the exam asks about architecture. Recognising that early is worth more than any particular tool choice.

A minimum technical lab: an identity provider, two segments, a log collector, one cloud account

What is worth building is the smallest environment in which architectural questions stop being abstract. Four components do most of the work.

• An identity provider. One directory that other things authenticate against, with at least two user accounts and two groups. Almost every domain 2 concept — federation, workload identity, zero trust, conditional access — becomes concrete the moment there is a real identity to reason about, and remains vague forever if there is not.
• Two network segments with a policy point between them. Two virtual networks and a firewall or router you control is enough to make segmentation, east-west traffic and trust boundaries real. You do not need a third.
• A log collector. Any SIEM or log platform with a free tier, receiving from the identity provider, the firewall and one host. Three sources is enough to practise parsing, normalisation and a correlation rule that joins on a username. It is not enough to practise baselining, and you should know that rather than pretend otherwise.
• One cloud account on a free tier, used for exactly the things that only exist in cloud: a shared responsibility boundary you can point at, an identity-based policy, an object store you can misconfigure deliberately and then detect.

Everything else — containers, a pipeline, a certificate authority — can be added when the lesson that needs it arrives, and torn down afterwards.

Two constraints are worth stating up front. Keep it destroyable: if rebuilding the whole lab is more than an afternoon, you will avoid experiments that might break it, and experiments that might break it are the ones worth running. And keep it free: use community editions, free tiers and developer licences deliberately, and if a component only exists behind a recurring cost, substitute or skip it. Nothing in CAS-005 requires a specific vendor, because the exam is vendor-neutral by design.

The paper half: a policy set, a risk register, a CMDB extract and a control matrix you write yourself

This is the part most candidates skip and the part that maps most directly onto the exam. Four artefacts, each producible in an evening.

A minimal policy set. One information security policy of two pages, two standards beneath it — one for cryptography, one for logging — and one procedure. Write them for your own lab estate, not for an imaginary company. The exercise that teaches is deciding what goes in which, which is exactly what lesson one examines.

A risk register. Ten rows covering your lab, each with an asset, a threat, a current control, an impact, a likelihood, an owner and a treatment decision. Ten rows is enough to discover that writing "medium" in two columns tells you nothing, which is the discovery that makes quantitative assessment worth learning.

A CMDB extract. A single table of every asset in the lab: identifier, owner, classification, environment, lifecycle state. Then run a discovery scan and compare. The difference between what you thought you had and what is there is the lesson, and it reproduces at any scale.

A control matrix. One spreadsheet mapping each control you have implemented to the framework clauses it satisfies, across two frameworks. This is the single most transferable artefact on the list: it is what a GRC platform automates, it is what an auditor asks for, and building one by hand is what makes the automation comprehensible.

Keep all four in version control alongside the lab configuration. Watching a policy document acquire a commit history is a surprisingly effective way to internalise why review cycles exist.

Using published free tiers and community editions so the whole lab costs nothing recurring

The lab described above can be assembled without recurring cost, but only if that is a design goal from the start rather than a hope.

Identity, log collection and cloud all have genuine free tiers, and each has a limit that matters: identity tiers cap conditional-access features, log platforms cap daily ingest volume, cloud free tiers cap hours and expire. Record the limit next to each component when you build it, because hitting one silently is indistinguishable from a misconfiguration — a SIEM that stopped ingesting at its daily cap looks exactly like a broken forwarder.

Three habits carried over from the Cloud+ lab lesson apply unchanged, and they are cheap insurance. Set a spending alarm and a hard cap on the cloud account before creating a single resource. Tag everything with a lab identifier from the first minute, because you cannot delete what you cannot find. And treat teardown as part of every exercise: if a component cannot be destroyed with one command or one click, it is not lab infrastructure, it is a pet.

For the virtual machines themselves, hypervisor and container runtime choices are genuinely interchangeable for this course. Pick what your hardware runs best and move on — time spent choosing is time not spent on domain 3.

Working the lab as a role: every later lesson has you act as the architect, not the administrator

The last piece is a habit rather than a component, and it changes what the lab teaches.

For each applied exercise in this course, do the work in the role the exam assumes: someone who decides, documents and justifies, rather than someone who configures. Concretely, that means every exercise ends with a written artefact — a decision record naming the options considered and why one was chosen, an update to the risk register, a new row in the control matrix, or an amendment to a standard.

This sounds like overhead and is the highest-yield part of the lab. CAS-005 scenarios overwhelmingly present a situation and ask which response is most appropriate, with two or three technically workable options. Answering those well is a practised skill, and the practice is exactly this: stating the options, naming the constraint that discriminates between them, and committing.

It also gives you something to revise from. Forty short decision records written in your own words, each tied to a lesson, are a far better revision artefact than a set of notes copied out of a syllabus — and they are the closest thing available to the experience the exam is written for.