A credible access-control demo shows intended access, excluded access, and what happens after permission is removed.
One successful login doesn't establish those boundaries. Use a small isolated lab, fictional accounts, and a harmless resource to test them separately.
Write expected results before running the tests. That keeps you from treating whichever behavior happens to occur as the result you meant to build, and gives the final explanation a clear standard for success.
Define one resource and one allowed action
Imagine a project folder containing synthetic planning documents. Members of the project-review group should be able to read the documents. People outside the project should not.
Keep the scenario that narrow at first. Don't combine it with privileged administration, cloud synchronization, and multiple applications unless those are part of the question you intend to answer.
Record the resource, the group, the accounts, and the permission path. Microsoft's access-control documentation explains how permissions connect security principals with protected resources.
Your test evidence should connect that configuration to observable behavior.
Test one: verify the approved user's intended action
Use an ordinary fictional account in the approved group—not an administrator session.
Record:
- Identity: The account used for the attempt.
- Resource: The designated sample folder or document.
- Action: The specific operation, such as reading.
- Expectation and observation: What should happen and what did happen.
If the requirement is read-only access, opening the file establishes that reading worked. It doesn't by itself establish that editing is blocked.
You can add an action-boundary check within this case, but keep its purpose explicit. The approved person should be able to do the approved work without silently receiving unnecessary authority.
This first case demonstrates usable permission. The excluded-user and removal cases add different evidence; don't use the success screenshot as a substitute for those tests.
Test two: an excluded person cannot use the resource
Use a separate ordinary account that should not have project access. Attempt the same read action against the same resource.
A denied result is useful only when you know why it happened. A powered-off server or an incorrect path would also prevent access, but would not demonstrate your authorization rule.
Confirm that the resource is reachable through the intended path and that the authorized control account still works.
This comparison helps distinguish a meaningful access denial from a general failure of the environment.
Test three: removed access actually stops working
Now take an account that previously had access and remove the relevant entitlement according to your lab design.
Retest under conditions appropriate to the system. Existing sessions or cached authorization information can affect what you observe, so document whether you started a fresh session and what you did not evaluate.
Don't promise that removing one group membership instantly terminates every possible session in every application. State the specific result your test demonstrates.
This case turns a static permission screenshot into a lifecycle example: someone had a reason for access, that reason ended, and you checked the effect.
Use consistent identities, resources, and conditions across tests
For each case, record the account's intended role, starting condition, action, expected result, actual result, and relevant evidence.
Use the same naming and resource references across the document. A reviewer shouldn't have to guess whether three screenshots refer to three different folders.
When a test behaves unexpectedly, keep the failed result and explain the investigation. The troubleshooting notes behind the final screenshot can be as useful as the successful retest.
Add a limitation such as “This exercise tested fresh Windows sessions against one test folder; it did not evaluate cloud application sessions.”
Explain what the three cases demonstrate
Together, the cases show intended access, exclusion, and removal. They don't prove that an entire identity environment is secure.
That bounded claim is enough for a useful portfolio project. It gives an interviewer concrete questions to ask about your reasoning and the design.
The Six-Figure IAM Career Playbook includes directory access, SSO, and identity lifecycle lab guidance for $9.
Use the projects to build evidence that answers a hiring question. A small demonstration with clear tests is easier to trust than a large environment with unexplained screenshots.