To demonstrate least privilege, define the task and show that nearby unnecessary actions remain unavailable.
Repeating “give users only what they need” doesn't establish which permissions a particular user needs or whether your configuration enforces that boundary.
Start with a fictional business task in an isolated lab. Choose a permission based on what it allows, then test both the intended work and the limits you claim to have set.
Define the task before selecting the permission
Suppose a contractor needs to read a set of project documents.
Reading does not automatically require editing, deleting, exporting unrelated material, or administering other users. Write the legitimate task in plain language before choosing a convenient role.
Also identify the resource scope. Access to one project folder is different from access to every departmental share.
A vague requirement such as “needs project access” makes it too easy to grant a broad permission and call the job complete.
Compare what permissions allow, not just their names
A role called “reader” or “operator” may not match your requirement as neatly as the label suggests.
Before selecting it, compare:
| Check | What to record |
|---|---|
| Required action | What must the fictional user accomplish? |
| Available permission | What actions does it actually allow? |
| Unnecessary authority | What else would the assignment permit? |
| Remaining mismatch | What cannot be limited with this configuration? |
Choose the smallest suitable option available within the system and your authority to configure it.
If that option is still broader than the requirement, document the limitation. You may need a different configuration or a discussion with the appropriate owner. Don't claim precise least privilege merely because you chose the least powerful-looking role in a menu.
Test the allowed action and two nearby boundaries
Verify that the contractor can read the approved document.
Then test a prohibited modification and an unrelated resource. Use the intended account and a consistent test context.
The result should show that the person can perform the work without receiving the extra access you excluded. A total denial is not success if it prevents the legitimate task.
Capture the expected and observed outcomes in a small table rather than relying only on the configuration screen.
Keep the approval decision separate from your technical test. The fact that a role is narrower than an administrator role does not establish that the user needs it. The permission still needs a justified connection to the task.
Include time and changing responsibilities
Least privilege is not only an initial assignment question.
If the contractor's work ends, the need changes. Show how your lab removes the relevant permission and verifies the resulting state. Clearly identify any sessions, applications, or processes outside the test's scope.
If access is temporarily expanded, record the reason, approver, and review or expiry condition in the fictional workflow.
This makes the principle a lifecycle decision rather than a one-time choice made during onboarding.
Apply the same reasoning to administration
Your own administrative activity deserves a boundary too.
Identify which tasks require elevated authority and avoid using an unnecessarily powerful account for ordinary tests. Keep the lab isolated and follow the platform's supported administration model.
The demonstration should show that you understand the difference between operating a control and testing it as the user affected by the control.
Consider why privileged accounts need separate rules as the next step when the basic user-access example is clear.
Explain the result without claiming universal security
In the portfolio, state the task, resource, permission choice, tests, and lifecycle change.
Then state the limit: this proves a specific access boundary in your lab, not that the entire environment is secure or that every application follows the same model.
That narrow explanation is useful because a reader can evaluate it and ask a relevant follow-up question.
The Six-Figure IAM Career Playbook includes practical access and lifecycle lab directions with guidance on career positioning. The $9 guide helps turn concepts such as least privilege into evidence connected to an IAM role.
Don't stop at the definition. Show the legitimate action, the denied alternatives, and what happens when the need for access ends.