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.

• ✗

  Create a second Sentinel workspace in the managing tenant and configure cross-workspace queries.

  Why it's wrong here

  Creating a second Sentinel workspace in the managing tenant and using cross-workspace queries would require SOC analysts to manually switch query contexts or write multi-workspace KQL, which does not provide a unified incident queue for triage across tenants. This option is tempting because cross-workspace queries are a legitimate method for analysing data from multiple workspaces in a single query, and would be correct if the requirement were ad-hoc hunting rather than centralised incident management.

• ✗

  Configure Azure AD B2B collaboration to grant external users access to each tenant's Sentinel workspace.

  Why it's wrong here

  Azure AD B2B collaboration lets you invite external users into each tenant's directory and assign Azure RBAC roles, but it only grants access to the Seninel workspaces that already exist. Each tenant's Sentinel instance remains a separate logical container with its own incident database, so SOC analysts must authenticate to each tenant and manually review distinct incident queues. B2B does not consolidate incidents or provide a single cross-tenant pane of glass, therefore it fails to meet the requirement for centralized incident management.

• ✗

  Use Azure Policy to enforce a standard analytics rule across all tenants.

  Why it's wrong here

  Azure Policy is a governance service that can enforce the presence of a standard analytics rule across subscriptions, but it cannot move incident records into a common workspace. Even if the identical rule is deployed in every tenant, each Sentinel workspace independently generates and stores its own incidents, forcing the SOC team to connect to each workspace separately for triage. Policy standardizes detection configurations but does not aggregate data or incidents, so it does not satisfy the operational requirement of a unified incident queue.

• ✓

  Onboard each tenant as a delegated resource under Azure Lighthouse, then route all logs to a single Sentinel workspace in the managing tenant.

  Why this is correct

  Onboarding each tenant with Azure Lighthouse grants the managing tenant's users delegated access to administer resources, including configuring diagnostic settings and data connectors to route logs centrally. By sending all logs into a single Sentinel workspace in the managing tenant, events and alerts are consolidated and correlated in one analytical store, and Sentinel generates a unified incident queue for SOC analysts. This gives a single pane of glass for triage and response without the need to switch between tenants or manually craft cross-workspace KQL queries, which keeps the data fragmented.

Go deeper

Related to this question