A home lab needs tests that support the claim you're making. A screenshot of a configuration does not prove that the intended user received access—or that an unauthorized user was blocked.
Before installing another product, identify the result your project should demonstrate. Then record what you expected, what happened, and which evidence supports the conclusion.
This can improve a small lab more than adding complexity. It also gives you a better interview explanation because you can describe behavior, not just the setup screens.
Turn the project claim into an observable result
Start with a sentence. “Only members of the approved group can read the test resource.”
Now ask what evidence would make that statement credible.
You'll need at least an approved account, an unapproved account, and a consistent attempt to perform the relevant action. You'll also need to know which account is active during each test.
The exact setup will vary, but the reasoning is simple: the claim determines the check.
A screenshot of the group configuration supports the explanation. The observed access results test whether the configuration achieved the requirement.
Those are different kinds of evidence.
Record the expected result before you run the test
Use a simple table rather than relying on memory:
| Field | What to record |
|---|---|
| Test case | The account, resource, and action attempted |
| Expected result | What should be allowed or denied, and why |
| Observed result | What actually happened |
| Conditions and evidence | Session state, recent changes, and the relevant screenshot or log |
Write the expected outcome first. Otherwise, it's easy to observe a result and quietly redefine that result as your original goal.
Include details that help someone interpret the test. Was this a new session? Had group membership changed? Were you using the ordinary user or an administrator account?
You don't need a formal testing platform. You do need enough context to investigate a surprise without rewriting the requirement to make the test pass.
Test that an unapproved user is denied access
A successful access test is only half of a permission scenario.
Try an account that should not have the access. Try the action the requirement excludes, where appropriate and safe in your lab.
The test should be authorized and contained. You are validating your own design, not probing somebody else's environment.
If the unapproved account succeeds, investigate the permission path. Broad inherited access or an unexpectedly privileged test identity can make the result misleading.
Don't fix everything at once. Change one relevant variable, then repeat the test.
That makes your troubleshooting explainable.
Check what happens after a change
Static screenshots miss an important part of identity work: access changes.
Remove a test assignment, change a fictional role, or correct a controlled error. Then verify the new expected state under documented conditions.
Pay attention to sessions and other state that can affect what you observe. Don't claim an instant revocation property you haven't actually tested.
When the result depends on a fresh sign-in or another action, record that.
A project becomes more useful when it explains not just the final configuration but the behavior you observed during a transition.
Keep the failed test that taught you something
You don't need to hide every mistake from a portfolio.
A genuine failed test can demonstrate how you reasoned.
Explain what you expected, what contradicted that expectation, which hypothesis you checked, and what changed after the correction.
Keep the story proportionate. Accidentally granting a test user broad access doesn't make you an incident responder. It gives you a specific troubleshooting example.
Don't manufacture failures or claim that you discovered a new vulnerability.
Clear, ordinary technical reasoning is enough.
Publish a conclusion with boundaries
End the project with a short statement of what the tests support.
For example: “Within this lab, the approved account could read the resource and the unapproved account could not. After the membership change and documented session refresh, the previous access no longer succeeded.”
That is much stronger than “The lab worked.”
It also avoids claiming that a small demonstration proves enterprise readiness.
The Six-Figure IAM Career Playbook includes practical projects and a way to document the architecture, configuration, tests, and lessons learned. The ebook is $9.
Keep the screenshots that matter. Then make sure at least some of them show an observed result, not just evidence that you finished clicking through the setup.