Before calling an IAM lab complete, specify who can do what, what should be denied, and how you verified both.
“It works” doesn't answer those questions. It may mean only that an administrator opened a resource once.
A small environment can still produce rigorous evidence. Use clear requirements, the intended test identities, meaningful success and failure cases, and an explanation another person can follow without watching you rebuild the project.
Write the requirement and test scope before checking settings
Use a complete statement of intended behavior. For example:
“Members of the fictional Finance Reports group can read the sample reports. Other ordinary users cannot.”
Then define the test boundary:
- Resource: Which sample files or application are involved?
- Access path: Local folder, network share, or application access?
- Action: Reading, modifying, or another specific operation?
- Identity: Which ordinary test accounts represent each case?
These aren't interchangeable demonstrations. A successful local test doesn't automatically establish the behavior of a network share or an application.
The requirement determines which screenshots, logs, and observations belong in the write-up. It also prevents the exercise from becoming “I changed settings until something opened” and then retroactively declaring that behavior the goal.
Identify the user and the permission path
Record which fictional account is being tested and how that account is expected to receive access.
The path might involve a group membership and a resource permission. In an application scenario, it may include assignment or a role mapping. Explain the path you actually built rather than adding architecture you didn't test.
Check for unintended alternate access. An administrator account can make an exercise appear successful while hiding whether the ordinary user's permission path works.
Use accounts appropriate to the scenario and document their relevant scope.
Run both the expected success and expected denial
Test the intended user performing the intended action. Then test an appropriate control user who should not have that access.
Record expected and observed outcomes separately. If the control user succeeds, the lab has uncovered a problem. Investigate it instead of selecting only the screenshot that supports the story you hoped to tell.
A negative test is useful when it is tied to a requirement. Randomly trying unrelated actions doesn't automatically make the project more convincing.
Check what happens when access changes
Where the exercise includes a lifecycle change, verify the resulting behavior rather than stopping at a membership screenshot.
For example, remove the fictional user's approved access and test the relevant action using an appropriate fresh session or other method for the system under examination. Explain any session or timing limitation that affects the result.
Don't claim universal immediate revocation from one narrow test.
This step connects the project to a real operational question: whether access continues to match the current approved state.
Include recovery and safe cleanup
Write down how you would return the lab to a known state after a deliberate mistake.
That might mean restoring the original setting, recreating a test account, or reverting the isolated environment. The method should fit your setup and avoid depending on undocumented memory.
Then remove unnecessary test artifacts and review anything you plan to publish for secrets or private information.
The project should leave you with evidence and understanding, not a personal machine accidentally carrying lab permissions or an exposed credential in a repository.
Confirm that another person can follow the result
Your final page should identify the problem, the relevant design, the tests, the observed result, and the limitations.
Use a clear definition of “finished enough to publish” to avoid polishing forever after the useful work is complete.
A reader should not need access to your running environment to understand the main claim. A short diagram, a small test table, and selected evidence may be enough.
The Six-Figure IAM Career Playbook provides three practical IAM lab directions and guidance on turning them into career evidence. The $9 guide is useful when you want a project to do more than occupy a weekend.
A finished lab doesn't need to prove everything. It needs to prove its stated requirement, honestly and clearly.