Describe the capabilities of Microsoft security solutions →hardMultiple ChoiceObjective-mapped

SC-900 Practice Question: Describe the capabilities of Microsoft security solutions

Exhibit

{
  "properties": {
    "displayName": "Require MFA for Azure Management",
    "policyType": "Custom",
    "mode": "All",
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Authorization/roleAssignments"
          },
          {
            "field": "Microsoft.Authorization/roleAssignments/roleDefinitionId",
            "equals": "[parameters('managementRoles')]"
          }
        ]
      },
      "then": {
        "effect": "auditIfNotExists",
        "details": {
          "type": "Microsoft.Authorization/roleAssignments",
          "existenceCondition": {
            "field": "Microsoft.Authorization/roleAssignments/principalId",
            "in": "[parameters('mfaEnabledPrincipals')]"
          }
        }
      }
    },
    "parameters": {
      "managementRoles": {
        "type": "Array",
        "defaultValue": ["8e3af657-a8ff-443c-a75c-2fe8c4bcb635"]
      },
      "mfaEnabledPrincipals": {
        "type": "Array"
      }
    }
  }
}

Refer to the exhibit. You are evaluating a custom Azure Policy definition. The policy is intended to audit whether users assigned to a management role have MFA enabled. However, the policy is not triggering alerts for non-compliant users. What is the most likely cause?

⚠ Common exam trap

It's easy for candidates to assume the policy will automatically detect MFA status from Azure AD, but Azure Policy requires explicit parameter input to define the compliant state, and failing to populate that parameter silently disables the audit.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The 'mfaEnabledPrincipals' parameter is not populated with the list of MFA-enabled users.

The policy definition includes a parameter named 'mfaEnabledPrincipals' that must be populated with the list of user object IDs who have MFA enabled. If this parameter is empty or not provided, the 'auditIfNotExists' effect cannot evaluate any users against the expected MFA status, resulting in no non-compliant alerts being triggered. Azure Policy relies on explicit parameter values to define the baseline for compliance evaluation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
The 'mfaEnabledPrincipals' parameter is not populated with the list of MFA-enabled users.
Why this is correct
The 'mfaEnabledPrincipals' parameter is crucial for this policy's logic, as the 'existenceCondition' relies on it to identify principals who have MFA enabled. If this parameter is not populated with the correct list of MFA-enabled user principal IDs, the policy's 'where' clause cannot accurately determine which principals are compliant. Consequently, the policy will fail to correctly evaluate whether non-MFA-enabled users hold owner role assignments, rendering its compliance assessment ineffective.
✗
The policy mode is set to 'All' instead of 'Indexed'.
Why it's wrong here
The policy mode 'All' is correctly applied here because role assignments are management plane resources that exist at various scopes (subscription, resource group, resource) and do not support tags or locations. Unlike 'Indexed' mode, which is designed for trackable resources deployed within resource groups that support tags and locations, 'All' mode is appropriate for evaluating resource types like role assignments, policies, or resource groups themselves. Therefore, setting the mode to 'All' is the correct configuration for this type of policy evaluation.
✗
The policy only evaluates role assignments of type 'Microsoft.Authorization/roleAssignments' but not users.
Why it's wrong here
Azure Policy evaluates resource properties and resource types, not users directly as a distinct resource type within the policy definition. This policy specifically targets 'Microsoft.Authorization/roleAssignments', which are the resources that define who (the principal, which can be a user) has what access (the role) to what scope. The policy correctly examines the properties of these role assignment resources, such as 'principalId', to infer information about the associated users and their access, making its scope appropriate for the intended evaluation.
✗
The effect 'auditIfNotExists' should be 'deny' to trigger alerts.
Why it's wrong here
The 'auditIfNotExists' effect is designed to identify and report non-compliant resources in the Azure Policy compliance dashboard, effectively triggering alerts and reporting without blocking operations. It correctly serves the purpose of identifying existing non-compliant role assignments. Conversely, the 'deny' effect would actively prevent the creation or modification of any role assignment that violates the policy, which is a different operational goal focused on prevention rather than just identification and reporting of existing issues.

Go deeper

SC-900 Practice Question: Describe the capabilities of Microsoft security solutions

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question