Azure / Basic: scope, identity, location, and resources / Lesson 1

Azure resource hierarchy and responsibility

Distinguish tenant, management group, subscription, resource group, and resource. Build an ownership model before choosing services or making any deployment request.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain identity, management, and billing boundaries.
Organize resources by lifecycle and ownership.
Separate a planning model from a deployment specification.

Several boundaries coexist

An Azure design includes identity, billing, management, networking, and application boundaries that need not coincide. A Microsoft Entra tenant provides an identity directory context. A subscription is an important management, quota, and billing boundary associated with a directory. Management groups organize subscriptions for governance. Resource groups organize related resources, while Azure Resource Manager provides the management plane for creating and controlling them. Do not infer that one subscription equals one user, one region, or one application. Start by naming the workload owner, data owner, and authority allowed to approve changes before choosing the hierarchy.

A resource group is a lifecycle decision

Resources placed together should have compatible lifecycle and management needs. Deleting a resource group can remove its contained resources, so a shared database should not casually live inside an experiment’s disposable group. Resource-group location stores group metadata and does not force every contained resource into that region. Regional service support remains a separate decision. The synthetic plan below separates a temporary frontend experiment from a retained data component. It is a teaching JSON model, not an ARM template, and does not prove Azure would accept particular names, policies, dependencies, or service configurations.

json A synthetic lifecycle plan

{
  "model": "planning-only",
  "groups": [
    {
      "name": "training-web-lab",
      "lifecycle": "disposable",
      "resources": [
        "frontend"
      ]
    },
    {
      "name": "training-data",
      "lifecycle": "retained",
      "resources": [
        "catalog-data"
      ]
    }
  ]
}

Expected output

frontend: disposable; catalog-data: retained

The separation protects the planning intent. It is not a safeguard enforced by Azure until actual policies, permissions, and lifecycle procedures are designed and verified.

Inventory must identify ownership, not just names

Use a consistent inventory with resource identifiers, environment, owner, purpose, and retention expectations. Names have resource-specific rules and are not interchangeable with stable IDs. Tags provide useful metadata but do not automatically become inherited permissions or a complete cost allocation system. Avoid secrets or personal data in names and tags. The local calculation groups a synthetic inventory by owner to expose an unassigned item. It only validates the arithmetic and missing-owner rule, not Azure discovery, permissions, billing completeness, or the state of an actual subscription. Every resource in this course is hypothetical.

python Offline ownership accounting

resources = [{"owner": "team-a"}, {"owner": "team-a"}, {"owner": None}]
assigned = sum(item["owner"] is not None for item in resources)
print(assigned, len(resources) - assigned)

Expected output

2 1

Two synthetic items have an owner and one needs a decision. No Azure account, SDK, network, or CLI is used.

Managed services change responsibilities rather than remove them

A managed service can reduce platform maintenance while leaving application correctness, data classification, access policy, and recovery decisions with the workload owner. The exact division depends on the service and hosting option. Do not treat a service badge as proof of compliance or recoverability. Define who checks identity access, network exposure, backup restoration, application dependencies, and support lifecycle. A resource hierarchy can make that ownership easier to apply, but a diagram alone cannot enforce it. Review both technical operators and the people who can approve a destructive or expensive change.

Plan with explicit assumptions and bounded evidence

Record the intended hierarchy and why it fits the workload. Verify actual service availability, quotas, governance rules, and identity scope through current official documentation before a future authorized implementation. This course performs no Azure account operations and makes no pricing, free-tier, or deployment-success promise. Offline JSON and arithmetic examples illustrate decisions only. A review should identify which resources share a failure or deletion boundary, what must survive an experiment, and which unknowns remain. That is more useful than a large subscription diagram whose ownership, cost scope, and lifecycle consequences are unexplained.

Common errors and fixes

A disposable group contains shared retained data

Why it happens: Grouping follows convenience rather than lifecycle.
How to fix it: Separate lifecycle ownership and review deletion impact.
Prevent it next time: Classify retained dependencies before planning cleanup.

Tags are assumed to enforce permission

Why it happens: Metadata is confused with an authorization boundary.
How to fix it: Design explicit role scope and policy controls.
Prevent it next time: Review metadata and access assignments separately.

A resource-group region is treated as every resource region

Why it happens: Metadata location and service placement are conflated.
How to fix it: Record each resource location and availability assumption.
Prevent it next time: Validate regional service choices independently.

Check your understanding

1. A temporary web experiment uses a database needed by another team. Where should lifecycle ownership be clarified?

Show worked solution

Identify the database as retained shared data and keep its lifecycle outside the disposable experiment plan. Document owner, dependencies, deletion impact, and the permission required for destructive changes. A separate group can help express that design, but access policy and operational review must enforce it.

2. Does a JSON planning model prove a valid Azure deployment?