A useful access-control lab can be much smaller than a domain or cloud environment. It needs an identity, a resource, a permitted action, and a boundary you can test.
Build and explain that permission boundary before adding infrastructure. A local exercise can demonstrate the relationship when you label the environment and limitations honestly.
The project below focuses on read, modify, and denied access with fictional accounts. It is a learning demonstration, not a claim that a small local setup represents a complete enterprise IAM deployment.
Use a disposable environment and fictional accounts
Create the exercise in an isolated virtual machine or another suitable lab environment, not on a work system or around personal files you cannot afford to lose.
Use ordinary test accounts and keep a separate administrative recovery path. Do not test the intended user experience while signed in with broad administrative rights.
Check your operating system's capabilities and documentation before changing permissions. The exact interface and supported features depend on the environment.
The lab should be easy to reset and should contain no real organizational data.
Define one resource and two different actions
A fictional supplier document can be enough. One test account should be able to read it, but not modify it. A second account should not be able to read it.
Write those expectations before configuring anything. Microsoft's access-control documentation describes the relevant Windows concepts. Your job is to apply them to a clear, bounded question.
Avoid vague requirements such as “secure the folder.” A requirement should identify who, what, and which action.
Configure the permission path you intend to test
You might use a local group to represent the approved readers, then assign the appropriate resource permission to that group.
Inspect inherited permissions and other assignments that could affect the result. A configuration is not minimal merely because it contains few objects; it is minimal when the relationship is understandable.
Do not add broad permissions to fix a confusing result. Investigate why the current assignments do or do not support the expected action.
Keep a short note of the intended permission path so you can compare it with the observed behavior.
Test the allowed action, prohibited action, and changed state
Use a compact test record:
| Test | What it checks |
|---|---|
| Authorized account reads | The required action is available |
| The same account tries a prohibited modification | Read access hasn't been confused with edit permission |
| Another account tries to read | The intended identity boundary holds |
| The grant is removed and retested | The relevant change affects access under appropriate refreshed conditions |
A successful sign-in is not the same as access to the resource.
Three test cases that make an access-control demonstration credible can organize the main comparison, with additional actions recorded where your scenario requires them.
Keep the access path consistent. Local file access and a network share may involve different checks. Record which path you used rather than combining them as though they prove the same boundary.
Explain what the lab does and does not prove
The exercise demonstrates a local permission model and your ability to test it. It does not demonstrate directory synchronization, enterprise application integration, or a production access-governance process.
That is a useful boundary, not a reason to dismiss the work.
You can later expand the same business requirement into a directory-based scenario and compare what changes. Keeping the requirement stable makes the added infrastructure easier to understand.
The directory, SSO, and lifecycle projects in The Six-Figure IAM Career Playbook help you choose the next layer based on your target role. The $9 guide is intended to keep the learning connected to a career purpose.
Start with a result you can explain. Complexity should be added because it answers a new question, not because a small lab feels insufficiently impressive.