Before installing another security dashboard, use your existing lab to verify what happens when a fictional employee changes teams.
Define the old and new access, make the approved changes, and test both the permissions gained and the permissions that should disappear.
That gives you a complete IAM problem to explain. Another installation may be useful later, but it won't automatically demonstrate that you understand access decisions, lifecycle changes, or how to investigate an unexpected result.
Start with a before-and-after access requirement
Imagine a fictional employee moving from a project-support role to a finance-support role.
Define the resources they need before the move and the resources they need afterward. Include access that should be removed, not only access that should be added.
Keep the example small: two test resources and a few clearly named groups are enough to begin.
You now have a question that uses your existing infrastructure: can you make the person's effective access match the new responsibility without retaining unnecessary permissions?
Establish what the user can do before changing anything
Sign in as the ordinary test user and attempt the relevant actions.
Record the result against the expected access matrix. Do not assume the starting state is correct because you remember configuring it that way.
If the baseline is already wrong, investigate and document that before moving on. Otherwise, you may attribute an existing problem to the role-change process.
A useful project begins with a known state, not a screenshot taken after several unexplained configuration changes.
Carry out the role change as a defined process
Write the approved changes for the fictional move.
Which membership should be added? Which should be removed? Who would authorize the decision in a real organization? Which system or resource needs to reflect the change?
Then perform only the changes in scope for your lab.
You can model approvals manually as long as you label them clearly. Do not claim automated governance when you manually edited groups after writing an approval note.
Test removed access as carefully as newly granted access
After the role change, compare the expected and actual behavior.
| Test | Question it answers |
|---|---|
| Attempt the newly approved action | Did the employee gain the required permission? |
| Attempt the old action | Is obsolete access unavailable under the test conditions? |
| Inspect other relevant assignments | Could a direct permission or another group preserve access? |
Use fresh sessions where appropriate and record exactly what you tested. State when existing sessions or other applications are outside the exercise.
The access questions raised by an employee changing teams help explain why this is more than another onboarding task. Adding the new access is only half of the intended change.
If a result differs from the requirement, investigate the remaining path before adding more tools. The mismatch is an opportunity to demonstrate your reasoning and verify the correction.
Investigate one mismatch instead of adding another product
If the user retains access unexpectedly, trace the reason.
Perhaps a broader group still grants access, a direct assignment exists, or your test session does not reflect the changed state. Follow evidence rather than guessing.
You may discover that the tools already available provide enough information. If an additional tool is genuinely needed, identify the missing evidence first and explain why the tool supplies it.
That is a stronger reason to expand the lab than wanting another attractive dashboard in the portfolio.
Publish the decision and verification trail
Your finished project should show the original requirement, baseline access, approved change, resulting access, and any discrepancy you investigated.
Add a short limitation statement and a sanitized diagram. Keep detailed notes available, but lead with the result and what you personally did.
This gives an interviewer a clear conversation about lifecycle responsibility, permissions, and troubleshooting. It is more specific than a list of platforms running on your host.
The Six-Figure IAM Career Playbook includes identity lifecycle alongside directory access and SSO as three practical lab areas. The $9 guide helps you turn existing infrastructure into relevant career evidence. You may not need another installation yet; you may need to finish the question your current environment can already answer.