Microsoft Azure Solutions Architect Expert Practice Test (AZ-305)

Azure Event Grid domains provide a fully managed, serverless publish/subscribe service that automatically scales to millions of events per second, supports event sizes up to 1 MB, and delivers events to multiple subscribers with at-least-once guarantees. Domains add tenant-level routing, making them ideal for multi-tenant SaaS scenarios. Event Grid integrates natively with Azure Functions using Event Grid triggers, allowing near real-time processing with minimal code.

Azure Service Bus topics deliver rich enterprise messaging features such as sessions and ordered delivery, but they require capacity planning and do not scale automatically to very high throughput. Azure Event Hubs is optimized for streaming telemetry; it uses a pull model, does not push events to multiple services, and needs consumer group management. Azure Storage Queues lack publish/subscribe fan-out and advanced routing. Therefore, Event Grid domains best meet the stated requirements.

Azure AD Privileged Identity Management (PIM) for Azure RBAC allows you to create eligible, time-bound assignments that can require approval and automatically expire after a maximum of eight hours. By defining a custom RBAC role that contains only the Microsoft.Compute/virtualMachines/restart/action permission, you enforce least privilege. Assigning that role as eligible directly to each engineer at the subscription scope avoids the limitation that group assignments cannot be made eligible, yet still requires only a one-time setup per engineer. The PIM settings let a shift lead approve each activation request. The Contributor and Virtual Machine Contributor roles grant unnecessary permissions, and monthly access reviews or automation pipelines do not deliver the required per-shift, approval-based, time-bound access.

The Business Critical service tier for Azure SQL Database implements a four-replica Always On availability group. When zone redundancy is enabled, each replica is automatically placed in a different availability zone within the same region. If one zone fails, the service promotes a healthy replica in another zone-typically within 30 seconds-so the database remains online for both reads and writes, meeting the sub-minute RTO. Active geo-replication and auto-failover groups focus on cross-region recovery and do not guarantee sub-minute failover inside the primary region. Running SQL Server on Azure VMs in an availability set still leaves the workload vulnerable to a full zone outage and introduces VM management overhead. Therefore, upgrading to Business Critical and enabling zone redundancy satisfies all stated requirements.

Azure Database Migration Service (DMS) supports online migrations from on-premises SQL Server to Azure SQL Managed Instance when you deploy the service in the Premium tier. Online mode keeps the source database fully operational by continuously replicating changes until you choose to perform a brief cut-over-typically well under 30 minutes-for final synchronization and application redirection.

Exporting a BACPAC requires taking the source database offline and importing a single static snapshot, resulting in hours of downtime for a 5-TB database.

Azure Site Recovery replicates virtual machines, not managed database services; failing over would move the workload to an Azure VM-hosted SQL Server, not to Azure SQL Managed Instance, and still involves more downtime while the VM is brought online and clients are reconfigured.

Azure SQL Data Sync is designed for bidirectional data synchronization of selected tables and is neither intended for full-database migrations nor able to guarantee sub-hour cut-over windows for multi-terabyte workloads. Therefore, deploying Azure Database Migration Service in Premium tier with online migration is the only option that meets both the downtime constraint and the target platform requirement.

Azure Batch is purpose-built for large-scale, parallel, or high-performance batch workloads. It automatically creates and manages pools of virtual machines (including GPU SKUs), queues and schedules jobs, distributes tasks, collects results, and scales the pool up or down so you pay only for the compute consumed. Azure Kubernetes Service, Azure Functions, and Azure Container Instances can run containerized workloads, but they require you to build and operate custom job schedulers or are constrained by execution limits and lack integrated VM-level autoscaling across thousands of tasks. Therefore, Azure Batch best meets the requirements for a managed, scalable batch rendering solution.

Use an Azure Storage account that combines a time-based immutable blob policy with the read-access geo-zone-redundant storage (RA-GZRS) replication tier.

• The immutable blob policy enforces write-once, read-many (WORM) protection, blocking all modifications and deletions for the specified seven-year retention period, which satisfies the compliance requirement.
• RA-GZRS stores three synchronous copies across separate availability zones in the primary region (ZRS) and asynchronously replicates to a secondary region. Because the secondary region is available for immediate read access, applications can continue reading data even if the primary region is unavailable, with a typical cross-region RPO of under 15 minutes.
• RA-GZRS provides at least eleven nines (99.999999999 %) annual durability while costing less than building and managing multiple independent storage accounts.

Why the other options do not meet requirements:

• ZRS plus immutability keeps data in a single region, so it cannot withstand a regional outage.
• GRS plus immutability replicates to a secondary region but does not allow reads there until Microsoft triggers a failover, violating the read-access requirement.
• Manually copying between two LRS accounts neither guarantees the stipulated RPO nor delivers the platform-managed durability and availability provided by RA-GZRS.

A dedicated Log Analytics workspace in a separate management subscription provides a single, durable location for logs that is unaffected if other subscriptions or resources are deleted. Subscription-level diagnostic settings can forward both Azure Activity Logs and resource diagnostic logs directly to this workspace. By assigning an Azure Policy initiative that automatically deploys and configures these diagnostic settings to any current or future subscription, you avoid manual per-subscription configuration and ensure consistent onboarding. The workspace's retention can be set to 730 days, meeting the compliance requirement. The other options either scatter logs across multiple storage accounts, rely on on-premises infrastructure, or use Application Insights (which is intended for application telemetry, not comprehensive platform logging) and therefore fail to meet centralization, durability, or administrative-effort requirements.

Azure SQL Database automatically takes full, differential, and transaction log backups that enable point-in-time restore for the retention period configured for the service tier-by default 7 days in Business Critical and extendable up to 35 days. For longer compliance retention, Azure SQL Database offers a built-in Long-Term Retention (LTR) feature that copies full backups to RA-GRS blob storage on a weekly, monthly, or yearly schedule and keeps them for up to 10 years. Enabling an LTR policy for monthly backups therefore meets the 10-year requirement without additional infrastructure or management overhead. Azure Backup cannot protect platform-as-a-service databases, geo-replication is intended for high availability rather than long-term retention, and exporting BACPACs with Automation adds operational complexity and cost compared to the native LTR capability.

Azure Data Box provides about 100 TB of raw (≈80 TB usable) capacity and is designed for one-time, offline transfers in the 40-500 TB range. You can order the appliance, copy the 80 TB locally at high speed, and then ship it back to Microsoft for ingestion into your Azure Storage account. After seeding, deploying Azure Data Box Gateway as an on-premises virtual appliance enables continuous synchronization over the existing WAN link. The gateway uploads only changed data blocks, easily handling the expected 200 GB per month with minimal administration.

AzCopy over a 50 Mbps connection would take well over a month to upload 80 TB and would still require manual scheduling for recurring jobs. Azure File Sync targets Azure Files, not Blob Storage. Azure Database Migration Service is intended for structured databases, not unstructured file content.

Because the SQL Server instance is hosted on-premises behind a firewall that blocks all inbound traffic, Azure Data Factory cannot initiate a direct connection from the Azure-hosted integration runtime. The correct approach is to install and register a self-hosted integration runtime (SHIR) inside the on-premises network. SHIR establishes only outbound, secure TCP 443 connections to the Azure Data Factory service, satisfying the security constraint while enabling the Copy activity to pull data every 15 minutes. The Azure integration runtime and Managed Virtual Network runtime run in Azure and cannot reach the on-prem server without opening inbound ports or using VPN/ExpressRoute. The Azure-SSIS integration runtime is intended for running existing SSIS packages; it is unnecessary when a code-free Copy activity is sufficient and would add cost and complexity.

Azure Container Apps is a fully managed service that runs containers on an Azure-managed Kubernetes environment yet hides cluster management from developers. It supports event-driven horizontal scaling with KEDA, including scaling to zero when workloads are idle, and offers native integration with the Dapr runtime for service invocation and pub/sub. Azure Kubernetes Service also supports KEDA and Dapr but still requires customers to operate and secure the cluster and cannot completely eliminate baseline node costs. Azure App Service for Containers and Azure Container Instances do not provide Dapr integration or scale-to-zero capabilities. Therefore, Azure Container Apps best meets all stated requirements.

An auto-failover group asynchronously replicates Azure SQL databases to a secondary server in a different region, typically keeping data lag under five seconds (meeting the RPO target) and enabling automatic failover within minutes (meeting the RTO target) with minimal operational overhead. Point-in-time restore for up to 35 days remains available because automated backups continue on both primary and secondary. Geo-restore based only on automated backups can have an RPO of up to one hour and requires manual action. Zone redundancy protects only against availability-zone failures inside the same region, not a regional outage. Nightly exports to Azure Storage are manual, increase management overhead, and can lose up to 24 hours of data, violating the RPO requirement.

Enabling multi-region writes on an Azure Cosmos DB account and turning on automatic failover satisfies all the stated requirements. Multi-region write accounts receive a 99.999 percent SLA for both reads and writes and can continue serving traffic from any healthy region if one becomes unavailable. Because every configured region can accept writes, users around the world write to the nearest region, minimizing latency.

The alternative designs fail to meet one or more requirements:

• A single-write-region Cosmos DB account-even with additional read regions-offers only a 99.99 percent write-availability SLA. Although such an account can be configured for automatic failover, it still falls short of the 99.999 percent availability target.
• Azure Table storage with geo-redundant replication guarantees only 99.9 percent write availability and relies on client-side retry logic for failover.
• Azure SQL Database with active geo-replication provides a 99.99 percent availability SLA, which does not meet the 99.999 percent requirement.

Azure Cache for Redis Enterprise supports active geo-replication, allowing caches in different regions to operate in active-active mode with automatic data synchronization and seamless failover. The Enterprise tier also supports persistence, key-level TTL, and all standard Redis eviction policies, while requiring only connection-string changes for most applications that already use Redis clients. Azure SQL Database is a relational store and cannot guarantee sub-millisecond cache latency. Azure Front Door Standard provides edge object caching but cannot store or replicate key-value shopping-cart data. In-memory caches inside App Service instances are not shared across regions and are lost during scale-out or failover. Therefore, Azure Cache for Redis Enterprise is the appropriate choice.

Configure Azure Monitor diagnostic settings on each supported resource (or at the subscription level for activity logs) to send the same platform log categories to both an Azure Storage account and an Azure Event Hub namespace. Store the data in a storage account that uses the Cool tier for cost-effective 12-month retention. The Event Hub namespace acts as the streaming endpoint that the Splunk Add-on for Microsoft Cloud Services can subscribe to for near-real-time ingestion. A single diagnostic setting can route the identical logs to multiple destinations (up to five), so no additional automation or intermediate services are required. The alternative options rely on unsupported targets (Service Bus), lack real-time guarantees (Data Collector API), or add unnecessary operational complexity (custom Automation runbooks).

Azure Migrate: Discovery and assessment is designed for the pre-migration evaluation of on-premises servers. Deploying the Azure Migrate appliance enables agentless discovery of VMware VMs, collection of historical performance data, generation of right-sizing and cost estimates for Azure virtual machines, and built-in network dependency visualization.

Azure Monitor with the Azure Monitor Agent can collect performance counters and, with the Service Map solution, show dependencies, but it does not automatically create right-sizing or cost assessment reports, so you would still need another tool. The Microsoft Assessment and Planning Toolkit is a legacy, no-longer-updated, on-premises tool that lacks native Azure cost calculations and requires additional steps to discover network dependencies. The Azure Site Recovery mobility service is used for replication and failover testing, not for pre-migration assessment or cost estimation. Therefore, deploying the Azure Migrate appliance and creating a discovery and assessment project is the correct first step.

Azure API Management natively provides a unified developer portal, policy-based request and response transformations (including SOAP-to-REST), built-in integration with Azure Active Directory for token validation, and a self-hosted gateway mode that can be deployed inside the on-premises network so internal traffic never leaves the private boundary. Service Bus, Application Gateway, and Front Door address messaging, load balancing, or global routing needs but lack the full API lifecycle features and transformation capabilities required for this scenario.

Azure Container Apps natively runs container images without size limits, integrates with KEDA to scale on Azure Service Bus queue length, and can scale out rapidly (up to hundreds of replicas) or all the way to zero when the queue is empty, providing true serverless consumption pricing. Azure Container Instances lack event-driven autoscale and therefore would require additional orchestration logic. Azure Functions premium plan can run containers but keeps at least one instance warm, so it cannot scale to zero and incurs always-on costs. Azure Kubernetes Service offers full control and autoscaling, but cluster creation, node patching, and control-plane management contradict the requirement to minimize infrastructure management effort.

The Ready methodology of the Microsoft Cloud Adoption Framework focuses on preparing the Azure environment to receive migrated or newly built workloads. Key guidance includes establishing an enterprise-scale subscription and landing-zone architecture that defines management-group hierarchy, role-based access control, Azure Policy assignments, and hub-and-spoke networking. Deploying an Azure landing zone therefore directly satisfies the need for a scalable, governed platform foundation.

Using Azure Migrate for assessments, configuring Azure Site Recovery, or building deployment pipelines are valuable tasks, but they belong to the Assess/Plan and Adopt (Migrate & Innovate) stages rather than the Ready stage, and they do not in themselves create the enterprise control plane required before migrations begin.

Azure Batch is designed for high-performance computing and large-scale, containerized batch workloads. It provisions and de-provisions compute node pools automatically, so administrators do not have to build, patch, or manage a cluster. A managed identity can be assigned to the Batch pool, allowing tasks to access Azure Blob Storage securely without storing secrets in code or containers. Azure Kubernetes Service would still require managing a Kubernetes control plane and node upgrades. Azure Container Instances lacks built-in job scheduling and autoscaling across hundreds of vCPUs. Although Azure Functions Premium can run long-running code, it is optimized for event-driven micro-tasks rather than coordinated HPC workloads that demand 500 vCPUs for several hours.