by IAM interviews start with definitions, authentication versus authorization, SAML versus OIDC, RBAC versus ABAC, and move fast into design and judgment: how you'd handle a Friday afternoon termination, a vendor that needs temporary access, or a manager who rubber-stamps every access review without reading it.
Interviewers use this mix to check 2 things: whether you know the standards well enough to implement them correctly, and whether you'll actually enforce least privilege when a business team is pushing for broad access to move faster.
These 20 questions cover both levels, with sample answers specific enough to show real IAM judgment instead of textbook definitions.
IAM at a glance
| Item | Details |
|---|---|
| Typical employers | Enterprises with compliance requirements (finance, healthcare, SaaS), managed security service providers, and cloud and identity vendors |
| Median pay | $129,180 a year for information security analysts overall (BLS, May 2025); BLS doesn't track IAM engineering as a separate role |
| Job outlook | 21% growth from 2025 to 2035 for information security analysts, about 14,100 openings a year (BLS) |
| Education | A bachelor's degree in computer science or a related field is typical; some IAM engineers move up from help desk or systems administration roles with certifications |
| Certifications | Vendor and industry credentials such as Microsoft's SC-300 (Identity and Access Administrator), Okta Certified Professional, or CompTIA Security+ are common, though none are required for most roles |
| Key tools | Okta, Microsoft Entra ID, SailPoint or Saviynt for identity governance, CyberArk or BeyondTrust for privileged access, and SCIM for provisioning |
| Interview format | A technical screen on standards and protocols, often followed by a design scenario and a round with a security or compliance stakeholder |
How the interview usually works
- Recruiter screen, confirming your background with specific identity providers and standards.
- Technical interview, covering authentication and authorization concepts, SSO protocols, and access control models.
- Design or scenario round, where you're asked to design a provisioning process or respond to an access incident.
- Stakeholder round, often with security, compliance, or an application owner who deals with access requests directly.
General and background questions
1. What experience do you have implementing or managing IAM systems in production?
Why they ask: They want the real scope of what you've owned, not a list of acronyms.
How to answer: Name the platform, scale, and a specific project you led.
Sample answer: I've managed identity for a company with about 3,000 employee accounts and 40-plus SaaS applications connected through Okta as our identity provider. I led the migration of our largest legacy app from local database authentication to SAML-based SSO, which took about 6 weeks including testing with the vendor, and I currently own our SCIM provisioning setup, which automatically creates, updates, and deactivates accounts in 15 downstream apps based on HR system changes.
2. How do you explain the difference between authentication and authorization to a non-technical stakeholder?
Why they ask: IAM engineers explain access decisions to people who aren't engineers constantly, and they want to see you do it clearly.
How to answer: Use a plain, accurate distinction without jargon.
Sample answer: I tell people authentication answers "are you who you say you are," and authorization answers "what are you allowed to do now that we know." I usually give an example: badging into the building proves who you are, but it doesn't mean every door in the building opens for you. When a stakeholder confuses the two, it's usually because they're asking why someone who logged in successfully still can't see a specific report, which is actually an authorization question, not an authentication problem.
3. How do you stay current on identity standards and credential-based attacks?
Why they ask: Standards and attack techniques both keep changing, and they want to know your actual habits.
How to answer: Name specific sources and a time it changed something you did.
Sample answer: I follow the identity provider's own release notes, Okta and Microsoft Entra ID specifically, since new features like phishing-resistant authentication methods show up there before anywhere else. I also read incident write-ups from real breaches, like the pattern of MFA fatigue attacks where an attacker spams push notifications until someone approves one by accident. That specific pattern is what got me to move our MFA policy from push notifications to number matching, where the user has to enter a code shown on the login screen instead of just tapping approve.
Technical questions
4. What's the difference between SAML and OIDC, and when would you choose one over the other?
Why they ask: This is a core protocol question, and a vague answer signals you haven't implemented either.
How to answer: Name the token format and typical use case for each.
Sample answer: SAML uses XML-based assertions and is the older, more established standard for enterprise SSO, still common with legacy on-premises applications and older SaaS vendors. OIDC sits on top of OAuth 2.0 and uses JSON web tokens, which are smaller and easier to work with in modern web and mobile applications. I default to OIDC for anything new, since it's simpler to debug and most current identity providers support it well, but I still implement SAML regularly because plenty of enterprise vendors, especially in areas like HR and finance software, only support SAML for SSO.
5. Walk me through how SSO actually works, from a user logging in to reaching an application.
Why they ask: They want to know you understand the mechanics, not just that SSO "lets you log in once."
How to answer: Describe the redirect flow between the service provider and identity provider.
Sample answer: A user tries to open an app, the service provider, and if there's no active session, it redirects the user to our identity provider, Okta in my case, with a request identifying which app is asking. The user authenticates against Okta, including MFA if required, and Okta then sends back a signed assertion or token, depending on whether the app uses SAML or OIDC, confirming who the user is and sometimes which groups they belong to. The application validates that signature against Okta's public certificate and, if it checks out, creates a session for the user without asking for another password. If the user then opens a second app connected to the same identity provider, they skip the login screen entirely since Okta already has an active session for them.
6. What's the difference between RBAC and ABAC, and when would you use ABAC instead of RBAC?
Why they ask: This tests whether you know the tradeoff, not just the definitions.
How to answer: State how each makes a decision and give a concrete case where roles alone don't work.
Sample answer: RBAC assigns permissions based on a user's role, like "finance analyst" or "IT admin," so access is easy to reason about and audit, but it gets messy when access should depend on something other than job title. ABAC evaluates attributes, like the user's department, the resource's sensitivity label, the time of day, or the device's security posture, against a policy, so it handles conditions RBAC can't express cleanly. I've used ABAC for a healthcare application where a nurse could view a patient's record only if they were assigned to that patient's unit that shift, which isn't something you can model as a fixed role without creating a new role for every possible unit and shift combination.
7. What is SCIM, and how does it change user provisioning compared to manual account creation?
Why they ask: SCIM is the standard most large IAM implementations run on, and they want to know you've used it, not just heard the acronym.
How to answer: Describe what SCIM automates and a concrete before-and-after.
Sample answer: SCIM is a standard protocol for creating, updating, and deactivating user accounts across systems automatically, instead of an admin manually creating an account in every app a new hire needs. Our HR system triggers a SCIM call to each connected app the moment a new employee's start date is confirmed, provisioning their account with the right group memberships based on department and role. Before we set this up, provisioning was a manual checklist across 12 apps that took an IT admin about 2 hours per new hire, and it was where deprovisioning delays for departing employees usually happened, since a busy admin might not get to it the same day.
8. How do you design multi-factor authentication so it improves security without users bypassing it?
Why they ask: MFA fatigue is a real design problem, and they want to know you've thought past "just turn it on."
How to answer: Name a specific factor choice and a policy detail that reduces bypass.
Sample answer: I avoid SMS as a factor where possible, since it's vulnerable to SIM swapping, and I push number matching over simple push approval, since a push a user can approve with one tap is exactly what MFA fatigue attacks exploit. I also set up risk-based policies so MFA prompts less often for a known device on a known network and more for a new device or an impossible-travel login, rather than prompting every single time regardless of risk, since constant prompting is what trains users to approve without reading. On one rollout, switching from push-only to number matching cut a specific attack pattern, employees approving prompts they didn't request, to zero over the following 6 months.
9. What's the difference between Okta and Microsoft Entra ID, and how would you decide between them?
Why they ask: These are the 2 most common identity platforms, and they want your actual decision criteria.
How to answer: Name what each does well and a factor that would tip the decision.
Sample answer: Okta is a standalone identity provider built to connect to almost any application through pre-built integrations, which makes it a strong fit for a company with a mixed vendor stack. Microsoft Entra ID, formerly Azure AD, ties tightly into the Microsoft 365 and Azure ecosystem, including Conditional Access policies and Intune device management, so it's a natural fit for a company already standardized on Microsoft. I'd lean toward Entra ID for a company that's Microsoft-first end to end, and toward Okta for a company with a wider mix of vendors or one already invested in Okta's integrations, since re-platforming an existing SSO setup causes enough user disruption that I wouldn't recommend it without a real reason.
10. How do you run an access review, and what do you do about a manager who approves everything without checking?
Why they ask: Access reviews are only useful if people actually look, and they want your process for that specific failure mode.
How to answer: Describe the review structure and a specific way you catch rubber-stamping.
Sample answer: I run quarterly access reviews where each manager gets a list of their team's access to sensitive systems and has to certify or revoke each entry individually, not approve the whole list in one click. To catch rubber-stamping, I sample a few reviews each cycle and cross-check them against actual usage logs, and if someone certified access to a system a person hasn't logged into in 6 months, I flag it and follow up directly rather than letting it pass silently. When one manager certified 100% of 40 entries in under 2 minutes, I had a direct conversation about what the review is actually for, and required their next cycle to go through me before being marked complete.
11. What is privileged access management, and how does it differ from regular IAM?
Why they ask: PAM is a distinct discipline within IAM, and they want to know you understand what makes privileged accounts different.
How to answer: Name the specific controls PAM adds beyond standard account management.
Sample answer: Regular IAM manages everyday user access to applications and data. PAM specifically manages accounts with admin-level privileges, domain admins, database root accounts, and service accounts, since a compromised privileged account can do far more damage than a compromised regular user account. A PAM tool like CyberArk vaults those credentials so nobody has the actual password memorized, rotates them automatically, and can grant just-in-time access for a specific task and time window instead of leaving standing admin rights active all the time. It also records privileged sessions, so if someone runs a command as a domain admin, there's a video or keystroke log of exactly what happened.
12. How would you design a joiner-mover-leaver process end to end?
Why they ask: This is a core part of IAM operations, and they want to see you cover all 3 stages, not just onboarding.
How to answer: Walk through each stage and name what triggers it.
Sample answer: For a joiner, the HR system's new-hire record triggers SCIM provisioning that creates accounts and assigns access based on a role template for their job title and department, ready before day one. For a mover, a role or department change in HR triggers a review of their current access against the new role's template, removing anything that doesn't carry over, since access tends to accumulate if nobody actively removes the old permissions during a transfer. For a leaver, the termination date in HR triggers same-day deprovisioning across every connected app, and for anyone with privileged access specifically, I'd also revoke active sessions immediately rather than waiting for the account disable to propagate, since some sessions stay valid until they expire on their own.
13. How do you handle service accounts and machine identities, since they can't use MFA the way a person can?
Why they ask: Non-human identities are a common blind spot, and they want to know you treat them as a real risk, not an exception you ignore.
How to answer: Name specific controls that substitute for MFA on non-human accounts.
Sample answer: I keep service accounts in the PAM vault just like privileged human accounts, with credentials rotated on a schedule instead of a password someone set once and forgot about. Where possible, I move applications to short-lived tokens or a certificate-based identity instead of a static username and password, since a leaked long-lived credential is one of the most common ways an environment gets compromised. I also require an owner on record for every service account, since an account with no owner is the one nobody notices when it should have been retired, and I run a quarterly review specifically for service accounts, separate from the human access review, since they get missed if they're mixed into the same list.
14. What's the principle of least privilege, and how do you actually enforce it rather than just state it?
Why they ask: Everyone can define least privilege; they want to know your mechanism for keeping it true over time.
How to answer: Name a specific practice that prevents access from accumulating.
Sample answer: Least privilege means a user has only the access needed for their current job, no more. I enforce it with role-based templates for provisioning, so new access starts at the minimum for the job, plus a default expiration on any access granted outside that template, so a temporary admin-level permission for a project has a built-in end date instead of turning into permanent access nobody revisits. Access that accumulates from role changes is the harder problem, which is why the review process for movers matters as much as the initial grant: without an active step to remove old access during a transfer, least privilege erodes within a year even if it was correct on day one.
Behavioral questions
15. Tell me about a time you found an access risk during an audit or review.
Why they ask: They want a real example of catching a problem, not a general statement about being thorough.
How to answer: Describe what you found, how you found it, and what you did about it.
Sample answer: During a quarterly review, I noticed a contractor's account still had access to our production database 4 months after their contract ended, since the offboarding ticket had been closed without the database access actually being revoked. I traced it to a gap in our offboarding checklist, which listed the identity provider and email but not database-level roles granted directly outside of SSO. I revoked the access immediately, confirmed there had been no unusual activity on the account in that window, and added database roles to the standard offboarding checklist so the same gap couldn't repeat for other systems provisioned the same way.
16. Tell me about a time you had to push back on a business request for broad access.
Why they ask: This tests whether you'll hold a security line under pressure from a team that wants to move fast.
How to answer: Name the request, the risk, and the alternative you offered.
Sample answer: A sales operations lead asked for admin access to our CRM for her entire team so they could stop filing tickets for every configuration change. I pushed back because CRM admin access includes the ability to export the full customer database and change data retention settings, well beyond what config changes need. I proposed a custom role instead, scoped to the specific settings her team actually changed, which took an extra day to set up with our CRM admin but gave her team the speed they wanted without the export and retention permissions attached. She agreed once she saw the narrower role covered every task her team had actually filed tickets for in the past 3 months.
17. Tell me about an IAM incident you diagnosed and fixed.
Why they ask: They want to see your troubleshooting process on a real identity problem, not a hypothetical.
How to answer: Describe the symptom, your diagnosis, and the fix.
Sample answer: Users across one department suddenly couldn't access several apps through SSO, all around the same time. I checked our identity provider's system log first and saw a spike in authentication failures tied to a specific group, which pointed at a group membership sync issue rather than the apps themselves. It turned out an HR system update had changed that department's name, and our SCIM mapping matched groups by department name rather than a stable ID, so the sync had removed everyone from the group tied to the old name. I restored access manually within 20 minutes, then changed the mapping to use the department's stable ID instead of its name so a future rename wouldn't repeat the problem.
Situational questions
18. An employee is terminated on a Friday afternoon, and IT says the deprovisioning script won't run until Monday. What do you do?
Why they ask: This tests whether you treat access risk as urgent even when the standard process is slower than the situation needs.
How to answer: Describe an immediate manual step and the follow-up to fix the process gap.
Sample answer: I wouldn't wait for Monday. I'd manually disable the account in the identity provider immediately, which cuts off SSO access to every connected app right away, and separately revoke any active sessions and API tokens tied to that account, since a disabled login doesn't always kill a session that's already active. I'd confirm with the manager whether the termination was contentious enough to warrant checking recent file access or downloads before Monday. After the immediate risk was handled, I'd raise the automation gap directly: a deprovisioning process that only runs on a schedule isn't sufficient for same-day terminations, and I'd push for a manual override path that any on-call admin can trigger.
19. A vendor needs temporary access to one internal system for a 2-week project. What's your approach?
Why they ask: Temporary access requests are common and easy to get wrong by either over-granting or forgetting to revoke.
How to answer: Describe scoping the access narrowly and setting an automatic expiration.
Sample answer: I'd create a scoped role limited to exactly the system and permissions the project needs, not a copy of an existing employee role that happens to include that system among other things. I'd set the account with a hard expiration date matching the project's end, so access ends automatically instead of depending on someone remembering to revoke it. I'd also require the vendor to use MFA and, if the system holds sensitive data, route their access through PAM so the session is logged. If the project runs long, extending the expiration is a deliberate action someone has to take, not a default.
20. Users are complaining that MFA prompts are excessive, and some are approving push notifications without checking. What do you do?
Why they ask: This tests whether you'll fix the actual design problem instead of just telling users to be more careful.
How to answer: Name a specific policy change that reduces prompt fatigue without weakening security.
Sample answer: I'd move from push-only approval to number matching, so a user has to enter a code shown on the login screen rather than tap approve on a notification, which removes the one-tap habit that causes accidental approvals. I'd also set up risk-based authentication so a known device on a known network doesn't prompt as often, reserving frequent prompts for genuinely unusual logins, since prompting everyone constantly regardless of risk is what causes the complaints in the first place. I'd track approval patterns afterward, since a user who still approves prompts without reading even with number matching in place is worth a direct conversation about what to do if a prompt they didn't request shows up.
Questions to ask the interviewer
- What identity provider does the team use today, and is there a migration planned?
- How is provisioning handled for apps that don't support SCIM?
- What does the access review process look like, and how often does it actually happen versus how often it's supposed to?
- How is privileged access managed here, and is there a PAM tool in place?
- What's the current state of MFA coverage, and are there any exceptions still using a weaker factor like SMS?
- What's the biggest identity-related risk the team is dealing with right now?
How to prepare
- Know SAML and OIDC well enough to draw the flow, not just recite the acronyms, since interviewers often ask you to describe the handshake.
- Bring specific examples of RBAC and ABAC decisions you've made, including a case where a role-based model wasn't enough.
- Review how SCIM provisioning actually works if you haven't implemented it directly, since it's central to most modern IAM setups.
- Know the difference between IAM and PAM cold, including what just-in-time access and session recording actually do.
- Practice a joiner-mover-leaver walkthrough out loud, since it's one of the most common design questions in this interview.
If you're preparing for adjacent security and infrastructure roles, our security engineer interview questions and cloud architect interview questions guides cover related ground, AWS networking interview questions is useful if the role touches cloud network security, and data architect interview questions is worth a look if governance and access control cross into data systems too.