Microsoft Azure Services and Architecture Questions

Direct answer

An Availability Set protects virtual machines (VMs) from failures inside one datacenter by spreading them across separate power and network segments (fault domains) and separate maintenance batches (update domains), earning a 99.95% connectivity SLA (Service Level Agreement, Microsoft's contractual uptime guarantee) for two or more VMs. Availability Zones spread VMs across physically separate datacenters within the same region, each with its own power, cooling, and networking, earning a 99.99% SLA for two or more VMs placed across two or more zones, at the cost of slightly higher inter-VM latency. A single-instance VM on Premium SSD or Ultra Disk gets a 99.9% connectivity SLA on its own, with neither construct in play.

Fault domains and update domains

• Fault domain (FD): a group of VMs sharing a physical rack, power source, and network switch inside one datacenter. Azure spreads the VMs in your set across up to 3 fault domains (the exact managed-disk FD count is 2 or 3 depending on region), so one rack or power failure only ever takes out one FD's share of your VMs.
• Update domain (UD): a group of VMs Azure reboots together during planned platform maintenance. A set gets 5 update domains by default (configurable up to 20), and Azure updates one UD at a time, waiting roughly 30 minutes before moving to the next, so at least one other UD is expected to stay live throughout a maintenance rollout.
• You don't choose which FD or UD an individual VM lands in beyond specifying the total counts; Azure assigns them automatically the moment you place two or more VMs in the same set.

Availability Zones

A zone is one or more physically separate datacenters in a region, each with independent power, cooling, and network connectivity. Spreading VMs across 2 or 3 zones survives a full datacenter-level outage, something an Availability Set (confined to one datacenter) cannot do. The trade-off is latency: inter-zone round trips run a bit higher than inter-fault-domain hops inside one datacenter (Microsoft doesn't publish a numeric guarantee, but plan for low single-digit milliseconds), which matters for synchronous, latency-sensitive replication. Not every Azure region has zones; every region supports Availability Sets.

SLA comparison

Worked example: three-tier web app, single region

The web tier (stateless, autoscaled) and app tier (stateless) gain the most from Availability Zones: 99.99% versus 99.95% is a meaningful jump at scale, and neither tier carries state that zone-spanning replication would complicate. Put each behind a zone-redundant Standard Load Balancer and spread instances across 3 zones.

The database tier is where the choice gets interesting. If it's SQL Server on VMs running a synchronous Always On availability group (a SQL Server feature that keeps a live, synchronized replica of a database ready to take over) and the workload is latency-sensitive OLTP (online transaction processing: many small, fast read/write operations), spreading replicas across zones adds real replication latency that keeping the database tier in one Availability Set (or even one zone) avoids; a synchronous secondary with minimal lag can be the right call even while the stateless tiers spread across zones. If instead surviving a full datacenter outage matters more than shaving replication latency, accept the extra hop and make the database tier zone-redundant too. Mixing constructs across tiers of the same application is normal, not a compromise.

Trade-offs and pitfalls

• You cannot convert a running Availability Set VM to a zone deployment in place; it requires redeploying the VM, so decide this at design time.
• Update domains only protect against Azure-initiated maintenance overlap; they do nothing for an application bug or a bad deployment you push yourself. Pair either construct with health probes and rolling application rollouts.
• A common mistake is assuming 5 update domains means "5x redundancy." Redundancy is bounded by fault domain count (up to 3), not update domain count; update domains only stagger when Azure reboots VMs, not how many can fail at once from a hardware fault.

Direct answer

A worthwhile correction to the premise first: on a Consumption-plan Function, the token is not actually fetched from the raw platform Instance Metadata Service (IMDS, 169.254.169.254) the way an IaaS VM or VM Scale Set would; App Service and Functions expose their own local token endpoint (the IDENTITY_ENDPOINT/IDENTITY_HEADER environment variables, sometimes called the "App Service MSI extension"), which is a different mechanism serving the same purpose. Knowing that distinction is itself a senior-level signal, since the two failure modes (a VNet [Virtual Network, Azure's private network boundary] blocking outbound to IMDS's link-local address versus a missing App Service environment variable) are different problems with different fixes.

The actual flow

1. Environment variables, set automatically when the identity is enabled: IDENTITY_ENDPOINT (a URL like http://127.0.0.1:<port>/msi/token, local to the sandbox the Function runs in) and IDENTITY_HEADER (a rotating secret value used to authenticate the local call and mitigate server-side request forgery against that local endpoint).
2. Token request: the Azure Identity SDK (or a raw HTTP client) makes a GET to IDENTITY_ENDPOINT with the resource URI to get a token for (https://vault.azure.net for Key Vault), the api-version query parameter (2019-08-01), and the X-IDENTITY-HEADER header set to the value of IDENTITY_HEADER.
3. What answers that request: the App Service/Functions host's local identity service (not Key Vault, not Entra ID directly) which itself holds a certificate or exchanges with Entra ID (Microsoft's cloud identity service, formerly Azure AD) on the platform's behalf, and returns a bearer token scoped to the requested resource, along with an expires_on timestamp.
4. Using the token: the caller (typically the Azure Identity SDK's SecretClient, not hand-rolled code) attaches the token as a Bearer header on the actual call to Key Vault's REST API to read the secret.
5. Authorization check at Key Vault: Key Vault checks whether the token's principal (the Function's managed identity's object ID) has been granted an RBAC (Role-Based Access Control) role (or, on the older access-policy model, an access policy) allowing get/list on secrets. This is a separate check from "the token was issued successfully"; a perfectly valid token for a principal with no grant on this vault gets a 403, not a 401.

sequenceDiagram
    participant F as Function code
    participant L as Local identity endpoint (IDENTITY_ENDPOINT)
    participant KV as Key Vault
    F->>L: GET ?resource=vault.azure.net&api-version=2019-08-01, X-IDENTITY-HEADER
    L-->>F: access_token, expires_on
    F->>KV: GET secret, Authorization: Bearer <token>
    KV-->>F: secret value (if RBAC grants get/list)

Token caching and refresh

The Azure Identity SDK's credential objects cache the token in memory for the life of the process and refresh proactively, typically requesting a new one a few minutes before the cached one expires, rather than on every single call. Two consequences worth knowing: first, a Consumption-plan Function that goes cold and gets a fresh instance also gets a fresh in-memory cache, so cold starts always pay the token-acquisition round trip; second, if an admin changes the managed identity's role assignment (grants or revokes access), the token the app already holds is still valid until it expires, since revocation doesn't invalidate already-issued tokens, and the platform's group/role membership cache for managed identities can itself take up to roughly 24 hours to reflect the change even for a brand-new token request in some cases, so "I just added the role assignment and it still fails" for a short window afterward is expected behavior, not a bug.

Common failure modes

• Missing or absent IDENTITY_ENDPOINT/IDENTITY_HEADER: happens when running the same code locally (outside Azure) without local.settings.json providing an alternative credential path, or when the managed identity was never actually enabled on the Function App; the Azure Identity SDK's DefaultAzureCredential will fail through its whole credential chain and surface a fairly generic "no credential available" error, which is easy to misdiagnose as a Key Vault problem when it's actually an identity configuration problem.
• Network restrictions: if the Function App has VNet integration and a route that forces all outbound traffic through an NVA (Network Virtual Appliance)/firewall or a restrictive NSG (Network Security Group, a per-subnet/NIC firewall rule set), calls to Key Vault's public endpoint (or, if Key Vault has a Private Endpoint, calls that aren't routed correctly to it) can time out; this looks identical to an RBAC failure from the error message alone (both surface as the SDK failing to get the secret) unless you check whether the failure happens before or after a token was actually issued.
• Insufficient RBAC: a valid token but no Key Vault Secrets User (or equivalent) role assignment on the vault (or the specific secret, if using more granular access controls) for that identity's object ID; this returns a 403 from Key Vault itself, not an SDK-level credential error, which is the fastest way to tell it apart from the two failure modes above.
• Wrong identity used: on a Function App with both a system-assigned and one or more user-assigned identities, DefaultAzureCredential without an explicit client ID can pick the wrong one (or fail ambiguously); when more than one identity exists, always specify which one explicitly (ManagedIdentityCredential(client_id=...)) rather than relying on the default resolution.

Trade-offs and pitfalls

The most common misdiagnosis is treating every "can't get the secret" failure as an RBAC problem and re-granting roles repeatedly, when the actual cause is a network path issue or a missing identity configuration; check whether a token was even issued (App Service diagnostic logs, or a deliberate try/except around just the credential acquisition step versus the Key Vault call) before assuming the permission model is wrong. The role-membership propagation delay is also a frequent source of false alarms right after granting access; if it's been minutes, not hours, since the role assignment, the fix might already be correct and just not yet visible everywhere.

Direct answer

Azure Storage, Azure SQL Database, and Azure VM disks all encrypt data at rest by default using Microsoft-managed AES-256 keys and enforce encryption in transit through TLS 1.2 or higher, with no application changes required. The real design decision most teams make is whether to layer a customer-managed key (CMK, also called bring-your-own-key or BYOK) on top, held in Azure Key Vault or Azure Key Vault Managed HSM (a dedicated hardware security module service), which becomes a requirement rather than a preference under most regulatory or data-sovereignty mandates.

Structured elaboration

Azure SQL Database also supports Always Encrypted, a separate, complementary control that encrypts specific sensitive columns client-side, so the data stays encrypted even from a database administrator with full access to the server, which is a different property than TDE's page-level, at-rest-only protection.

Platform-managed versus customer-managed keys. With platform-managed (Microsoft-managed) keys, Microsoft creates, rotates, and safeguards the key; there is zero operational burden, and it satisfies baseline compliance for most SOC 2 (an independent audit of how a service provider protects customer data) or ISO 27001 (an international standard for information security management) needs, but you cannot independently revoke access or prove exclusive control of the key to an auditor. With customer-managed keys, you control the key's creation, rotation cadence, and revocation; disabling or deleting the key in Key Vault is a real cryptographic kill switch that also cuts off Microsoft's own ability to read your data. That control comes with real operational responsibility: if the key becomes unavailable, so does your data, so the key needs the same high-availability discipline (soft delete, purge protection, an offline backup of the key material) as the data it protects.

Managed HSM specifically. Azure Key Vault Premium and Azure Key Vault Managed HSM are both FIPS 140-3 (the U.S. government standard for validating cryptographic hardware and software) Level 3 validated today (the Standard tier, by contrast, uses software-protected keys with no dedicated hardware at all). The real distinction between Premium and Managed HSM is not the compliance level, it is tenancy: Key Vault Premium runs your HSM-protected keys on a shared, multi-tenant HSM pool, while Managed HSM gives you a single-tenant HSM pool dedicated entirely to your organization, with its own security domain and its own administrative control plane (the management interface used to configure and administer the resource, distinct from the data plane that handles actual key operations), separate from Key Vault's role-based access control (RBAC) model. Choose Managed HSM when a regulator or contract requires a dedicated, non-shared hardware boundary, not merely "an HSM," or when you need that independent administrative control plane; otherwise Key Vault Premium already gives you HSM-backed keys without Managed HSM's higher cost floor.

Worked example

A healthcare ISV storing patient records in Azure SQL Database and Blob Storage needs to show, for a HIPAA (the U.S. law governing protection of patient health information) business-associate audit, that it can revoke Microsoft's technical ability to decrypt its data within a bounded time. With platform-managed keys this is not possible, since Microsoft holds the only key. With a customer-managed key in Key Vault, disabling or deleting that key makes the data unreadable once every dependent service's cached key-validity check next expires (each service's own caching interval, not an instantaneous cutoff, so the exact bound should be confirmed against current Microsoft Learn documentation for Storage and SQL specifically before it is written into a compliance commitment). If the auditor's requirement is a dedicated, non-shared hardware boundary rather than Key Vault Premium's shared HSM pool, the ISV moves that same key into Managed HSM instead, which changes the tenancy model without changing anything about how Storage or SQL consume the key.

Trade-offs and pitfalls

Treating a customer-managed key as a free security upgrade rather than an operational commitment is the most common mistake: an inaccessible or accidentally deleted key takes production data down with it. Assuming Managed HSM is "just a bigger Key Vault" misses that it is a separate resource type with its own RBAC model and a materially higher cost floor, so most teams should default to Key Vault Premium and only move to Managed HSM when a specific requirement forces the single-tenant boundary. Finally, conflating "encrypted in transit" with "authenticated" is a real gap: TLS alone does not stop a valid but compromised credential from reading the data once it's decrypted server-side.

Direct answer

Use a single StorageV2 account, hierarchical namespace is not needed here since this is asset storage by key rather than a folder-hierarchy-heavy analytics workload, with a container layout separating originals from any derived renditions, a lifecycle-management policy with two time-based rules (Hot to Cool at 30 days, Cool to Archive at 360 days) driven off last-modified time, and Azure CDN or Front Door in front of the Hot and Cool tiers only. Archived content should never serve live traffic, both because Archive has no online read access at all and because rehydrating from Archive takes hours, not milliseconds.

Structured elaboration

Storage account and container design.

flowchart LR
    Upload[Blob uploaded to hot tier] --> Hot[Hot tier, days 0 to 30]
    Hot -->|lifecycle rule at day 30| Cool[Cool tier, days 30 to 360]
    Cool -->|lifecycle rule at day 360| Archive[Archive tier, year 1 to 6]
    Hot --> CDN[CDN edge cache for popular videos]

One StorageV2 account, or more if regional data residency requires it, with separate containers for originals (the source video files) and renditions (transcoded, streaming-ready outputs, if the platform does adaptive bitrate streaming, since those have a different access pattern, typically read far more often than the original master file). Key blobs with a hash or content-ID prefix rather than a sequential or date-only prefix, so a viral video's read traffic does not concentrate on a single storage partition.

Lifecycle management rules. Rule 1: after 30 days since last modification, tier to Cool. Rule 2: after 360 days since last modification, 30 in Hot plus 330 in Cool, matching the stated requirement, tier to Archive. The policy runs automatically once configured. Using last-modified rather than last-accessed as the trigger, unless the account explicitly enables last-access-time tracking, is a genuine trade-off worth naming directly: a video that is still frequently watched but has not been re-uploaded still ages out of Hot on this schedule.

CDN integration. Point Azure CDN or Front Door at the storage account, ideally through a small API or redirect layer, so frequently watched videos are served from edge cache on every request, not directly from Blob Storage's origin tier. This decouples which storage tier a blob's origin copy sits in from how fast a popular video loads for a viewer, since the CDN's own cache, with its own time-to-live set independently of the storage lifecycle policy, is what actually serves nearly all real traffic for anything popular, regardless of whether the origin has already tiered to Cool.

Cost versus retrieval-latency trade-offs, per tier. Hot costs the most per gigabyte stored but has no retrieval fee and no retrieval delay, appropriate for the 30-day window when a new upload is most likely to be actively watched and shared. Cool costs meaningfully less per gigabyte but adds a per-gigabyte retrieval fee and a minimum-storage-duration charge if moved or deleted early, appropriate once viewing has dropped off but a small tail of views, or a moderation or legal request, still needs immediate, no-wait access. Archive costs the least by a wide margin but has no online read at all: retrieving a blob requires an explicit rehydrate operation taking hours, a "high priority" rehydrate is faster than "standard" priority but still not immediate, and both should be confirmed against current SLA documentation before being quoted as an exact number to a client, so anything in Archive is, by design, a durability and compliance retention copy, not part of the live-serving path.

Audit and retrieval-SLA cost estimation. If the platform has any obligation, a legal hold, a content-moderation appeal, a copyright dispute, to produce a specific archived video within a bounded time, that bound has to be checked against Archive's actual rehydrate SLA, not assumed. If a business requirement states any video must be produced within 1 hour of a request, standard-priority Archive rehydrate does not meet that bar, so either high-priority rehydrate needs to be the default for this scenario at materially higher per-request cost, or a small percentage of flagged, high-risk content should be kept in Cool rather than Archive specifically to preserve fast retrievability, an explicit, costed exception to the general lifecycle policy rather than a blanket one, since archiving something that might need a 1-hour turnaround defeats the purpose of Archive's own SLA in the first place.

Worked example

A 2 GB video uploaded today sits in Hot for 30 days, viewed heavily in week 1 per the platform's own analytics, tapering off by day 20, then Cool for the next 330 days, a small trickle of views, each incurring Cool's per-gigabyte retrieval fee, negligible at this scale for a single file but the reason the lifecycle rule exists across the platform's full catalog, then Archive for the following 5 years, roughly month 12 through year 6 of the asset's life. If a copyright takedown request arrives in year 3, requiring review within 24 hours, standard-priority Archive rehydrate, typically completing within roughly 15 hours per Microsoft's documented target, which should be re-verified against current documentation before being written into an actual SLA commitment, fits inside that 24-hour window with margin. If the platform's actual legal requirement were instead 1 hour, this specific tiering schedule would need the flagged-content exception described above, since standard Archive rehydrate cannot reliably meet a 1-hour bound.

Trade-offs and pitfalls

Serving directly from the origin storage account instead of through CDN cache for popular content means every viewer's request pays Hot tier's read cost, and the origin's own throughput limits become the platform's actual scaling bottleneck. Triggering lifecycle transitions off last-accessed without enabling that tracking feature, or assuming it is on by default when it must be explicitly enabled and has its own small ongoing cost, silently falls back to last-modified and produces unexpected early archiving of still-popular-but-unedited content. And treating the 5-year archive retention as set once and done, without ever validating that a real request against archived content can be served inside whatever SLA the business has separately promised, is exactly the gap a compliance audit finds the hard way if it is never tested in advance.

Direct answer

Microsoft Entra ID (the current name for what was Azure Active Directory, or Azure AD) manages identities for an organization's own employees, partners, and devices; Azure AD B2C is a separate product for authenticating an organization's external customers in its own applications. As of May 2025, Azure AD B2C itself is closed to new customers; Microsoft's current recommendation for a new consumer-facing identity build is Microsoft Entra External ID, its next-generation customer identity and access management (CIAM) platform, so an answer to "which should I use today" for a brand-new project is not quite the same as "what is Azure AD B2C for," even though the underlying purpose the question is really asking about is unchanged.

Structured elaboration

Primary purpose. Microsoft Entra ID exists to manage who can access an organization's own resources: employees signing into Microsoft 365 or internal line-of-business apps, partner organizations granted limited access, and devices enrolled for management. Azure AD B2C (and its successor, Entra External ID) exists to manage an organization's customers: people who sign up for a consumer or business-customer-facing application the organization built, with no employment relationship to the organization at all.

Authentication flows each supports.

• Microsoft Entra ID: OAuth 2.0, OpenID Connect (OIDC), and Security Assertion Markup Language (SAML) for enterprise single sign-on, plus hybrid protocols like Kerberos (a ticket-based authentication protocol long used for logins inside on-premises Windows networks) for on-premises-integrated scenarios, conditional access policies, and passwordless methods like FIDO2 security keys (physical or built-in hardware authenticators, such as a USB key or a device's fingerprint reader, that replace a typed password under an open industry standard).
• Azure AD B2C / Entra External ID: OAuth 2.0 and OIDC as the primary protocols, social identity provider sign-in (Google, Facebook, Apple), local username/password or email one-time-passcode accounts, and fully customizable, brandable sign-up and sign-in journeys built for a consumer audience rather than an enterprise one.

Integration points. Microsoft Entra ID integrates with the enterprise application gallery, System for Cross-domain Identity Management (SCIM) provisioning for automatically syncing users from another system, and device compliance tools, which is exactly the toolkit an internal line-of-business app or a partner-facing enterprise portal needs. Azure AD B2C and Entra External ID integrate through web and mobile software development kits, custom authentication extensions for pulling data from external systems into the token, and self-service account management flows, which is what a public-facing consumer app or customer portal needs instead.

Scenarios where each is the better fit. Choose Microsoft Entra ID when the users are the organization's own workforce or trusted partners and the requirement is single sign-on, group-based access, device compliance, or integration with the broader Microsoft ecosystem. Choose the consumer identity product (Entra External ID for a new build, or continued use of Azure AD B2C for an organization that already has it) when the users are the public: customers signing up for a product with social login, self-service password reset, and a fully custom-branded experience with no internal directory relationship at all.

Worked example

Consider a company running both an internal expense-reporting tool used only by its own employees, and a public mobile app used by its retail customers. The expense tool authenticates through Microsoft Entra ID: employees sign in with their existing corporate account, group membership determines who can approve expenses over a threshold, and conditional access requires multi-factor authentication (MFA) from unmanaged devices. The retail mobile app authenticates through the consumer identity product instead: a customer signs up with their email or a Google account, no corporate directory entry exists for them at all, and the sign-up experience is fully custom-branded to match the retail app rather than looking like an internal Microsoft tool. Running both through the same Microsoft Entra ID tenant used for employees would either expose the internal directory structure to millions of consumer accounts or force awkward workarounds to keep them separate, which is precisely the problem the two-product split solves.

Trade-offs & pitfalls

The pitfall worth naming explicitly given where things stand today: an organization still describing a brand-new project as "we'll use Azure AD B2C" should be told that new B2C tenants have not been purchasable since May 2025, and pointed at Entra External ID instead, since building against a product that is closed to new customers is a real, avoidable planning mistake. A second common mistake is trying to force consumer-facing self-service sign-up through the organization's regular Microsoft Entra ID tenant to avoid standing up a second product, which conflates two fundamentally different trust boundaries: your own workforce directory is not the right place to hold millions of unvetted public sign-ups.