You can prove useful IAM lab work without publishing real identities, secrets, or a full directory export.
Show the requirement, the design, and the tests needed to support your claim. Extra environmental detail often adds exposure without adding evidence.
Build the public version around a skeptical reviewer's questions: what did you configure, why, what happened, and what remains untested? Use fictional data from the start so sharing safely isn't an afterthought.
Use fictional identities from the beginning
Create sample users, groups, and resources specifically for the lab.
Use clearly fictional names and data rather than importing a workplace structure and trying to anonymize it afterward. That makes the exercise easier to share and keeps the scenario focused on the skill being demonstrated.
Also keep the lab separate from personal accounts and files where possible.
You should be able to explain the access requirement without revealing who works at your company, which applications they use, or how the organization's internal permissions are arranged.
Show the design at the level needed for the claim
A diagram can identify the directory, application, test users, and resource without exposing private addresses or unnecessary identifiers.
Label the relationships that matter: which component authenticates, where authorization is evaluated, and how a group or role relates to the resource.
Don't replace every label with “redacted” until the diagram becomes meaningless. Use a purpose-built fictional example instead.
The public design should preserve the logic of the exercise. It doesn't need to preserve every implementation detail from your private environment.
Pair each claim with a specific observed test
State the capability you intend to demonstrate, then show evidence at that same scope.
| Claim | Evidence that fits |
|---|---|
| A directory group controls read access | Approved user succeeds; unrelated user is denied |
| A fictional transfer changes access | Required before-and-after permissions and checked results |
| A correction restored intended behavior | Original symptom, justified change, and comparable retest |
Include expected and observed outcomes, test conditions, and limitations.
This gives the reviewer something concrete to question. “Built enterprise IAM” doesn't explain which behavior was tested or how you established the result.
You don't need sensitive details to make the evidence credible. A clear synthetic scenario and accurate test record are more informative than publishing an extensive configuration that a reader cannot connect to a specific claim.
Share reproducible steps without exposing operational secrets
A short setup description or sanitized configuration example can help another person reproduce the important behavior.
Use placeholders for environment-specific values and keep secrets outside the repository. Review scripts, exported files, logs, and screenshots before publication, not only the README.
If a credential is exposed, deleting the visible file is not enough. GitHub's sensitive-data guidance explains why revocation or rotation and appropriate cleanup matter.
Do not rely on a private repository as permission to store credentials carelessly either. The project should have a sensible separation between shareable evidence and operational secrets.
Be honest about what remains private
You can say that some implementation notes are retained privately because they are unnecessary for the public explanation.
However, don't use privacy as a reason to make claims that have no supporting evidence at all.
If you cannot share professional material, describe the work at an appropriate level and create a separate fictional lab to demonstrate the principle. Clearly distinguish the two.
Use a deliberate boundary between public evidence and private implementation material to decide what belongs in the portfolio.
Make the page useful to a skeptical reader
Before publishing, ask whether someone could answer four questions: What did you intend to prove? What did you build? How did you test it? What are the limits?
If the answers are clear, the page can establish useful credibility without revealing sensitive details.
Practice the verbal walkthrough as well. You should be able to explain the design and respond to questions without opening private accounts or improvising unsupported claims.
The Six-Figure IAM Career Playbook includes practical lab directions and guidance on turning them into portfolio evidence. The $9 guide helps you build a career asset rather than a public copy of your environment.
Good proof makes the reasoning visible. It does not require making every technical detail public.