Azure Cloud — Identity, Storage, Networking, App Service

Review and execution boundary

This is a source-qualified design lesson and offline model, not an executed Azure deployment. The full original and current bodies were re-read on 10 October 2026. Verified 7–8 October evidence is reused where applicable; newly checked official snapshots govern availability zones, region/SKU gates, network direction, registry roles and cost scope. Mutable Azure documentation is not proof that your region, subscription or plan exposes every feature.

No Azure SDK call, tenant/resource operation, paid service, cluster, installation or deployment was performed. The original Python credential example pinned azure-identity==1.17.1; its source-level credential order is reviewed below, not imported or executed. Only the pure local readiness function and arithmetic are executed. Publication metadata is unchanged.

Session 68 · M07 Systems & Infrastructure · SYS. Goal: design a small three-tier app by tracing identity, data, network and compute contracts. The original 90-minute session and timed phases are planning cues; optional preparation and operational exercises require separate time and authorization.

Why this session exists

Instead of memorizing a service count or assuming what every enterprise uses, trace one request: who calls, which data it needs, how it reaches that data, and where the code runs. Four teaching categories make those decisions inspectable.

By the end, name a service in each category; distinguish workforce/customer identity, managed identity and resource RBAC; choose Blob, Table, Cosmos DB or SQL from a query contract; and design a private network path without confusing a private endpoint with authorization.

Prerequisites

• S065 · Docker — you know what an image + registry are.
• S066 · Kubernetes basics — helpful when we cover AKS.
• S060 · Operating-system fundamentals — understand processes, ports and permissions. Azure VMs may run Linux or Windows; managed compute adds provider-specific lifecycle and identity contracts.

Pre-read and pacing

Choose preparation by gap: identity first if token audiences and roles are unfamiliar, networking first if DNS and routes are unfamiliar. The original “25 min total” cannot describe watching all three listed videos plus the readings. No video was watched or timed for this review; historical titles/channels below are finding labels, not verified attribution, praise, current availability or a promise of exam success.

• Microsoft Azure Fundamentals Certification Course (AZ-900) - Pass the exam in 3 hours! — originally labelled freeCodeCamp.org; optional overview of identity, storage, networking and compute. The title's duration and exam promise are not endorsed.
• Azure Networking — VNets, Subnets, Peering, Private Endpoints — originally labelled John Savill; optional packet-path orientation, not a requirement to watch at 1.5×.
• Microsoft Azure Managed Identity Deep Dive — originally labelled John Savill's Technical Training; optional workload-token orientation. Managed identity does not make credential leaks impossible.
• Azure Well-Architected Framework — original official reading pointer for reliability, security, cost, operations and performance; these five review dimensions differ from our four service categories.
• Authentication vs Authorization in Entra ID — original legacy-path reading pointer; use it to separate identity/token validation from access decisions. This exact historical destination is preserved, not newly reachability-certified.
• Introduction to Azure Storage — original official reading pointer for Blob, Files, Queue, Table and Disk access patterns. Not every storage product is a service inside one storage account: managed disks have their own resource contract.

(a) Intuition · 5 min

An office-building analogy separates the security desk (identity), storage rooms (data), connecting routes (networking) and workspaces (compute). It is only an orientation aid: a shared network is not automatic trust, a token is not permission to every room, and a managed room still needs a recovery plan.

Azure ML, API Management and Azure DevOps combine several of these concerns. A product's brand is not a new primitive or evidence that it has the same availability and billing contract as another product.

The four pillars in one sentence each

• Identity: Entra ID authenticates users/workloads; resource authorization is a separate decision. Azure RBAC role assignments have principal, role definition and scope. Anonymous/public data and key/SAS-authenticated requests exist too, so not every Azure request uses an Entra principal.
• Storage: Storage accounts provide Blob, Files, Queue and Table services; Cosmos DB and Azure SQL address different data/query contracts.
• Networking: VNets/subnets define address spaces; NSGs filter supported network paths. A Private Endpoint places a private network interface for a PaaS connection in a VNet; it does not move the whole managed service into that subnet.
• Compute: App Service, Container Apps, AKS, Functions and VMs trade control for operations burden. These are four teaching categories, not the five Azure Well-Architected Framework pillars.

A quick history so the naming makes sense

Microsoft’s 25 March 2014 announcement says Windows Azure would become Microsoft Azure beginning 3 April 2014, reflecting support beyond Windows. The Entra naming FAQ dates the Azure AD → Microsoft Entra ID announcement to 11 July 2023, with service-plan display names changing on 1 October 2023. This was a rename, not a new tenant or automatic replacement of application protocols. The original timeline mixed announcements, general availability and evolving product branding; those are different events and should not be used to infer a service’s support lifecycle.

Azure AD's rename to Microsoft Entra ID changes terminology, not the distinction between authentication and authorization. App Service is a managed web host; AKS exposes Kubernetes APIs; Container Apps abstracts orchestration; Fabric integrates analytics experiences rather than making every underlying service identical. Prefer current service documentation to inferring capabilities from historical brand timelines.

A reference three-tier app on Azure — what talks to what

Rather than memorising Azure's service catalog, trace a three-tier request from public entry to private data access. The labels on the API's outgoing paths introduce the identity and networking decisions behind each service choice.

Front Door is the public entry point; the API reaches storage and secrets under its own identity. The rest of the design breaks down into choosing a data store, granting access, connecting the network, and selecting where the code runs. The arrows are logical dependencies, not proof of private origin access or enabled WAF: those require supported SKU, origin configuration, DNS and network checks. The API needs a supported VNet-connected environment to reach private data endpoints; a line in this diagram creates none of that infrastructure.

The storage-service decision tree

Worked choice: put a course video in Blob, a transactionally consistent invoice/order model in SQL, and a simple (tenant, lesson) progress lookup in Table if its queries and single-partition constraints suffice. Consider Cosmos when distribution, document access and consistency/cost requirements justify it, not because “NoSQL is faster”. Estimate point reads and fan-out queries separately: an inefficient cross-partition query can dominate the RU budget.

The Identity model — what is a Managed Identity, and why do you care?

Identity answers who is acting; audience binds the token to a resource; authorization and networking decide whether that action can succeed.

Workforce identity, customer identity and workload identity

A user authenticates to an intended tenant/application; an access token's audience identifies the resource. Azure management RBAC is not the same as an application's roles, and role assignments need not all appear as token claims. A service principal is a tenant-local application identity; it can authenticate via certificates, secrets or federation. Managed identities are a special service-principal type whose credentials are managed by Azure, not a separate species of “identity with no credentials anywhere”.

System-assigned identity follows the resource lifecycle. User-assigned identity is separately managed and can be granted permissions before a runtime needs it (useful for private-registry image pulls). Both need the target's data-plane role and network reachability. A VM's IMDS endpoint, App Service/Container Apps identity endpoints and AKS workload-identity federation are different mechanisms; not every workload calls 169.254.169.254.

For customer sign-up/sign-in, distinguish Entra External ID external tenants from workforce tenants. Azure AD B2C stopped being available for purchase by new customers on 1 May 2025; existing customers have a documented support/lifecycle path. Do not prescribe a new B2C deployment in a 2026 design simply because an old tutorial uses it.

Key Vault references and credential selection

App Service Key Vault references let settings contain a secret URI rather than the value. The platform resolves the reference using the configured identity; the application still receives sensitive configuration and must not log/export it. Unversioned references cache values and are normally refetched within 24 hours; an app configuration change or supported refresh endpoint can force refetch. That is different from making an SDK get_secret request on every HTTP request. Secret rotation is not a promise that every consumer switches immediately.

DefaultAzureCredential is a versioned chain, not magic authentication. In Azure Identity Python, environment/workload/managed credentials precede developer credentials according to the installed version/options. In the original Python azure-identity 1.17.1 implementation, eligible environment, workload-identity and managed-identity credentials precede the optional shared token cache and developer tools; workload identity is gated by its required environment settings, and interactive browser is excluded by default. Do not transplant newer chain options into that historical pin. Diagnose which credential actually succeeded; a wrong environment service-principal setting can defeat the assumption “Azure means managed identity”. Prefer an explicitly chosen production credential and a deliberately configured developer identity; do not share a development client secret as the default fix. GitHub OIDC also needs its supported credential/token exchange setup, not automatic discovery from any CI job.

Networking — the five pieces you'll wire up

1. Choose non-overlapping VNet ranges based on expected scale and peering. Subnet sizes are service-dependent: delegation, reserved addresses, upgrade surge and platform minimums matter more than copying /24, /26 or /28 from a diagram.
2. NSGs are stateful filters at supported subnet/NIC boundaries. Default rules allow VNet traffic and Azure load-balancer probes before denying other inbound traffic; “private” is not least privilege by itself. Changing a rule is not necessarily termination of existing flows.
3. A Private Endpoint requires an approved connection, correct target subresource (for example Blob versus File), routing and DNS. Preserve the service hostname for TLS while resolving it through the private DNS path. Linked zones or a correctly configured shared resolver/forwarder can supply that path; direct linkage to every VNet is not the only possible architecture.
4. Creating an endpoint does not automatically disable the service's public endpoint. Configure public network access/firewalls independently and verify from allowed and disallowed networks.
5. Front Door is a global HTTP entry/acceleration service; Application Gateway is regional and VNet-oriented. Choose supported protocols, WAF tier, origin connectivity, latency and cost. Neither is always right for every public app.

Worked subnet arithmetic: an Azure IPv4 /27 has 32 addresses and five are reserved, leaving 27 before service-specific requirements. This arithmetic does not prove it is a supported or sufficient Container Apps/AKS subnet.

Compute — pick one; don't shop

Use the smallest operational surface that meets the workload. A two-service app can use AKS when an existing platform makes it appropriate, but “microservices” by itself is not a reason to create a cluster.

The service choices make the request path concrete, but its availability also depends on which underlying dependencies share a failure domain. Managed services do not remove that regional design question.

Availability zones and hidden dependencies

A region contains one or more datacenters; an availability zone is a grouping of one or more datacenters with independent power, cooling and networking relative to other zones. A zonal deployment pins a supported resource to one zone; a zone-redundant service distributes or replicates its components across zones under its own contract. Neither “three instances” nor “this region has zones” proves the resource spans them. Not every region is paired, and a region pair is not automatic application failover.

Worked SKU decision: the retrieved App Service reliability guide supports zone redundancy for Premium v2–v4 plans with at least two instances, a supported region and a zone-capable scale unit. For v4, both v4 availability and zone support must be checked. All apps in the plan share its workers; three apps in one nonzonal plan are not three independent failure domains. Inspect the plan's supported zone count and configuration before calling it redundant. Then size surviving-zone capacity: losing one of two equally loaded instances at 70% each would require 140% of one instance's prior capacity. Redundancy without headroom can still overload.

Zones reduce datacenter-level correlated failure for supported zone-redundant configurations; they do not eliminate shared identity, DNS, policy, quota, application-bug or regional dependency risks. A multi-region API that reads one regional vault still has that dependency. Pre-provision appropriate recovery capacity where ARM unavailability would otherwise block recovery, and test RPO/RTO with real data-replication/failover contracts. Existing data-plane traffic can continue during a control-plane outage, but it is not guaranteed independent of every underlying dependency.

For an authorized read-only inventory, these commands show metadata, not proof of availability:

az resource list --query "[].{n:name, loc:location, t:type}" -o table
az account list-locations --query "[?metadata.regionType=='Physical'].{name:name, pair:metadata.pairedRegion[0].name}" -o table

Storage redundancy, recovery and cost scope

For storage accounts, LRS keeps replicas within a datacenter; ZRS synchronously distributes data across supported zones; GRS/GZRS add asynchronous replication to a secondary region (with different primary-region redundancy). RA-GRS/RA-GZRS additionally expose secondary reads. Secondary data can lag; promotion/failover and application reconnection remain separate from replication. These storage-account modes are not the same as Cosmos consistency or SQL failover groups. Check service, region, account kind and feature compatibility before choosing one.

Worked failure: an object overwrite is replicated faithfully, so more replicas do not recover yesterday's object. Versioning, soft deletion, retained backups and restore tests address different recovery requirements. For regional loss, explicitly bound acceptable data loss (RPO), recovery time (RTO), the actor authorized to fail over, and whether DNS/client caches and dependent identity/network services still work.

Cost has scope, meter and time: instance-hours/minimum replicas, stored bytes and operations, Cosmos throughput or request consumption, image registry, logs, private endpoints, bandwidth and recovery capacity can all contribute. A “free” API allowance does not make the whole architecture free. Estimate low/base/high traffic with current region/SKU/currency rates; no dollar figure here is a live quote. An illustrative meter of 2 instances × 24 hours is 48 instance-hours, before any other meter. A budget sends notifications after cost processing/evaluation; it does not stop consumption or create a hard cap. Scope budgets and ownership to the resources actually billed and handle shared-cost allocation deliberately.

Hierarchy, tags and blast radius

Management groups organize subscriptions; subscriptions associate with an Entra tenant for identity and provide management/billing/quota scopes; resource groups group compatible lifecycles. RBAC and Policy can inherit through these scopes. Not every quota is per subscription per region: inspect the specific service/tenant/resource limit and any increase process. Resource moves have supported-type and dependency constraints.

Tags help ownership/cost reporting and can participate in supported policy/attribute-based controls with proper permissions. They are not a universal substitute for management scope, but saying tags can never be used for enforcement is also wrong. Restrict who can mutate security-relevant attributes. Policy exemptions and RBAC permissions mean inheritance is not an immutable magical boundary.

Choosing subscription boundaries

A separate production subscription is a useful default design candidate, not a zero-cost guarantee. Record why the boundary fits this platform, automate baseline policy/access, and identify shared services explicitly. Cost can also be grouped by subscription/resource group without relying entirely on tags. Ownership metadata can be backfilled, but establishing it at creation is easier.

Control plane, data plane and throttling

Creating an account is control-plane work; reading its blobs is data-plane work. A management Contributor role does not automatically confer Blob Data Reader. Conversely, broad control-plane rights can sometimes obtain keys or change network settings, so they are not harmless just because a data-plane role is absent. Assess those escalation capabilities.

Cosmos request-unit limits, SQL capacity and other service quotas govern different workloads. Respect SDK-supported retry-after behavior for throttling and cap retries/deadlines; a 401 normally needs authentication diagnosis, not a blind exponential-retry storm. Identity SDKs cache still-valid tokens under their contract; do not bypass token validation or authorization to create a “fallback” during an identity outage.

(c) Hands-on · 25 min

Review the three-tier architecture above as an offline threat/permission exercise. The original shell script created cloud resources, lacked a complete private-registry image-pull identity grant and exposed secret metadata through a public endpoint. It is not a safe complete deployment recipe.

Prepare this dependency matrix before any authorized deployment:

Sequence identities and grants before their dependent image pulls; RBAC propagation is eventual, so a fixed sleep is not proof. Record bounded retry/status checks without printing tokens. Configure a boolean readiness result with no secret contents or lengths. Set actual application/container limits and a budget notification, but do not call that a hard cost cap.

Exercise: registry access works locally under your developer identity but deployment cannot pull. Solution: check the runtime pull identity, scope/role, registry configuration and DNS independently. Your local login is not evidence that the hosted runtime has access.

Worked reconstruction of the original deployment lab

The original lab's learning path remains useful: resource group → private registry build → Key Vault → container host → identity/grants → request → cleanup. It needs separate actors and an observable contract:

1. Lifecycle: choose an explicitly authorized disposable subscription/resource group and inventory chargeable components. A free execution allowance does not make registry, logs, network and storage cost zero.
2. Artifact: build the reviewed Dockerfile/source, scan/pin dependencies and retain the pushed image digest. ACR build is a remote build with its own permissions/architecture; do not infer native architecture from the developer laptop.
3. Registry pull: create/select a user-assigned managed identity, grant the applicable registry pull permission at the correct scope and configure the Container App's registry identity. In classic ACR RBAC mode, AcrPull is the familiar pull role; in RBAC + ABAC repository-permissions mode, use the supported Container Registry Repository Reader role and repository conditions as appropriate. Check the registry's mode rather than copying a role name across modes. User-assigned identity avoids needing a running container before pull permission exists. A system-assigned bootstrap flow can also work when implemented in the supported sequence; merely adding --system-assigned is insufficient.
4. Secrets: a provisioning actor writes an actual secret through a protected flow; the runtime receives only its own read permission. Do not use az ad user show on every caller: a CI principal is not necessarily a human UPN. No demonstration password belongs in a command line or public response.
5. Hosting: configure the reviewed image, resource limits, port and ingress. Container listeners bind the container interface required by hosting; any local verification server binds loopback. Validate readiness without returning secret contents, lengths or vault identifiers.
6. Application credential: select the user-assigned identity explicitly where multiple identities exist. Reuse a supported SDK client and avoid fetching a secret on every public request merely to demonstrate identity. Credentials are not authorization: test each data-plane operation independently.
7. Observation: record readiness, revision/image digest and a redacted dependency status. Role propagation and token caches can delay both grants and revocations. A fixed 20/30-second sleep or revision suffix does not prove convergence.
8. Cleanup: inventory resources before deletion; asynchronous deletion is not confirmation that every resource and billable dependency is gone. Locks, backups and external dependencies require verification.

Private-endpoint extension: worked packet path

Container App revision → environment VNet route → resolver → vault-name.vault.azure.net resolved through the private-link DNS path → approved vault endpoint → TLS hostname validation → managed identity token → Key Vault data-plane authorization. The original extra VNet/endpoint commands never connected the existing Container Apps environment to that network or configured DNS, so they could not establish this path. Select the supported environment networking profile up front, configure its dedicated infrastructure subnet and private DNS/resolver, then disable public access after the private path is proven. An NSG affecting a Private Endpoint needs the corresponding private-endpoint network policy enabled; a rule on an unrelated “database subnet” does nothing.

Safe offline readiness projection

A boolean projection can be tested without a vault, credentials or HTTP server. This is a minimal model, not a replacement for production health-check implementation, redacted diagnostics or SDK exceptions.

def readiness(dependencies):
    required = ("registry_image", "identity", "dns", "secret_read")
    return {"ready": all(dependencies.get(name) is True for name in required)}

Given all four statuses true it returns only {"ready": True}. If DNS or permission is false/missing it returns false; adding a secret value/length to the input cannot make that metadata appear in output. A real startup probe and a real token flow remain unexecuted.

(d) Production reality · 15 min

Three failure analyses, not invented postmortems

Token issuance unavailable: existing valid tokens may continue to work until expiry depending on service/session policy; new issuance can fail. Use supported SDK caching, bounded transient retries and appropriate degraded features, but never skip authorization or blindly retry every 401. The earlier named/date-specific 14-hour Azure AD story was not established by its linked source and is not asserted here.

Signing trust compromised: a token accepted under a compromised trust key is an identity security incident, not something a network firewall alone repairs. Restrict audience/issuer/tenant and permissions, retain audit evidence, follow provider key-revocation guidance and analyze access. Conditional Access and short token lifetime reduce some risks but do not categorically defeat forged-token validation bugs. The former Storm-0558 prose made unverified causal/remediation claims beyond the retrieved source; it is replaced by this explicit synthetic trust-boundary analysis, not recast as a real incident.

Lateral network reachability: an approved Private Endpoint can be reachable from connected networks unless controls restrict them. Apply supported endpoint network policies and NSGs/routes, inspect effective behavior and retain database authorization. Reachable port does not mean authenticated database access. Private endpoint creation does not by itself disable public access.

Common footguns you'll hit

• Confusion of subscriptions, resource groups, tenants — a tenant is your Entra ID directory; subscriptions are associated with a tenant; resource groups organise resources within a subscription. Get the hierarchy wrong and you make a resource nobody has access to.
• Role assignment propagation delay — RBAC and managed-identity token caches have service-specific propagation behavior, sometimes much longer than five minutes. Use bounded probes and distinguish wrong scope/role from propagation; never turn a fixed sleep into a success assertion.
• Assuming public access from defaults — inspect each service/account's actual public-network setting and firewall, including policy/template overrides. A private endpoint does not disable the public path. Prove the private path before an authorized public-access change.
• Az CLI points at the wrong tenant/subscription — an authorized future operator must compare the resolved tenant/subscription/resource IDs with the intended scope and fail closed on mismatch. A hard-coded context switch is not evidence that the caller is allowed to modify that scope; no context switch is performed here.

Where this shows up in the rest of the plan

Terraform/Bicep turn these resource contracts into declarative lifecycle management; AKS connects the Kubernetes lessons to Azure identity and networking; Front Door and CDN connect to edge-cache behavior. Azure Monitor, Log Analytics, Application Insights and KQL connect to observability. Conditional Access, PIM and Defender are optional identity/governance/security topics, not a guarantee this architecture implements them. Cosmos DB, Front Door and Traffic Manager raise replication, HTTP entry and DNS-routing choices respectively; their names alone do not prove multi-region recovery.

Azure Arc and hybrid management are optional control-plane extensions, and Fabric/Synapse/Data Factory/Power BI are analytics services/experiences with distinct contracts. Historical launch/branding cards were not reliable support-lifecycle evidence; use the verified Azure/Entra rename dates above and current service-specific documentation instead of inferring feature availability from a year label.

(e) Recall + stretch · 10 min

Worked recall answers

Question 1: Name the four pillars of Azure and one flagship service in each.

Answer: Identity/Entra, storage/Blob, networking/VNet and compute/App Service are this lesson's four categories. Reliability, security, cost, operations and performance are the distinct Well-Architected review dimensions. Question 2: What's the difference between a Service Principal and a Managed Identity?

Answer: A service principal is a tenant-local workload identity, not necessarily a client-secret credential. Managed identity lets Azure manage credentials; federation or certificates are also alternatives to stored application secrets. Authorization remains separate. Question 3: You need a global multi-region NoSQL store with 5-ms reads and multi-master writes. What Azure service?

Answer: Cosmos DB can fit distributed document/point-read workloads, but do not promise every query completes in 5 ms. Multi-region-write accounts cannot use strong consistency. Current documentation describes bounded staleness for multi-region writes too, while noting it is primarily beneficial to single-write-region accounts; choose it from its lag/throttling tradeoff, not as a universal default. Session/consistent-prefix/eventual choices have different contracts. Size partition keys and conflict resolution before making latency/cost claims. Question 4: Explain a Private Endpoint in one sentence.

Answer: A Private Endpoint supplies a private interface/address for a supported service connection. DNS, routing, endpoint approval, public-access settings and data-plane authorization are independent checks. Question 5: You have a static site + a small REST API. Which compute service?

Answer: A static site plus small API can fit Static Web Apps, App Service or Container Apps depending on runtime and operations. Prefer AKS only when its capabilities or an existing platform justify its overhead. Question 6: What's the difference between Front Door and Application Gateway?

Answer: Front Door is global HTTP entry/acceleration; Application Gateway is regional/VNet-oriented. Verify protocol, SKU/WAF and private-origin support rather than using a fixed PoP count or universal choice rule. Question 7: How do you give an App Service permission to read secrets from Key Vault without any client secret?

Answer: Enable the intended identity, authorize its vault secret-read operation, configure a reachable reference URI and verify resolution. App Service caches references; it does not necessarily fetch on every request. Question 8: What does ‘az group delete -n RG --yes --no-wait’ actually do?

Answer: az group delete --no-wait submits asynchronous deletion of the selected group and its contained resources; locks/errors can prevent completion. Review the exact scope and verify completion rather than assuming command return means all resources/costs disappeared. Question 9: Your app authenticates OK from Azure but fails locally. Why?

Answer: Inspect which credential the installed DefaultAzureCredential version selected and the local user's target-tenant/data-plane access. Environment credentials can precede developer login. Fix the intended identity/role/network path; do not add broad Contributor or share a dev secret as a default remedy.

Stretch answer: one million connections is a capacity problem

Original question: Stretch — Draw the architecture for a WhatsApp-like chat backend on Azure that must scale to 1M concurrent users. Which services?

Do not pick services by brand and call the design proven. If one million sockets average 16 KiB connection memory, that is roughly 15.26 GiB before application state, TLS, buffers or runtime overhead. One 200-byte event per user per minute is about 3.33 MB/s payload before fan-out, envelopes, retries and network overhead. Measure per-instance connection limits and partition traffic; front-door/proxy protocol support and timeouts must match the actual socket path.

A candidate design separates connection gateways (a supported managed realtime service or measured AKS/Container Apps/App Service workers), durable messages/metadata (partitioned Cosmos or a relational store according to consistency), media (Blob with narrowly scoped expiring access), ephemeral presence (a supported cache) and durable notifications (queue/pub-sub selected for ordering/delivery semantics). Evaluate Entra External ID for new customer-identity deployments rather than presuming new B2C availability. Use supported Azure Managed Redis or another reviewed cache rather than adopting a retiring legacy Redis tier by name.

Decide ordering per conversation, idempotency key, reconnect/replay window and offline delivery before drawing fan-out arrows. A recipient must be authorized before message/media access; a SAS is a bearer capability and must be scoped/short-lived. Private endpoints protect network paths, not message authorization. Observe connection churn, per-partition throttling, queue lag, end-to-end latency and cost. A service list alone is neither a one-million-socket benchmark nor an SLA proof.

Explain-out-loud test

1. What are the four Azure pillars and which service anchors each?
2. Why is Managed Identity better than a Service Principal with a secret?
3. When would you pick App Service over AKS, and vice versa?

What comes next

Next: S069 · Infrastructure as Code — Terraform / Bicep Basics. This transition carries resource/state lifecycle forward; it does not certify the destination's current review.

Hub: The 6-Month Learning Plan

Session 68 of the original 130-session sequence: intuition → visual → offline practice → failure analysis → recall. The 90-minute plan is an estimate, not an evergreen-correctness or completion guarantee.

What each block does

The original automated shell sequence is replaced by a dependency matrix because it did not completely grant private-registry pull permission and exposed secret metadata. Resource-group creation is a lifecycle/control-plane operation; registry build/push produces an artifact; identity and role grants authorize independent data-plane actions; hosting configuration connects that artifact to a listener. None should be inferred from another stage's success.

Trace failures in order: artifact exists at the recorded digest; runtime pull identity is assigned and authorized; revision has started and bound the configured port; DNS/routes reach the dependency; dependency data-plane role is effective; application authentication/authorization permits only the intended caller. Do not fix an image-pull failure by making the registry public or fix a Key Vault denial by logging its value. Bounded role-propagation retries should inspect status, not sleep and assume success. This is a valid conceptual deployment diagnosis lesson without creating cloud resources.

Corrected contracts and failure analysis

Managed identity authenticates a workload without a developer-managed credential, but access still requires the correct data-plane RBAC role and network reachability. Contributor on a storage account is a management role, not automatic Blob Data Reader/Contributor authorization. Private endpoints require correct private DNS resolution; a private IP without name resolution does not prove the application is private.

App Service VNet integration is outbound, not an inbound private endpoint. Storage redundancy selection depends on durability, recovery-point/recovery-time requirements, region constraints and cost. Geo-replication is asynchronous and is not a substitute for tested backups or application failover. Choose compute from workload duration, latency, state and operating burden; neither AKS nor Functions is a universal best choice. Budgets issue notifications, not hard spending caps.

Boundary exercise with solution

A workload resolves storage to a public IP despite a private endpoint. Should adding Contributor fix it?

Source-backed review notes

Full-body re-review: 10 October 2026. The batch-38 packet re-verifies inherited 7 October raw/canonical snapshots and retains added governing passages, document identity and hashes. Mutable documentation is not a pin to an installed service/runtime version.

Original incident-reading pointers are retained for context, not accepted as evidence for the former date/duration/causal claims: historical Azure AD incident report destination and Microsoft mitigates China-based threat actor Storm-0558. Their present availability and full incident contents were not reverified; the body uses explicitly synthetic failure analyses.

• Frequently asked questions (FAQ) for Azure Active Directory B2C | Microsoft Learn — B2C end-of-sale for new customers requires a different new-customer identity evaluation.

• Consistency level choices - Azure Cosmos DB | Microsoft Learn — Multi-write excludes strong consistency; this restriction must not be invented for every weaker level.

• Introduction to Table storage - Object storage in Azure | Microsoft Learn — Table is a key/attribute non-relational store and a distinct original objective.

• What is a private endpoint? - Azure Private Link | Microsoft Learn — Private endpoint creates a NIC/address, not relocation of the entire service into the VNet.

• Manage network policies for private endpoints - Azure Private Link | Microsoft Learn — Private endpoint NSG/route policy must be explicitly enabled for supported controls.

• Azure Container Apps image pull from Azure Container Registry with managed identity | Microsoft Learn — Identity and registry pull permission can be established before private-image deployment.

• Managed identities for Azure resources - Managed identities for Azure resources | Microsoft Learn — Managed identity is a special service principal with lifecycle and separate authorization.

• Credential chains in the Azure Identity library for Python - Python on Azure | Microsoft Learn — Credential chain order/options matter; developer login is not always tried first.

• Use Key Vault References as App Settings - Azure App Service | Microsoft Learn — App Service reference cache/refetch differs from per-request SDK reads.

• Upcoming Name Change for Windows Azure | Microsoft Azure Blog — Vendor announcement fixes rename timing and cross-platform meaning.

• New name for Azure Active Directory - Microsoft Entra | Microsoft Learn — Entra naming date is a rename event, not automatic identity/protocol migration.

• Availability zones, regions and App Service reliability — region, plan, scale-unit and instance-count gates.

• App Service VNet integration, private endpoint DNS and NSGs — outbound versus inbound, resolver and stateful-flow contracts.

• Storage redundancy, budgets, RBAC scope and ACR roles — recovery, meter/scope and mode-specific permissions.

• Functions hosting limits and Python DefaultAzureCredential 1.17.1 source — plan-specific timeouts and the original pinned credential contract, not SDK execution.