A city IT team deploys a storage account from the Azure portal, then creates a virtual network with Azure CLI, and later updates a resource group with Azure PowerShell. Which Azure capability do all three methods use as the common control plane?

Azure Resource Manager (ARM) is the shared control plane that accepts create, update, and delete requests for Azure resources no matter which client the city IT team uses. Portal clicks, Azure CLI commands, and Azure PowerShell cmdlets all translate into ARM API calls, so tagging, locks, role-based access, and resource-group placement behave consistently across tools. That single pipeline is why mixed tooling still produces a coherent municipal estate instead of three incompatible ways of changing Azure.

Azure Advisor fails this requirement because it only issues personalized best-practice recommendations for cost, security, reliability, and operational excellence; it never sits in the path of every deployment request. Azure Service Health fails because it communicates Microsoft platform incidents, planned maintenance, and health history for subscriptions—not the control plane that builds a storage account or virtual network. Microsoft Purview fails because it focuses on data governance, cataloging, and compliance mapping of data estates rather than provisioning infrastructure through a common management fabric.

Exam caveat: candidates sometimes treat the portal as a separate "product" from CLI and PowerShell. At AZ-900 depth, remember that those interfaces are clients of ARM; they are not alternate control planes.

Operational check: after deploying with different tools, open the resource in the portal and confirm the same resource group, tags, and activity-log entries appear regardless of whether the last change came from CLI or PowerShell—evidence that ARM unified the request path.