AZ-305 Design business continuity solutions: 270 practice questions

12 of the 270 Design business continuity solutions questions in the Certsqill AZ-305 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-305? Take the free 5-min readiness check →

1. Test Failover to an isolated Azure VNet: Which ASR operation achieves this without affecting ongoing replicati

1. Disable replication temporarily, start the VMs manually in Azure to validate them, then re-enable replication from scratch after testing completes

   Incorrect. Disabling replication loses the recovery point history and requires reconfiguring replication from scratch. This adds significant recovery time and operational risk — Test Failover is specifically designed to avoid this disruption.
2. Planned Failover to Azure — cleanly shuts down the on-premises VMs and fails the workload over to Azure with zero data loss for validation

   Incorrect. Planned Failover is a production operation — it shuts down on-premises VMs and activates the Azure copies as production. This is not a test; it actually moves the workload. Using Planned Failover for a test would disrupt production operations.
3. Unplanned Failover (Failover) to Azure — immediately starts the Azure VMs from the latest available recovery point to validate the application

   Incorrect. Unplanned Failover is for actual disasters — it starts Azure VMs from the latest recovery point without gracefully shutting down on-premises VMs. Using this for a test causes data inconsistency and stops production replication.
4. Test Failover to an isolated Azure VNet — replicated VMs start in Azure for validation without interrupting replication to the production VNet ✓

   Correct. ASR Test Failover creates copies of replicated VMs in an isolated VNet (not connected to production) — replication continues uninterrupted. The team can validate VM startup, application functionality, and network connectivity. After testing, 'Cleanup Test Failover' removes the test VMs without any production impact.

ASR Test Failover validates replicated VMs in an isolated Azure VNet without interrupting ongoing replication to production — the designed testing mechanism for DR validation.

2. Priority routing with East US as Priority 1 and West: Which Traffic Manager routing method meets these require

1. Priority routing with East US as Priority 1 and West Europe as Priority 2 ✓

   Correct. Priority routing sends all traffic to the highest-priority healthy endpoint. With East US at Priority 1 and West Europe at Priority 2, all normal traffic goes to East US. When East US health probes fail, Traffic Manager automatically routes to West Europe (Priority 2). No load balancing between sites when both are healthy.
2. Weighted routing with East US at weight 100 and West Europe at weight 1

   Incorrect. Weighted routing distributes traffic proportionally — with weights 100:1, approximately 99% goes to East US and 1% to West Europe during normal operation. This violates the requirement that ALL traffic goes to East US when it's healthy. Weighted routing doesn't implement true active-passive.
3. Geographic routing with every client region mapped to the East US endpoint

   Incorrect. Geographic routing directs traffic based on the user's geographic origin. You cannot assign all geographies to one endpoint without losing DR capability — if East US fails, all geographies mapped to it would receive errors, not failover to West Europe.
4. Performance routing based on the lowest measured latency per client

   Incorrect. Performance routing sends each client to the endpoint with the lowest measured latency — clients in Europe would be routed to West Europe even during normal operation when East US is healthy. This doesn't implement the all-traffic-to-East-US requirement.

Priority routing sends all traffic to the highest-priority healthy endpoint (East US), automatically failing over to the backup (West Europe) when health probes fail — the active-passive DR pattern.

3. Azure Front Door in front of both regions: Which service provides all capabilities in a single solution?

1. Azure Traffic Manager with a per-region Application Gateway (WAF v2)

   Incorrect. Traffic Manager is DNS-based (Layer 4/DNS layer) — failover time depends on DNS TTL (minutes, not sub-second). It also doesn't support SSL offloading or WAF natively. While Application Gateway per region adds WAF and SSL, failover between regions via Traffic Manager would take 1-5 minutes, not sub-second.
2. Azure Front Door (Standard or Premium tier) in front of both regions ✓

   Correct. Azure Front Door provides: SSL termination at 200+ edge POPs globally, integrated WAF policy, URL-based routing rules (path-based routing to different origins), anycast-based sub-second failover (not DNS-based), and HTTP/HTTPS health probes to backends. It operates at Layer 7 and handles all five requirements in one service.
3. Azure Application Gateway v2 with cross-region backend replication

   Incorrect. Application Gateway is a regional load balancer (Layer 7) — it cannot natively route between Azure regions. Cross-region failover requires Traffic Manager or Front Door in front of regional Application Gateways. Application Gateway alone cannot satisfy the multi-region requirements.
4. Azure Load Balancer (Standard) with cross-region Global Load Balancing

   Incorrect. Azure Load Balancer operates at Layer 4 — it has no URL-based routing, WAF, or SSL offloading capabilities. Global Standard Load Balancer is a cross-region load balancer but still Layer 4, without HTTP-aware routing.

Azure Front Door provides Layer 7 global load balancing with SSL offloading, WAF, URL-based routing, and anycast-based sub-second regional failover in a single service.

4. Recovery Services Vault with GRS backup storage: Which Azure Backup configuration meets these requirements?

1. Recovery Services Vault with LRS backup storage and a standard backup policy providing daily, weekly, and monthly recovery points, plus Instant Restore snapshots for fast restores

   Incorrect. LRS backup storage is not geo-redundant — a regional failure would make backups inaccessible. The requirement explicitly requires geo-redundant backups. GRS or GZRS must be selected for the vault's backup storage replication.
2. Backup Center with an Azure Policy initiative enforcing backup tags, plus a custom daily/weekly/monthly backup schedule orchestrated through Azure Automation runbooks

   Incorrect. Backup Center is a management interface for monitoring multiple vaults — it doesn't replace Recovery Services Vault configuration. Custom backup schedules via Automation are unnecessary; Azure Backup's native GFS retention policy supports all specified retention tiers natively.
3. Recovery Services Vault with GRS backup storage, Enhanced backup policy with daily/weekly/monthly retention tiers, and Instant Restore snapshot retention for 2-5 days ✓

   Correct. Recovery Services Vault with GRS stores backups in a geo-redundant paired region. Enhanced backup policy (available for Azure VMs) supports Grandfather-Father-Son (GFS) retention: daily 30 days, weekly 12 weeks, monthly 12 months. Instant Restore snapshots (2-5 days) enable rapid restore from local snapshots meeting the 4-hour RTO.
4. Azure managed disk snapshots via Azure Automation on a daily schedule, with geo-replication of the snapshots to the paired region for redundancy and retention

   Incorrect. Azure VM snapshots (managed disk snapshots) require custom Automation for scheduling, retention management, and geo-replication. They don't support GFS retention natively, lack consistent restore points, and require significant operational overhead vs Azure Backup's managed service.

Recovery Services Vault (GRS) + Enhanced VM backup policy with GFS retention tiers + Instant Restore snapshots provides geo-redundant protection with the specified retention schedule and <4-hour RTO.

5. Deploy VMs across 3 Availability Zones: Which configuration provides the highest resiliency?

1. Deploy VMs across 2 Availability Zones with a Basic Load Balancer distributing traffic between the tiers in each zone

   Incorrect. Basic Load Balancer does not support Availability Zones — it cannot balance traffic across zone-deployed VMs. Zone-redundant Standard Load Balancer is required for cross-AZ traffic distribution. Additionally, 2 AZs provides protection against one zone failure; 3 AZs is the best practice.
2. Deploy all VMs in a single Availability Set with 3 fault domains and 3 update domains across the datacenter racks

   Incorrect. Availability Sets distribute VMs across fault domains (different server racks) and update domains within a single datacenter. They protect against hardware rack failures and planned update reboots but do NOT protect against a full datacenter failure — all fault domains are in the same building.
3. Deploy VMs across two paired regions (East US and West US) with Azure Traffic Manager routing traffic between the regional tiers

   Incorrect. Cross-region deployment protects against regional failures — it exceeds the stated requirement of protection within a region. This is more expensive and complex than the required intra-region AZ redundancy. The question asks for protection against datacenter failure within a region.
4. Deploy VMs across 3 Availability Zones (one per tier per zone), using a Zone-redundant Standard Load Balancer between tiers ✓

   Correct. Availability Zones are physically separate datacenters within a region — each has independent power, cooling, and networking. Distributing VM instances across 3 AZs protects against both individual hardware failure (Azure SLA covers hardware within a zone) and entire datacenter failure. Zone-redundant Standard Load Balancer routes traffic across zones.

Availability Zones (3 physically separate datacenters per region) with Zone-redundant Standard Load Balancer protects against both hardware failures and entire datacenter failures within the region.

6. Application-consistent recovery point: Which recovery point type should be selected at failover, and what is i

1. Application-consistent recovery point; RPO is the interval between application-consistent snapshots (configurable, typically 60 minutes), so actual RPO may exceed the 15-minute target ✓

   Correct. Application-consistent recovery points use VSS (Volume Shadow Copy Service) to capture a consistent state where all in-flight transactions are committed. However, application-consistent snapshots are generated at longer intervals (typically 60 minutes default, minimum 60 minutes for Windows). The RPO for application-consistent recovery is the snapshot interval — which may exceed 15 minutes. Crash-consistent points are taken every 5 minutes but may leave the application in an inconsistent state.
2. Crash-consistent recovery point; RPO is under 5 minutes because ASR generates crash-consistent points every 5 minutes, and disk-level consistency is sufficient for databases

   Incorrect. While crash-consistent recovery points are generated every 5 minutes (meeting the 15-minute RPO), they represent the state of disk at a moment in time — like power loss. For a database, this may result in partial transactions requiring roll-forward/rollback recovery. The application may not be in a fully consistent state.
3. Latest processed recovery point; RPO equals the last point processed by the mobility service (typically under 10 minutes) and it already guarantees application consistency

   Incorrect. 'Latest processed' is the most recently available recovery point (crash-consistent) — it minimizes RTO by using the last processed point without additional consistency processing. It is equivalent to crash-consistent in terms of application consistency.
4. Custom recovery point configured with 15-minute application-consistent snapshot intervals; this simultaneously satisfies the sub-15-minute RPO and full application-consistency requirement

   Incorrect. The minimum application-consistent snapshot interval in ASR is 60 minutes (for Windows with VSS), not 15 minutes. You cannot configure application-consistent snapshots at 15-minute intervals — this is a technical limitation of VSS quiescing. The 15-minute RPO and application consistency requirements create a genuine conflict in ASR.

Application-consistent recovery requires VSS quiescing (minimum 60-minute interval), creating a conflict with the 15-minute RPO requirement — this trade-off must be communicated to stakeholders.

7. Azure Backup for AKS with the Backup extension installed: Which solution provides complete AKS backup with lea

1. GitOps with Flux or ArgoCD storing all cluster manifests in Git, combined with scheduled Azure Disk snapshots for persistent volume data

   Incorrect. GitOps manages desired state (manifests) but doesn't capture runtime state or secrets. Combining with disk snapshots requires custom orchestration for coordinated cluster + PV restore. This is operationally complex and not point-in-time consistent across cluster state and PVs.
2. Azure Backup for AKS with the Backup extension installed on the cluster and a backup policy providing daily backups and 30-day retention ✓

   Correct. Azure Backup for AKS captures both Kubernetes resource configurations (deployments, services, ConfigMaps, PVCs) and Azure Disk persistent volume snapshots in a single operation. It supports point-in-time restore with 30-day retention. The backup extension is installed as an AKS extension — no custom tooling required.
3. Azure Policy enforcing resource labels plus a daily kubectl export of cluster state to Azure Blob Storage, with disk snapshots for volumes

   Incorrect. Kubectl export of cluster state captures YAML manifests but does not back up persistent volume data. Restoring from YAML exports requires manual recreation without persistent volume snapshots. This is not a complete backup solution.
4. Velero open-source tool backed by Azure Blob Storage for cluster state, paired with Azure Disk snapshots for the persistent volumes

   Incorrect. Velero is a valid and widely-used AKS backup solution. However, it requires installation, configuration, and ongoing management as custom tooling. Azure Backup for AKS is the native managed service that provides the same capabilities without custom tool management — the question asks for least custom tooling.

Azure Backup for AKS (Backup extension) provides managed backup of both Kubernetes configurations and Azure Disk PV data with point-in-time restore — no custom tooling required.

8. Implement a custom health endpoint that checks database: What change enables application-level health detectio

1. Enable Traffic Manager nested profiles that combine health-check results from several child monitoring profiles into one aggregated, application-level health signal for failover

   Incorrect. Nested profiles combine multiple Traffic Manager profiles for complex routing scenarios. They don't add application-level health checking capability beyond what individual profile endpoints support. The root issue is the probe type (TCP vs HTTP/custom health endpoint).
2. Configure Azure Monitor alerts on application exception rates to automatically trigger a Logic App that disables the unhealthy Traffic Manager endpoint

   Incorrect. Azure Monitor alerts can trigger Logic Apps or Azure Functions to disable Traffic Manager endpoints programmatically. While technically achievable, this is a complex custom solution with additional failure points (alert latency, action group execution time). The health endpoint + Traffic Manager probe is the direct, purpose-built pattern.
3. Implement a custom health endpoint (/health) that checks database connectivity and dependencies, and configure Traffic Manager to use HTTP probes against this endpoint ✓

   Correct. A custom health endpoint returns HTTP 200 when all application dependencies are healthy and HTTP 500 (or similar error) when any dependency fails. Traffic Manager HTTP/HTTPS probes check this endpoint — if it returns an error or times out, the endpoint is marked unhealthy and traffic is diverted to the secondary region. TCP probes only detect port availability, not application health.
4. Increase the TCP probe frequency from 30 seconds down to 10 seconds so Traffic Manager can detect backend application failures much more quickly

   Incorrect. TCP probes only verify that port 443 is listening — they cannot detect application-level failures like a broken database connection. Increasing probe frequency detects the same limited information faster, but doesn't enable detection of application health issues.

A custom /health endpoint checking application dependencies + Traffic Manager HTTP probe enables application-level health detection — TCP probes only detect port availability.

9. Enable soft delete for Azure Backup on the Recovery: Which Azure Backup feature provides this protection?

1. Enable RBAC with the Backup Operator role to restrict who holds backup delete permissions

   Incorrect. RBAC controls who can perform delete operations. If an attacker gains admin credentials (as stated in the scenario), they have full permissions — RBAC cannot prevent deletion by someone with admin rights. Soft delete adds a time-based safety net independent of credential compromise.
2. Configure the Recovery Services Vault to use the Immutable Vault feature for stored backups

   Incorrect. Immutable vault (Immutable Vault feature) prevents changes to backup policy and prevents reducing retention — it is an additional layer of protection. However, the question specifically asks about protection against backup data deletion after a delete request. Soft delete is the direct answer for this scenario.
3. Enable geo-redundant backup storage (GRS) to keep a second copy in the paired region

   Incorrect. GRS replicates backup data to a paired region for geographic redundancy. However, if the backup data is deleted from the vault, GRS does not retain a separate copy — the replication follows delete operations. GRS protects against regional failures, not against intentional data deletion.
4. Enable soft delete for Azure Backup on the Recovery Services Vault with 14-day retention ✓

   Correct. Soft delete for Azure Backup retains deleted backup data for a configurable period (14 days default, up to 180 days) even after deletion is requested. During the soft delete retention period, backup data is marked as 'Soft Deleted' and can be recovered without data loss. An attacker who deletes backups cannot permanently destroy the data within the retention window.

Soft delete retains deleted Azure Backup data for up to 180 days after deletion — an attacker with admin credentials who deletes backups cannot permanently destroy data within the retention window.

10. ASR Recovery Plan with groups and a post-action script: Which ASR feature orchestrates this?

1. ASR Recovery Plan with groups (Group 1: database VMs, Group 2: app servers, Group 3: web servers) and a post-action script (Azure Automation Runbook) for DNS update ✓

   Correct. ASR Recovery Plans define ordered groups of VMs to failover in sequence. Group 1 fails over first (database), then Group 2 after Group 1 completes (app servers), then Group 3 (web servers). Post-action scripts (Azure Automation Runbooks or Azure Functions) can be added to any group to execute custom logic — DNS update runs after Group 3 VMs are online.
2. ASR failover policy using automatic VM dependency mapping to discover and order the failover sequence, then running the custom DNS update script once all tiers are online

   Incorrect. ASR does not have an automatic dependency-mapping feature that determines failover order from VM dependencies. Failover order is explicitly defined through Recovery Plans with manual group assignment — dependency discovery is a feature of Azure Migrate, not ASR failover.
3. Azure Logic App triggered by the ASR failover event to sequentially restart each VM tier in order and then execute the custom DNS update script

   Incorrect. While Logic Apps can respond to ASR events, this requires building a custom orchestration workflow that duplicates Recovery Plan functionality. Recovery Plans are the native, purpose-built ASR feature for exactly this scenario — ordered group failover with Automation Runbook integration.
4. Manual, sequenced failover of each VM tier performed by an operator, followed by a custom DNS script run interactively from Azure Cloud Shell

   Incorrect. Manual individual VM failovers require human intervention at each step — this is slow, error-prone, and does not meet the orchestration requirement. During an actual disaster, human-mediated sequenced failover introduces unacceptable RTO delays.

ASR Recovery Plans with ordered VM groups and Automation Runbook post-actions provide sequenced failover orchestration and custom script execution — the native DR orchestration feature.

11. App Service Plan with zone redundancy enabled: Which App Service configuration achieves all three?

1. Premium App Service Plan with Azure Front Door in front for global cross-region failover, plus deployment slots and slot swap for zero-downtime releases and rollback

   Incorrect. Front Door provides global routing and failover between regions but doesn't protect against zone failures within a region if only one regional App Service is deployed. Zone redundancy on the App Service Plan is required for AZ protection within a region.
2. App Service Plan (Premium v2 or v3) with zone redundancy enabled, deployment slots (staging slot for zero-downtime swap), and swap with preview for gradual rollout ✓

   Correct. Premium v2/v3 with zone redundancy distributes App Service instances across Availability Zones, protecting against datacenter failure. Deployment slots enable zero-downtime: deploy to staging, warm up, then swap to production. Swap with Preview allows routing a percentage of traffic to staging before full swap — instant rollback by re-swapping if issues arise.
3. Basic App Service Plan with Always On enabled, zone redundancy, and deployment through a PowerShell script that runs health checks before switching live traffic

   Incorrect. Basic tier has no zone redundancy, no deployment slots, and limited scaling. It cannot achieve 99.95% SLA for a critical application. Always On prevents app pool recycling but doesn't provide AZ protection.
4. Standard App Service Plan with manual scale-out to 3 instances, deployment slots for zero-downtime swaps, and slot swap for instant rollback of releases

   Incorrect. Standard tier supports scaling to multiple instances but does NOT support Availability Zone redundancy — all instances may be in the same datacenter. Standard tier also doesn't guarantee AZ distribution (AZ support requires Premium v2/v3). Manual scaling doesn't ensure AZ distribution.

App Service Premium with zone redundancy (AZ protection) + deployment slots (zero-downtime swap) + swap with preview (instant rollback) addresses all three requirements.

12. RTO = 4 hours: Which statements correctly identify the RTO and RPO?

1. RTO = 4 hours (the interval between successive backups), RPO = 1 hour (the time needed to complete a full failover)

   Incorrect. RTO is not the time between backups — that determines RPO. RTO is the maximum downtime. RPO is not the failover completion time — that's part of RTO. The definitions are misapplied.
2. RTO = 1 hour (the data recovery window), RPO = 4 hours (the time required to restore operations)

   Incorrect. RTO and RPO are reversed: RTO = time to restore service (4 hours), RPO = acceptable data loss (1 hour). Confusing the two is a common mistake.
3. RTO = 4 hours (maximum acceptable downtime), RPO = 1 hour (maximum acceptable data loss measured in time) ✓

   Correct. Recovery Time Objective (RTO) is the maximum duration that a service can be unavailable after a disaster — in this case, 4 hours. Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time — backups or replication must ensure no more than 1 hour of data can be lost.
4. RTO and RPO are the same concept, both measuring the maximum acceptable downtime threshold of 4 hours

   Incorrect. RTO and RPO measure different dimensions: RTO measures TIME (downtime duration), RPO measures DATA (amount of data loss in time). They are distinct metrics with separate technical solutions.

RTO = maximum acceptable service downtime (4 hours), RPO = maximum acceptable data loss in time (1 hour) — distinct metrics requiring different DR solutions.

Other AZ-305 domains

• Design infrastructure solutions — 572 questions →
• Design identity, governance, and monitoring solutions — 470 questions →
• Design data storage solutions — 340 questions →
• All 1652 AZ-305 questions →