25–30%
1. Design identity, governance & monitoring solutions
Identity & access (Microsoft Entra ID)
- Authentication: choose SSO across apps; use Conditional Access to apply controls (MFA, compliant device, location) based on signals.
- Identity Protection: sign-in risk and user risk policies trigger MFA or password reset only when risk is detected.
- Managed identities (system- or user-assigned) eliminate stored credentials for Azure resource-to-resource auth. Prefer over service principals with secrets.
- B2B for external partners (guests); B2C / External ID for customer-facing apps.
- Hybrid identity: password hash sync (simplest), pass-through auth, or federation (AD FS) for on-premises dependency.
Governance
| Tool | Purpose | Exam cue |
|---|
| Management groups | Apply policy/RBAC across many subscriptions via inheritance | "across all subscriptions" |
| Azure Policy | Enforce/audit resource rules (allowed locations, SKUs, tags). Effects: Deny, Audit, Modify, DeployIfNotExists | "prevent", "enforce", "auto-add tag" |
| RBAC roles | Who can do what. Reader/Contributor/Owner + custom roles | "view only" = Reader; "least privilege" |
| Resource locks | CanNotDelete / ReadOnly to prevent accidental change | "prevent deletion" |
| PIM | Just-in-time, time-bound, approval-gated privileged access | "no standing access", "time-bound", "approval" |
| Blueprints / landing zones | Repeatable environment of policies + RBAC + resources | "consistent, repeatable subscriptions" |
What they test
Distinguish Policy (governs resource properties) from RBAC (governs identities/permissions). "Add a tag automatically" = Policy with Modify. "Grant view access everywhere" = Reader at management-group scope.
Monitoring
- Log Analytics workspace = central KQL store for logs. Azure Monitor Agent (AMA) + data collection rules collect guest OS data at scale.
- Application Insights for app performance/telemetry (APM).
- Diagnostic settings route platform metrics/resource logs to Log Analytics, Storage (archive), or Event Hubs (stream to SIEM).
- Alerts (metric, log, activity log) + action groups for notification/automation.
20–25%
2. Design data storage solutions
Choosing a data store
| Need | Service |
|---|
| Global, low-latency NoSQL, multi-region writes, 99.999% | Azure Cosmos DB |
| Managed relational OLTP, near full SQL Server compatibility (SQL Agent, cross-db) | Azure SQL Managed Instance |
| Managed relational, single DB, minimal admin | Azure SQL Database |
| Open-source relational | Azure Database for PostgreSQL / MySQL |
| Petabyte analytics / data warehouse | Azure Synapse Analytics / Microsoft Fabric |
| Unstructured objects, tiering, lifecycle | Azure Blob Storage |
| SMB/NFS file shares in the cloud | Azure Files (+ Azure File Sync for hybrid) |
| High-performance enterprise NAS | Azure NetApp Files |
| In-memory cache | Azure Cache for Redis |
Storage tiers & lifecycle (Blob)
- Hot (frequent), Cool (≥30 days), Cold (≥90 days), Archive (lowest cost, offline, hours to rehydrate).
- Lifecycle management rules move/delete blobs by age or last-access automatically.
- Immutable storage (WORM) with time-based or legal-hold retention for compliance.
Data protection
| Control | Protects |
|---|
| TDE | Data at rest (files/backups) |
| Always Encrypted | Specific columns — hidden even from DBAs (client-side keys) |
| Dynamic data masking | Obscures values in result sets (not true security boundary) |
| TLS | Data in transit |
| Private Endpoint / Service Endpoint | Restrict data services to your VNet |
What they test
"Minimize administrative overhead" almost always points to PaaS. "Near 100% SQL Server compatibility" = SQL Managed Instance. "Immutable for N years" = blob WORM time-based retention, never a lock or soft delete.
15–20%
3. Design business continuity solutions
Key terms
- RPO (recovery point objective) = max acceptable data loss. RTO (recovery time objective) = max acceptable downtime.
- Lower RPO/RTO ⇒ replication (continuous), not periodic backup.
High availability vs. disaster recovery
| Scope of failure | Design |
|---|
| Hardware / rack / host within a datacenter | Availability set (VMs) |
| Entire datacenter within a region | Availability zones |
| Entire region (disaster) | Multi-region: geo-replication, ASR, paired-region deployment |
Service-specific BCDR
| Workload | HA (in-region) | DR (cross-region) |
|---|
| Azure VMs | Availability zones / sets | Azure Site Recovery (low RPO, recovery plans) |
| Azure SQL Database | Zone-redundant Business Critical | Auto-failover group (active geo-replication) |
| Storage | ZRS | GRS / GZRS / RA-GRS |
| Web apps | Zone-redundant App Service | Two regions + Azure Front Door |
Backup
- Azure Backup (Recovery Services vault) for VMs, files, SQL in VM, etc. Larger RPO than replication.
- Storage redundancy: LRS (1 DC) → ZRS (3 zones) → GRS (paired region) → GZRS (zones + region).
What they test
Map the scope of failure to the right construct. "Survive a datacenter failure" = zones. "Survive a regional outage" = multi-region (Front Door / failover group / ASR). "Minutes of data loss" rules out backup.
30–35%
4. Design infrastructure solutions
Compute selection
| Workload | Service |
|---|
| Event-driven, short-lived, scale-to-zero, pay-per-use | Azure Functions (Consumption) |
| Managed web app/API hosting, minimal ops | Azure App Service |
| Serverless containers, scale-to-zero, no K8s API needed | Azure Container Apps |
| Full Kubernetes control, complex microservices | Azure Kubernetes Service (AKS) |
| Full OS control, lift-and-shift | Azure Virtual Machines / VM Scale Sets |
| Single container, simple/burst job | Azure Container Instances |
Networking
| Need | Service |
|---|
| Global L7 routing, TLS, WAF, path-based, failover | Azure Front Door |
| Regional L7 load balancing + WAF | Application Gateway (with WAF) |
| DNS-based global routing (no L7) | Traffic Manager |
| Regional L4 load balancing, zone-redundant | Azure Load Balancer (Standard) |
| Private, dedicated link to on-premises (no internet) | ExpressRoute |
| Encrypted tunnel over internet to on-premises | VPN Gateway (site-to-site) |
| Central inspection/routing in hub | Azure Firewall / NVA + user-defined routes |
| Private RDP/SSH without public IPs | Azure Bastion |
| Private access to PaaS over backbone | Private Endpoint (Private Link) |
Hub-and-spoke is the canonical enterprise topology: shared services (firewall, gateway, DNS) live in the hub; workloads live in peered spokes; UDRs force traffic through the hub for inspection.
Migration
- Azure Migrate discovers, assesses, and migrates servers, databases, and web apps.
- 5 Rs: Rehost (lift-and-shift to VMs), Refactor (to PaaS), Rearchitect (to containers/microservices), Rebuild, Replace (SaaS).
- Data Box for large offline data transfer; Database Migration Service for DB moves.
What they test
"Global + WAF + L7" = Front Door. "Regional + WAF" = App Gateway. "DNS only" = Traffic Manager. "No public IP for management" = Bastion. "Private, dedicated, no internet" = ExpressRoute. Match keywords precisely.
Exam-day strategy
- Case studies first. They appear in their own section that you cannot return to once you leave it. Read the tabs (Overview, Requirements, etc.) carefully.
- Highlight the constraints. Words like "minimize cost", "minimize administrative effort", "least privilege", and "during a regional outage" decide the answer.
- Eliminate, then choose. Most questions have two clearly wrong options; focus on the trade-off between the remaining two.
- Mark and move on. Don't burn time; flag and revisit via the navigator (non-case sections allow this).
- Never leave blanks — there's no penalty for guessing.