A joiner-mover-leaver lab can show that you understand how access should change when an employee starts, transfers, and leaves.
Use one fictional employee and test the access at each stage. Give them a role, a manager, and a small set of resources. Then record which permissions should be added, retained, or removed.
You don't need an enterprise governance platform to demonstrate the reasoning. You need a clear starting state, approved changes, and evidence that the resulting access matches the requirement.
Define one employee and a small access model
Suppose Casey joins a fictional company in customer support.
Support employees need the support application and a shared knowledge resource. Finance employees need a separate finance resource. Neither role requires administrative privileges.
Create a table showing the access intended for each role.
Keep the system count small. Two resources are enough to expose the important decisions.
Record which facts trigger a change and who approves access. In a real organization, the authoritative source and approval process require explicit design; in your lab, state the assumptions clearly.
You're building a model, so make its boundaries visible.
Test onboarding access, not just account creation
For the joiner event, define the starting state before making changes. Use Casey's fictional account to answer:
- Identity: Does the account exist, with the attributes your scenario needs?
- Approval: Who approved each requested entitlement?
- Required access: Which task should Casey be able to complete?
- Restricted access: What unrelated resource should remain unavailable?
Perform the setup, then test through Casey's ordinary account rather than your administrator session.
Record both an allowed action and an intended denial. Seeing an account appear in a console is not enough: the business requirement was usable, appropriate access.
If the test fails, keep the result and investigate before moving to the transfer stage. Your portfolio will be more useful when it shows how you verified the requirement than when it only shows the account-creation screen.
Make the transfer the interesting part
Now move Casey from support to finance. Add the required finance access and decide what should happen to the support access.
This is where a simple project can reveal a meaningful design issue. A process that only adds permissions will accumulate access as the employee changes roles.
Record any temporary overlap as an explicit exception with an owner and review point. Don't let “maybe they still need it” become an undocumented permanent decision.
Then test the intended new state. Microsoft describes joiner, mover, and leaver as phases that lifecycle workflows can address. The concept is useful even when you model it manually. Source: Microsoft lifecycle workflows.
Define what leaving means for each system
For the leaver event, list the relevant accounts, assigned permissions, and application access.
Explain the actions your lab performs and what it cannot verify.
Disabling one account isn't sufficient evidence that every possible downstream account or active session has been handled. Different systems can require different controls.
You don't need to simulate every complication. You do need to avoid claiming more than you tested.
Include a check for a failed or incomplete action. In a small lab, that might simply be an exception record showing which step needs review and why.
Publish the state changes, not a wall of screenshots
A reader should be able to compare three states: joined, transferred, and departed.
Show the intended access beside the observed results.
Include the event, approval assumption, action, verification, and any exception. Add a compact diagram when it clarifies which systems participate.
Automation can come later. First prove the workflow makes sense.
An automated mistake is still a mistake, and a script that reports success doesn't remove the need to test the resulting access.
Use only fictional data and keep credentials out of the public repository.
Tie the project to a responsibility
The strongest explanation is not “I built an IAM lab.”
It is “I modeled an employee lifecycle, implemented role-based access changes, and verified both the required access and its removal.”
Use wording that matches what you actually completed.
The Six-Figure IAM Career Playbook includes lifecycle work among its three lab directions and explains how to present the evidence alongside your existing IT experience. The ebook is $9.
This project is valuable because it gives you a process to explain.
A person changed. Their access needed to change with them. You showed how, and you checked the result.