Memory hook: Requirements first; failure and ownership next.
Reviewed 10 October 2026. Read this once, then answer the last-pass checks without looking.
Scope/version: Passing AZ-305 alone does not award the Expert credential: Microsoft also requires Azure Administrator Associate. Confirm current credential prerequisites before booking.
Must remember by domain
| Domain | Rapid revision |
|---|---|
| Identity/governance | Choose authentication separately from authorization. Entra roles, Azure RBAC and service data permissions are distinct. Managed identity removes app-managed credentials; PIM reduces standing privilege; access reviews check continuing need. Management-group/subscription boundaries reflect policy, ownership and billing, not arbitrary organization charts alone. |
| Monitoring | Route platform/resource/application/identity logs to the required analysis, archive or streaming destination. Metrics quantify; logs explain; traces connect. Define retention, owners, action groups and collection health. A central workspace must satisfy residency and access requirements. |
| Relational data | SQL Database suits managed database workloads; Managed Instance suits greater instance compatibility; SQL Server VMs allow OS/engine control. Choose tier by compatibility, latency, IO, scale and licensing. Elastic pools share capacity across suitable databases; read scale does not automatically solve write bottlenecks. |
| Other data/integration | Cosmos DB suits partitioned distributed document access with deliberate consistency; Blob/ADLS suits objects/analytics; Files suits shared-file protocols. Warehouse/lakehouse choices depend on engines and governance. Data Factory orchestrates movement; Spark transforms distributed data; caching needs expiry and invalidation. |
| Continuity | Availability protects from selected failures; backup protects historical states; DR recovers a wider outage. Match RPO/RTO to database-native replication, failover groups, Backup or Site Recovery. Asynchronous geo-replication can lose recent writes. Keys, DNS, identity, capacity and dependencies belong in the recovery plan. |
| Compute/application | VM = guest control; managed app/container platform = less operations; AKS = Kubernetes requirement; Functions = event code; Batch = parallel batch jobs. Service Bus = brokered work; Event Grid = notifications; Event Hubs = high-volume stream; Logic Apps = integrations; API Management = API policy/exposure. |
| Network | VPN and ExpressRoute solve hybrid connectivity differently. Private endpoints need resource/subresource approval and DNS. Load Balancer is L4; Application Gateway regional HTTP; Front Door global HTTP; Traffic Manager DNS routing. Stateful central inspection needs a symmetric return path. |
| Migration/deployment | Inventory dependencies → assess compatibility/capacity/cost → choose rehost/replatform/refactor/replace → rehearse copy and cutover → reconcile data/permissions → validate and retain rollback. Azure Migrate, database migration services and offline data transfer solve different parts. |
Decision order and traps
Identify the hard constraint → choose the least operationally complex service that satisfies it → check failure boundaries → protect data/history → verify full cost. Well-Architected evaluates workload tradeoffs; Cloud Adoption Framework/landing zones organize adoption and governance. A service SLA does not prove the application's SLA, and replication is not protection from replicated corruption.
Last-pass self-check
1. Global HTTP routing with edge delivery?
Front Door; Traffic Manager only returns DNS routing answers.
2. Must retain exact server-level compatibility and OS control?
Assess SQL Server on a VM; managed offerings may not meet those constraints.
3. Can multi-region replicas replace backups?
No. They can reproduce accidental or malicious changes.
4. Best starting point for migration service selection?
Actual dependencies, compatibility, downtime and rollback requirements.
5. When does caching fail a correctness requirement?
When stale results, missing tenant context or invalidation behavior violate the workload contract.
Sources
Every topic at a glance
Open any topic to revisit its essential facts, decisions and exam traps. Use the full topic for active recall and supporting references.
01 · Microsoft Entra ID and Azure RBAC
Memory hook: Entra identifies the principal; Azure RBAC authorises an action at a scope.
Must remember
- A Microsoft Entra tenant is an identity directory. An Azure subscription is a billing/resource-management boundary associated with a tenant. Management groups organise subscriptions; resource groups organise resources. Do not treat tenant and subscription as synonyms.
- Manage users, groups, properties, assigned licences and guest access deliberately. Security groups organise access; dynamic membership uses rules when licensing/features permit. B2B guests retain an external identity relationship. Self-service password reset needs appropriate eligibility, authentication methods and configuration.
- An Azure role assignment is principal + role definition + scope. Scope can be management group, subscription, resource group or resource, with inheritance. Inspect effective assignments rather than only the nearest resource. Entra directory roles and Azure resource roles are different permission systems.
- Owner can manage resources and access; Contributor manages resources but does not normally grant Azure roles; Reader reads management information. Data-plane roles, such as Storage Blob Data Reader, authorise data operations separately. Management-plane access is not always data access.
- System-assigned managed identity follows one resource's lifecycle; user-assigned identity is an independent reusable resource. Both avoid embedded secrets for supported authentication. Grant the identity's service principal only the required target roles.
- PIM supports time-bound/eligible privileged access; Conditional Access evaluates sign-in conditions and grant controls with appropriate licensing. MFA strengthens authentication; it does not create a missing resource role assignment. Keep a monitored emergency-access design.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| App needs storage access without stored credentials | Managed identity plus an appropriate data role. |
| User can manage a storage account but cannot read blobs | Check data-plane permissions. |
| Temporary privileged operations | Eligible/time-bound access using PIM where available. |
Traps
- Entra administrator is not automatically Owner of every Azure subscription.
- Contributor and Owner differ in access-management privileges.
- A role at a parent scope can remain effective after a narrower assignment is removed.
02 · Subscriptions, Policy and Cost Governance
Memory hook: RBAC decides who may act; Policy evaluates what configuration is acceptable.
Must remember
- A management-group hierarchy applies governance across subscriptions. Resources belong to resource groups and subscriptions, but not every resource type supports every move. Check dependencies, provider registration, quotas and move validation before changing scope.
- Azure Policy definitions evaluate resource properties; initiatives group policies; assignments apply them at scopes with exclusions/exemptions. Effects include audit, deny, modify and deployIfNotExists. Existing noncompliant resources may need a remediation task and suitable managed-identity permissions.
- A CanNotDelete lock blocks management-plane deletion; ReadOnly can block management operations that look like reads but use POST. Locks are inherited and are not a universal data-plane protection mechanism. A privileged user able to remove a lock can change its protection.
- Tags support ownership and cost allocation, but tags do not automatically inherit from resource group to resource. Policy can enforce or add supported tags. Keep a naming/tagging convention and handle untaggable/shared resources explicitly.
- Cost Management analyses spending; budgets notify configured thresholds; Advisor recommends improvements. A budget is not a universal immediate resource shutdown. Billing latency, reservations/savings commitments and shared costs affect interpretation.
- Resource groups are useful for lifecycle management, but deleting a group is a broad action. Review dependencies and locks first. Region affects resource availability, residency and price; the resource group's metadata location does not force every contained resource into that Region.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Prevent unsupported regions at deployment | Azure Policy deny at the appropriate scope. |
| Let a team manage resources but not grant roles | Contributor, constrained to the required scope. |
| Find an oversized idle workload | Usage evidence plus Advisor/Cost Management recommendations. |
Traps
- Audit reports a problem; it does not block it.
- A tag on a group is not automatic tag inheritance.
- A budget alert is not a guaranteed spending cap.
03 · Storage Access, Encryption and Redundancy
Memory hook: Network reachability, authorisation and encryption are separate storage controls.
Must remember
- Storage accounts expose supported services such as blobs, files, queues and tables. Choose the account kind/features, Region and redundancy before relying on a capability. Names and endpoints have service-specific scope rules.
- Prefer Entra/managed-identity authorisation where supported. Account keys are broad credentials; rotate them with a staged client update. A SAS delegates selected operations for a time window and resource scope. User-delegation SAS uses Entra-backed delegation for supported Blob access; service/account SAS have different signing and capabilities.
- A stored access policy can centrally control/revoke associated supported service SAS permissions; it does not apply to every SAS type. Time skew, expiry, signed permissions, protocol and network restrictions can explain an otherwise valid token's failure.
- SAS recall: service SAS is signed with an account key and can reference a stored access policy; account SAS is signed with an account key and can cover supported account/service operations; user-delegation SAS is signed with an Entra-backed delegation key for supported Blob access. Stored access policies do not apply to account SAS or user-delegation SAS. Choose scope and revocation requirements before choosing the token type.
- Storage firewalls restrict network access. A service endpoint uses supported service networking and VNet rules; a private endpoint gives a private IP path and requires correct private DNS. Neither substitutes for authorisation. Disable public access deliberately when the requirement demands it.
- LRS replicates within one location; ZRS spans zones in a Region; GRS/GZRS add asynchronous geographic replication; RA variants allow supported secondary reads. Geo-replication lag affects possible data loss. Redundancy is not backup against authorised deletion.
- Storage encryption protects at-rest data; customer-managed keys add key lifecycle and access responsibilities. Object replication between supported blob accounts has prerequisites and scope; it is not a universal synchronisation of every storage service.
- Use Storage Explorer for interactive data management and AzCopy for scripted transfer. Choose an authentication method and validate source/destination permissions; success transferring a subset does not prove the entire dataset reconciles.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Temporary restricted blob access | A suitably scoped SAS, preferably user delegation when it fits. |
| Private IP access from a VNet | Private endpoint plus DNS and data authorisation. |
| Regional AZ resilience without a second Region | ZRS where supported. |
Traps
- A private endpoint does not automatically disable the public endpoint.
- RA-GRS secondary data may lag.
- A management role can lack permission to read stored data.
04 · Blob Storage and Azure Files
Memory hook: Versions preserve earlier content; soft delete recovers deletion; lifecycle controls aging.
Must remember
- Blob containers hold objects; Azure Files exposes managed file shares over supported protocols. Blob access and a mounted file share are different application interfaces. Identity-based SMB access combines share-level permissions with file/directory permissions.
- Blob access tiers trade storage price against access/retrieval charges and availability behaviour. Hot, cool, cold and archive fit different access patterns; archive rehydration takes time and minimum-duration charges can apply. Check account/redundancy compatibility.
- Versioning retains previous eligible blob versions. Soft delete retains deleted eligible data for a configured period. Container soft delete, blob soft delete and file-share soft delete protect different objects. A snapshot is a point-in-time copy/reference with its own lifecycle.
- Lifecycle rules filter eligible blobs/versions and automate tiering/deletion. Consider current versions, previous versions and snapshots separately. Moving to a cheaper tier too early can create retrieval and early-deletion costs.
- Azure Files snapshots/backup support recovery according to configuration. Restore the correct file/share point and validate permissions and usability. A retained snapshot can continue consuming storage after active files are removed.
- Object replication has supported block-blob/versioning/change-feed requirements and destination behaviour. It does not duplicate every account setting or immediately provide a tested application disaster-recovery plan.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Recover yesterday's overwritten blob | A retained previous version or suitable backup. |
| Recover a recently deleted share | Configured share soft delete/backup, depending on the event. |
| Rarely used data must remain immediately readable | Choose an online tier rather than assuming archive fits. |
Traps
- Soft delete must have protected the resource before the event.
- Archive is not an instant-access tier.
- Deleting current content can leave charged historical versions.
05 · ARM Templates and Bicep
Memory hook: Declare the desired resources, inspect the proposed change and preserve clear ownership.
Must remember
- ARM templates are declarative JSON; Bicep offers a concise language that compiles to ARM deployments. Parameters supply inputs, variables simplify expressions, resources declare objects, modules group reusable declarations and outputs expose selected results.
- A resource reference can establish an implicit dependency; explicit dependsOn is for dependencies not already expressed. Deployment ordering does not prove application readiness. Existing-resource declarations reference objects without necessarily taking over their full lifecycle.
- Use parameter files and secure parameters for sensitive inputs, but remember that secrets can still leak through outputs, logs or resource properties. Prefer managed identities and Key Vault references where supported.
what-ifpreviews supported changes; template validation checks syntax/configuration within its scope. Neither proves a deployment will have quota, permissions or a functioning application. Check incremental versus deletion behaviour and use deployment stacks or supported lifecycle controls deliberately.- Exported templates are a starting point, not always a complete reusable description of every deployed feature. Bicep decompilation may need repair/refactoring. Review API versions, unique names, dependencies, region support and hard-coded IDs.
- Deploy at the scope the resource type supports: resource group, subscription, management group or tenant. The deployer needs the required resource/deployment permissions; a reusable module does not grant them. Inspect deployment operations for the first relevant failure before retrying.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Reusable network deployment across environments | Bicep module with validated parameters. |
| See what an update may change | ARM/Bicep what-if plus review. |
| Secret needed at runtime | Managed identity and a supported secret-reference pattern. |
Traps
- An exported template can omit unsupported state.
- A successful what-if is not a guarantee of apply success.
- A secret marked secure can still be leaked by unsafe output use.
06 · Virtual Machines, Disks and Scale Sets
Memory hook: Size for the bottleneck, place for failure and distinguish stopped from deallocated.
Must remember
- Choose VM family/size using CPU, memory, storage throughput, networking and compatibility. Availability differs by Region and quota. Resizing may require restart/deallocation or a compatible host allocation; check disk and NIC limits too.
- Managed disks have performance and redundancy options. OS disks, data disks and temporary disks have different purposes; temporary storage is not durable business data. Snapshots capture disk state, but application consistency may require additional coordination.
- Availability sets distribute supported VMs across fault/update domains; availability zones distribute across zonal failure domains. A VM Scale Set manages a group of instances with selected orchestration, upgrade and autoscale behaviour. Health probes and application readiness affect safe replacement.
- Stopped within the guest can leave compute allocated and billed; deallocated releases allocation, though retained disks, snapshots and other resources can still bill. Public/private address behaviour depends on address configuration and lifecycle.
- Encryption at host protects supported host-side storage paths; disk encryption and guest/application encryption solve related but distinct requirements. Use trusted boot/security features where the workload and VM generation support them.
- Moving a resource group/subscription is a management-scope operation; moving to another Region generally involves a supported relocation/redeployment process. Validate dependencies, identity/role assignments, network addresses, extensions and backup settings after any move.
- Use Bastion or appropriate controlled administration paths. VM extensions and cloud-init/custom-data mechanisms help configure guests, but failed bootstrap scripts need logs and exit-status investigation. Never assume the portal's running state means the app is ready.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Scale a replaceable VM fleet | VM Scale Sets with health-aware policy. |
| Survive a zone loss | Sufficient working capacity across zones and resilient state. |
| Stop paying for allocated compute during a pause | Deallocate, then account for retained resources. |
Traps
- Guest shutdown and deallocation differ.
- Temporary disk data must be reproducible.
- A Region move is not merely changing a resource-group label.
07 · App Service and Container Platforms
Memory hook: Separate image storage, execution, application configuration and the hosting plan.
Must remember
- ACR stores container images/artifacts. Authenticate pushes/pulls with appropriate identities and roles; prefer immutable image digests for a known release. Registry access does not grant the running application permission to its database.
- Container Instances runs container groups without managing a cluster. Container Apps provides managed application environments, revisions, ingress and event-driven scaling capabilities. AKS gives Kubernetes orchestration with greater platform control and responsibility; it is not the default answer for every container.
- Size container CPU/memory and configure health/startup behaviour. Container Apps scaling rules and minimum replicas affect availability, cold starts and cost. Separate revision traffic from image publishing; pushing an image alone is not necessarily deployment.
- An App Service plan determines shared compute capacity, Region and pricing tier; apps run within it. Scale up changes plan capability; scale out changes instance count. Apps sharing a plan can compete for its resources.
- Deployment slots support staged releases and swaps on eligible tiers. Mark environment-specific settings as slot settings where needed. Warm up and validate the target before swapping; external database changes require their own compatibility plan.
- Configure custom-domain ownership, DNS records and TLS bindings separately. VNet integration primarily handles supported outbound access; private endpoints support private inbound access. Access restrictions, DNS and the destination's permissions still matter.
- Backup support depends on plan/features and configuration; define a restore test. Managed identity and Key Vault references reduce stored credentials. Inspect app logs and dependency/network failures before simply increasing plan size.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Run a small container without managing nodes | Container Instances or Container Apps, according to application/scaling needs. |
| Test a web release before moving users | App Service deployment slot. |
| App needs private database access | Supported VNet integration plus routes, DNS and authorisation. |
Traps
- A registry is not a container runtime.
- VNet integration is not equivalent to private inbound access.
- A slot swap does not reverse database writes.
08 · Virtual Networks, Routes and Secure Access
Memory hook: Check the effective route and the effective rule in both directions.
Must remember
- VNets contain address spaces and subnets. Plan non-overlapping ranges and future growth; supported peering requires compatible addresses. Peering connects VNets but is not automatically transitive through a third VNet.
- Azure selects routes using prefix specificity and route-source precedence for equal prefixes; inspect effective routes when system, BGP and user-defined routes interact. A UDR can direct traffic to a virtual appliance, but the appliance must forward it and the return path must work.
- For ordinary equal-prefix comparisons, remember UDR → BGP → system; first compare the destination prefix length. A matching
/24normally beats a/16regardless of that general source order. Service-specific routes have exceptions: service-endpoint routes cannot simply be overridden by a UDR. Inspect the effective route rather than treating the mnemonic as universal. - Azure reserves the first four and last IPv4 addresses of each subnet. A
/27contains 32 addresses, leaving 27 usable; service-specific subnet sizing can require more than the generic minimum. Subnet capacity planning must include service reservations and scale-out needs. - NSGs are stateful network filtering with priority-ordered allow/deny rules. They can apply at subnet and NIC scopes; evaluate the effective combination. Application security groups group supported VM interfaces for rule targeting; they are not application-layer WAFs.
- Public IP addresses have SKU/allocation/zone properties. NAT Gateway supports explicit outbound SNAT for associated subnets; consider port use and destination patterns. Do not assume new workloads receive default outbound internet access.
- Bastion provides managed administration through supported private VM access without exposing a public management port on each VM. It still needs the required deployment/network configuration and authorised users.
- Service endpoints extend supported service access from a VNet using its public service endpoint and service-side rules. Private endpoints use a private IP for a specific resource/subresource; DNS must resolve appropriately. Endpoint creation and resource approval are separate checks.
- Diagnose with Network Watcher tools, Connection Monitor, effective security rules/routes, name resolution and application listener checks. Existing stateful flows may not behave like brand-new test connections after a rule change.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| One private PaaS resource endpoint | Private Link/private endpoint with private DNS. |
| Traffic must traverse a network appliance | UDR plus forwarding and a symmetric return path. |
| VM administration without a VM public IP | Bastion where appropriate. |
Traps
- Peering is not automatically transitive.
- A service endpoint does not put the service itself inside your subnet.
- An NSG allow does not create a route.
09 · DNS and Load Balancing
Memory hook: DNS answers names; Layer 4 forwards connections; Layer 7 routes application requests.
Must remember
- Azure DNS hosts authoritative public zones; domain registration is a separate function. Delegate with the correct name servers. Private DNS zones require links to the VNets that need resolution; autoregistration is a specific feature, not universal record creation.
- Azure DNS Private Resolver supports hybrid resolution through inbound/outbound endpoints and forwarding rulesets. Avoid loops and test from the real client network. DNS TTL and negative caching can make a corrected record appear stale.
- Azure Load Balancer operates at Layer 4 for supported TCP/UDP traffic, with public or internal frontends, backend pools, probes and rules. Probe success depends on the actual response and permitted probe path. An inbound NAT rule is not the same as balancing to a pool.
- Application Gateway provides regional HTTP/S routing and WAF integration. Front Door provides global HTTP/S application delivery and edge features. Traffic Manager uses DNS routing and is not a reverse proxy for every request.
- TLS can terminate at an application gateway/edge, with a separate encrypted connection to the origin where configured. Host headers, certificate names, SNI and backend settings must align. A valid frontend certificate does not prove origin TLS works.
- Troubleshoot the client DNS answer, frontend connectivity, rule, backend health and application listener in order. A health probe can be too shallow: test a path that reflects usable service without making every shared dependency trigger an unnecessary fleet-wide outage.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Regional path-based HTTP routing | Application Gateway. |
| Global HTTP application delivery | Front Door. |
| TCP/UDP load distribution | Azure Load Balancer. |
Traps
- Traffic Manager decisions can remain cached.
- A healthy probe is only as useful as its tested condition.
- Private-zone association is not inherited through every network connection.
10 · Azure Monitor, Logs and Alerts
Memory hook: Metrics quantify, logs explain, traces connect and alerts start a response.
Must remember
- Azure Monitor combines metrics and logs; Log Analytics workspaces hold queryable log data. Activity Log records management-plane events; resource/application logs require relevant collection configuration. Diagnostic settings route supported categories to selected destinations.
- Azure Monitor Agent uses data collection rules for supported guest telemetry. VM, Storage and Network Insights provide focused views; Application Insights adds application performance and tracing with suitable instrumentation. Guest memory/disk metrics are not automatically identical to platform metrics.
- KQL pipelines transform tables:
wherefilters,projectselects columns,summarizeaggregates,bin()groups time intervals, and joins combine data. Example:Heartbeat | summarize LastSeen=max(TimeGenerated) by Computerfinds each computer's latest recorded heartbeat; absence can mean collection failure, not only host failure. - Alert rules define signal, scope, evaluation and condition. Action groups define notifications/actions. Alert processing rules modify processing such as suppression under selected conditions; they do not change the source telemetry. Use dynamic thresholds where appropriate and test missing-data behaviour.
- Network Watcher and Connection Monitor help inspect path and connectivity. Logs, effective routes/rules and an application test answer different questions. Narrow time windows and correlation IDs reduce noise; retention and ingestion volume affect cost.
- Monitor the collection pipeline itself. Permissions, network access, workspace configuration and data collection rules can break visibility. Avoid logging secrets and unnecessary personal data, and define retention according to operational/evidence requirements.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Who changed an Azure resource? | Activity Log and relevant audit evidence. |
| Notify an operations group on a metric breach | Alert rule linked to an action group. |
| Investigate recurring connection failures | Connection Monitor plus route, rule and application evidence. |
Traps
- No logs can mean no collection.
- Action groups do not define the alert threshold.
- Average response time can conceal severe tail latency.
11 · Azure Backup and Site Recovery
Memory hook: Backup restores a point; replication supports failover; neither is proven until tested.
Must remember
- Recovery Services vaults and Backup vaults support different workload/protection scenarios. Select the vault type, Region, redundancy and policy supported by the resource. A vault existing does not mean a backup is configured or healthy.
- Backup policies control schedule/retention; backup instances/items and recovery points show actual protection. App-consistent recovery requires supported coordination. Soft delete and immutability settings can protect backups but also affect deletion and retention obligations.
- Restore to the intended location or an isolated validation environment as supported. Check encryption-key access, identity permissions, networking, data consistency and application startup. Monitor job failures, missing recovery points and restore results, not just policy assignments.
- Site Recovery replicates supported workloads for disaster recovery. Recovery plans coordinate sequencing and automation. A test failover validates a separate test environment; planned and unplanned failover have different source availability and data-loss implications.
- RPO measures tolerable lost data/time; RTO measures time to useful service. Replication lag, application dependencies, DNS, certificates, secrets and capacity all affect the measured result. Failback needs reverse protection/synchronisation and deliberate traffic control.
- Keep recovery responsibilities documented, practise drills and review costs for replicas, snapshots, storage and reserved recovery capacity. Replication can preserve infrastructure availability while still copying logical corruption.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Recover data before an accidental deletion | A suitable retained backup/recovery point. |
| Move a supported workload to a DR Region during outage | Site Recovery failover with a tested recovery plan. |
| Validate DR without disrupting production | Test failover in an isolated network. |
Traps
- Replication is not historical backup.
- A successful backup job does not measure restore time.
- A vault lock/immutability policy must match retention and deletion requirements.
12 · Architecture Requirements and Landing Zones
Memory hook: Start with constraints and ownership; pick services only after defining the boundaries.
Must remember
- Translate business needs into SLOs, RPO/RTO, latency, data residency, identity, consistency, budget and operating-skill constraints. Azure Well-Architected considers reliability, security, cost optimisation, operational excellence and performance efficiency. Cloud Adoption Framework/landing zones address organisation-wide adoption and governance.
- Design tenant/subscription/management-group boundaries, privileged access, policy and central evidence. Managed identities reduce secret handling; directory roles, resource roles and data permissions remain distinct. Centralised services need resilience and a clear owner.
- Choose VM versus managed app/container/serverless hosting by required control, execution pattern, scaling and operating burden. AKS is useful for Kubernetes requirements but adds platform responsibilities. Event-driven designs need retry, idempotency, poison-message and backpressure handling.
- Service Bus handles brokered queues/topics and enterprise messaging; Event Grid distributes events; Event Hubs ingests high-volume streams; Logic Apps orchestrates integrations; Functions performs event-driven code; API Management governs API exposure. Do not substitute a notification bus for every durable work queue.
- Network choices include hub/spoke, Virtual WAN, peering, VPN/ExpressRoute, private endpoints and central inspection. Determine address space, DNS, route propagation, public/private access and transfer costs. Application Gateway, Front Door and Traffic Manager solve different delivery problems.
- Migration begins with inventory/dependency discovery, Azure Migrate assessment and a business case. Rehost, replatform, refactor or replace according to constraints; select suitable data-migration tools and staged cutover. Validate licences, capacity and rollback before retiring the source.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Strict OS/custom-agent requirement | VM-based hosting may be justified. |
| Managed enterprise messaging with subscriptions | Service Bus topics/subscriptions. |
| Organisation-wide resource constraints | Landing-zone governance with Policy and scoped access. |
Traps
- A cloud service name is not an architecture justification.
- Centralisation can increase blast radius and transfer cost.
- An Expert credential has prerequisites beyond one exam.
13 · Data Architecture and Business Continuity
Memory hook: Data model, consistency, recovery and operating responsibility determine the storage choice.
Must remember
- Azure SQL Database provides managed database capabilities; SQL Managed Instance improves instance-level compatibility for supported SQL Server workloads; SQL Server on Azure VMs offers OS/instance control with more management. Choose by required features, migration compatibility, isolation, scale and cost.
- Azure Database for PostgreSQL supports managed PostgreSQL workloads; Cosmos DB supports distributed non-relational patterns with partitioning and configurable consistency. Blob/Files provide object/file interfaces, not relational query semantics. Analytics may combine Data Lake Storage, Data Factory, Synapse or Fabric according to requirements.
- Select storage tiers, redundancy and lifecycle based on access frequency, retrieval time, residency and retention. Private endpoints, data roles, encryption/key ownership and auditing are separate controls. A cheaper stored GB can create costly retrieval and data movement.
- RPO/RTO determine backup, replica and failover design. Geo-replication can be asynchronous; read scale does not automatically provide transparent write failover. Failover groups, availability features, Backup and Site Recovery have workload-specific behaviour and limitations.
- Plan application-consistent recovery, key/secret availability, network/DNS changes, capacity and dependencies. A multi-Region design needs write ownership/conflict handling and a failback plan. Test recovery using useful user transactions rather than VM power state.
- Use caching, partitioning, query/index tuning, elastic pools or scaling where the evidence supports them. Optimise complete cost, including licences, standby capacity, storage history and transfer. Protect against logical errors with recoverable history even when replicas are highly available.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Need SQL Server instance compatibility with managed operations | Evaluate SQL Managed Instance. |
| Need global key/document access with tunable consistency | Evaluate Cosmos DB with deliberate partition design. |
| Need to recover before a bad deployment corrupted data | A suitable point-in-time recovery/backup strategy. |
Traps
- HA replicas can replicate a bad write.
- A storage redundancy label is not an application recovery plan.
- The strongest consistency option may add latency/availability trade-offs.