IAM engineer interviews are lost on the follow-up question, not the first one: most candidates can say what SAML is, far fewer can explain why an assertion was rejected or why a service account still had access after its owner left. This guide gives the questions hiring managers ask across federation and SSO, OAuth and OpenID Connect, authentication, lifecycle and governance, privileged and non-human identities, and design scenarios, with model answers that show the depth expected. It is for candidates preparing for IAM engineer, identity architect and IGA analyst roles, and for hiring managers building a consistent question bank. Answers are vendor-neutral: an interviewer may ask about the platform you used, but the reasoning they test is the same on any product. For the role itself, routes in and progression, see the IAM Engineer Career Guide.
Key takeaways
- Explain the flow, then the failure. A strong answer describes who sends what to whom, then names the check that stops an attack or the error you would see when it breaks.
- Know the current standards by name. RFC 9700 (OAuth 2.0 Security Best Current Practice), NIST SP 800-63B-4 and SCIM (RFC 7643 and 7644) are the references interviewers expect a 2026 candidate to cite.
- Governance questions test judgement, not tools. Expect to defend how you would run an access review that people actually complete, and how you would handle accounts nobody owns.
- Non-human identities are now standard questions. Service accounts, API keys, workload identity federation and AI agent credentials appear in most senior IAM interviews.
- Scenarios carry the most weight. Practise one design question and one incident question out loud, with trade-offs and a rollback plan.
How IAM engineer interviews are structured
| Round | What is assessed | How to prepare |
|---|---|---|
| Recruiter or hiring manager screen | Scope of past work: number of users and apps, platforms, which part of the lifecycle you owned | Have numbers ready: apps federated, identities in scope, reviews run, time saved |
| Protocol and fundamentals | SAML, OIDC, OAuth 2.0, SCIM, Kerberos, MFA; can you read a token or assertion | Walk each flow on paper; decode a sample JWT and SAML response |
| Governance and process | Joiner, mover, leaver; access reviews; segregation of duties; audit evidence | Prepare one story where a review or JML change reduced real risk |
| Design scenario | Architecture judgement, trade-offs, phasing, rollback | Practise a 30-minute whiteboard: SSO for 200 apps, or removing service account keys |
| Troubleshooting or incident | Diagnosis method under pressure | Rehearse "user cannot sign in" and "token stolen" from first log to fix |
| Behavioural | Working with app owners, auditors and security; saying no constructively | Two or three situation, action, result stories |
Federation and SSO questions
Q: Walk me through an SP-initiated SAML 2.0 sign-in. Model answer: the user requests the service provider, which builds an AuthnRequest and redirects the browser to the identity provider. The IdP authenticates the user, builds a Response containing an Assertion with a Subject (NameID), Conditions (NotBefore, NotOnOrAfter, AudienceRestriction) and an AuthnStatement, signs it and posts it back to the SP's Assertion Consumer Service URL through the browser. The SP validates the signature against the IdP certificate it holds, checks the audience, the time window and that the InResponseTo matches its request, then creates a session. Strong candidates add that the browser carries the assertion, so the SP must never trust anything in it that is not covered by the signature.
Q: What is the difference between IdP-initiated and SP-initiated SSO, and why do some teams disable IdP-initiated? Model answer: IdP-initiated has no AuthnRequest, so there is no InResponseTo to bind the response to a request the SP made. That makes replay and login-CSRF style issues harder to rule out. Where the app supports it, prefer SP-initiated and keep IdP-initiated only for portals that need it.
Q: A SAML login fails after the IdP signing certificate was rotated. What do you check? Model answer: whether the SP has the new certificate or metadata, whether the IdP rotated before the SP was updated, and the clock skew on the SP. Fix by publishing the new certificate as secondary first, updating SPs, then switching. See the SAML SSO Errors Troubleshooting Guide.
Q: What is Golden SAML and how would you detect it? Model answer: an attacker who steals the IdP token-signing key can mint assertions for any user and any app without touching the IdP. Detection compares SP sign-ins with IdP authentication events: a session at the app with no matching IdP sign-in is the signal. Prevention is protecting the signing key in an HSM or managed service and treating the federation server as tier zero. See the Golden SAML and Federation Trust Abuse Defence Guide.
Q: When would you choose OIDC over SAML for a new app? Model answer: OIDC for new web, mobile and API-heavy apps, because it is JSON and JWT based, works natively with OAuth access tokens, and suits native clients. SAML where the app only supports SAML or the enterprise integration is already standard. See the SAML vs OIDC Guide.
OAuth 2.0 and OpenID Connect questions
Q: What is the difference between an ID token and an access token? Model answer: an ID token is an OpenID Connect JWT for the client, describing the authentication event, with required claims iss, sub, aud, exp and iat. An access token is for the resource server, to authorise an API call; its format is up to the authorisation server. A client must not send the ID token to APIs as if it were an access token, and an API must not accept tokens whose audience is not itself.
Q: Which OAuth grant types would you allow in 2026, and which would you block? Model answer: authorization code with PKCE for user-facing apps, client credentials for service-to-service, device authorization for input-constrained devices, and refresh tokens with rotation or sender-constraining for public clients. Block the implicit grant and the resource owner password credentials grant: RFC 9700 says clients should not use implicit and the password grant must not be used. See the OAuth 2.1, GNAP and FAPI Guide.
Q: What does PKCE protect against, and who needs it? Model answer: interception of the authorisation code. The client sends a hashed code_challenge (S256) with the authorisation request and the original code_verifier when redeeming the code, so a stolen code is useless on its own. RFC 9700 requires PKCE for public clients and recommends it for confidential ones, and requires authorisation servers to reject a code_verifier when no challenge was sent.
Q: What is the nonce in OIDC for? Model answer: it binds the ID token to the client's session and mitigates replay. The client sends it in the request, the server returns it unchanged in the ID token, and the client must check it.
Q: Why does exact redirect URI matching matter? Model answer: pattern or prefix matching lets an attacker register or find a URI that passes the check and receive codes or tokens. RFC 9700 requires exact string matching, with an exception only for localhost ports in native apps.
Q: A user granted a third-party app access to mail. How would you find and remove risky grants? Model answer: list OAuth consent grants and their scopes from the IdP or SaaS admin API, flag high-risk scopes and unverified publishers, restrict user consent to verified publishers and low-risk scopes, and route the rest through admin consent. See the Consent Phishing and Illicit OAuth Grants Guide.
Authentication and MFA questions
Q: What does NIST SP 800-63B-4 change about passwords? Model answer: single-factor passwords must be at least 15 characters, passwords used only within MFA at least eight, no composition rules and no forced periodic change, with a change required when compromise is suspected. Candidates who still recommend 90-day expiry should expect a follow-up.
Q: What makes an authenticator phishing-resistant, and what does AAL3 add? Model answer: the authenticator binds its output to the origin or channel, so a relayed login fails; FIDO2 and WebAuthn passkeys and PKI smart cards do this, push and SMS codes do not. Under SP 800-63B-4, AAL2 verifiers must offer a phishing-resistant option and AAL3 requires a phishing-resistant authenticator with a non-exportable key, so syncable passkeys are allowed at AAL2 but not AAL3. See the Passwordless and Passkeys Guide.
Q: How would you handle MFA fatigue attacks? Model answer: number matching and context in push prompts, rate limits on prompts, alerting on repeated denials, and moving privileged users to phishing-resistant methods. Then fix the recovery path, because attackers move to the help desk. See the MFA Fatigue and Bypass Guide.
Q: Explain Kerberos in two minutes. Model answer: the client gets a ticket-granting ticket from the KDC, then uses it to request service tickets for each service, which the service validates with its own key. Follow-ups cover Kerberoasting (service tickets encrypted with a service account's password hash, so weak service account passwords crack offline) and delegation types. Strong candidates mention gMSA for service accounts. See the Kerberos Security Guide.
Lifecycle and identity governance questions
Q: Design joiner, mover and leaver for a company with an HR system and 300 SaaS apps. Model answer: HR is the authoritative source; changes flow into the IdP, which provisions to apps through SCIM where supported (RFC 7644 defines the /Users and /Groups endpoints and PATCH for partial updates) and through tickets or connectors where not. Birthright access is role based; anything else is requested and approved. The mover case matters most: remove the old role's access, do not only add the new one. Leavers are disabled in the IdP immediately, with sessions and tokens revoked. See the Joiner-Mover-Leaver Guide and the SCIM Provisioning Guide.
Q: Access reviews have a 98% approval rate. Is that good? Model answer: probably not; it usually means rubber-stamping. Reduce what reviewers see (only privileged and changed access), show last-use data, revoke automatically when a reviewer does not respond for high-risk access, and measure the revocation rate. See the Access Reviews Guide.
Q: How do you implement segregation of duties? Model answer: define toxic combinations with the business (create vendor and approve payment), enforce them preventively at request time, detect existing violations, and record approved exceptions with compensating controls and an expiry.
Q: When would you use RBAC, ABAC or relationship-based access? Model answer: RBAC for coarse, stable job functions; ABAC when decisions depend on context like department, data classification or location; ReBAC for sharing models such as documents and folders. Most estates combine them. See the Authorisation Models Guide.
Privileged and non-human identity questions
Q: How would you reduce standing admin access? Model answer: inventory privileged roles, move them to just-in-time elevation with approval and time limits, separate admin accounts from daily accounts, vault the break-glass accounts and alert on every use. See the Privileged Access Management Guide.
Q: You find 4,000 service accounts and nobody knows who owns half of them. What do you do? Model answer: build the inventory from directories, cloud IAM and secrets stores; assign owners from creator, last change and consuming application; disable unowned accounts in stages after a notice period, with a fast re-enable path; then require an owner and expiry at creation. See the How to assign owners to orphaned service accounts guide.
Q: How would you remove long-lived cloud keys from CI pipelines? Model answer: use OIDC workload identity federation so the pipeline exchanges its own short-lived token for cloud credentials, bound to repository, branch or environment claims; then disable key creation by policy. See the GitHub Actions OIDC Federation Hardening Guide.
Q: How should an AI agent authenticate to internal APIs? Model answer: with its own identity, not a shared user's token; short-lived, scoped credentials; delegation recorded so actions trace back to the user who asked; and the same owner, review and revocation rules as any NHI. See the Identity Governance for AI Agents Guide.
Scenario questions and what a strong answer contains
| Scenario | Weak answer | Strong answer includes |
|---|---|---|
| Migrate 200 apps to a new IdP | "Move them all over a weekend" | App inventory by protocol and risk, pilot wave, parallel trust, cut-over per app with rollback, user communications |
| Session token stolen from a user's browser | "Reset the password" | Revoke sessions and refresh tokens, review sign-ins and grants made during the window, check for new MFA methods or mailbox rules, token binding or shorter lifetimes after |
| Auditor asks for evidence of leaver removal | Screenshots | HR termination dates joined with disable timestamps from logs, exceptions explained, sample of downstream apps |
| App owner refuses SSO | Escalate immediately | Understand the blocker, offer a phased route, record the risk with an owner and date |
| Help desk social-engineered into an MFA reset | "Train the help desk" | Verified identity proofing for resets, callback to a known number, alerting on reset followed by new device, step-up for privileged users |
Standards interviewers expect you to know
| Topic | Standard or framework | What to be able to say |
|---|---|---|
| OAuth security | RFC 9700 (BCP 240, January 2025) | PKCE, no implicit or password grant, exact redirect matching, refresh token protection |
| Identity tokens | OpenID Connect Core 1.0 | ID token claims, nonce, authorisation code, implicit and hybrid flows |
| Provisioning | SCIM, RFC 7643 and RFC 7644 | Resources, endpoints, PATCH, filtering |
| Authentication assurance | NIST SP 800-63B-4 | AAL1 to AAL3, phishing resistance, password rules, syncable authenticators |
| Access control | NIST SP 800-53 Rev. 5 AC-2, AC-5, AC-6; NIST CSF 2.0 PR.AA | Account management, separation of duties, least privilege |
Questions to ask the interviewer
- Scope: which identity types the team owns: workforce, customer, privileged, non-human.
- Source of truth: how HR data reaches the IdP, and how reliable it is.
- Coverage: what share of apps use SSO and automated provisioning today.
- Governance: who signs off access reviews, and what happens when nobody does.
- Machine identities: who owns service accounts and secrets, and whether there is an inventory.
Common failure patterns in IAM interviews
- Product-only answers: describing menus in one console without explaining the protocol underneath.
- Outdated guidance: recommending forced password expiry or the implicit grant.
- Forgetting the mover: JML answers that only cover joiners and leavers.
- No rollback: design answers with no pilot, no fallback and no communication plan.
- Ignoring machine identities: treating service accounts as someone else's problem in a role that will own them. See the Service Account Security Guide.
Practitioner checklist
- Draw SAML SP-initiated, OIDC authorization code with PKCE and client credentials flows from memory.
- Decode a sample JWT and a SAML response and name every security-relevant field.
- Learn the RFC 9700 recommendations and the SP 800-63B-4 password and AAL rules.
- Prepare one JML story, one access review story and one incident story with measurable results.
- Practise a 30-minute design scenario out loud, including phasing and rollback.
- Prepare an answer on service accounts, API keys and workload identity federation.
- Prepare three questions for the interviewer about scope and governance.
- Hiring managers: score answers on the same rubric for every candidate, with the strong-answer column above as a guide.
Standards and references
- IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
- OpenID Foundation: OpenID Connect Core 1.0
- IETF: RFC 7644 System for Cross-domain Identity Management: Protocol
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: IAM Engineer Career Guide · Cyber Security Interview Preparation Guide · IAM and IGA Basics · SAML Security Guide