If I rebuilt an IAM portfolio from the beginning, I'd choose the claims I wanted to prove before selecting the tools.
A small first portfolio could cover an access boundary, a sign-in integration, and an identity lifecycle change. Each should answer a different question rather than repeat an installation with new screenshots.
I wouldn't start by recreating a large company. I'd start with a role I'd consider and evidence that helps explain why I'm a credible candidate.
Choose one job direction to guide the first projects
I'd compare several suitable postings and identify the responsibilities closest to my existing experience.
Then I'd record:
- Primary role: The kind of identity work I would genuinely pursue.
- Existing strengths: Responsibilities supported by professional examples.
- Missing evidence: Capabilities a small project could help demonstrate.
- Excluded work: Interesting topics that don't serve these first projects.
A directory-focused administrator and a customer identity developer may need very different examples. Trying to look equally qualified for both can make a first portfolio unfocused.
This choice isn't permanent. It gives the initial projects a purpose and makes it easier to decide what not to build yet.
Once the evidence is complete, I'd use it in actual applications before assuming a fourth project is automatically the best next investment.
Project one would prove a clear access boundary
I'd use fictional identities and a small resource to show who should be allowed to do what.
The project would include the permission path, an expected success, and an expected denial. I'd also document a relevant change, such as removing the approved access and checking the resulting state.
This is a manageable way to demonstrate authorization reasoning.
The headline would describe the behavior being tested rather than announce that I installed a server. The infrastructure matters because it supports the evidence, not because its existence is the result.
Project two would make a sign-in flow understandable
Next, I'd connect a test application to an appropriate identity system and document the participating components.
After establishing a working baseline, I'd introduce one safe, reversible configuration fault and investigate it. The public case study would explain the evidence, correction, and retest.
I'd be explicit about what I implemented and what the application or platform handled for me.
The goal is to show that I can follow a flow and reason about a failure—not claim that a small lab is equivalent to owning a production identity service.
Project three would show access changing over time
I'd create a fictional employee who joins one team, moves to another, and leaves.
For each event, I'd define the approved state and identify the changes needed. The transfer would include removing old access, not simply accumulating more permissions.
This project can combine a simple technical environment with a clear process model. Any proposed automation or governance control that isn't implemented should be labeled accordingly.
The result would demonstrate a different capability from the first two projects: connecting access to changing business responsibility.
I would make the public pages consistent but not identical
Each page would begin with the problem and the result. Then it would show the design, tests, evidence, and limitations relevant to that particular project.
I would use a shared README structure so readers can find information quickly, while keeping the actual examples and reasoning distinct.
All identities and data would be fictional. I would review screenshots, configuration files, and repository history before publication.
The portfolio should be understandable without exposing employer information or requiring someone to run the entire environment.
I would use the work before adding a fourth project
Once the three examples were complete, I'd practice a short walkthrough of each and connect them to suitable applications.
Feedback might reveal a specific missing capability. That would give the fourth project a reason to exist.
Without that feedback, adding more tools can become a way to avoid the less comfortable part of the process: showing the work to the market.
I built The Six-Figure IAM Career Playbook around this kind of focused approach. The $9 guide connects three IAM lab directions, role selection, and a 90-day plan.
Starting again, I would still care about technical depth. I would just make sure each piece of depth answers a hiring question instead of adding another unfinished system to the lab.