Microsoft Azure Services and Architecture Questions

Direct answer

Split the design into two independent problems that only merge at policy level: which vault tier holds which secret (Key Vault for general secrets and shared-tenant HSM-backed keys, Managed HSM for keys that must never leave a single-tenant, customer-controlled cryptographic boundary), and what governs when a key or secret changes (a routine rotation schedule tied to a defined cryptoperiod, versus an emergency path triggered by suspected compromise). PCI-DSS (Payment Card Industry Data Security Standard) does not mandate a universal rotation calendar; it mandates that you define and document a cryptoperiod per key based on its strength, algorithm, and exposure, and that you can prove role separation and an audit trail for every key-management action. Key Vault's built-in role-based access control (RBAC), version history, and Managed HSM's customer-held security domain give you exactly that natively, if you design around them instead of bolting audit on afterward.

Structured elaboration

Vault tiering

Rotation frequency and cryptoperiod

PCI-DSS Requirement 3.7 is the one that requires documented key-management processes and procedures covering the full key lifecycle, generation, distribution, storage, cryptoperiod-based changes, retirement, and custodian acknowledgment, with sub-requirement 3.7.6 specifically covering manual cleartext key operations and requiring split knowledge and dual control wherever a human ever touches key material in the clear. Requirement 3.6 is the companion requirement covering how the keys themselves must be secured, for example stored encrypted, inside a secure cryptographic device, or as full-length key components, with cleartext key access restricted to the fewest custodians necessary. Neither requirement hands you a fixed number of days; you set the cryptoperiod based on key strength, algorithm, and exposure, following NIST (National Institute of Standards and Technology) Special Publication 800-57 guidance, and you write that reasoning down.

In practice, for a PCI-DSS environment: rotate data-encryption keys (DEKs) on a defined cadence, commonly quarterly to annually, using envelope encryption, meaning the DEK is wrapped by a key-encryption key (KEK) held in the vault. Rotating the KEK does not require re-encrypting the underlying cardholder data, only re-wrapping the DEK, which is what makes frequent KEK rotation operationally cheap. Rotate application secrets and API keys more aggressively (30 to 90 days is a common baseline) since they are lower-value, higher-exposure targets and cheaper to rotate. Key Vault supports an automated rotation policy natively for keys, setting a rotation time and emitting an Event Grid notification, rather than requiring you to build a scheduler.

Certificates should auto-renew at a fixed percentage of their remaining lifetime (Key Vault's integrated-CA renewal typically triggers well before expiry) so rotation is never a manual fire drill.

Emergency rotation

Trigger conditions: confirmed or suspected key compromise, an offboarding event for someone who held cleartext access, or an audit finding. The first action is always to disable the affected key or secret version, not delete it: disabling stops new use immediately while preserving the version, so anything that legitimately still needs to decrypt old data with the old key version can still do so under access control, whereas deletion, even with soft-delete and purge protection, is a recovery operation, not a revocation one.

Whether the emergency rotation is seamless depends on a design decision made long before the emergency: applications that reference a secret by its versionless URI pick up a new version automatically on the next fetch, while applications pinned to a specific version ID require a redeploy or config change to move. Anything in the PCI-DSS cardholder data environment (CDE, the network segment that stores, processes, or transmits cardholder data) that might need emergency rotation should default to versionless references specifically so an emergency does not turn into an outage.

For any manual, cleartext key-management step, which in practice comes up specifically during a Managed HSM security-domain download or restore (the encrypted backup artifact that lets you recover the HSM in a disaster), PCI-DSS 3.7.6's split-knowledge and dual-control requirement maps directly onto Managed HSM's own quorum design: the security domain is protected using Shamir's Secret Sharing among a minimum of 3, and up to 10, customer-held RSA key pairs, so no single custodian can reconstruct it alone. Use that native feature as your compliance control rather than inventing a separate manual process, since it is the same requirement Managed HSM was built to satisfy.

Versioning, revocation, and rollback

Both Key Vault and Managed HSM keep an automatic, immutable version history for every key and secret; this is what "rollback" actually means in this context, since you cannot literally restore a value, only re-point consumers at, or re-enable, a prior version. Design the emergency-rotation runbook to include the rollback path explicitly: if a new key version breaks a downstream integration, the fastest safe recovery is re-enabling the previous version, not disabling the vault or the application.

Access revocation is a role-assignment change, not a secret change, whenever possible: prefer Managed Identities (an Entra ID, Microsoft's cloud identity and access management service formerly called Azure AD, identity tied to an Azure resource itself, with no long-lived credential for an application to hold or leak) over service principals with client secrets for anything talking to the vault, because there is then no long-lived secret to rotate or revoke on the application side at all, only a role assignment to remove.

Role separation in practice: a small, break-glass-only Key Vault or HSM Administrator role that manages the vault and its access policy, a Crypto Officer role that can create and rotate keys, and a Crypto User role, assigned to applications via managed identity, that can only use keys (encrypt, decrypt, wrap, unwrap) and can never export or manage them. Auditing every operation under these roles through Azure Monitor and a Log Analytics workspace, retained per your PCI-DSS retention requirement, is what turns "we have RBAC" into "we can prove who did what, when" for an assessor.

flowchart TD
    A[Compromise suspected: alert, audit finding, or offboarding] --> B[Disable affected key/secret version]
    B --> C{Manual cleartext operation involved?}
    C -->|Yes, e.g. HSM security domain restore| D[Split-knowledge custodians act under quorum]
    C -->|No| E[Automated rotation policy issues new version]
    D --> F[Re-point consumers via versionless reference or redeploy]
    E --> F
    F --> G[Confirm old version unusable: disabled and RBAC-blocked]
    G --> H[Write audit trail: who, what, when, approval ticket]

Worked example

A retail platform's tokenization key, used to convert primary account numbers into tokens before storage, lives in Managed HSM. An internal audit flags that a departing contractor held Crypto Officer access for three weeks longer than their engagement required. The emergency path: disabling the key itself is not needed, since there is no evidence of use, but the contractor's role assignment is revoked immediately (a role-assignment removal, seconds, no key operation needed). Because the incident review cannot fully rule out access, the key is rotated as a precaution: a new key version is generated, the application, which references the key by its versionless URI, picks up the new version on its next token-generation call with no redeploy, and the previous version is disabled, not deleted, so tokens already generated with it and needing detokenization later still resolve correctly, under the now-revoked contractor's removed access. The audit trail records the role-removal timestamp, the rotation timestamp, and the ticket number, exactly the who, when, what record a PCI-DSS assessor asks for.

Trade-offs & pitfalls

Rotating a KEK is cheap under envelope encryption; rotating a DEK directly is not, because it requires re-encrypting the underlying data. Confusing the two in a rotation policy is the single most common design mistake: teams write "rotate keys every 90 days" without specifying which layer, then discover the policy implies re-encrypting a multi-terabyte cardholder data store every quarter.

Pinning applications to a specific key or secret version for change-control reasons, a legitimate practice for high-risk changes, directly trades away emergency-rotation speed. Decide deliberately, per secret, which property matters more.

Managed HSM's single-tenant isolation and local RBAC are real security wins but come at a real cost and operational premium over shared Key Vault tiers. Reserve it for cardholder-data-scope keys specifically, not as a default for every secret in the environment, or the cost and the quorum-management overhead becomes its own operational burden.

A rollback plan that only covers "re-enable the previous version" is incomplete if the previous version was already disabled for a reason, for instance because it was the thing being rotated away from after a suspected compromise. The runbook needs an explicit rule for when rollback is not the safe choice, not just a default revert action.

Direct answer

Microsoft Entra ID (the current name for what was Azure Active Directory) answers "who are you": it authenticates a user, service principal, or managed identity and issues a token. Azure RBAC (role-based access control) answers "what can you do": it evaluates a role assignment, a security principal plus a role definition plus a scope, against every Azure Resource Manager request after Entra ID has already authenticated it. For a multi-team environment, put dev, staging, and prod in separate subscriptions and grant each team roles scoped only to the subscription their work touches, never at the tenant level by default.

Structured elaboration

Authentication (Entra ID). Covers identity lifecycle (users, groups, app registrations and service principals, managed identities), sign-in security (multi-factor authentication, Conditional Access policies that can require a compliant device or a specific network location before a token is issued), and directory-level roles such as Global Administrator, which manage the directory itself, not Azure resources.

Authorization (Azure RBAC). A role assignment binds a security principal, always sourced from Entra ID, to a role definition (a list of allowed actions, such as Microsoft.Compute/virtualMachines/start/action) at a scope: management group, subscription, resource group, or a single resource. RBAC is additive: a principal's effective permissions are the union of every assignment applying at or above its own scope, so a broad assignment at a management group is inherited by everything beneath it. That inheritance is exactly why scope discipline is the design problem, not the role names themselves.

Design for dev, staging, and prod. Put each environment in its own subscription, not just a resource group, since a subscription is the strongest RBAC, cost-reporting, and Azure Policy isolation boundary Azure offers, then group the three under a shared management group so tenant-wide guardrails apply consistently. Assign the built-in Contributor role to the engineering team at the dev subscription; a narrower custom role (deploy without delete) at staging; and, at prod, no standing human access beyond Reader, with real changes flowing only through a pipeline's service principal holding the minimum RBAC it needs. Use Entra ID groups, never individual users, as the RBAC principal, so onboarding and offboarding become a group-membership change instead of a per-subscription audit.

Separation of duties, concretely. The person who approves a pipeline's production deployment stage should not also hold standing Contributor on the prod subscription. The person who manages Entra ID directory roles, who could in principle grant themselves any Azure RBAC role by first granting themselves ownership, is a distinct, separately audited function from day-to-day Azure administration.

Worked example

A team of 8 engineers and 2 leads works across dev, staging, and prod subscriptions under one management group. Dev: the "eng-dev" Entra ID group gets Contributor at the dev subscription, so all 8 engineers create and delete resources freely. Staging: the same group gets a custom role granting most write actions but no delete actions, so promotion happens but destructive mistakes are harder to make by accident. Prod: no standing human access at all; only the CI/CD pipeline's service principal holds Contributor scoped to prod, and the 2 leads hold Reader plus eligibility for a time-boxed, approval-gated Owner role activation (Privileged Identity Management) for genuine emergencies. This gives a clean, mechanical answer to "who could have made this prod change on this date": either the pipeline's identity, which is logged and code-reviewed, or a specific, timestamped emergency activation.

Trade-offs and pitfalls

Putting all three environments in one subscription and trying to enforce the boundary with resource groups and RBAC alone works at small scale, but subscription-level quotas, cost reporting, and the blast radius of a single subscription-wide network or policy mistake all leak across environments anyway. Assigning roles to individual users instead of groups creates an offboarding gap: a departed employee's access lingers until someone remembers to remove it, because it is not visible in one place. Confusing Owner, which includes the ability to grant others any role, with Contributor, which cannot manage access at all, is a common mistake when writing a role for someone who should deploy but never re-permission the environment.

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.

Direct answer

The query below finds the top 5 resources by Error-level log count in the AzureDiagnostics table over the last 24 hours, with each resource's count and its percentage of the total error volume in that window. Grouping is done by the _ResourceId column (the resource's full ARM ID), which is the column that actually uniquely identifies a specific resource in this table; the more commonly guessed ResourceId is not the real column name.

Structured elaboration: approach and query

let window = 24h;
let errors = AzureDiagnostics
    | where TimeGenerated >= ago(window)
    | where Level == "Error";
let totalErrors = toscalar(errors | count);
errors
| summarize ErrorCount = count() by _ResourceId
| top 5 by ErrorCount desc
| extend PercentOfTotal = round(100.0 * ErrorCount / totalErrors, 2)
| project _ResourceId, ErrorCount, PercentOfTotal

Key points. The query computes totalErrors once with toscalar() over the whole 24-hour error set before grouping, so the percentage column is a true share of all errors in the window, not a share of just the top 5's combined count (a subtle but common mistake: computing the denominator only from the already-filtered top-5 rows instead of the full population). Level == "Error" is the correct filter for AzureDiagnostics because AzureDiagnostics is a shared table across many resource types that use "Azure Diagnostics mode" (Key Vault, Application Gateway, Azure Firewall, and others among them) and Level is one of the common columns present across that shared schema.

Edge cases. Not every resource that logs to AzureDiagnostics populates Level consistently; some resource types express severity differently (for example through a ResultType or a resource-specific status column instead), so this query only sees error volume for resource types that do populate Level, and a resource type that logs errors under a different column would silently show zero here rather than erroring out, which is worth checking with a quick AzureDiagnostics | where isnotempty(Level) | distinct ResourceType before relying on this query for a resource type you have not already confirmed uses Level. Also note that many Azure resource types have since moved to "resource-specific" diagnostic log tables instead of the shared AzureDiagnostics table (Microsoft's newer, recommended collection mode); a resource on resource-specific mode will not appear in AzureDiagnostics at all, so this query is scoped to whichever resources are still configured for Azure Diagnostics mode.

Worked example: converting this into an alert rule

1. Create a scheduled query rule (Microsoft.Insights/scheduledQueryRules) using this query (or a variant without the top 5, since an alert usually should not silently cap itself to 5 resources and miss a 6th one also spiking).
2. Set the evaluation frequency and lookback window much shorter than 24 hours for an alert (e.g. evaluate every 15 minutes over a 15-minute window), since a 24-hour rolling window is good for a daily report but far too slow to catch an emerging problem for paging purposes; keep the 24-hour version as a scheduled report/Workbook, not the live alert.
3. Configure the rule with "split by dimension" on _ResourceId so one rule definition fires a separate alert instance per resource that crosses the threshold, rather than one alert for "some resource somewhere is over threshold" that then requires a human to go re-run the query to find out which one.
4. Set the threshold as a count comparison, for example "number of rows with ErrorCount greater than a defined threshold, per resource, is greater than 0," and route the resulting alert to an action group scoped by resource type or owning team so the right people get paged.
5. Add a suppression window or a slightly higher threshold for any resource type known to log a noisy-but-harmless error pattern periodically, to avoid the alert becoming background noise the team starts ignoring.

Trade-offs and pitfalls

Because AzureDiagnostics is a shared, wide table across many resource types, a naive count() grouped only by _ResourceId conflates very different kinds of "errors" (a Key Vault access-denied event and an Application Gateway backend-health error look completely different in severity) into one ranked list; for anything beyond a first-pass triage view, also group by ResourceType or Category so the top-5 list distinguishes "many low-severity Key Vault throttling events" from "a handful of serious Application Gateway backend failures" rather than ranking them purely by raw count.

Direct answer

For a stateless web app on a Virtual Machine Scale Set (VMSS), pair metric-based autoscaling, since there is no stated daily pattern to schedule around here, with the Rolling upgrade policy so new instances or new image versions roll out in controlled batches, gated between batches by a health check, back it with Application Gateway or a Standard Load Balancer using an application-level health probe, and protect in-flight instances from being torn down mid-upgrade or mid-scale-in with instance protection. A stateless app's main resilience risk during change is not losing state, it is serving a broken or half-initialized instance to real users.

Structured elaboration

flowchart TD
    Deploy[New model version applied] --> Batch[Upgrade one batch of instances]
    Batch --> Probe[Health probe check]
    Probe -->|healthy| Next[Move to next batch]
    Probe -->|unhealthy| Repair[Automatic instance repair, batch paused]
    Next --> Complete[All instances on new model]

Autoscale triggers. CPU and, or request-count-per-instance metric rules for scale-out and scale-in, with the scale-out threshold set lower and faster-reacting than the scale-in threshold. This asymmetry is itself a defense against oscillation: if both thresholds sit close together, normal load variance can cross both in quick succession and trigger a scale-out immediately followed by a scale-in.

Health probes and probe-timing. Configure the probe interval and unhealthy-threshold count so a single slow response, a garbage-collection pause or a momentary downstream blip, does not immediately mark a healthy instance as failed and pull it from rotation. This is a second, distinct oscillation risk from the autoscaling-threshold one, this time at the load-balancer level: a probe interval of 15 to 30 seconds combined with requiring 2 to 3 consecutive failures before marking an instance unhealthy, rather than one, absorbs transient blips without meaningfully slowing real failure detection, since a genuinely broken instance keeps failing every subsequent probe too.

Upgrade policy choice. Manual gives full control at the cost of operational overhead, since you explicitly trigger and control every instance's upgrade. Automatic applies updates to all instances with no batching or health gating, fastest but riskiest, since a bad image version can hit the whole fleet near-simultaneously. Rolling upgrades a configurable batch of instances at a time, waits for the health probe to report each batch healthy before proceeding, and can pause or roll back automatically if a batch fails its health check. Rolling is the right default for a production stateless web app specifically because it bounds the blast radius of a bad deployment to one batch instead of the whole fleet, while remaining largely automated.

Instance protection. Two distinct protections serve two distinct purposes: "protect from scale-in" stops the autoscaler from removing a specific instance, useful for one mid-upgrade or temporarily pinned for debugging; "protect from scale-set actions" stops both scale-in and upgrade or reimage operations from touching an instance. Apply scale-in protection automatically to any instance currently draining requests during a scale-in event so in-flight requests complete instead of being cut off, which for a genuinely stateless app matters less for data loss, there is no server-side state to lose, but still matters for not returning a connection-reset error to a real user mid-request.

Custom image or extension management. Bake the application into a custom VM image, via Azure Image Builder or an equivalent pipeline, rather than installing it via an extension or startup script on every boot. A custom image makes boot-to-ready time faster and deterministic, with no dependency-download step that can fail or vary at boot time, and makes "what code is running" a property of the image version, exactly what the Rolling upgrade policy operates on. Version the image, a new version per release, so a rollback is redeploying the previous version, a well-understood, tested operation, rather than reverse-engineering what changed.

Integration with Application Gateway or Load Balancer, including session affinity and cache warming. Since the app is stateless, avoid enabling session affinity, cookie-based sticky sessions, unless there is a specific reason for it, since affinity works against even load distribution and reintroduces a soft dependency on a specific backend instance that a stateless design is trying to avoid. Where cache warming does matter is the health-probe path: if the app loads an in-memory cache on startup, a local performance optimization that does not make it stateful in the durability sense, the health probe must not report healthy until that warm-up completes, otherwise the load balancer routes real traffic to an instance that serves slow, cold-cache responses for its first several seconds or minutes in rotation, the same class of problem as scheduled-scaling probe timing, applied here to every new instance rather than only to a scheduled spike.

Worked example

A new image version, v42, is ready to roll out to a 20-instance scale set with a Rolling upgrade policy configured for a maximum batch of 4 instances (20 percent) and an unhealthy-instance tolerance of 20 percent per batch. The rollout drains batch 1, 4 instances, applies the new image, waits for the health probe (checking a /healthz endpoint that itself verifies cache warm-up completed, not just that the process is listening) to report all 4 healthy, then proceeds to batch 2. If batch 3 comes back with 2 of 4 instances failing health checks, 50 percent of that batch, exceeding the 20 percent threshold, the Rolling upgrade automatically stops and does not proceed to batches 4 and 5, leaving 12 instances on v42 and 8 still on the previous version while the team investigates, rather than continuing to roll a broken image out to the entire fleet.

Trade-offs and pitfalls

Choosing Automatic upgrade policy for convenience on a production fleet removes exactly the batch-gating and automatic-pause-on-failure behavior that makes Rolling safe. A health probe that only checks whether the process is running, rather than whether the instance has finished its own startup work, silently reintroduces the cold-instance-serving-real-traffic problem that both the health-probe design and the Rolling upgrade's batch-health-gating are meant to prevent. And enabling session affinity by habit on a genuinely stateless app does not cause an outright bug, but it does concentrate load unevenly and makes a future rolling deployment's "which instances still have old traffic pinned to them" question harder to reason about than it needs to be.