Azure Security Interview Questions — Entra, Conditional Access, Answers & Cheat-Sheet

① Identity & access — Entra ID, RBAC, PIM and Conditional Access

Azure interviews open on identity, because in the cloud identity is the perimeter. Microsoft Entra ID (formerly Azure AD) is the identity provider; Conditional Access is the policy engine that decides, per sign-in, whether to grant access and under what conditions.

The Azure security vocabulary every interview opens with

Know these four cold before anything else. Tap each card.

Two authorisation models confuse candidates. Azure RBAC governs what you can do to resources (VMs, storage, networks) at a scope; Entra roles govern the directory itself. PIM makes privileged roles eligible rather than permanent, so admins activate just-in-time. And Managed Identity lets a VM or app call other Azure services with no secret stored anywhere — the modern answer to "where do I keep the password?".

What is Entra ID Protection, and how do risk-based Conditional Access policies work?

Entra ID Protection is the engine that scores identity risk in real time and feeds those scores to Conditional Access. It produces two signals interviewers expect you to name precisely. Sign-in risk is the probability that this authentication attempt isn't the real user — triggered by anonymous/Tor IPs, atypical (impossible) travel, malware-linked IPs or unfamiliar sign-in properties. User risk is the probability that the account itself is compromised — driven by leaked credentials found on the dark web or a pattern of risky sign-ins.

A risk-based Conditional Access policy turns those scores into action. Microsoft's recommended pattern: require MFA when sign-in risk is Medium or High, and require a secure password change (risk remediation) when user risk is High. The elegant part is self-remediation — a user who passes the MFA challenge or completes the secure password reset clears their own risk, so the admin never has to investigate routine events. Risk-based policies need Entra ID P2 (standard MFA/Conditional Access only needs P1). One 2026 fact worth dropping: the legacy risk policies that lived inside ID Protection are retiring on 1 October 2026 — you now configure risk policies in Conditional Access itself, which gives report-only mode, Graph API and the ability to combine risk with other conditions like location.

How and why do you block legacy authentication in Entra?

Legacy authentication is any protocol that can't do MFA — IMAP, POP3, SMTP AUTH, older Office clients. Block it because it is the single biggest MFA bypass: per Microsoft's telemetry, more than 99% of password-spray attacks and ~97% of credential-stuffing attacks ride legacy protocols, since an attacker who hits an IMAP endpoint never gets prompted for a second factor. You block it with a Conditional Access policy: All users → All resources → Conditions ▸ Client apps = Exchange ActiveSync clients + Other clients → Grant = Block. First identify who still uses it via the Entra sign-in logs (Client App filter), roll out in Report-only to avoid breaking a mailbox, then flip it On. Always exclude your break-glass accounts and migrate any script using legacy auth to a Managed Identity.

How would you design break-glass (emergency access) accounts?

Conditional Access is powerful enough to lock everyone out — a single mis-scoped “require compliant device” policy can leave you with no way back in. Break-glass accounts are the safety valve. Design them as: two cloud-only accounts (not federated, not synced from on-prem so an AD/sync outage can't kill them), with the Global Administrator role, excluded from every Conditional Access policy so a policy mistake never locks them out. Protect them instead with extremely long unique passphrases split and stored offline in a safe, phishing-resistant FIDO2 keys, and — critically — a monitored sign-in alert so any use of a break-glass account immediately pages the SOC. They are for emergencies only; everyday admin still goes through PIM just-in-time.

② Network security — NSG, Azure Firewall, Private Link and the hub-spoke

Azure network security is layered, and interviewers test whether you confuse the layers. An NSG is a free, stateful L3-4 rule set on a subnet or NIC; an ASG is a logical tag (web, app, db) you reference inside NSG rules so you stop maintaining IP lists. Azure Firewall is the paid, central L3-7 firewall in the hub VNet doing FQDN filtering, IDPS and threat-intel.

Private Endpoint via Private Link pulls a PaaS service (Storage, SQL, Key Vault) onto a private IP inside your VNet — the public endpoint can then be disabled. Azure Bastion removes public RDP/SSH; forced tunneling (a UDR) forces all egress through the firewall instead of straight out.

③ Data & platform protection — Key Vault, encryption, Storage and Defender for Cloud

Secrets, keys and certificates live in Key Vault. A 2026 gotcha: from API version 2026-02-01 new vaults default to Key Vault RBAC instead of legacy Key Vault access policy. RBAC is preferred because it scopes least-privilege roles centrally, supports PIM and is auditable, where access policies are per-vault and coarse.

Encryption at rest is on by default; encryption in transit is enforced with HTTPS-only and TLS 1.2. For Storage, the wins are: disable public access, scope SAS tokens tightly, and front it with a Private Endpoint. Defender for Cloud then scores the whole estate.

Platform-managed vs customer-managed keys — and what infrastructure (double) encryption adds

Azure encrypts every storage account, managed disk and database at rest by default with 256-bit AES using platform-managed keys — Microsoft generates, stores and rotates them, zero configuration, no extra cost. You switch to customer-managed keys (CMK) when compliance demands that you control the key lifecycle: your RSA key lives in Key Vault or Managed HSM and, via envelope encryption, wraps the data-encryption key. The payoff: you own rotation and you can revoke the key to make the data instantly unreadable. The trade-off interviewers want to hear: more control means more responsibility — if your key is lost or revoked by accident, the service loses access too.

Don't confuse CMK with infrastructure encryption. That is the double-encryption answer: a second encryption layer beneath the service layer, with a separate key and a different algorithm so a flaw or compromise in one layer can't expose the data. The two layers use independent key hierarchies — the service layer can be PMK or CMK, but the infrastructure layer is always Microsoft-managed. It must be enabled at storage-account creation and is meant for high-assurance/regulated workloads; for most workloads single-layer SSE is already strong enough.

Defender for Cloud — free Foundational CSPM vs the paid Defender plans

Interviewers probe whether you know what's free and what costs money. When you turn Defender for Cloud on, you get Foundational CSPM at no cost: asset inventory, security recommendations against the Microsoft Cloud Security Benchmark, multicloud coverage and the secure score — that is the “posture for free” layer. Paying unlocks two distinct things. Defender CSPM is the advanced posture plan — attack path analysis, the cloud security graph (security explorer), agentless vulnerability and secrets scanning, and risk prioritisation. Separately, the Defender workload plans (Defender for Servers, Storage, SQL, Containers, Key Vault, App Service) add real-time threat protection per resource type. The clean one-liner: Foundational CSPM tells you what's mis-configured for free; Defender CSPM prioritises the riskiest attack paths; the Defender workload plans detect active attacks — and those alerts flow into Sentinel for investigation.

④ Monitoring & governance + troubleshooting — Sentinel, Policy and the shared-responsibility model

Posture and detection are different jobs. Microsoft Sentinel is the cloud-native SIEM/SOAR — it ingests logs, you hunt with KQL and automate response with playbooks. Azure Policy enforces guardrails at scale; Azure Monitor and Log Analytics are the telemetry pipeline underneath both.

SigninLogs
| where RiskLevelDuringSignIn == "high"
| where IPAddress !startswith "10." and IPAddress !startswith "172.16."
| project TimeGenerated, UserPrincipalName, IPAddress, Location
| join kind=inner (
    AzureActivity
    | where OperationNameValue == "Microsoft.Authorization/roleAssignments/write"
) on $left.UserPrincipalName == $right.Caller

TimeGenerated         UserPrincipalName        IPAddress       Location
2026-06-11T04:12:00Z  rahul@infra.bank.in      203.0.113.51    Singapore
2026-06-11T04:13:20Z  rahul@infra.bank.in      203.0.113.51    Singapore
(2 rows) — risky sign-in immediately followed by a self role-assignment