A resource ID is Azure's entire hierarchy, spelled out

Unlike AWS ARNs, which compress the account/region/service/resource hierarchy into a compact colon-delimited string, an Azure resource ID lays the full path out as a literal filesystem-like path: subscription, then resource group, then resource provider namespace, then resource type and name, repeated for nested child resources. That verbosity is deliberate — an Azure resource ID doubles as the actual REST API path used to manage that resource, so the ID you see in the portal or CLI output is, structurally, the same thing you'd send in an ARM API request. Parsing it is really just reading off that hierarchy segment by segment.

Why nested child resources repeat the type/name pattern

A resource like a subnet doesn't exist independently — it's a child of a virtual network, which is itself a top-level resource under a provider namespace. Azure represents that nesting by repeating the type/name pair for each level of the hierarchy (`.../virtualNetworks/vnet1/subnets/subnet1`), rather than inventing a separate ID scheme for child resources. This tool walks that repeating pattern to reconstruct the full resource type and name, which is why a deeply nested resource ID (several levels of parent/child) parses the same way structurally as a simple top-level one — it's just more repetitions of the same pattern.