hardMultiple ChoiceObjective-mapped

SC-100 Practice Question: Refer to the exhibit

Exhibit

Refer to the exhibit.

```json
{
  "properties": {
    "displayName": "Require MFA for Azure management",
    "state": "Enabled",
    "conditions": {
      "userRiskLevels": [],
      "signInRiskLevels": [],
      "clientAppTypes": ["all"],
      "applications": {
        "includeApplications": ["797f4846-ba77-4853-9e6f-4433c3e1d1c5"],
        "excludeApplications": []
      },
      "users": {
        "includeUsers": ["All"],
        "excludeUsers": ["BreakGlassAdmin@contoso.com"]
      },
      "locations": {
        "includeLocations": ["All"],
        "excludeLocations": ["AllTrusted"]
      }
    },
    "grantControls": {
      "builtInControls": ["mfa"],
      "termsOfUse": [],
      "operator": "OR"
    }
  }
}
```

Refer to the exhibit. A security architect reviews the Azure AD Conditional Access policy JSON. The policy is intended to require MFA for all users accessing Azure management (Microsoft Azure Management app ID 797f4846-ba77-4853-9e6f-4433c3e1d1c5), except for the BreakGlassAdmin account and from trusted locations. However, some users report being prompted for MFA even when connecting from the corporate office (which is marked as a trusted location). What is the most likely cause?

⚠ Common exam trap

Test-takers frequently assume the policy logic is flawed (e.g., grant operator or app scope) when the real issue is a misconfiguration in the location definition, which is a common oversight in Conditional Access troubleshooting.

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 corporate office location is not correctly defined as a trusted location in Azure AD

The policy is designed to require MFA for all users accessing Azure management, except for the BreakGlassAdmin account and from trusted locations. If the corporate office location is not correctly defined as a trusted location in Azure AD, the Conditional Access policy will not recognize it as an exception, and users connecting from that location will still be prompted for MFA. This mismatch between the intended trusted location definition and the actual location configuration is the most likely cause of the unexpected MFA prompts.

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 corporate office location is not correctly defined as a trusted location in Azure AD
Why this is correct
The conditional access policy is configured to exclude trusted locations, but the corporate office IP range is not added as a named location in Azure AD. Without that configuration, the corporate office is not considered a trusted location by the policy engine. As a result, the 'AllTrusted' exclusion does not apply to corporate IPs, so the policy enforces MFA for those sign-ins, causing users at the office to be prompted unexpectedly.
✗
The grant controls operator is set to 'OR' instead of 'AND'
Why it's wrong here
The grant controls operator is set to 'OR' rather than 'AND', but this is not the problem. When only one grant control (for example, MFA) is configured, 'OR' is the correct and standard operator because there is only a single condition to satisfy. 'AND' would be necessary only if multiple controls had to be simultaneously required, such as requiring both MFA and device compliance. Therefore, the operator setting does not explain the unexpected MFA prompt.
✗
The policy is in 'Report-only' mode
Why it's wrong here
The policy is not in 'Report-only' mode; the JSON explicitly shows the state is 'Enabled'. In Report-only mode, the policy would be evaluated and results written to logs, but it would not enforce any controls or block access. Because the policy is enabled, it actively enforces the MFA grant control, which is consistent with users being challenged for MFA. Thus, the mode is not the root cause of the issue.
✗
The policy applies to all cloud apps, not just Azure management
Why it's wrong here
The policy does not apply to all cloud apps; the JSON shows the includeApplications condition contains the specific application ID for Microsoft Azure Management. If the policy applied to all cloud apps, it would affect sign-ins to every integrated application, which could produce broader unexpected prompts. However, the actual policy is scoped narrowly to Azure management, so this is not the cause of the MFA challenge. The problem is related to the location condition, not the app scope.

Go deeper

SC-100 Practice Question: Refer to the exhibit

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question