Security / cybersecurity interviews

What does an IAM analyst do?

By Interview Clozo · Published 27 October 2026 · Last verified 26 October 2026 · 13 min read

An identity and access management (IAM) analyst is a security or information technology (IT) professional who controls who can use which systems: creating and removing accounts, granting roles, and checking that access still fits each person's job. Employers use the title for different jobs, so the duties vary. A common answer, password resets, covers only authentication, and interviewers expect you to separate that from authorization, as the second step of the lifecycle shows.

In this article

Before you start
Why interviewers ask this
IAM analyst from first principles
Worked example
Trade-offs and edge cases
How to answer it in an interview
Common mistakes
Follow-up questions
Sources

Before you start

This page belongs to the cyber security interview guide, which covers the neighboring roles and topics.

Nothing else is assumed. Every other term is explained where it first appears.

Why interviewers ask this

Interviewers ask about the IAM analyst role to find out whether a candidate understands access as a lifecycle rather than a login screen. Employers use the title for different jobs, so the duties vary. A candidate who explains the work from first principles shows they can adapt to either.

A weak answer lists tools and says "I reset passwords and add people to groups." A strong answer says what each action protects against: an account that outlives its owner, a person who collects access over the years, an approval nobody checked. A Staff-level answer adds the trade-off, because every control that restricts access also slows someone down, and says how to measure whether a review caught anything. Questions reported by candidates for this role mix these themes with scenario prompts such as a leaver whose access was never removed.

IAM analyst from first principles

Least privilege: Least privilege is the rule that an account should hold only the permissions its owner needs to do the current job, and no more. It limits the damage when an account is misused or stolen, because the account can reach little. Applying it means starting from nothing and adding access deliberately. Control AC-6 (AC stands for access control), Least Privilege, in NIST Special Publication (SP) 800-53 Rev. 5 covers it.
Access review: An access review is a scheduled check in which a named owner looks at who holds which access and confirms or removes each grant. It finds access that was never taken away after someone changed jobs or left. The result is a record that shows who approved what and when. Control AC-2, Account Management, in NIST SP 800-53 Rev. 5 includes reviewing accounts at a defined frequency.
Role-based access control: Role-based access control is a way of granting access in which permissions are attached to a role, such as helpdesk or finance, and people receive the role instead of individual permissions. Changing what a job may do then means editing one role. It also makes reviews shorter, as the worked example shows.

Identity and access management (IAM) is the discipline of administering who each identity is and what it may reach. The National Institute of Standards and Technology (NIST) glossary says that in enterprise IT, identity management "is about establishing and managing the roles and access privileges of individual network users". The glossary attributes that wording to a NIST publication under the term identity management, so it defines the identity half of the field, not the whole of IAM. The IAM analyst is the person who does that work day to day.

In plain words

Think of a building with a reception desk. Reception checks who you are, issues a badge, and the badge opens only some doors. When you change teams, the badge is reprogrammed. When you leave, it is cancelled. Once a year the building manager walks the corridors and asks each door's owner whether everyone on its list still needs it. An IAM analyst does the reception, badge and walk-around work for a company's systems.

The analogy breaks in one place: digital badges are copied, shared and forgotten far more easily than plastic ones, and a person may hold hundreds of them across applications. In one precise sentence, an IAM analyst maintains the link between each real person, the accounts that person holds, and the permissions those accounts carry, and keeps that link correct over time.

Step 1: Each person gets one identity when they join

Each person gets one identity record when they join, and every account they later hold is tied to it. The input is a hiring or onboarding request from a manager. The output is an identity plus the starting accounts the job needs, such as email and a ticketing tool.

In the trade this stage is called the joiner step. The analyst's job is to make sure the request is genuine, approved by someone with authority, and gives only the starting access. Access added on day one often stays long after it is needed, so a careless first grant is the origin of many later problems. You now know where access begins; the next step explains how a system trusts the identity before it lets it do anything.

Step 2: Authentication proves who you are, authorization limits what you can do

Authentication is the check that a person or program really is the identity it claims to be, usually with a password, a code or a device; NIST Special Publication (SP) 800-63-4 is the current NIST guidance on digital identity, including authentication. Authorization is the decision about what that proven identity is allowed to do. They are separate questions answered at separate moments, and an analyst who mixes them up is easy to spot in an interview.

Input: a sign-in attempt. Authentication outputs yes or no for "is this who they say?" If yes, authorization looks up the roles and permissions attached to the identity and allows or refuses each action. A stolen password defeats authentication only; broad permissions make the theft far more damaging, because authorization then allows too much. Resetting passwords touches authentication alone, which is why describing the whole role that way undersells it.

Authentication proves identity; authorization limits what that identity can reach.CC BY 4.0 — source: What does an IAM analyst do?

Text description of the diagram

Authentication proves that an account belongs to the person using it.
Authorization decides which actions that proven account may take.

Step 3: A role grants only the access the job needs

A role grants only the access the job needs, and people receive roles instead of individual permissions. A role is a named bundle: "finance analyst" might bundle read access to a ledger and write access to a reporting folder. This is role-based access control, defined above, and it is how least privilege is applied at scale.

Input: the person's job and an approved request. Output: membership in one or more roles. Grant by role and the question "who can see payroll?" has an answer you can read in one place. Grant by individual permission and nobody can answer it without checking every account. A request that does not fit any role is an exception, and exceptions are tracked separately because they are the grants most likely to be forgotten.

Step 4: Access is reviewed and removed when it no longer fits

Access is reviewed and removed when it no longer fits. People change teams, which the trade calls a mover event, and leave, which it calls a leaver event. Each should trigger a change of roles or a full removal of accounts. The review is the safety net for the cases where the trigger was missed.

Input: the current list of grants. Output: each grant confirmed or removed, with a record of who decided. Reviews and removals together are what auditors ask to see, so the analyst keeps the evidence; control AC-2 in NIST SP 800-53 Rev. 5 treats account review as part of account management. You now have the whole cycle: create the identity, check who signs in, grant by role, review and remove. Related reading on how identity is carried between systems is in the JavaScript Object Notation (JSON) Web Token interview questions.

Every identity moves through the same four stages, from joining to review and removal.CC BY 4.0 — source: What does an IAM analyst do?

Step-by-step description

One identity is created at joining.
Authentication checks who you are.
A role grants only what the job needs.
Access is reviewed and removed.

Each person gets one identity record when they join.
Authentication proves who you are, authorization limits what you can do.
A role grants only the access the job needs.
Access is reviewed and removed when it no longer fits.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Worked example

The example below is hypothetical, built to show why role-based grants make reviews shorter. A company has 160 employee accounts in five roles: helpdesk, developer, finance, human resources and administrator. The role sizes are 40, 60, 30, 20 and 10 employees, and the roles carry 8, 12, 10, 6 and 25 permissions. In addition, 14 permissions were granted outside any role as exceptions (illustrative).¹

If the reviewer checks every employee's grants, the count is each employee times the permissions of that employee's role: 320, 720, 300, 120 and 250, a total of 1,710 grants, plus the 14 exceptions, 1,724 items.¹ A role-based review has three parts. The reviewer checks each role definition once, which is 61 permissions in total. The reviewer also checks each person's role membership, which is 160 assignments, one per employee. Finally the reviewer checks the same 14 exceptions. That is 235 items.¹

Reviewing the five role definitions, the 160 role memberships and the 14 exceptions takes 235 items instead of 1,724, about 7.3 times fewer, or 13.63% of the work.
Quantity	Value (computed from illustrative inputs)
Employee accounts	160
Permissions defined across the five roles	61
Grants derived from roles	1,710
Exceptions outside any role	14
Items in a per-user review	1,724
Role memberships (one per employee)	160
Items in a role-based review (61 + 160 + 14)	235
Ratio of per-user to role-based items	7.34
Role-based review as a share of the per-user review	13.63%

The saving holds only while the role definitions stay tight and few, since every extra role adds items to the first part of the review.¹

Reviewing roles, memberships and exceptions is far less work than reviewing every grant.CC BY 4.0 — source: What does an IAM analyst do?

Text description of the diagram

A per-user review has 1,724 items.
A role-based review has 235 items.

Trade-offs and edge cases

Every IAM control trades safety against speed, and the analyst's judgment is where on that line a company sits. Five cases show it.

Role explosion: if the company creates a new role for every special request, there are soon more roles than people and the review saving disappears. Roles must be few and reviewed. Convenience: single sign-on (SSO) lets a person sign in once and reach many applications, which reduces password reuse, but a compromised sign-in then opens many doors, so it is paired with multi-factor authentication (MFA), a sign-in that needs two or more kinds of proof such as a password and a code from a phone (the NIST digital identity guidelines cover it). MFA adds friction, and users look for ways around friction.

Accounts that belong to programs, not people, often called service accounts, are easy to forget because no leaver event ever fires for them; each needs a named owner.

Privileged accounts, those with administrator rights over systems or other accounts, do the most damage if stolen, so privileged access management (PAM) adds tighter controls such as separate admin accounts and logged, time-limited use. Segregation of duties (SoD) is the rule that no single person can complete a sensitive task alone, for example both request and approve a payment; NIST SP 800-53 Rev. 5 calls the control separation of duties (AC-5). Automated provisioning, where a human-resources record triggers account creation and removal, makes joiner and leaver events reliable but moves the risk into the rules, which the analyst must review.

Finally, an access review that is approved by reflex, with every box ticked, produces a record but no protection. A strong analyst samples the approvals and checks whether anything was ever removed. The neighboring roles overlap but differ: the security operations center (SOC) analyst watches for attacks as they happen, while the IAM analyst prevents the excess access that makes attacks easier. Builders of software cover related ground in application security questions.