AZ-305 Design infrastructure solutions Practice Question
Your organization is migrating a legacy on-premises application to Azure. The application uses a monolithic architecture and requires high availability. The application tier runs on Windows Server and uses a SQL Server database. You need to design a migration strategy that minimizes changes to the application code while maximizing availability. The application can be stateless if session state is externalized. You have the following requirements: (1) The application must be resilient to Azure region failures. (2) The database must have an RPO of 5 minutes and RTO of 1 hour. (3) The migration must be completed within 6 months. (4) The solution should use platform-as-a-service (PaaS) services where possible to reduce operational overhead. Which approach should you recommend?
⚠ Common exam trap
A common mix-up: candidates choose Option A (rehost on VMs with Always On Availability Groups) because it seems familiar for SQL Server high availability, but they overlook the requirement to minimize operational overhead and the need for regional resilience, which PaaS services like App Service and Azure SQL Database with active geo-replication address more effectively.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Migrate the web tier to Azure App Service with staging slots and use Azure SQL Database with active geo-replication.
It uses Azure App Service (PaaS) to host the stateless web tier with staging slots for zero-downtime deployments and Azure SQL Database with active geo-replication to meet the RPO of 5 minutes and RTO of 1 hour. This approach minimizes code changes by externalizing session state (e.g., using Azure Cache for Redis) and leverages PaaS to reduce operational overhead while providing regional failover resilience.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Rehost the application on Azure VMs in an availability set and use SQL Server Always On Availability Groups.
Why it's wrong here
Rehosting on Azure VMs in an availability set keeps the application on IaaS, requiring manual patching, scaling, and management of the web server and OS. SQL Server Always On Availability Groups adds significant setup and maintenance overhead—like configuring cluster listeners and managing multiple replicas—and cannot provide the easy regional failover and automatic storage replication that Azure SQL's active geo-replication offers. This approach does not reduce operational burden, and the availability set only protects against failures within one datacenter, leaving disaster recovery to be built separately.
- ✓
Migrate the web tier to Azure App Service with staging slots and use Azure SQL Database with active geo-replication.
Why this is correct
Azure App Service with staging slots gives you zero-downtime deployments through slot swaps, and you can use external session state (e.g., Redis Cache) so the web tier can scale out. Azure SQL Database with active geo-replication creates a readable secondary in a paired region, supporting manual or automatic failover to meet RPO/RTO targets. This PaaS solution requires minimal or no code changes—much less than a microservices refactor—and offloads patching, high availability, and backup management to the platform.
- ✗
Refactor the application into microservices and deploy to Azure Kubernetes Service.
Why it's wrong here
Refactoring a monolithic legacy application into microservices is a large architectural change, introducing new concerns such as service discovery, inter-service communication, and distributed data management. Deploying to AKS also means managing Kubernetes clusters, node pools, and ingress controllers, adding significant operational overhead. This directly violates the stated requirement to minimize code changes and prolongs the migration timeline with higher risk compared to a direct PaaS lift-and-shift.
- ✗
Containerize the application using Docker and deploy to Azure Container Instances in paired regions.
Why it's wrong here
Containerizing a legacy application with Docker often requires changing the code to handle configuration injection, logging, and process lifecycle, so it is not a true 'minimal change' rehost. Azure Container Instances runs containers on demand but has no built-in permanent load balancing, rolling updates, or staging environment, and you would have to design a failover strategy across paired regions. For a legacy monolithic app that expects a persistent, always-on web tier, ACI is not a natural fit and the deployment becomes more infrastructure engineering than the PaaS solution.
Go deeper
Related to this question
Learn chapter
Data Residency and Sovereignty Requirements
Key term
BIA and RPO RTO Design
Business Impact Analysis and the design of Recovery Point Objective and Recovery Time Objective define how much data loss and downtime a business can tolerate after an IT failure, guiding the architecture of backup and disaster recovery systems.
About these practice questions
Courseiva writes every AZ-305 question from scratch — 795 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-305 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-305 exam.