AZ-305 Practice Question 23: Workspace Topology Residency
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 3 · question 3 of 10
A manufacturer has 35 subscriptions in one Microsoft Entra tenant, with resources in West Europe, East US, and Germany West Central. The monitoring design must satisfy:
- Telemetry generated by resources in Germany must be stored in Germany. - Each of the 18 application teams must be able to query telemetry for the resources they own, without being granted read access to other teams' telemetry. - The central operations team must query across as much of the estate as possible from one place. - The design should use as few workspaces as possible, partly so that overall ingestion qualifies for a commitment tier discount.
Which workspace architecture should you recommend?
Show answer and explanation
Answer:
Microsoft's stated design strategy is to start with a single workspace and add workspaces only as specific criteria force it, using the fewest that meet the requirements. Exactly one criterion forces a split here: each workspace resides in a particular Azure region, and a requirement to keep data in a particular geography means a separate workspace for that geography. Two workspaces is therefore the minimum, and consolidating everything else keeps ingestion volume high enough to reach a commitment tier. The per-team requirement is then met without any extra workspaces by resource-context RBAC: with the default access control mode, a user who has read access to a resource inherits permission to that resource's monitoring data in the workspace, and sees nothing else.
Option A multiplies workspaces by a factor of seventeen for no requirement. It splits ingestion across 35 workspaces so no commitment tier applies, and cross-workspace queries become the normal case rather than the exception, the scenario Microsoft warns scales poorly.
Option C satisfies every requirement except the one that is not negotiable. A single West Europe workspace stores German resources' telemetry outside Germany, breaking the residency requirement. Table-level RBAC is also the wrong tool for this cut: it grants or denies whole tables to users, whereas the teams need per-resource separation *within* the same tables.
Option D is the most expensive design in the list. It creates 54 workspaces, prevents any commitment tier, forces the operations team to query across dozens of workspaces, and still needs per-team access management, all to achieve what resource-context RBAC already gives inside one workspace.