IAM Engineer Interview Questions 2026

Last updated: October 10, 2026

By Jennifer Burdick, Recruiting Manager, KORE1

IAM engineer interview questions in 2026 should spend most of the hour on tokens, consent grants, and non-human accounts, because that is where the identity breaches of the last three years actually happened. Definitions are what the candidate studied. Breaches are what the candidate will face.

A card servicing company in Wilmington, Delaware, learned that in the spring. About 1,400 people, a Microsoft shop, Entra ID for workforce sign-on and SailPoint for governance. They hired a senior IAM engineer at $178,000 after a loop that went beautifully. The panel asked him to explain the difference between authentication and authorization. He did. SAML versus OIDC. Clean. Role-based versus attribute-based access control, with an example from his last job. Everyone on the panel scored him a four out of four. Easy call.

Four months later a contractor in collections clicked a phishing link and typed her password into a fake sign-in page.

The help desk reset the password within the hour. Fast. Good. The new engineer confirmed the reset, closed the ticket, and went home. Nobody revoked the sessions. Nobody thought to. The attacker had already signed in once, and the refresh token issued to that session kept working for two more days while somebody quietly read her mailbox and searched it for the word “wire.” A contractor on the infrastructure team found it on a Thursday because a mailbox rule looked strange.

Not a stupid engineer. A well-interviewed one.

The loop had tested whether he knew what a token was. It never asked what happens to one after the password changes, and that was the only question the job ever put to him that spring.

I have recruited for identity seats at KORE1 since the job was mostly resetting Active Directory passwords and arguing about group naming conventions. Those searches now run through our IAM engineer staffing desk, and the calls I get after a bad identity hire sound a lot like the one from Wilmington.

Where I stand, financially. KORE1 is paid when a client hires an engineer we introduced, so I want your search to end in a hire. The questions below work just as well on a candidate who came through your own referral program. Use them there too.

What the Hour Is Supposed to Find

An IAM engineer interview is a structured evaluation of whether a candidate can build and run the systems that decide who and what can reach your applications. The useful version puts token handling, application consent, MFA coverage, and workload identity in front of the candidate as real failures. A certification exam already checked the definitions.

I read the pages that rank for this search before writing this one. TechTarget has fifteen questions. Pomerium has forty. Over on Glassdoor, one IAM candidate wrote that a panel had him sketch the HTTP requests behind a login. Others got authentication versus authorization, again. None of those pages mention Okta’s 2023 support breach, Midnight Blizzard, or the 165 Snowflake customers. They were written for candidates who are preparing, and for that job they are fine.

For a hiring manager in a SailPoint and Entra ID shop, they are close to useless. Your three finalists read the same forty questions the night before. So the panel hears the same answers. Polished, correct, and identical. Every time.

Whether the seat should exist, which of the five identity jobs you are actually hiring for, and how to run a thirty-day search are covered in our guide to hiring an IAM engineer, along with five screening questions about terminations, access reviews, and orphaned service accounts that I will not repeat here. Pay belongs to the IAM engineer salary guide. This page assumes the req is scoped and you have three or four candidates who all know the vocabulary.

They always know the vocabulary.

Six Breaches, Read as Interview Questions

Every question below comes from an incident that was investigated in public, with a written account from the company or a government review board. That matters. Twice over. The candidate cannot dismiss the scenario as unrealistic, and you can check their reasoning against what actually happened. You are not grading whether they remember the news. You are grading what they would check on Monday.

The Session That Outlived the Password Reset

The question: “A user’s password was reset an hour ago after a phishing report. The attacker is still reading her mail. How is that possible, and what do you do in the next ten minutes?”

Between September 28 and October 17, 2023, an attacker inside Okta’s customer support system downloaded files that 134 customers had uploaded with their support cases. Some of those were HAR files, browser recordings that troubleshooting often asks for, and some of them contained live session tokens. According to Okta’s own root cause write-up, those tokens were used to hijack sessions at five customers. No password needed. The session already existed.

A strong candidate separates the password from the session in the first sentence. They will talk about revoking refresh tokens and signing the user out everywhere, which in Entra ID means revoking sessions for the user and not only resetting the credential. Then they go further. They check for new mailbox forwarding rules, new MFA methods the attacker may have registered, and any OAuth app the user consented to in the last day, because each of those survives a password change too. The best answer I have heard ended with “and then I want to know why our help desk runbook stops at the reset.”

A weak candidate says “reset the password and force MFA.” That is the Wilmington ticket. Closed too early.

A Test Tenant Nobody Remembered

The question: “Find every application in our tenant that can read every mailbox. How long does that take you, and what exactly do you run?”

In January 2024 Microsoft disclosed that the group it tracks as Midnight Blizzard had password-sprayed its way into a legacy, non-production test tenant account that did not have MFA. Microsoft’s guidance for responders describes what came next. The attacker found an old test OAuth application with elevated access to the corporate environment, created more applications, and used them to obtain the Exchange Online full_access_as_app role. That role reads mailboxes. All of them. Quietly.

This question sorts people fast. Really fast. Delegated permissions act as a signed-in user. Application permissions act as the application itself, with no user present, and an application permission on mail is a skeleton key. Candidates who have done this work know the difference without being asked and will go straight to the service principals and their app role assignments, usually with Microsoft Graph PowerShell. Some will mention that Microsoft’s own guidance names EWS.full_access_as_app and EWS.AccessAsUser.All as the permissions to review first. Good candidates also ask who can grant admin consent in your tenant, which is the question behind the question.

Then ask how long. “An afternoon” is honest. Fine. “I would open a ticket with the vendor” is not an answer.

The Key That Should Have Been Retired in 2021

The question: “One of our internal APIs accepts tokens from our identity provider. Tell me every single thing it should check before it trusts one.”

The Storm-0558 intrusion is the reason this question exists. The Cyber Safety Review Board’s report, released in April 2024, found that the attackers forged authentication tokens with a Microsoft consumer signing key created in 2016, a key that should have been retired years earlier. They used those tokens to reach the Exchange Online mailboxes of 22 organizations and more than 500 individuals. Part of the failure was that the forged consumer tokens were accepted where only enterprise tokens should have been.

Listen for a checklist that comes out in order, because the people who have built token validation recite it that way. Signature against the published signing keys. Issuer. Audience. Expiry and not-before. Then the subtler ones: whether the key that signed it belongs to the tenant you expect, whether the token type is right for this API, and what the app does when the identity provider rotates its keys. Anyone who says “the library handles that” should be asked which library and which version.

Some will not get past audience. That is common. Plenty of working engineers never had to.

Seven Hundred Companies and One Chat Widget

The question: “Which third-party tools hold a refresh token into Salesforce or Microsoft 365 right now? Who approved each one, and what scopes did they get?”

From August 8 to August 18, 2025, a group tracked as UNC6395 used OAuth tokens stolen from Salesloft’s Drift chat integration to pull data out of customers’ Salesforce instances. Google’s Threat Intelligence Group later widened its advisory to tell customers to treat every authentication token stored in or connected to Drift as compromised, and it told reporters that more than 700 organizations were potentially affected. The attackers were not after the CRM data for its own sake. They searched it for secrets, especially AWS access keys, passwords, and Snowflake tokens that had ended up inside records like support cases.

No one phished anybody. A vendor held a token. The vendor was breached. That was enough.

Most candidates have never been asked to own this inventory, and that is fine. What you want is how they would build it. Connected apps in Salesforce, enterprise applications and their consent grants in Entra ID, the OAuth app list in Google Workspace, and somebody in procurement who knows which tools were bought on a credit card. Strong answers bring up refresh token lifetimes, IP restrictions on integration users, and the idea that an integration should get its own user with the narrowest profile you can give it. The very best candidates will say, a little uncomfortably, that the answer is probably a spreadsheet today and that they would fix that before anything else.

Passwords From 2020

The question: “Which of our systems still accept a username and password without going through SSO?”

Short question. Long silence, usually. In 2024 a group Mandiant tracks as UNC5537 stole data from roughly 165 organizations’ Snowflake instances. According to Mandiant’s investigation, the attackers simply signed in with credentials harvested by infostealer malware, some of it dating back to 2020, on accounts that had no MFA. At least 79.7 percent of the accounts used had prior credential exposure. Snowflake itself was not breached. The customers’ local accounts were the door. Wide open.

Every enterprise has these. Yours too. The data warehouse service user, the vendor portal from 2019, the break-glass admin that has to work when SSO is down. A good candidate knows that SSO coverage is not the same as MFA coverage and can describe how they would find the local accounts nobody migrated. A great one asks which of them are break-glass on purpose, and how those are vaulted and watched.

One Remote Access Portal

The question: “How would you prove to an auditor that MFA covers one hundred percent of our external entry points? Not that the policy says so. That it does.”

In written testimony to the House Energy and Commerce Committee in May 2024, UnitedHealth Group’s chief executive stated that the attackers behind the Change Healthcare ransomware attack used compromised credentials on February 12, 2024, to reach a Citrix remote access portal that did not have multifactor authentication. One portal. One password.

The policy-versus-proof framing is the whole point. A candidate who answers with the conditional access policy has described intent. A candidate who answers with sign-in logs filtered to single-factor successes, a list of policy exclusions with an owner next to each, and an external scan of every login page the company exposes has described evidence. Ask the second kind how often they would rerun it.

The Pipeline That Logs In as Production

This last one is not a breach story. It is a configuration that turns up again and again in security research, and it belongs on the list because almost nobody interviews for it.

The question: “Our deploy pipeline in GitHub Actions assumes an AWS role through OIDC instead of using stored keys. What in the role’s trust policy decides which workflows can assume it?”

The answer is the subject claim. Just that. GitHub’s documentation for OIDC in AWS tells you to evaluate the token’s sub condition in the trust policy so that only specific repositories and branches can assume the role. Teams write a wildcard during setup because the exact value is fiddly, then never come back. A trust policy that matches every repository in the organization lets any of them deploy to production.

Candidates from a pure workforce identity background may never have seen one of these. That is all right. Hand it to them anyway, and watch whether they reason toward the sub claim or give up. For a seat that will touch cloud roles, our cloud security engineer staffing desk sees this question decide more offers than any other.

A Packet of Three Artifacts

Questions tell you how a person talks. An artifact tells you how they read. For the second round, print three short artifacts, each with one flaw planted in it, and give the candidate thirty minutes and a pen. No laptop. No phone. Nobody helps.

An insurance carrier in Cedar Rapids, Iowa, started doing this after two senior hires in a row could explain conditional access beautifully and could not find a hole in a policy that had been sitting in their own tenant for three years. Their third candidate found all three flaws in nineteen minutes, then found a fourth one they had not planted. They hired her that week.

Artifact one is a decoded access token. The candidate is told it was presented to the claims portal API.

{
  "iss": "https://login.microsoftonline.com/{tenant-id}/v2.0",
  "aud": "api://payments-ledger",
  "scp": "Ledger.ReadWrite",
  "iat": 1760090400,
  "exp": 1762682400,
  "appid": "{client-id}",
  "sub": "{user-object-id}"
}

There are two problems, and the order a candidate finds them in is interesting. The audience is the payments ledger, not the claims portal, so the claims API should reject it outright. The quieter one is the lifetime. Subtract iat from exp and you get 2,592,000 seconds. Thirty days. For an access token. Most identity providers default to about an hour.

Artifact two is a conditional access policy, written out as plain text.

Name:          Require MFA for all users
Users:         Include all users
               Exclude grp-svc-legacy-sync, grp-test-accounts
Target apps:   All cloud apps
Client apps:   Browser; Mobile apps and desktop clients
Grant:         Require multifactor authentication
State:         On

The exclusions are the obvious flaw. Start there. Who is in them, who owns them, and when were they last reviewed? Midnight Blizzard walked in through a test account. The less obvious flaw is the client apps line, which leaves out Exchange ActiveSync and the other legacy clients that cannot do MFA at all. A strong candidate asks whether legacy authentication is blocked by a separate policy before they call it a hole.

Artifact three is the condition block from an AWS role trust policy.

"Condition": {
  "StringEquals": {
    "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {
    "token.actions.githubusercontent.com:sub": "repo:claims-platform/*"
  }
}

The role deploys to production. Read that twice. The wildcard lets any repository in the organization, on any branch, assume it.

Grade the explanations. Not the count. A candidate who finds two flaws and explains exactly how each would be exploited is a stronger hire than one who circles all three and cannot say why they matter.

What a Strong Answer Names

Give this to every panelist before the interview so they score the same things. Most of the panel will not be identity specialists, and they do not need to be. They need to know what words to listen for. Nothing more.

Adjusting the Set for the Seat You Are Filling

Not every identity hire needs all seven. Few do. The hire guide breaks the title into five different jobs, and the weighting should follow the job.

• A governance engineer on SailPoint or Saviynt should get the consent inventory question and the MFA proof question, then spend the rest of the round on a certification campaign they designed.
• Privileged access. Use the break-glass part of the Snowflake question and stay there for twenty minutes, because vaulting the accounts that must work when everything else is down is most of the job.
• For federation and SSO seats, the token validation question is the one that separates people, and the conditional access artifact is the exercise.
• Customer identity engineers on Auth0 or Okta Customer Identity live in refresh tokens. Ask the reset question, then ask how they would detect a stolen refresh token being replayed. RFC 9700, the OAuth 2.0 security best practice the IETF published in January 2025, requires the authorization server to either rotate the refresh tokens it gives public clients or bind them to the client. They should know which one their last product did.
• Workload identity: the pipeline question, the third artifact, and nothing else matters as much.

On level. An identity analyst should be able to reason through the reset question and the MFA proof question, and nobody should expect them to recite token validation. A senior engineer, the kind who usually lands between $150,000 and $200,000 base, should handle six of seven without long pauses. If the role is a defined migration with an end date, a contract identity engineer is often the better buy, and the packet works for contractors just as well. For a permanent seat that will own the program, the loop belongs inside a direct hire search with a second round long enough for the artifacts.

If you want overlapping material for the broader security team, our security engineer interview questions cover design and incident response, which these mostly skip.

What the CISO Wanted Settled Before Approving the Loop

Should the panel still ask the textbook definition questions at all?

One or two, on the phone screen, only to save everybody time when a candidate does not know the basics.

Authentication versus authorization takes thirty seconds and filters out the occasional résumé that was written by someone else. After that it has done its job. Spending a technical round on definitions tells you who prepared, and every finalist prepared.

Realistically, how many of these fit in one round?

Short answer: four questions in a sixty-minute technical round, if the panelist asks short follow-ups and mostly listens.

Pick the four that match the seat. Run the artifact packet as its own thirty-minute block in round two, with a different panelist, so you get two independent reads on the same person. Two rounds is plenty. Really. Identity candidates who are any good are in more than one process, and a four-round loop loses them.

Our stack is Okta, not Entra ID. Do the Microsoft questions still apply?

The mechanics transfer completely, and only the vocabulary and the admin screens change.

Okta has sessions that survive password changes, API tokens and OAuth grants that need an inventory, and admin consoles that can be reached with a stolen session. Okta’s own remediation after 2023 included binding administrator session tokens to network location, which makes a good follow-up for an Okta candidate. Rewrite the second artifact as an Okta authentication policy and keep everything else.

Is it fair to ask about breaches the candidate never worked on?

Yes, as long as the panel grades reasoning about your environment and not recall of the news story.

Tell the candidate the facts of the incident before you ask the question. Then ask what they would check in your tenant. Somebody who never heard of Storm-0558 but walks through issuer, audience, and key checks in the right order is a better hire than somebody who can recite the review board’s findings and stops there.

What if a candidate finds a flaw in the packet we did not plant?

Hire them, usually, and then go fix the flaw, because it probably came from your real configuration.

It happens. More than you would expect. Most panels build the artifacts by copying something from their own tenant and changing a few values, and real configurations carry real mistakes that nobody has looked at since the consultant who first set up the tenant moved on to another client. The Cedar Rapids candidate found a token lifetime policy nobody remembered setting.

Do the questions change if the role touches AI agents?

They get sharper rather than different, because an agent is one more non-human identity holding tokens and consent grants.

Add one follow-up to the third-party token question. What would the candidate grant an agent that acts on a user’s behalf, and how would they cut it off without cutting off the user? Candidates who have thought about this tend to answer with scopes and expiry. The ones who have not tend to answer with a product name.

Put a Real Token on the Table

The Wilmington company ran its next identity search with the reset question first. Their second finalist answered it in about four minutes. She separated the password from the session before the panelist finished reading the question, listed the inbox rule check without being prompted, and then asked whether their help desk could revoke sessions or had to escalate. They could not. She started in August. That was her first project.

Most of the loop was the same as before. One question changed. So did the hire.

If you would like a second set of eyes on the artifact packet, or want us to run the first technical screen before your panel meets anyone, reach out to our identity recruiting team. KORE1 has placed security and identity people across more than 30 U.S. metros since 2005, and 92 percent of the people we place are still on the client’s payroll twelve months after they start.