SC-200 Manage a security operations environment Practice Question

Answer analysis

Option-by-option breakdown

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

• ✗

  Use Azure Policy to restrict access to automation rules.

  Why it's wrong here

  Azure Policy is an organization-level governance service that enforces compliance rules (e.g., tagging, allowed locations, resource types) on Azure resources; it does not manage identity-based access or role assignments. While you could use Azure Policy to audit or enforce configuration of automation rules via DeployIfNotExists, it cannot restrict which users can create, edit, or delete automation rules inside Microsoft Sentinel. Access to Sentinel automation capabilities is controlled exclusively through Azure RBAC roles such as Microsoft Sentinel Contributor or custom roles with Microsoft Sentinel Automation Contributor. Therefore, Azure Policy is the wrong tool for this requirement because it addresses 'what state resources should be in' rather than 'who is allowed to perform an action.'

• ✗

  Assign the 'Microsoft Sentinel Contributor' role to all security analysts.

  Why it's wrong here

  Assigning the Microsoft Sentinel Contributor role to all security analysts grants them full read, write, and delete permissions on all Sentinel resources, including analytics rules, data connectors, workbooks, and threat intelligence, far exceeding the least-privilege principle. This broad role allows analysts to alter security configurations, disable detections, or modify SIEM settings in ways that could impact the entire security operations environment, creating an undue risk of accidental or malicious change. The task only requires managing automation rules, so the Microsoft Sentinel Contributor role is over-privileged and inappropriate for a least-privilege access model. Instead, a custom role limited to the Microsoft Sentinel Automation Contributor permission should be used.

• ✗

  Assign the 'Microsoft Sentinel Reader' role to the analysts and grant them 'Automation' permissions via a separate policy.

  Why it's wrong here

  Microsoft Sentinel Reader is a read-only role that provides visibility into Sentinel resources but does not grant any write or management capabilities; there is no 'Automation' permission that can be added to it through a separate policy. Azure RBAC does not support adding granular permissions to a built-in role via a policy—policies enforce compliance, not role-permission augmentation. Even if you attempted to attach a custom role definition alongside the Reader role, the combined effective permissions would not include automation rule write access unless a custom role with Microsoft Sentinel Automation Contributor is assigned. Thus, this option fails because it relies on a nonexistent mechanism to elevate the Reader role beyond its read-only scope.

• ✓

  Create a custom role with 'Microsoft Sentinel Automation Contributor' permission and assign it to the analysts.

  Why this is correct

  Creating a custom role that includes the Microsoft Sentinel Automation Contributor permission is the correct approach because it provides the least-privilege access needed to read, create, edit, and delete automation rules, playbooks, and automation rule actions without granting full control over all Sentinel resources. The Microsoft Sentinel Automation Contributor role (often the built-in role or a custom role based on it) scopes permissions specifically to automation rule management, including the ability to trigger playbooks, while avoiding broader Sentinel management rights. Assigning this custom role only to the security analysts ensures they can perform their required tasks without exposing sensitive configurations or other security operations features. This aligns with Azure RBAC best practices and the principle of least privilege, making it the technically correct solution.

Go deeper

Related to this question