4 of the 4 questions we have for this objective, shown with the answer and the reasoning.
Implement Microsoft Security Copilot
Hartwell Insurance has a Security Copilot workspace. A group of 25 SOC analysts named SG-Copilot-Users must be able to run prompts and use promptbooks and the enabled plugins, but must not be able to change workspace settings, manage plugins, or adjust the capacity. You must follow the principle of least privilege.
Which role should you assign to SG-Copilot-Users in Security Copilot?
- ACopilot contributorCopilot contributor is the usage role: it allows running sessions, prompts, and promptbooks with the enabled plugins without any administrative rights over the workspace.
- BCopilot ownerCopilot owner adds the ability to manage settings, plugins, and role assignments, which exceeds what analysts need.
- CSecurity Administrator in Microsoft Entra IDSecurity Administrator is a directory role that is implicitly treated as a Copilot owner and also grants broad Microsoft 365 security management rights far beyond Copilot usage.
- DMicrosoft Sentinel Reader on the Sentinel workspaceA Sentinel role governs access to Sentinel data that a plugin might read; it does not grant any access to Security Copilot itself.
Why: Security Copilot has two of its own roles. Copilot owner manages the workspace, including plugin settings, data sharing, and who can use the service; Copilot contributor can use Copilot but cannot administer it. Microsoft Entra Global Administrator and Security Administrator are implicitly owners. For analysts who need to run prompts and nothing more, Copilot contributor is the least privileged role, and it is typically assigned to a security group rather than to individuals. The traps are the owner role, which over-grants, and directory or Sentinel roles that either are too broad or do not grant Copilot access at all.
Implement Microsoft Security Copilot
Meridian Logistics has a Security Copilot workspace used by 40 analysts who hold the Copilot contributor role. Analysts want Copilot to query the Microsoft Sentinel workspace law-ml-soc and the company's internal ticketing system, which exposes a REST API described by an OpenAPI specification. Security leadership requires that only the two Copilot owners can add or change custom plugins, while analysts may still turn the approved plugins on or off for their own sessions.
What should you do?
- AAs a Copilot owner, enable and configure the Microsoft Sentinel plugin with the workspace details, add the ticketing system as a custom plugin from its OpenAPI specification, and in Owner settings restrict adding and managing custom plugins to owners onlyMicrosoft plugins such as Sentinel are enabled and configured by owners, custom plugins are built from OpenAPI or KQL definitions, and owner settings control whether contributors can add and manage custom plugins while still letting them toggle approved plugins.
- BAsk each analyst to add the Sentinel plugin and the ticketing plugin in their own session settingsThis leaves custom plugin management with contributors, which violates the requirement that only owners add or change custom plugins.
- CInstall the Microsoft Sentinel content hub solution for the ticketing system and connect it through a data connectorA Sentinel data connector ingests ticket data into Log Analytics; it does not give Security Copilot the ability to call the ticketing API.
- DGrant the analysts the Copilot owner role so that they can configure the plugins themselvesMaking analysts owners defeats the requirement to restrict custom plugin administration to the two designated owners.
Why: Plugins are how Security Copilot reaches data and actions. Microsoft plugins such as Microsoft Sentinel, Defender XDR, and Entra are enabled and configured by owners, typically with workspace or tenant details. Custom plugins are authored from an OpenAPI specification, a KQL query, or a GPT-style definition and can be scoped to the whole tenant or to the author. Owner settings include controls over who can add and manage custom plugins and who can toggle Microsoft plugins, which is how leadership's restriction is implemented without taking away the contributors' ability to use approved plugins. The traps are letting contributors manage plugins, promoting them to owner, and confusing a Sentinel data connector with a Copilot plugin.
Implement Microsoft Security Copilot
Ashgrove Biotech wants to begin using Microsoft Security Copilot. The company licenses Microsoft 365 E3, not E5 or E7, so Security Copilot is not included with its licenses. It has an Azure subscription named Sub-Security and a Microsoft Entra tenant in which the security engineer holds the Security Administrator role and the Owner role on Sub-Security. Nothing related to Security Copilot has been set up yet, and the engineer must make the standalone Security Copilot experience usable for the SOC.
Which two actions should you perform? Each correct answer presents part of the solution.
- ACreate a Security Copilot capacity resource in Sub-Security with a provisioned number of Security Compute Units (SCUs) per hourFor organizations without the Microsoft 365 E5 or E7 inclusion, Security Copilot is billed through SCUs provisioned on an Azure capacity resource, which needs Contributor or Owner on the subscription or resource group; without a capacity there is nothing for the workspace to consume.
- BIn the Security Copilot portal, complete the first-run setup to create the workspace and associate it with the capacityA Security Copilot workspace holds the settings, plugins, and role assignments and must be associated with a capacity before prompts can run; attaching the capacity requires Security Administrator or higher in the tenant.
- CPurchase per-user Security Copilot add-on licenses for every SOC analyst in the Microsoft 365 admin centerNo per-user Security Copilot license exists. Security Copilot is either included with Microsoft 365 E5 or E7 at the tenant level or paid for through SCU capacity in Azure; access is then governed by Copilot roles.
- DEnable Microsoft Sentinel on a Log Analytics workspace in Sub-SecurityA Sentinel workspace is one of many optional data sources that a plugin can connect to; it is not required to set up Security Copilot itself.
- EAssign the Microsoft Entra Global Administrator role to every SOC analyst so that they can open Security CopilotGlobal Administrator is both unnecessary and a serious violation of least privilege; analysts need only the Copilot contributor role.
Why: There are two kinds of Security Copilot customers. Microsoft 365 E5 and E7 customers have Security Copilot included and auto-provisioned once Microsoft rolls it out to the tenant. Everyone else, including this Microsoft 365 E3 company, follows the manual path, which has two halves in two portals: in Azure you create a capacity resource that defines how many Security Compute Units per hour are provisioned, which is the billing unit for the service, and in the Security Copilot portal you complete first-run setup to create the workspace, associate it with that capacity, confirm data storage location and sharing settings, and assign roles. The engineer's Security Administrator and subscription Owner roles are sufficient for both steps. The traps are a per-user license, which does not exist, Sentinel as a prerequisite, and granting Global Administrator for ordinary access.
Implement Microsoft Security Copilot
Coralview Finance has Security Copilot provisioned with a capacity of 5 SCUs per hour and uses Microsoft Defender for Office 365 Plan 2 with unified role-based access control enabled in the Defender portal. The SOC receives about 400 user-reported phishing submissions per week and wants them triaged automatically, with verdicts and explanations shown in the Defender portal, and with the agent learning from analyst feedback. The engineer is a Security Administrator in Microsoft Entra ID.
What should you do?
- AIn the Defender portal, open the Security Store (or the Agents page), set up the Microsoft Phishing Triage Agent, assign it an identity with the minimum Defender for Office 365 permissions, and configure its scope and triggersThe Phishing Triage Agent is a generally available Microsoft-built Security Copilot agent that runs in the Defender portal, consumes SCUs from the provisioned capacity, and autonomously triages user-reported phishing with explanations and feedback-based tuning; setting it up requires Defender for Office 365 Plan 2, unified RBAC, and the Security Administrator role.
- BCreate an automation rule in Microsoft Sentinel that closes incidents whose title contains PhishingAn automation rule can close incidents on a text match but performs no analysis, produces no verdict explanation, and cannot learn from feedback.
- CEnable the Microsoft Defender XDR plugin in Security Copilot and ask analysts to prompt for each submissionThe plugin lets analysts ask questions interactively; it does not run autonomously against incoming submissions, so 400 per week would still be manual work.
- DBuild a custom plugin from an OpenAPI specification that calls the Defender for Office 365 APIA custom plugin extends what Copilot can query; it is not an autonomous agent and would have to be invoked by a user for every submission.
Why: Security Copilot agents are autonomous workflows that run on the Copilot capacity and act on their own triggers, which is what distinguishes them from plugins that answer a user's prompt. Microsoft provides first-party agents such as the Phishing Triage Agent, which is set up from the Security Store or the Agents page in the Defender portal, and partners publish additional agents through the Microsoft Security Store; agents consume SCUs like any other Copilot feature and need no separate license. Setting up the agent requires Security Administrator, Defender for Office 365 Plan 2, and unified RBAC; you give it an identity with the minimum permissions it needs and define its scope, and it then triages each submission and explains its verdict. The traps are the plugin and the Sentinel rule, which either need a human for every case or lack any analysis.