8. Interview Questions

A cloud identity provider and directory. It stores an organisation's users, groups, devices, and applications, and issues short-lived, signed OAuth 2.0 / OpenID Connect tokens that relying parties verify.

The problem: without a shared directory, every application keeps its own credential store — many password databases, many offboarding processes, and no single place to enforce policy. Entra ID centralises authentication so that applications verify a signature rather than a password, and so that revoking access once affects everything.

Say the rename: it was Azure Active Directory until 2023. Same product, same APIs.

Strong answers add the distinction that it does authentication, and that authorisation is a separate concern handled by Azure RBAC for resources, directory roles for the directory, and app roles for applications.

A tenant is one Entra ID directory — the identity and policy boundary, identified by a GUID. A subscription is a billing and blast-radius boundary for Azure resources, and it trusts exactly one tenant for authentication. A tenant can own many subscriptions. Below the subscription sit management groups (above, actually), resource groups, and resources.

The consequences worth stating:

• Identity is above subscriptions, not inside them. There's no per-subscription directory.
• Moving a subscription to a different tenant breaks every role assignment and every managed identity in it, because those principals existed in the old directory.
• Entra ID itself is not an ARM resource and doesn't live in a resource group.

See the scope hierarchy.

Two separate systems.

Directory roles (Global Administrator, User Administrator, Application Administrator) govern directory objects. They live in Microsoft Graph and are scoped to the tenant or to an administrative unit.

Azure RBAC roles (Owner, Contributor, Key Vault Secrets User) govern Azure resources. They live in Azure Resource Manager and are scoped to a management group, subscription, resource group, or individual resource.

Global Administrator ≠ Owner. A Global Administrator has no inherent authority over Azure resources; an Owner has no inherent authority over the directory. The one bridge is the "Access management for Azure resources" elevation toggle, which grants a Global Administrator User Access Administrator at the root management group — logged, and worth alerting on.

When the users are your product's customers rather than your employees. External ID (formerly Azure AD B2C) provides self-service sign-up, social identity providers, branded and customisable sign-in journeys, and per-monthly-active-user billing rather than per-seat licensing.

The reason it matters architecturally: workforce tenants assume employees. Licensing, Conditional Access scoping, guest-invite semantics, and directory quotas are all built around that assumption. Putting consumers into a workforce tenant is one of the hardest decisions to reverse, because the identities become entangled with the organisation's own directory.

Per user per month for the tier — Free, P1, P2, plus add-ons like Entra ID Governance and Workload ID. External ID bills per monthly active user. Entra Domain Services bills per hour as a real Azure resource. Log Analytics ingestion of sign-in and audit logs is billed per GB.

What keeps billing when idle: the licences. There is no scale-to-zero. A user who never signs in costs the same as one who signs in hourly, which is why stale licence assignments are a real cost line.

The cost trap worth naming: licences are per user who benefits from a feature, and nothing enforces this at configuration time. A Conditional Access policy scoped to "All users" requires P1 for every user in scope — discovered at audit, not at deployment.

Authorisation Code flow with PKCE:

1. The app redirects the browser to /oauth2/v2.0/authorize on the tenant's authority, with client_id, redirect_uri, scope, state, and a PKCE code_challenge.
2. Home realm discovery determines the directory; if the domain is federated, the user is redirected to the external IdP.
3. Credentials are collected — or skipped entirely if the device presents a valid Primary Refresh Token.
4. Conditional Access is evaluated. All matching policies run; blocks win; grant controls are unioned and must all be satisfied.
5. A single-use authorisation code returns to the registered redirect URI.
6. The app redeems the code at /oauth2/v2.0/token with its own credential and the PKCE verifier, receiving an ID token, an access token, and a refresh token.
7. The app calls the API with Authorization: Bearer <access token>.
8. The API validates the token offline — signature against cached JWKS keys, plus iss, aud, exp, and the scp/roles claims. It does not call Entra ID.

Step 8 is the one to emphasise, because everything about token lifetimes and revocation latency follows from it.

Neither plane is ARM, which is the twist.

Control plane: Microsoft Graph (graph.microsoft.com) — creating and modifying directory objects. Governed by directory roles and Graph permissions granted through consent.

Data plane: the token endpoints (login.microsoftonline.com) — authentication and token issuance. Governed by credentials and Conditional Access.

Azure RBAC governs neither. Being Owner on every subscription grants no directory access. The two systems touch at exactly one point: Microsoft.Authorization/roleAssignments is an ARM resource that references an Entra object ID.

The classic mistake has two forms. First, assuming a control-plane role grants data-plane access on other services — being Contributor on a storage account doesn't let you read a blob with your own identity, and Key Vault Contributor doesn't let you read a secret. Second, assuming an Azure role grants directory access, or vice versa. Automation that can create role assignments but can't resolve a service principal's object ID is failing on the directory side while every error message points at ARM.

Delegated (scope, scp claim): the app acts on behalf of a signed-in user. Effective access is the intersection of what the app was granted and what the user can do. Consent may be by the user or an admin depending on the permission.

Application (app role, roles claim): the app acts as itself, no user involved. Access is exactly what was granted, tenant-wide, with nothing capping it. Always requires admin consent.

Why it matters: they look nearly identical in the portal and differ enormously in blast radius. Delegated User.ReadWrite.All does not let a normal user edit everyone — their own permissions still cap it. Application User.ReadWrite.All lets a daemon edit every user in the tenant, full stop.

The practical rule: use delegated permissions whenever a user is genuinely present; use application permissions only for true daemons, and then scope them as narrowly as possible — Application.ReadWrite.OwnedBy rather than .All.

Workload identity federation. Register a federated identity credential on an app registration describing an external issuer, subject, and audience. The pipeline presents an OIDC token from its own platform; Entra ID validates issuer + subject + audience against the registered credential and exchanges it for an access token. No secret exists anywhere.

For GitHub Actions: issuer https://token.actions.githubusercontent.com, audience api://AzureADTokenExchange, subject something like repo:contoso/orders-api:environment:prod. The job needs permissions: id-token: write.

The security control is the subject string. Matching on repo:owner/repo:environment:prod requires the protected GitHub environment, which is what carries the approval gate. Matching on repo:owner/repo:pull_request lets a pull request from any fork authenticate as your production identity. Read the subject on every federated credential you inherit.

Inside Azure, the equivalent is a managed identity, and for AKS it's Entra Workload ID — which replaces the retired AAD Pod Identity.

No — not on every resource, and this is the most important nuance in the whole topic.

Resources validate access tokens offline against cached signing keys. Disabling the account revokes the refresh token, so no new access tokens can be minted, but existing access tokens remain valid until exp — historically up to about an hour ⚠️ verify current defaults.

Continuous Access Evaluation (CAE) is the fix. Participating resources — Microsoft Graph, Exchange Online, SharePoint, and a growing list — subscribe to critical events (account disabled, password changed, high risk, network change) and reject the token in near real time, returning a claims challenge that forces the client to get a fresh one. CAE-aware tokens are deliberately issued with longer lifetimes precisely because they can be killed on demand.

The operational answer to "we've been compromised": disable the account, explicitly revoke sessions (az ad user revoke-sign-in-sessions / Revoke-MgUserSignInSession), reset credentials, review consented applications and any credentials added to app registrations — and treat non-CAE resources as exposed for one token lifetime.

They're two different objects, and "enterprise application" is just the portal's name for one of them.

App registration (applications in Graph) is the global definition: redirect URIs, credentials, requested API permissions, published scopes and app roles. It lives in the tenant that owns the application and has an Application (client) ID.

Service principal (servicePrincipals in Graph), shown in the portal as an enterprise application, is the local instance in a tenant that uses the app: consent grants, role assignments, user assignments, sign-in state. It has its own Object ID.

Blueprint vs. instance. In a single-tenant app they're created together and feel like one thing. In a multi-tenant app there's one registration in the vendor's tenant and one service principal per customer tenant, created on consent — which is why "Microsoft Graph" appears as an enterprise application you never created.

Practically: role assignments and consent attach to the service principal's object ID, not the client ID. Confusing the two is a rite of passage.

The dangerous ones share a property: they change the object ID.

• Deleting and recreating a service principal or a user-assigned managed identity.
• Changing an app_role.id — replaces the role and silently revokes every assignment of it.
• Renaming a Terraform resource address without a moved {} block or terraform state mv, which makes Terraform destroy and recreate.
• Some sign_in_audience transitions ⚠️ verify against current provider documentation.

Why it's worse than replacing, say, a VM: for most resources replacement is a brief outage. For an identity, every reference to the old object ID is now dangling — Azure role assignments across any scope, consent grants, group memberships, app-role assignments, external systems that pinned the object ID. Terraform doesn't see most of those, so the plan looks small and the outage doesn't.

Orphaned role assignments show as "Identity not found" and, worse, an object recreated with the same name does not inherit them — so it looks broken in a way that tempts people to grant broad permissions to make it work.

Mitigations: lifecycle { prevent_destroy = true } on directory objects, hard-coded stable GUIDs for app roles, user-assigned rather than system-assigned identities for anything recreated often, and reading every # forces replacement line in an identity plan as "revokes access for everyone".

The group overage claim.

Group memberships are emitted in the token's groups claim, but only while they fit — past roughly 150 groups for SAML or 200 for JWT ⚠️ verify current values, Entra ID drops the claim entirely and substitutes _claim_names / _claim_sources pointing at a Graph endpoint the application must call to enumerate groups.

An application that authorises on groups and doesn't handle the overage fails for exactly the long-tenured, heavily-permissioned people. It's a fingerprint diagnosis: works for developers, fails for directors.

Confirm it by decoding one of their tokens and looking for _claim_names instead of groups.

Fix it, in order of preference:

1. Authorise on app roles rather than raw group membership. This is the correct design — app roles are emitted in roles, are application-specific, and don't overflow.
2. Configure the group claim to emit only groups assigned to the application.
3. Handle the overage claim properly by calling Graph — the last resort, since it adds a runtime dependency and a throttling surface to every sign-in.

Separate the three identity populations, because conflating them is the mistake:

Your customers' end users. Either (a) your app is a multi-tenant Entra application — one app registration in your tenant, sign_in_audience = AzureADMultipleOrgs, a service principal created in each customer tenant on consent — which is right when customers are enterprises already using Entra ID; or (b) Microsoft Entra External ID, when customers are consumers or use mixed identity providers.

For the multi-tenant path, the non-negotiables: validate tid against an allow-list (a correctly signed token from a tenant you've never heard of is still correctly signed), use the organizations authority rather than common, publish app roles for authorisation rather than relying on the customer's groups, and provide an admin-consent URL so a customer admin can consent once for the whole organisation.

Your own workloads. Managed identities inside Azure, workload identity federation for anything outside. No secrets.

Your own staff. Your workforce tenant, with PIM on anything that can reach customer data, and Conditional Access requiring phishing-resistant MFA and a compliant device for production access.

Tenancy of the data plane is the design question underneath: per-customer database, schema, or row-level isolation — and whichever you pick, the authorisation check must key on the tid claim from the token, never on anything the client sends.

What I'd be nervous about: consent friction (application permissions require admin consent and enterprise customers will read them line by line, so request the minimum), and per-customer Conditional Access policies you can't see and can't control breaking sign-in for reasons that look like your bug.

An illicit consent grant. The user was sent to a genuine, correctly-signed Microsoft consent page for an attacker-controlled application requesting permissions like Mail.Read or Files.Read.All. They consented. No password was stolen and MFA didn't help, because nothing about the flow was fake — the user granted an application access on their own behalf, which the tenant's default settings permitted.

The attacker now holds a refresh token and can read mail without ever authenticating as the user again.

Response, in order:

1. Find the grant. Query AuditLogs for Consent to application in the window; list oauth2PermissionGrants and app-role assignments for the service principal.
2. Revoke the consent and delete the service principal from the tenant.
3. Revoke the user's sessions (az ad user revoke-sign-in-sessions) — deleting the app doesn't invalidate tokens already issued.
4. Scope the damage. Check whether anyone else consented to the same app, and what the app actually accessed — mailbox audit logs, MailItemsAccessed, forwarding rules created.
5. Check for persistence — inbox rules, added credentials on other applications, new federated credentials, new app registrations.

Prevent the recurrence — and this is the part the interviewer is listening for, because it's a configuration change, not a product:

• Restrict user consent to a verified-publisher, low-impact subset, or disable it entirely.
• Enable the admin consent workflow so users can request rather than approve.
• Alert on new consent grants to high-privilege permissions.
• Review existing consents — this attack has often already happened and nobody looked.

Break-glass account. Two cloud-only accounts in the .onmicrosoft.com domain, excluded from every Conditional Access policy, with credentials stored offline. Sign in with one, disable the policy, verify, and only then investigate.

If break-glass doesn't exist or was itself in scope, the honest answer is that you are opening a Microsoft support case, and recovery time is measured in hours you don't control. Say that plainly — an interviewer wants to hear that you know the failure has no self-service path.

Why it happened: a policy targeting All users and All cloud apps, enabled directly rather than in report-only. There's no ordering and no priority in Conditional Access — any matching block terminates the sign-in — so a single over-broad policy is sufficient.

Preventing it:

• Report-only mode for every new policy, always. It's fully evaluated and logged under conditionalAccessStatus without being enforced.
• Break-glass exclusions written into the policy resource in code, so the next apply can't remove them.
• The What If tool to simulate before enabling.
• Manage policies as code with a review gate, and treat enabling one as a change window, not a deployment.
• Alert on any Conditional Access policy being created, modified, or disabled.

Worth adding: the same reasoning applies to the automation identity. A policy that locks out the pipeline locks out the rollback.

Detect it three ways, ideally all three:

1. Scheduled terraform plan in CI, failing on a non-empty diff. This is the primary control and costs one cron entry.
2. The Entra audit log, which records every directory write with actor, target, and old/new values — alert on writes to objects you manage as code, filtering out the pipeline's own service principal.
3. Access reviews for the membership-shaped drift that a diff won't make a judgement about.

Then decide, and it's a conversation not a policy:

• The config was right and the portal change was wrong → re-apply. Tell whoever made the change why the pipeline exists.
• The portal change was right and the config is stale → bring it into code and apply, or terraform import if the object itself was created outside.

The Entra-specific traps in that recovery:

• Some fields the provider doesn't track will never show as drift. Absence of a diff is not proof of no change; the audit log is.
• A re-apply that replaces an identity is far worse than the drift — read the plan for forces replacement before running it.
• If the manual change was an admin consent grant, Terraform never saw it and destroying the app won't clean it up.

And the structural point: drift is usually a symptom of friction. If people click in the portal because the pipeline takes forty minutes or needs an approval nobody's awake for, fixing the pipeline prevents more drift than any detection ever will.

Four options, roughly in order of preference:

1. B2B guest invitation. Invite their users as guests. Their home tenant owns the credential and the offboarding — when their employer disables the account, your access dies too, with no action from you. This is the default answer and the reason is that sentence.
2. Cross-tenant access settings to configure it properly at scale: which of their users may be invited, whether you trust their MFA and device claims (so guests aren't forced to register MFA twice), and what your users may do in their tenant. Without this, guests hit MFA friction that makes people ask for exceptions.
3. Entra ID Governance entitlement management — an access package bundling the application, the groups, and an expiry, with the partner's sponsor as approver. Access expires by default rather than persisting by default, which is the property you actually want.
4. Federation with their IdP if they don't use Entra ID — or email one-time passcode for low-assurance, occasional access.

What I would not do: create accounts for them in my tenant. That means I own their credentials, their MFA registration, and their offboarding — and their leavers become my stale accounts, which nobody will notice for two years.

Controls to apply regardless: guests scoped with app-role assignments (not just tenant membership), Conditional Access targeting the guest population specifically, and access reviews with automatic removal on the guest group. Guests without an expiry date are the most common finding in any tenant review.