← Back to all questions
StaffIdentitySecurity
Design Enterprise Identity & Access Management
A full Staff-level walkthrough of an Entra-style enterprise identity platform — the trust root for 700M+ identities across 50M tenants — issuing OAuth/OIDC/SAML tokens at up to 500K auth/sec while staying fail-closed at five-nines. It trades global replication latency against tenant isolation, with conditional access, continuous access evaluation, and ML risk scoring sitting in the authentication hot path. Follow it top to bottom, or jump to any step.
100% free · No login required
WHAT THIS QUESTION TESTS
·Fail-closed by default — an auth outage is a security event, not just downtime
·Cryptographic tenant isolation so one tenant's breach can't leak to another
·Event-driven token revocation (CAE) shrinks exposure from ~60 min to ~1 min
·Client-side JWT validation via cached JWKS keeps validation off the central path
★ STAFF-LEVEL SIGNALS
★Hybrid partitioning: dedicated shards for large tenants, hashed colocation for small ones
★Explains why compute dominates the bill and how local validation cuts it ~10x
★Compiles overlapping conditional-access policies into a decision tree for O(log n) eval
★TPM-bound Primary Refresh Token as the device-anchored root of single sign-on
0
Scope & ambiguity
Enterprise IAM is the foundation of Microsoft’s entire cloud security posture. If Entra ID authentication is down, ALL of Azure, M365, Dynamics, and every third-party app integrated via OAuth/SAML is down. This is not a feature service — it is the trust root for 700M+ identities.
3-Phase Delivery:
Phase
Timeline
Scope
P1
0-4 mo
Core directory + OAuth 2.0/OIDC endpoints, basic conditional access (user/group/location), password hash sync via Azure AD Connect
P2
4-10 mo
Advanced conditional access (risk-based, device compliance), passwordless auth (FIDO2/Windows Hello), Continuous Access Evaluation (CAE)
P3
10-18 mo
Verified ID (decentralized identity via DID), AI-powered Identity Protection (behavioral ML), cross-cloud federation (Azure+AWS+GCP)
Team Ownership:
Team
Scope
Size
Directory Service
Partition store, tenant isolation, global replication
~40 eng
Auth Platform
OAuth/OIDC/SAML token issuance, JWKS rotation
~35 eng
Conditional Access
Policy engine, risk evaluation, session controls
~25 eng
Hybrid Identity
Azure AD Connect, PHS/PTA/federation, cloud sync
~20 eng
Identity Protection
ML risk scoring, compromised credential detection
~15 eng
Governance
Access reviews, entitlement management, lifecycle
~15 eng
Key Ambiguity: 700M identities — what ratio is human vs service principal? In practice, service principals and managed identities account for ~60% of auth volume (workload identity). Service-to-service auth is 10x the volume of interactive auth with fundamentally different patterns (no MFA, shorter token lifetimes, certificate-based credentials). This shapes the entire system design.
1
Requirements
Functional Requirements
ID
Requirement
Detail
FR1
Auth protocols
OAuth 2.0 (authorization code, client credentials, device code, ROPC), OIDC, SAML 2.0, WS-Fed
FR2
Conditional access
Policy engine: IF (user+device+location+risk+app) THEN (allow/block/MFA/compliant device)
FR3
Hybrid sync
Azure AD Connect: password hash sync, pass-through auth, federation (AD FS)
FR4
CAE token revocation
Event-driven revocation (user disabled, password change, location change) within 1-2 min
FR5
Tenant isolation
Cryptographic isolation — one tenant's compromise must NEVER leak to another
FR6
Passwordless
FIDO2 security keys, Windows Hello for Business, Microsoft Authenticator phone sign-in
FR7
B2B cross-tenant
Guest users, cross-tenant access settings, external collaboration with policy controls
Non-Functional Requirements
Metric
Target
Rationale
Auth latency p50
<100ms
Interactive login must feel instant
Auth latency p99
<500ms
Tail latency budget for CA evaluation + risk scoring
Token validation p99
<10ms
Client-side JWKS cache, no network call for validation
Availability
99.999%
5.26 min downtime/year — auth outage = total cloud outage
Throughput
30B+ auth/day
350K sustained, 500K peak auth/sec globally
Tenant isolation
Cryptographic
Partition-level encryption keys, no cross-tenant data leakage
Compliance
FedRAMP High, GDPR, SOC2, HIPAA
Sovereign clouds: GCC, GCC High, DoD, China (21Vianet)
Organizational Context: Entra ID is the most critical Azure service. Every M365 workload (Teams, Exchange, SharePoint, OneDrive) depends on it for auth. It must operate across sovereign deployments: commercial, US GCC, US GCC High, US DoD (IL5), and China 21Vianet — each with separate data boundaries and compliance regimes.
2
Back-of-envelope estimation
Scale Numbers
Dimension
Value
Derivation
Total identities
700M+
Users + service principals + managed identities across 50M tenants
Tenants
50M
From startups (1 user) to enterprises (500K+ users)
Auth events/day
30B
~350K/sec sustained, peaks to 500K/sec (9am Monday, US+EU)
Token validations/sec
5M
Most apps validate JWTs locally; Graph API alone does ~2M/sec
Conditional access evaluations
15B/day
Multiple policies evaluated per auth event
Storage Breakdown
Data
Size
Retention
Storage
Directory (identities, groups, roles)
~3.5 TB
Permanent
Custom partitioned store
Group memberships (nested graph)
~700 GB
Permanent
Graph-optimized store
Auth logs
~15 TB/day → 1.35 PB/90d
90 days (default)
Azure Data Explorer/Kusto
CA policies
~2 TB
Permanent
Cosmos DB
Active sessions / refresh tokens
~500 GB
Session lifetime
Distributed cache (Redis-like)
Signing keys (RSA 2048+)
<1 GB
Rotated every 6 weeks
Key Vault + HSM
Monthly Cost Estimate
Component
Cost
Notes
Directory storage + replication
~$2M
3.5TB x 30+ regions x 3 replicas
Compute (auth processing)
~$8M
500K QPS peak across global fleet
Global replication (bandwidth)
~$3M
Cross-region sync for directory + tokens
ML inference (Identity Protection)
~$1M
Risk scoring on every auth event
Audit log ingestion + storage
~$500K
Kusto cluster for 1.35PB/90d
HSM infrastructure
~$500K
FIPS 140-2 Level 3 for signing keys
Total
~$15M/month
Compute-dominant
Key Insight: Compute is the dominant cost because every auth event requires policy evaluation, risk scoring, and token issuance. However, client-side JWT validation (JWKS cached locally) eliminates 90%+ of what would otherwise be central token validation load. Without this, the system would need 10x compute.
3
API design
OAuth 2.0 / OIDC Endpoints (Public)
GET /common/oauth2/v2.0/authorize # Authorization code flow entry
POST /common/oauth2/v2.0/token # Token issuance (code→tokens)
GET /common/v2.0/.well-known/openid-configuration # OIDC discovery
GET /common/discovery/v2.0/keys # JWKS (public signing keys)
POST /common/oauth2/v2.0/devicecode # Device code flow initiation
POST /common/oauth2/v2.0/logout # Session termination
Microsoft Graph API (REST, per-tenant)
GET /v1.0/users/{id} # Read user profile
PATCH /v1.0/users/{id} # Update user attributes
GET /v1.0/groups/{id}/members # List group members (paginated, max 999)
GET /v1.0/identity/conditionalAccess/policies # List CA policies
POST /v1.0/identity/conditionalAccess/policies # Create CA policy
GET /v1.0/auditLogs/signIns # Auth audit logs (Kusto-backed)
GET /v1.0/identityProtection/riskyUsers # Risk-scored users (ML-backed)
Internal gRPC Services
service TokenService {
// Issues OAuth tokens. Hot path — p99 <200ms, 99.999% availability.
rpc IssueToken(TokenRequest) returns (TokenResponse);
// Validates refresh tokens against session store.
rpc ValidateRefreshToken(RefreshTokenRequest) returns (ValidationResponse);
// CAE: event-driven token revocation.
rpc RevokeTokensForUser(RevocationRequest) returns (RevocationResponse);
}
service PolicyEngine {
// Evaluates conditional access policies. In the auth hot path — p99 <50ms.
rpc EvaluateAccess(PolicyEvaluationRequest) returns (PolicyDecision);
// Bulk policy compilation (offline, for cache warming).
rpc CompilePolicies(TenantPoliciesRequest) returns (CompiledPolicySet);
}
service DirectoryService {
// Reads user/group from partitioned store. p99 <30ms (cache hit), <150ms (miss).
rpc LookupIdentity(IdentityLookupRequest) returns (IdentityRecord);
// Group membership graph traversal (nested groups).
rpc ResolveGroupMembership(GroupRequest) returns (MembershipGraph);
}
4
Data model
Storage Choice Table
Data
Store
Rationale
Alternative Considered
Directory (users, groups, SPs)
Custom partitioned store
Tenant-partitioned, globally replicated, strong consistency on writes, eventual on reads; nothing off-shelf meets scale + isolation requirements
Cosmos DB — rejected: 700M identities with complex graph queries (nested groups) need custom indexing
CA policies
Cosmos DB (strong consistency)
Low volume (~2TB), strong consistency required (policy changes must take effect immediately), multi-region replication built-in
Custom store — rejected: overkill for low-volume config data
Auth logs
Azure Data Explorer (Kusto)
Time-series optimized, fast analytics (KQL), handles 15TB/day ingestion, 90-day hot retention
Azure Blob + Spark — rejected: query latency too high for real-time investigation
Active sessions / refresh tokens
Distributed cache (Redis-like)
Sub-ms reads, 500GB fits in memory, TTL-based expiration matches token lifetimes
Cosmos DB — rejected: latency too high for session lookups in auth hot path
Signing keys (RSA/ECDSA)
Key Vault + HSM (FIPS 140-2 L3)
Hardware-backed key protection, automatic rotation, audit trail; keys never leave HSM boundary
Software keys — rejected: compliance requirement for FIPS 140-2 Level 3
Core Schemas
// Directory partition (one per tenant shard)
TenantPartition {
tenant_id: UUID (partition key)
encryption_key: reference → Key Vault
primary_region: string
replica_regions: [string] // 3+ regions
}
// Identity record (polymorphic: user, group, SP, managed identity)
Identity {
tenant_id: UUID (partition key)
object_id: UUID (sort key)
type: enum(User, Group, ServicePrincipal, ManagedIdentity)
display_name: string
upn: string (users only)
credentials: EncryptedBlob (password hash / cert thumbprint)
mfa_methods: [MFAMethod]
risk_level: enum(None, Low, Medium, High)
created_at: timestamp
last_sign_in: timestamp
}
// Conditional Access Policy
CAPolicy {
tenant_id: UUID
policy_id: UUID
state: enum(Enabled, Disabled, ReportOnly)
conditions: { users, groups, apps, platforms, locations, risk_levels }
grant_controls: { require_mfa, require_compliant_device, block, ... }
session_controls: { sign_in_frequency, persistent_browser, ca_enforcement }
priority: int
}
5
High-level architecture
┌─────────────┐
│ Client │ (Browser / Mobile / Service Principal)
└──────┬──────┘
│ HTTPS (TLS 1.3)
▼
┌──────────────────┐
│ Azure Front Door │ (Global L7 LB, DDoS protection, WAF)
│ + Traffic Mgr │ (Geo-routing to nearest region)
└──────┬───────────┘
▼
┌──────────────────┐ ┌─────────────────────┐
│ Auth Gateway │────▶│ Conditional Access │
│ (Protocol layer) │ │ Engine (p99 <50ms) │
│ OAuth/OIDC/SAML │ └──────────┬──────────┘
└──────┬───────────┘ │
│ ▼
▼ ┌─────────────────────┐
┌──────────────────┐ │ Identity Protection │
│ Token Service │ │ (ML risk scoring) │
│ (p99 <200ms) │ └─────────────────────┘
│ Issue / Revoke │
└──────┬───────────┘
│
▼
┌──────────────────┐ ┌─────────────────────┐
│ Directory Store │ │ Hybrid Identity │
│ (Partitioned, │ │ (Azure AD Connect) │
│ 3+ replicas) │ │ PHS / PTA / Fed │
└──────────────────┘ └─────────────────────┘
│
▼
┌──────────────────┐ ┌─────────────────────┐
│ Session Store │ │ Audit Logs (Kusto) │
│ (Redis-like) │ │ 15TB/day ingestion │
└──────────────────┘ └─────────────────────┘
Service-to-Team Mapping
Service
Team
SLA
On-Call
Auth Gateway
Auth Platform
99.999%
24/7 follow-the-sun
Token Service
Auth Platform
99.999%
24/7, page within 1 min
Conditional Access Engine
Conditional Access
99.999%
24/7, p99 <50ms alert
Directory Store
Directory Service
99.999%
24/7, partition-level monitoring
Identity Protection ML
Identity Protection
99.99%
Business hours + on-call
Azure AD Connect
Hybrid Identity
99.99%
Business hours + on-call
Audit Logs (Kusto)
Governance
99.9%
Best-effort (non-blocking)
Failure Domain Analysis
CRITICAL INSIGHT: Auth services must fail-CLOSED (deny by default), not fail-open. A fail-open auth system is a security breach. This is the opposite of most availability-focused services.
Failure Domain
Blast Radius
Mitigation
Recovery
FD1: Auth Gateway down
New logins blocked region-wide
Existing tokens still work (validated locally via JWKS), multi-region failover via Front Door <30s
Auto-failover, no data loss
FD2: Directory partition failure
Only affected tenant(s) impacted
3+ replicas with automatic leader election, other tenants unaffected
Replica promotion <10s
FD3: CA Engine failure
Fail-CLOSED — deny by default
Cached compiled policies as fallback (stale-but-safe), degrade to block+alert rather than allow
Cache TTL 5 min, alert + manual override
FD4: Identity Protection ML
Risk scores unavailable
Fall back to rule-based risk (IP reputation, impossible travel heuristics), CA policies still enforce
ML model redeployment <15 min
6
Deep dives
WHERE STAFF IS WONPartition Strategy Comparison
Strategy
Description
Pros
Cons
Verdict
Per-tenant partition
Each tenant's data on a dedicated partition shard
Perfect isolation, simple compliance (delete tenant = delete partition), per-tenant encryption keys
Small tenants waste resources, 50M partitions is a lot to manage
Selected for large tenants (>1K identities)
Hash-based partition
Consistent hash ring across all identities
Even load distribution, simple routing
Cross-tenant data on same shard (isolation concern), tenant deletion is scatter-gather
Used for small tenants (colocated, <1K identities)
Geographic partition
Data stays in tenant's declared region
Simplifies data residency (GDPR, sovereignty)
Cross-region queries for B2B collaboration, replication complexity
Used as overlay — primary region pinning with read replicas
Hybrid approach: Large tenants get dedicated partitions (isolation + compliance). Small tenants are hash-distributed across shared partitions with logical isolation (encryption-key-per-tenant). Geographic pinning as overlay for sovereign requirements.
Directory Service at Global Scale
Azure AD/Entra ID manages 700M+ identities globally:
- Users, groups, service principals, managed identities
- Multi-tenant: each organization is an isolated tenant
- Global replication: directory replicated across 30+ regions
Partition model:
- Each tenant's directory on a specific partition
- Partition replicated across 3+ regions
- Write to primary partition → async replicate to secondaries
- Read from nearest replica (eventually consistent)
- Strong consistency for authentication (read from primary)
Authentication Protocols
Supported protocols:
1. OAuth 2.0 / OIDC: modern apps (SPA, mobile, API)
- Authorization code flow (web apps)
- Device code flow (smart TVs, CLI tools)
- Client credentials flow (service-to-service)
2. SAML 2.0: legacy enterprise SSO
- Still used by thousands of enterprise apps
- Federated with on-premises AD FS
3. WS-Federation: Windows-specific (legacy)
Token lifecycle:
- Access token: 1 hour lifetime, used for API access
- Refresh token: 24 hours-90 days, used to get new access tokens
- ID token: contains user claims, used for sign-in
- Continuous Access Evaluation (CAE): revoke tokens in real-time
(e.g., user leaves company → tokens revoked within minutes, not waiting for expiry)
Continuous Access Evaluation (CAE) — Deep Dive
Traditional token model: access tokens are valid until expiry (1 hour). If a user is disabled at minute 1, they retain access for 59 minutes. This is unacceptable for enterprise security.
CAE replaces polling-based revocation with event-driven revocation:
CAE Event Flow:
1. Critical event occurs (user disabled, password changed, high-risk detected)
2. Entra ID publishes event to CAE Event Bus (< 30 sec)
3. Resource providers (Exchange, SharePoint, Teams) subscribe to events
4. On next API call, resource provider checks:
- Is token in revocation list? → Reject, force re-auth
- Has client IP changed? → Challenge with claims request
5. Client receives 401 with "claims" challenge → redirects to /authorize
Latency comparison:
Traditional: Token expiry-based → up to 60 min exposure
CAE: Event-driven → 1-2 min exposure
CAE + IP: Network-change detect → immediate on next request
Critical events that trigger CAE:
- User account disabled/deleted
- Password changed/reset
- MFA re-registration
- Admin explicitly revokes tokens
- User risk level elevated to High (Identity Protection)
- Device falls out of compliance (Intune)
# Pseudocode: CAE evaluation in resource provider
def validate_access_token(token, request_context):
# Standard JWT validation (local, <1ms)
claims = verify_jwt_signature(token, jwks_cache)
if claims is None:
return DENY
# CAE: check if token has been revoked (event-driven)
if cae_revocation_cache.contains(claims.oid, claims.tid):
return CHALLENGE_REAUTHENTICATE
# CAE: IP-based enforcement (network change detection)
if claims.ipaddr != request_context.client_ip:
if not is_trusted_network(request_context.client_ip, claims.tid):
return CHALLENGE_WITH_CLAIMS # 401 + claims challenge
# CAE: check real-time policy (if within evaluation window)
if token_age(claims) > CAE_EVALUATION_WINDOW: # typically 1 hour
return CHALLENGE_REAUTHENTICATE
return ALLOW
Conditional Access
Policy engine that decides whether to allow/block/challenge authentication:
Policy: IF (condition) THEN (action)
Conditions:
- User/group membership
- Application being accessed
- Device platform (Windows, iOS, Android)
- Location (IP range, country)
- Risk level (sign-in risk, user risk from Identity Protection)
- Device compliance (managed, encrypted, up-to-date)
Actions:
- Allow (grant access)
- Block (deny access)
- Require MFA
- Require compliant device
- Require password change
- Require terms of use acceptance
Example policies:
"Require MFA for all users accessing Exchange Online from outside corporate network"
"Block access from countries we don't operate in"
"Require compliant device for accessing SharePoint from mobile"
Hybrid Identity (On-Premises AD + Cloud)
Most enterprises have existing on-premises Active Directory:
Sync options:
1. Azure AD Connect: sync users/groups from on-prem AD to Azure AD
- Password Hash Sync: hash of password synced to cloud (most common)
- Pass-through Authentication: auth request forwarded to on-prem (password stays on-prem)
- Federation (AD FS): on-prem identity provider handles auth
2. Cloud-only: no on-prem AD (new organizations, born-in-cloud)
Migration path: most enterprises start hybrid → gradually move to cloud-only
Phase 1: Azure AD Connect with PHS (simplest)
Phase 2: Enable Conditional Access in cloud
Phase 3: Migrate apps from ADFS to Azure AD
Phase 4: Eventually decommission on-prem AD (years out for most)
Zero Trust Token Architecture — Primary Refresh Token (PRT)
The Primary Refresh Token (PRT) is the foundation of SSO across all Microsoft services on a device. It bridges device identity with user identity.
PRT Lifecycle:
1. User signs in on Windows (Hello PIN / password + MFA)
2. Cloud AP plugin authenticates with Entra ID
3. Entra ID issues PRT (bound to device via TPM)
- Contains: user claims, device claims, MFA claim, session key
- Session key encrypted to device's TPM → PRT unusable on other devices
4. PRT stored in LSASS, protected by TPM-bound session key
5. On each app access:
- Browser plugin / WAM broker presents PRT + proof-of-possession
- Entra ID validates PRT → issues app-specific access token
- No additional login prompt (SSO)
Security properties:
- Device-bound: PRT session key sealed to TPM, cannot be exfiltrated
- MFA claim embedded: apps get MFA satisfaction without re-prompting
- Rotated on use: each token refresh rotates the session key
- Revocable: admin disables user → PRT invalid on next use (CAE)
SSO flow across Microsoft services:
Device (PRT) → Edge/Chrome (WAM broker) → Entra ID → Access token for:
├── Exchange Online (Outlook)
├── SharePoint / OneDrive
├── Teams
├── Azure Portal / CLI
└── Third-party OIDC apps (Salesforce, ServiceNow, etc.)
7-8
Bottlenecks & evolution
Bottleneck Analysis
Bottleneck
Impact
Mitigation
Residual Risk
Auth latency at 500K QPS
p99 breaches 500ms budget during Monday 9am peaks (US+EU overlap)
Regional overprovisioning (2x headroom), pre-computed CA policy cache, connection pooling to directory
Flash crowds from major incident (e.g., Teams outage → mass re-auth) can 3x normal peak
Global replication lag
Directory writes in US-West visible in EU-West after 50-200ms
Strong consistency for auth reads (always hit primary), eventual consistency acceptable for profile reads
Split-brain during network partition → fail-closed (deny auth until partition heals)
CA policy complexity explosion
Large tenants accumulate 100+ overlapping policies, evaluation time grows O(n)
Offline policy compilation into decision tree (O(log n) evaluation), cache compiled policies per tenant
Policy conflicts produce surprising deny results → need simulation/what-if tooling
Hybrid sync conflicts
Password changed on-prem and cloud simultaneously, group membership divergence
Last-writer-wins with conflict log, Azure AD Connect handles conflict resolution with configurable precedence
Sync lag up to 30 min (default cycle) can confuse users — cloud sync reduces to 2 min
Observability
Key Metrics (all emitted per-tenant and globally):
Auth:
- auth_latency_p50, auth_latency_p99 (target: <100ms, <500ms)
- auth_success_rate (target: >99.9%)
- auth_events_per_second (capacity planning)
- token_issuance_rate (correlates with compute cost)
Token Validation:
- jwks_cache_hit_rate (target: >99.5%, miss = network call)
- cae_revocation_events_per_min (security posture indicator)
- token_validation_latency_p99 (target: <10ms client-side)
Conditional Access:
- ca_evaluation_latency_p99 (target: <50ms)
- ca_policy_deny_rate (security vs friction balance)
- ca_cache_staleness_seconds (freshness of compiled policies)
Hybrid Sync:
- sync_cycle_duration (target: <30 min for Connect, <2 min for cloud sync)
- sync_error_count (object-level sync failures)
- password_hash_sync_lag_seconds (critical for PHS users)
Identity Protection:
- risky_sign_in_detection_rate (ML model efficacy)
- false_positive_rate (target: <5% at medium risk threshold)
- risk_remediation_time_median (user self-service vs admin action)
Alerting tiers: P0 (page immediately): auth success rate <99.5% globally or <95% per-region, auth p99 >1s. P1 (page within 15 min): CA engine latency p99 >100ms, sync lag >1 hour. P2 (next business day): Identity Protection false positive rate >10%, audit log ingestion delay >15 min.
Evolution Roadmap
Timeline
Capabilities
Key Decisions
Year 1
Core directory + auth (OAuth/OIDC/SAML), Conditional Access (user/group/location/device), hybrid sync (Azure AD Connect with PHS), basic Identity Protection (leaked credential detection)
Partition model (per-tenant vs hash), fail-closed vs fail-open policy, JWKS rotation cadence
Year 2
Passwordless (FIDO2, Windows Hello for Business, Authenticator phone sign-in), Verified ID (decentralized identity via W3C DID standard), Identity Governance (access reviews, entitlement management, lifecycle workflows), CAE GA across all M365 workloads
Passkey vs FIDO2 strategy, DID blockchain choice (ION on Bitcoin), governance automation level
Year 3
AI-powered Identity Protection (behavioral ML: impossible travel, anomalous token usage, session anomaly), cross-cloud federation (Azure + AWS IAM + GCP IAM unified identity), identity as platform (third-party ISVs build on Entra ID APIs), decentralized identity at scale
ML model serving infrastructure (real-time vs batch), cross-cloud trust model, API versioning for platform ecosystem
★
Rubric — Senior vs Staff
Dimension
Senior signal
Staff signal
Availability posture
Multi-region failover keeps logins available.
Argues fail-closed over fail-open; degrades to cached-deny rather than ever allowing.
Tenant isolation
Separates each tenant's data.
Weighs per-tenant shards vs hashed colocation, per-tenant keys, and geo pinning for sovereignty.
Token revocation
Uses short token lifetimes to limit exposure.
Designs event-driven CAE with IP-change challenges and reasons about the revocation window.
Storage selection
Maps each data type to a suitable store.
Justifies a custom directory store vs Cosmos/Kusto/Redis against scale, consistency, and compliance.
Risk & resilience
Adds risk-based MFA via conditional access.
Falls back from ML risk scoring to rule-based heuristics so auth still enforces when models fail.
★ MORE WALKTHROUGHS
Want more breakdowns like this?
Join free early access for upcoming RAG, LLM eval, agents, and AI infrastructure walkthroughs.