A public IAM portfolio should expose your reasoning and tested results—not sensitive details from the environment.
Separate what a reviewer needs, what requires careful sanitization, and what should remain private. Make that decision before copying configuration or screenshots into a repository.
Fictional identities and sample data make the boundary easier to maintain. A public project should never depend on recreating an employer's environment from information you weren't authorized to share.
Publish enough to explain the requirement and result
The opening page should establish:
- Problem: What access need did the exercise model?
- Design: Which components and permission path matter?
- Test: What was allowed, what was denied, and under what conditions?
- Scope: What did you implement, and what remains assumed or untested?
For a fictional access-control project, a small diagram and expected-versus-observed table can communicate more than a large configuration export.
Distinguish platform-provided behavior from your own configuration and validation. A reviewer should be able to tell what work was yours without seeing every environmental identifier.
Choose evidence because it supports the claim. Details that add exposure without helping explain the design or result can remain private. A portfolio is an explanation of useful work, not an obligation to publish everything you possess.
Review supporting evidence before sharing it
Screenshots, logs, and configuration examples can support the claim, but each one needs inspection.
Check names, account identifiers, browser tabs, addresses, notifications, tokens, connection strings, and other visible details. Do not assume the only sensitive information is the field you intended to capture.
Use synthetic values where appropriate and explain that they are examples.
Sanitization should not change the meaning of the evidence. If removing a detail makes the result impossible to interpret, create a safer fictional test rather than publishing a confusing image covered in redaction boxes.
Keep secrets and unnecessary operational detail private
Credentials, private keys, authentication tokens, and recovery material do not belong in the public repository.
Neither do employer or customer records, internal tickets, or confidential architecture simply because they would make the project look more realistic.
Some personal setup notes may also be unnecessary for the public explanation. Keep them separate instead of treating the repository as a backup of every file in the lab.
A private repository still needs sensible secret handling. Privacy settings are not a substitute for deciding what should never be committed in the first place.
Inspect history as well as the current files
A clean-looking current version does not prove that sensitive material was never committed.
GitHub's guidance on removing sensitive data explains the importance of addressing exposed credentials and the limits of repository cleanup. Its ignore-file documentation also distinguishes ignoring future files from handling files already tracked.
Review before the first commit whenever possible. If you discover an exposure, follow the appropriate recovery process rather than assuming that deleting one visible file resolves every risk or copy.
Keep a public explanation separate from private implementation notes
A useful project folder can have a deliberate publication area containing the README, selected evidence, and sanitized examples.
Private operational notes can remain elsewhere. Do not rely on remembering which files were safe the last time you pushed changes.
Use a prepublication removal checklist before sharing an update, especially after adding logs or screenshots.
The workflow should make safe publication repeatable. If every update requires a rushed search through unrelated files, the project structure needs improvement.
Publish enough to support the claim, not everything you possess
A skeptical reader needs a clear requirement, an understandable design, and evidence that the result matches the claim.
They do not need your credentials or your employer's internal details.
Practice explaining the project without opening private systems. If the public material is too thin to support the explanation, add a fictional test or clearer documentation rather than exposing more sensitive information.
The Six-Figure IAM Career Playbook includes practical lab directions and portfolio guidance for turning existing IT experience into a more focused career move. The $9 guide helps you choose evidence with a purpose.
A good public portfolio is a curated demonstration. It is not a public backup of the lab, your work history, or every configuration you have access to.