Troubleshooting Conditional Access Policy Exclude Platforms in PowerShell

Answer analysis

Option-by-option breakdown

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

• ✓

  1. Create a new Conditional Access policy, 2. Assign users and groups, 3. Configure conditions (cloud apps, locations, etc.), 4. Configure access controls (Grant/Block) and enable policy

  Why this is correct

  The correct sequence mirrors the Microsoft Entra admin center workflow: first you instantiate a new Conditional Access policy object to give it a name and serve as the container for all later settings. Next you assign the target users or groups — this scope is the prerequisite for defining any conditions, because conditions like cloud apps or locations are evaluated against those identities. Only after the target population and conditions are set should you configure access controls such as Grant (Require MFA, Require compliant device) or Block, as these controls are applied to the requested session after all conditions are matched. Finally, you must enable the policy (or set it to Report-only) in the final step; until then it is inert and enforces nothing.

• ✗

  1. Configure access controls, 2. Assign users and groups, 3. Configure conditions, 4. Create a new Conditional Access policy

  Why it's wrong here

  This order is invalid because you cannot open the access-controls blade for a Conditional Access policy that has not been created; the portal only exposes Grant and Session controls from within an existing policy's configuration pane. Even if you could, placing access controls before user and group assignments is conceptually backwards: Grant and Block decisions are only meaningful after you know which identities and which conditions trigger the policy. Additionally, the mandatory 'Create new policy' step must be first, so any sequence that starts elsewhere omits the object that holds all other settings.

• ✗

  1. Create a new Conditional Access policy, 2. Configure conditions, 3. Assign users and groups, 4. Configure access controls and enable policy

  Why it's wrong here

  Although creating the policy first is correct, configuring conditions (cloud apps, locations, device platforms) before assigning users and groups is premature: the condition selectors in the Microsoft Entra admin center are populated and evaluated in the context of the 'Assignments > Users and groups' scope already chosen. Without a defined set of target users, a condition like 'All cloud apps' has no identity context to be applied to, which can lead to a policy that behaves unexpectedly or matches nothing. The supported order is users/groups first, then conditions, then access controls and enablement.

• ✗

  1. Assign users and groups, 2. Create a new Conditional Access policy, 3. Configure access controls, 4. Enable policy

  Why it's wrong here

  This sequence attempts to assign users and groups to a Conditional Access policy object that does not yet exist — the assignment step requires an existing policy reference, and the UI forces you to create the policy first. Additionally, the flow omits the conditions step entirely, which is required to define which cloud apps, locations, or device states the policy targets; a policy with only users and access controls cannot evaluate a context properly. Finally, enabling the policy should occur only after every assignment and control has been configured.

Go deeper

Related to this question