Common interview slip
Many candidates blur Azure AD with Entra ID, or say 'MFA alone is enough for Zero Trust.' Both slip-ups cost marks in an Entra ID interview.
Microsoft Entra ID is the new name for Azure Active Directory — rebranded in 2023 — and is now the umbrella for the whole Entra portfolio (Entra ID, Entra External ID, Entra ID Governance, Entra Permissions Management). Conditional Access is the Zero Trust policy engine, not just an MFA toggle: it evaluates signals (user identity, sign-in risk from Identity Protection, device compliance, location, app sensitivity) and enforces grant controls (MFA, compliant device, approved app) and session controls. MFA alone is one grant control inside a CA policy — CA is the decision layer that decides when to require it and what else to require. Knowing this distinction is exactly what SC-300 and Entra ID architect interviews probe.
① Tenants, objects & licensing — Entra ID fundamentals
Q: What is a Microsoft Entra ID tenant and what core objects live in it?
Model answer: A tenant is a dedicated, isolated instance of Microsoft Entra ID that represents one organisation. It gets a globally unique identifier (tenant ID) and a default domain (yourorg.onmicrosoft.com). Inside the tenant, the core directory objects are: users (members and guests), groups (security and Microsoft 365, assigned or dynamic), devices (Entra-joined, hybrid-joined, registered), app registrations (the identity definition of an application in your tenant), and service principals (the tenant-local instance of an app registration that holds the actual permissions and consent). The separation between app registration (the definition) and service principal (the instance) trips up many candidates — name both and you stand out.
Q: What is the difference between an app registration and a service principal in Entra ID?
Model answer: An app registration lives in the home tenant of the developer or organisation that owns the application. It defines the app's identity: client ID, redirect URIs, API permissions requested, and any secrets or certificates. A service principal is the per-tenant instance of that app — when an admin consents to an app in their tenant, Entra ID creates a service principal in that tenant. The service principal holds what has actually been granted (granted permissions, app roles assigned, conditional access exclusions). So a multi-tenant Microsoft app like Teams has one app registration in Microsoft's tenant but millions of service principals — one in each customer tenant. The interview one-liner: app registration = the blueprint, service principal = the tenant-local instance that holds the actual grants.
Q: Explain the Entra ID licensing tiers and what key features each adds.
Model answer: Entra ID Free is included with any Microsoft cloud subscription and covers basic directory, SSO for up to 10 apps per user, self-service password reset for cloud-only users, and basic security defaults. Entra ID P1 (included in Microsoft 365 Business Premium and E3) adds Conditional Access, Entra Application Proxy, dynamic groups, group-based licensing, and hybrid identity with Entra Connect. Entra ID P2 (included in E5) adds Identity Protection (risk-based sign-in and user risk signals for CA) and Privileged Identity Management (PIM). Entra ID Governance adds access reviews at scale, entitlement management (access packages and catalogs), lifecycle workflows, and advanced PIM features. The clean summary: P1 = Conditional Access + hybrid; P2 = risk-based CA + PIM; Governance = full lifecycle and entitlement management.
When asked about app identities in Entra ID, interviewers want to hear both objects: the app registration (the blueprint in the home tenant — client ID, redirect URIs, permissions requested) and the service principal (the per-tenant instance created by admin consent — the object that holds what's actually been granted). Naming the distinction shows you understand the multi-tenant model, not just the portal buttons.
What is the relationship between an app registration and a service principal in Microsoft Entra ID?
② SSO, MFA & Conditional Access — the Zero Trust policy engine
Q: What are the three hybrid authentication methods in Entra ID, and when do you choose each?
Model answer: When synchronising an on-premises Active Directory to Entra ID with Entra Connect, you choose how authentication actually happens. Password Hash Sync (PHS) syncs a hash of the password hash to the cloud — authentication happens in Entra ID, so it works even if the on-prem AD is down and is the simplest option. Pass-Through Authentication (PTA) routes authentication to an on-prem agent in real time — the password never leaves the corporate network, which suits organisations with strict password policies or regulatory requirements, but it requires the on-prem agent to be available. Federation (AD FS / third-party IdP) redirects authentication entirely to an on-prem identity provider — chosen when you need on-prem claims, smartcard, or complex custom sign-in logic, but it is the most complex to operate. A fourth option for pure cloud-only tenants is managed authentication (no sync needed). The rule of thumb: PHS is the default recommendation; PTA when the password must never leave the network; federation only when claims or custom login are truly required.
Q: Walk me through how you design a Conditional Access policy and what signals it evaluates.
Model answer: A Conditional Access policy follows an if-then structure: if the assignment conditions are met, then enforce the access controls. The assignment signals (the if) include: Users and groups (who), Cloud apps or actions (which app or action like device registration), Conditions — sign-in risk level (from Identity Protection, needs P2), user risk level, device platform, location (named locations, trusted IP ranges, countries/regions), client apps (browser, mobile apps, legacy protocols), and device state (compliant, hybrid-joined). The access controls (the then) are either Grant (block, require MFA, require compliant device, require hybrid-joined device, require approved app, require app protection policy, require password change — combinable with AND/OR) or Session (sign-in frequency, persistent browser session, app-enforced restrictions, Defender for Cloud Apps session proxy, token binding). Always deploy in report-only mode first to see impact before enabling enforcement. The interview money line: CA is the Zero Trust policy engine — it decides what to enforce, using signals from users, apps, devices, locations and real-time risk — and MFA is just one of many grant controls it can require.
Q: What is Entra ID Identity Protection and how does it plug into Conditional Access?
Model answer: Identity Protection (P2 feature) is the risk-detection engine. It continuously calculates two risk signals: sign-in risk — the probability that the specific sign-in is not from the legitimate user (e.g. impossible travel, unfamiliar location, password spray detected) — and user risk — the probability that a user's account is compromised (e.g. leaked credentials, anomalous behaviour). These signals are surfaced as low/medium/high risk levels. A Conditional Access policy can then use sign-in risk condition or user risk condition to dynamically require MFA, block access, or force a password change. For example: if sign-in risk = high, block; if sign-in risk = medium, require MFA. The clean description: Identity Protection detects risk signals; Conditional Access consumes them as policy conditions to respond in real time.
Q: What is Seamless SSO and what is a Primary Refresh Token (PRT)?
Model answer: Seamless SSO (Seamless Single Sign-On) lets users on domain-joined corporate machines sign into cloud apps without entering their credentials again — the device uses Kerberos behind the scenes to obtain an Entra ID token silently. It works with both PHS and PTA (not federation, which has its own SSO mechanism). A Primary Refresh Token (PRT) is a long-lived token (valid up to 14 days, renewable) issued by Entra ID to a device when a user signs in. It represents the user + device combination and is used by the Windows Account Manager to silently obtain new tokens for apps (giving the SSO experience). The CA device state condition (compliant or hybrid-joined) is enforced by evaluating the device claim in the PRT. The interview point: PRT = the device-bound SSO token that enables seamless sign-in; it carries device compliance claims that CA can verify.
A tenant is the isolated Entra ID instance for one org. An app registration is the app blueprint in the home tenant; a service principal is the per-tenant instance created when an admin consents — it holds the actual grants and role assignments.
CA is the Zero Trust policy engine: if assignments match (user, app, conditions) then enforce grant controls (MFA, compliant device, block) or session controls. Deploy in report-only mode first. MFA is just one of many grant controls.
PIM = eligible not standing. Admin activates the role, passes MFA + optional approval, gets a time-limited window, then auto-expires. Covers Entra ID directory roles and Azure RBAC roles. Requires P2 or Entra ID Governance.
B2B collaboration = invite business partners as guests in your workforce tenant, sign in with their own org credentials. Entra External ID external tenant = CIAM for customers (successor to Azure AD B2C), with self-service sign-up and social IdPs.
A very common interview error is saying 'we enabled MFA, so we have Zero Trust.' MFA is one grant control inside a Conditional Access policy. Zero Trust means evaluating all signals — user identity, sign-in risk from Identity Protection, device compliance state, location, and app sensitivity — and enforcing the right combination of controls for that context. Conditional Access is the policy engine that does this evaluation. Always describe CA, not just MFA, when answering Zero Trust questions.
You want to require MFA only when a user's sign-in risk is medium or high. Which feature provides the risk signal used as the Conditional Access condition?
③ Governance & PIM — just-in-time, reviews and entitlement management
Q: What is Privileged Identity Management (PIM) and how does just-in-time (JIT) access work?
Model answer: PIM (Entra ID P2 or Governance) eliminates standing privileged access — instead of an admin having the Global Administrator role permanently, they are made eligible for the role. When they need it, they activate it: they request elevation, provide a business justification, pass MFA (and optionally wait for manager approval), and receive the role for a time-limited window (configured max, typically 1–8 hours). When the window expires the elevation ends automatically. PIM covers both Entra ID directory roles (e.g. Global Admin, User Admin) and Azure RBAC roles (e.g. Owner, Contributor on a subscription or resource group). The 2026 addition: PIM can now require Conditional Access reauthentication at activation time, so the MFA check at elevation is enforced through a CA policy, not just a PIM setting — strengthening the assurance level. The one-liner: PIM = eligible not standing, activate with JIT + MFA + optional approval, auto-expire.
Q: What are Entra ID Access Reviews and when do you use them?
Model answer: Access Reviews are a periodic, automated process that asks reviewers to confirm whether users still need the access they have. You create a review for a group membership, an application role assignment, or a PIM eligible/active role. Reviewers can be the resource owners, managers of the users, or the users themselves (self-review). When the review period ends, Entra ID can auto-apply the result — removing access for anyone the reviewer denied or for anyone who did not respond (if you configure the on-no-response setting to remove). Use cases: quarterly review of privileged role members, annual review of guest access, semi-annual review of application role assignments. Access Reviews are an Entra ID Governance feature and are the standard answer to the interview question 'how do you enforce least-privilege over time?'
Q: What is Entitlement Management in Entra ID Governance?
Model answer: Entitlement Management lets you define access packages — bundles of resources (groups, SharePoint sites, Teams, app roles) that a user type needs — and publish them in a catalog with an access request policy. Employees or guests self-request the package; Entra ID routes the request for approval, grants the bundled access when approved, and can optionally set an expiry so access lapses automatically. This replaces the pattern of admins manually assigning individual resources. The interview framing: Entitlement Management = self-service access bundles (packages) with approval workflows and auto-expiry, replacing manual resource-by-resource assignment. Combined with Access Reviews, it gives a full access lifecycle: request → approve → periodic review → auto-remove.
Before switching any Conditional Access policy from off to enabled, set it to report-only mode first. Report-only records what the policy would have done (grant, block, MFA required) in the sign-in logs without actually enforcing it. Review the logs for at least a few days across the user population, use the What If tool to spot edge cases, then switch to enforce. This prevents unexpected lockouts — the most expensive Entra ID mistake in production.
▶ Watch a sign-in evaluated by Conditional Access — and see it blocked
Step through how a user sign-in is evaluated by a Conditional Access policy requiring MFA for a risky sign-in. Press Play for the healthy path, then Break it to see what happens when Identity Protection detects high risk and the user has no MFA method registered.
In PIM, what is the difference between an 'eligible' role assignment and an 'active' role assignment?
④ Hybrid, external & scenarios — Entra Connect, B2B, External ID
Q: Compare Entra Connect Sync and Entra Cloud Sync — when do you choose each?
Model answer: Both tools synchronise on-premises Active Directory objects to Microsoft Entra ID, but they have different deployment models. Entra Connect Sync (the traditional tool, formerly Azure AD Connect) is installed on a dedicated on-prem server, offers the widest feature set (device writeback, group writeback, password writeback, Exchange hybrid, complex filtering, all three authentication methods), and supports complex multi-forest topologies. Entra Cloud Sync uses a lightweight agent installed on each domain controller (no dedicated server) and syncs through a cloud-hosted provisioning engine. Cloud Sync is the right choice for simpler environments, multi-forest scenarios where the forests are disconnected (it handles each forest independently), and for new deployments where you don't need writeback features. Microsoft's direction is toward Cloud Sync for most new implementations. The headline: Connect Sync = full-featured on-prem server; Cloud Sync = lightweight agent, simpler to operate, preferred for new projects.
Q: What is the difference between B2B collaboration and Entra External ID?
Model answer: B2B collaboration is the Entra ID feature that lets you invite external partners or contractors (from other organisations) as guest users in your tenant. They sign in with their own organisation's credentials (or a Microsoft/Google account) and are represented as guests. You control what they can access via groups and Conditional Access, and Access Reviews clean up stale guests. Entra External ID is the umbrella product for customer-facing (CIAM) identity — it has two tenant models: the workforce tenant (where B2B collaboration lives) and the external tenant (the CIAM-focused model, the successor to Azure AD B2C). The external tenant is built for consumer sign-up/sign-in flows with social identity providers (Google, Facebook) and is separate from your corporate directory. The clean split: B2B collaboration = invite business partners as guests in your tenant; Entra External ID external tenant = customer-facing CIAM apps with self-service sign-up, successor to Azure AD B2C.
Q: A user is blocked by Conditional Access in a way you did not expect. How do you investigate?
Model answer: Start with the Sign-in logs in the Entra ID portal (Monitor & Health → Sign-in logs) — filter on the user, find the failed sign-in, and open the Conditional Access tab to see exactly which policy applied, the result (granted, blocked, MFA required) and why. The What If tool in Conditional Access lets you simulate a sign-in (user, app, location, device state, risk level) and see which policies would fire before any real user is impacted — essential for pre-validation. For investigation, also check the CA policy in report-only mode — any policy in report-only shows in the sign-in log what it would have done without actually enforcing it. If the block is unexpected, the most common causes are: the policy targets a group the user was recently added to, a new named-location rule, a recent device compliance change, or a risk level triggered by Identity Protection. The gold line: Sign-in log CA tab first for the actual block reason, What If for pre-validation, report-only for safe pre-deployment testing.
Priya at FinEdge Solutions in Hyderabad faces this
FinEdge rolled out a new Conditional Access policy requiring compliant devices for all Microsoft 365 access. Two days later, the helpdesk is flooded: dozens of employees can sign in to Entra ID but are immediately blocked when they try to open Outlook or Teams. Priya is the Entra ID administrator and must diagnose and fix the issue without disabling the policy for everyone.
The CA policy requires device compliance, but many employee laptops have not yet enrolled in Microsoft Intune or have not received their compliance policy. The devices are Entra-joined but show as 'non-compliant' in Intune because the compliance policy evaluation has not completed or the devices are still running the old Intune enrollment profile.
In the Entra ID Sign-in logs, filtered on the affected users, the Conditional Access tab shows the policy 'Require compliant device for M365' applied with a block result and the reason 'Device is not compliant.' The What If tool confirms the same result for a test user with a non-compliant device signal.
Monitor & Health ▸ Sign-in logs ▸ select a blocked event ▸ Conditional Access tab; then Devices ▸ All devices ▸ filter by compliance statePriya adds the affected users' department group to a CA policy exclusion temporarily while Intune compliance policies propagate. She opens Intune, confirms the compliance policy is assigned to the affected device group, triggers a device sync, and verifies the devices become compliant. Once all devices show compliant, she removes the CA exclusion. She also enables the CA policy in report-only mode in the staging tenant before future policy rollouts.
After Intune compliance propagates, the Sign-in logs for the same users show the CA policy result as 'Granted (compliant device)' and employees can open Outlook and Teams without interruption.
A user is unexpectedly blocked by Conditional Access. What is your fastest first diagnostic step in the Entra ID portal?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: what is Conditional Access and how does it differ from just enabling MFA? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Tenant
- A dedicated, isolated Microsoft Entra ID instance representing one organisation, with a unique tenant ID and default domain (yourorg.onmicrosoft.com).
- App Registration vs Service Principal
- App registration is the identity blueprint of an application in its home tenant (client ID, declared permissions). Service principal is the per-tenant instance created by admin consent — it holds what has actually been granted.
- Conditional Access
- The Entra ID Zero Trust policy engine that evaluates signals (user, app, sign-in risk, device compliance, location) and enforces grant or session controls. Deploy new policies in report-only mode before enforcing.
- Identity Protection
- Entra ID P2 feature that calculates sign-in risk (per-session probability of compromise) and user risk (per-account probability of compromise) as signals for Conditional Access policies.
- PIM (Privileged Identity Management)
- Entra ID P2/Governance feature that replaces standing privileged role assignments with eligible assignments, requiring just-in-time activation with MFA and optional approval, auto-expiring after a time window.
- Access Reviews
- Entra ID Governance feature for periodic recertification of group memberships, application role assignments, or PIM roles, with auto-removal of access when reviewers deny or do not respond.
- Entra Connect Sync vs Cloud Sync
- Entra Connect Sync: full-featured on-prem server, all auth methods and writebacks. Entra Cloud Sync: lightweight per-DC agent, simpler, preferred for new deployments, handles disconnected multi-forest.
- B2B Collaboration
- Invites external business partners as guest users in your workforce tenant; they authenticate with their own organisation's credentials and are managed via groups and Conditional Access.
- Entra External ID External Tenant
- The CIAM-focused tenant model for customer-facing apps — successor to Azure AD B2C — supporting self-service sign-up, social identity providers, and branded consumer experiences, separate from the workforce directory.
- Primary Refresh Token (PRT)
- A long-lived, device-bound token issued by Entra ID on user sign-in, used to silently obtain new tokens for apps (enabling SSO). It carries device compliance claims evaluated by Conditional Access.
📚 Sources
- Microsoft Learn — What is Microsoft Entra ID? Tenant overview, objects and licensing tiers. learn.microsoft.com/en-us/entra/fundamentals/whatis
- Microsoft Learn — What is Conditional Access in Microsoft Entra ID? Signals, controls, report-only mode and What If. learn.microsoft.com/en-us/entra/identity/conditional-access/overview
- Microsoft Learn — What is Privileged Identity Management (PIM)? Just-in-time access, eligible assignments and activation. learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure
- Microsoft Learn — Entra ID Governance — access reviews, entitlement management and lifecycle workflows licensing fundamentals. learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals
- Microsoft Learn — Microsoft Entra Connect vs Entra Cloud Sync — choose a hybrid identity solution. learn.microsoft.com/en-us/entra/identity/hybrid/cloud-sync/what-is-cloud-sync
- Microsoft Tech Community — What's new in Microsoft Entra: May 2026 — External ID external tenant, PIM Conditional Access reauthentication. techcommunity.microsoft.com/blog/microsoft-entra-blog/whats-new-in-microsoft-entra-may-2026
What's next?
Done with interview prep? Go deeper on Entra ID design — Conditional Access architecture, PIM role assignment strategies, Entra Connect topology planning, and securing external identities with Entra External ID.