Before choosing identity tools, define the person, resource, permitted action, and event that should end access.
For example, a contractor needs to read project documents for a limited assignment, must not change them, and should lose that permission when the work ends.
That gives your lab a purpose and a test plan before you install anything. Choose tools that can demonstrate those requirements, rather than inventing a business story afterward to justify the products you wanted to try.
Define the people and the resource
Keep the first scenario small. Use a fictional contractor, a project owner, and one test resource containing dummy information. Decide who needs access and who has authority to approve it.
Avoid adding departments, subsidiaries, and dozens of applications simply to make the story look like an enterprise. Each extra element should create a question you intend to investigate.
A narrow scenario is easier to test and explain. You can expand it later when a new requirement justifies the extra complexity.
Specify the action, duration, and boundary
Write what the user should be able to do, for how long, and what should remain unavailable.
“Has project access” is too broad. “Can read the project folder during the assignment, cannot modify its files, and cannot access finance material” gives you testable conditions.
Then define what should trigger a change. The assignment might end, the person's role might change, or the sponsor might reject a renewal.
These details help you distinguish access provisioning from the ongoing decision about whether access is still appropriate.
Write the test cases before configuring the tools
Build a small validation table for the fictional contractor:
| Condition | Expected result | Evidence to capture |
|---|---|---|
| Approved contractor reads a project file | Allowed | The account, action, and observed result |
| Contractor attempts to modify the file | Denied | The failed operation under the intended permissions |
| Assignment ends and access is removed | Access no longer works under the documented test conditions | The change and subsequent access check |
Creating an account doesn't prove any of these requirements. Likewise, removing a membership is a configuration action; the resulting behavior still needs a test.
The three identity test cases that make a demo credible provide a useful starting point for this validation plan.
Record session conditions and limitations. Don't claim that one fresh-session check proves every existing session or connected application has been terminated.
Choose a tool that can support the intended test
Now consider the implementation. A directory and test folder may be sufficient for a resource-access exercise. A test identity provider and compatible application may be more appropriate for sign-in. A manual approval record can support a governance design exercise when you clearly distinguish it from automated enforcement.
Check product documentation, prerequisites, licensing, and the limits of your environment before committing.
There is no advantage in choosing a large platform when most of your time will be spent managing dependencies unrelated to the skill you want to demonstrate.
Keep policy and enforcement separate in the write-up
Your policy states what should happen. Your configuration or workflow describes how you attempted to make it happen. Your test results show what you observed.
Those three layers should not be merged into one claim.
For example, a document saying access expires on Friday does not prove the system removes it. A scheduled removal does not prove every application session has ended. Your evidence should match the exact boundary you tested.
That distinction makes a small lab more credible without requiring you to simulate every production concern.
Finish with a case study someone can follow
Lead with the fictional situation, show the important design choice, present the results, and state the limitations.
Put installation details below the explanation. The reader should understand why the project exists before seeing how you installed its components.
You now have a project selected for a reason, rather than a tool installation searching for a story.
The Six-Figure IAM Career Playbook includes directory access, SSO, and identity lifecycle lab areas alongside role-selection guidance. The $9 guide helps you choose a relevant direction; a clear business scenario helps make the resulting work understandable and worth discussing in an application or interview.