Don't rule yourself out of an IAM engineer role—or assume you're ready for an analyst role—based on the title alone.
Compare the responsibilities and level of ownership before deciding which job fits. One employer may use “analyst” for substantial technical investigation. Another may call an administration-heavy position “engineer.”
The titles can describe a progression within one company without meaning the same thing elsewhere. Your application will be stronger when it explains the work you can perform rather than arguing that you've reached a particular label.
Compare the duties and decisions behind each title
Take two postings and temporarily hide their titles. First identify the work, then the decisions the person would own.
| What to inspect | Examples to look for |
|---|---|
| Activities | Reviewing requests, investigating discrepancies, administering identities |
| Technical changes | Building integrations, writing automation, maintaining policies |
| Ownership | Following a procedure, recommending an approach, implementing a design, or owning the design |
Those distinctions reveal more than “analyst” versus “engineer.” Someone can perform a complex implementation without owning the architecture. Someone else may own operational decisions without writing much code.
Highlight the responsibilities that are central to the position, rather than treating every bullet equally. Then identify an honest example of your experience for each central requirement.
This gives you a concrete basis for applying or choosing a project to close a gap.
Look for the operational center of the role
An access-focused analyst position might emphasize reviews, approvals, investigations, and coordination.
A platform-focused engineering position might emphasize implementation, integration, scripting, and technical maintenance.
Those are illustrative patterns, not universal definitions. Some jobs combine both. Smaller teams may expect broad coverage. Larger teams may divide responsibilities more narrowly.
Don't force a posting into a category because it fits a neat career ladder you've seen online.
Ask what occupies most of the team's week, what the new hire would own, and where they would receive support.
Match your evidence to the ownership expected
Suppose your experience includes handling approved access requests, investigating account issues, and maintaining accurate records.
That could be relevant to roles centered on operational identity work. You would still need to compare the specific requirements.
If you've built integrations, tested changes, written maintainable automation, and handled the consequences of those changes, you may have evidence for more implementation-heavy responsibilities.
Keep lab work separate from production ownership. A lab can demonstrate understanding and initiative. It doesn't erase a requirement for having operated a critical service in a real environment.
The strongest application explains both what you can do and where you would need to grow.
Use an interview to resolve the ambiguous title
Ask concrete questions. What would the person be expected to deliver in the first few months? Which decisions can they make independently? Who reviews changes? How much time is spent on requests, projects, troubleshooting, and documentation?
Ask about the tools, but don't stop there.
Two jobs using the same platform can provide very different learning opportunities and schedules.
You also need to understand the operational expectations: support coverage, on-call work, travel, and the environments involved.
A title that sounds like a promotion can still be a poor fit.
Build the project that answers the missing question
Don't create a generic portfolio and hope it covers both roles equally.
For a workflow-oriented position, a clearly documented joiner-mover-leaver scenario may help you discuss approvals, exceptions, and verification.
For an integration-oriented position, a tested application sign-in project may provide a more relevant discussion.
Neither project guarantees qualification. It helps expose your reasoning in a way connected to the responsibility.
If the posting asks for scripting, show code you understand and tests you actually ran. If it asks for analysis, show the decision and the evidence behind it.
The project should answer a question the role raises.
Choose the next responsibility you want
It's reasonable to care about a title. It affects how a career move looks and may influence future searches.
Just don't let it replace the substance. A role with clear ownership, good support, and relevant work can be a better next step than a grander title attached to unclear expectations.
The Six-Figure IAM Career Playbook helps map your current background to identity specialties and choose practical evidence for the gap. The ebook is $9.
Start with the responsibilities you can credibly pursue.
Then decide whether the particular analyst or engineer role moves you in the direction you actually want.