During an AZ-900 study session, a municipal IT trainee asks what Conditional Access is for—without needing full policy JSON. Which statement best describes its purpose?
Select an answer to reveal the explanation.
Short Explanation
Keep Conditional Access at the "purpose" level for Fundamentals: look at signals, then allow, block, or demand MFA. Nobody needs to hand-write policy JSON for AZ-900. That deeper authoring belongs elsewhere.
Full Explanation
At Azure Fundamentals depth, Conditional Access exists to evaluate identity-related signals during sign-in and then enforce an access decision. Signals commonly include user or workload identity context, application being accessed, location, device state, and risk indicators. Controls typically include allowing access, blocking access, or requiring stronger proof such as multifactor authentication. Municipal IT trainees do not need to author full policy JSON to understand that purpose: it is policy-based, identity-driven access control for cloud apps and resources protected by Microsoft Entra ID.
It is not a mandatory ARM template language for deploying virtual machines—ARM is infrastructure-as-code deployment, a different domain. It is not a billing SKU that freezes subscription spend; cost management and budgets address spending, not sign-in enforcement. It is also not Microsoft Sentinel’s SOAR playbook console; Sentinel is a SIEM/SOAR security operations product beyond the Conditional Access purpose statement expected on AZ-900.
Exam caveat: know the purpose and typical outcomes (allow/block/require MFA) without diving into enterprise policy design depth reserved for security administrator exams.
Operational check: in a lab tenant, create a simple Conditional Access policy in report-only mode that targets a test user and a cloud app, require MFA as the grant control, review the sign-in logs for the policy result, then decide whether to enforce.