A national museum and archives network wants its Fabric admin to group every conservation-telemetry workspace across all branches under one shared policy classification in the Fabric admin portal, separate from billing and separate from item labels. Which capability should the admin use?
Select an answer to reveal the explanation.
Short Explanation
Think of a domain like a folder that groups workspaces for governance purposes, not for billing. A capacity is about compute money; a domain is about which workspaces share the same policy umbrella. Grouping the conservation-telemetry workspaces under one domain keeps oversight consistent without touching how they're paid for.
Full Explanation
A Fabric domain is an admin-portal construct that groups related workspaces so an organization can apply consistent governance and default configuration to all of them at once, independent of which capacity pays for their compute. Assigning the conservation-telemetry workspaces to a shared domain is the direct fit here. Moving workspaces onto one capacity SKU controls compute cost and throttling behavior, not policy grouping -- two workspaces can share a capacity and belong to entirely different domains, or vice versa. Applying the same sensitivity label to each workspace is an item- and workspace-level classification tool for data protection, not a grouping mechanism for administration. Adding the workspaces to one deployment pipeline conflates lifecycle promotion (dev/test/prod) with organizational grouping; a pipeline moves content between stages, it does not classify workspaces for governance. Before finalizing, check the admin portal's Domains list to confirm each conservation workspace shows the expected domain assignment and that a domain admin has the rights to manage it.