Before adding a VM, explain the responsibility of the machine already in your lab, its dependencies, and the test that shows it works.
An operating-system name and memory allocation don't explain why the component belongs in the project. Its purpose should connect to the identity question you're investigating.
Establish that baseline before expanding. More infrastructure can be useful when it enables a new test, but it can also make a poorly understood environment harder to troubleshoot and harder to explain to someone reviewing your work.
Give every machine a job in the scenario
A directory server might provide identity services for a test domain. A client might let you evaluate a user's sign-in and access experience. An application server might represent the resource being accessed.
Those roles justify the machines because they enable specific observations.
“Another server would make the lab more realistic” is not enough on its own. Realism should serve the problem you're studying, not simply increase the number of boxes on the diagram.
Write one sentence describing why each component exists.
Trace one request through the environment
Choose a simple action, such as a test user opening a protected resource.
Explain which systems participate, what information they need, and where the decision to allow or deny access occurs. Separate what you know from what you still need to investigate.
You may discover that you understand the installation steps but not the dependency between name resolution, authentication, and resource access.
That discovery is useful. It gives you a focused learning task without requiring another download or another machine.
Verify the existing component before expanding the topology
Use a small baseline checklist:
- Reachability: Can the intended client contact the component?
- Expected operation: Does the required action succeed under the right conditions?
- Boundary: Does an inappropriate request fail as intended?
- Evidence: Can you distinguish a configuration problem from a connectivity problem?
Run safe, controlled tests inside the isolated environment. Avoid changing several settings merely to see which combination works.
Record the account, request, and relevant result so the baseline is more than a memory of a successful screen.
When you add another component, you can compare against this known state. That makes it easier to identify which dependency changed and whether the original role still behaves as expected.
The additional machine should answer a new question, not conceal uncertainty about the first one.
Document the dependency you would otherwise forget
Write down the configuration facts that matter to the scenario: names, roles, relationships, and assumptions.
Keep sensitive values out of public notes. In a portfolio, fictional identifiers and a sanitized diagram are enough to explain the architecture.
Record why you selected a setting when the choice affects behavior. A list of values without reasoning may help you rebuild the machine, but it won't necessarily help you explain the system in an interview.
The objective is understanding you can recover after a week away from the project.
Add a machine when a new test requires it
Expansion is justified when the existing setup cannot demonstrate a meaningful next requirement.
Perhaps you need a separate client to observe a user experience, or a test application to study federation. State the new question before making the infrastructure change.
Then define the smallest addition that answers it. You don't need to introduce monitoring, automation, backup, and a second directory at the same time unless the project actually concerns those interactions.
Use a scope limit for an entry-level IAM lab to prevent useful complexity from becoming uncontrolled scope.
Explain the small environment well before showing the large one
A candidate who can describe one access path, a failed test, and the reasoning behind a configuration has something concrete to discuss.
A candidate who can only list installed systems has more explaining to do, regardless of the machine count.
That isn't an argument against ambitious labs. It's an argument for making each layer understandable before adding the next.
The Six-Figure IAM Career Playbook includes three focused IAM lab directions and a plan for connecting them to job requirements. The $9 guide helps keep the build centered on useful evidence.
Add the next machine when you can explain what question it will answer. Until then, the most valuable work may be a diagram, a test, and a clearer account of what you already built.