Cloud identity and Azure interview questions

An app registration is the global definition of an application: its client ID, redirect URIs, secrets or certificates, and the permissions it asks for. It lives in the home tenant.

An enterprise application is a service principal, the local instance of that app in a tenant. It is where you assign users and groups, grant consent, configure single sign-on and apply Conditional Access. A multi-tenant app has one registration and one service principal in each tenant that uses it.

Password hash sync is the default recommendation. It is the simplest, has no on-premises dependency at sign-in, and enables leaked credential detection in Identity Protection.

Pass-through authentication suits organisations that must validate passwords against on-premises AD, at the cost of agents that must stay available. Federation with AD FS is only worth it for a requirement Entra ID cannot meet. Many migrations go the other way, from AD FS to cloud authentication.

B2B collaboration invites external users as guests, usually one at a time or through an access package, and they authenticate in their home tenant.

Cross-tenant synchronisation automatically creates and updates B2B users between tenants in the same organisation, for example after a merger. It is driven by provisioning rules rather than invitations.

An access package, in Entitlement Management, bundles groups, apps and SharePoint sites that users can request, with approval, an expiry and policies for who may ask.

An access review periodically asks owners, managers or the users themselves to confirm that existing access is still needed. Packages control how access is granted; reviews check whether it should be kept. They are often used together.

Start with the Entra sign-in logs: the error code, the authentication details, and which Conditional Access policies applied and with what result. The "What If" tool shows which policies would apply to a given sign-in.

Then check the account (blocked, disabled or not yet synced), the authentication methods, the device state if a policy requires a compliant device, and whether Identity Protection flagged the user or sign-in as risky.

Require MFA for all users, with phishing-resistant strength for administrators. Block legacy authentication. Require MFA or block risky sign-ins. Protect security information registration.

Every policy starts in report-only mode and excludes two break-glass accounts. Roll out with a pilot group before enforcing it for everyone.

Two cloud-only Global Administrator accounts kept for emergencies, such as a Conditional Access mistake or an MFA outage. They are excluded from the policies that could lock everyone out.

Protect them with FIDO2 keys stored securely, long random passwords, and alerts on any sign-in. Test them on a schedule so you know they still work.

Methods bound to the origin cryptographically, so a proxy phishing site cannot relay the sign-in. In Entra ID these are FIDO2 security keys and passkeys, Windows Hello for Business, and certificate-based authentication.

Push notifications and one-time codes can be relayed or approved by mistake. Authentication strengths in Conditional Access let you require phishing-resistant methods for specific users or apps.

Roles become eligible instead of active. Admins activate them for a limited time, with MFA, a justification and optionally an approval, and every activation is logged.

PIM also supports time-bound assignments and access reviews of role holders, which shrinks the window in which a stolen admin account is useful.

A dedicated, hardened device used only for sensitive administration: no email, no general browsing, restricted applications, and managed and monitored as a high-value asset.

It keeps privileged sessions away from the everyday device, where phishing and malicious extensions happen. It works together with separate admin accounts and a Conditional Access policy that requires the PAW for admin portals. See the PAW section of this site for a role planner.

Assets are grouped by how much control they give: the control plane (identity, Tier 0), the management plane, and data and workload planes. Credentials and devices from a lower level must never be used to administer a higher one.

In practice that means separate admin accounts per level, PAWs for Tier 0, and no Tier 0 sign-ins on ordinary servers or workstations.

Prefer managed identities, so there is no secret to store. Otherwise use certificates or workload identity federation instead of client secrets.

Grant least-privilege roles at the smallest scope, review application permissions such as Graph app roles regularly, and monitor service principal sign-ins. Workload Identities Premium adds Conditional Access and risk detection for them.

RBAC decides who can perform an action on a scope. Policy decides whether a resource configuration is allowed or compliant, whoever deploys it.

An Owner can still be blocked by a Deny policy, and a policy never grants anyone access.

Definitions, initiatives, assignments and exemptions are stored in Git and deployed by a pipeline, with pull request review and history.

For a Deny, assign it first with enforcementMode DoNotEnforce or the Audit effect, review the compliance results, fix or exempt existing resources, then enforce. Promote through a test management group before production. The Policy as Code page on this site walks through an example.

Modify changes properties of the resource being created or updated, typically tags or a setting such as public network access.

DeployIfNotExists deploys a separate related resource, such as diagnostic settings or an extension, when it is missing. Both need a managed identity with the right roles, and existing resources are fixed through remediation tasks.

Follow the Azure landing zone pattern: a top intermediate group, then Platform (identity, management, connectivity), Landing Zones (corp and online), Sandbox and Decommissioned.

Organise by governance needs, not by org chart, keep the hierarchy shallow, and assign policy and RBAC at management group level so new subscriptions inherit them.

It queries resource properties across all subscriptions you can read, using KQL, and returns results in seconds without calling each resource provider.

Typical uses are inventory, finding untagged or public resources, checking policy compliance state at scale, and feeding dashboards or workbooks.

An alert rule defines the signal and condition that fire an alert, such as a metric threshold or a log query.

An alert processing rule acts on alerts after they fire. It can add action groups or suppress notifications for a scope or schedule, for example during maintenance, without changing the alert rules themselves.

An SLI is the measurement, such as the percentage of successful requests. An SLO is the internal target for that measurement, such as 99.9% over 30 days. An SLA is the external commitment, with consequences if it is missed, and is usually looser than the SLO.

The gap between 100% and the SLO is the error budget, which balances release speed against reliability.

Enable TLS 1.2 for SChannel client and server in the registry, set SchUseStrongCrypto and SystemDefaultTlsVersions for .NET Framework, and restart the server.

Check the .NET Framework version first, test the sync afterwards, and script the change so every server is configured the same way.