Free Microsoft AZ-305 Practice Test Questions MCQs

Explanation:

The requirements are failover with zero data loss, availability during a zone outage, and minimized costs. Here is how each deployment option measures up against these goals, supported by official Microsoft documentation:

Azure SQL Managed Instance Business Critical: This tier is designed for mission-critical applications with high IO performance and high transaction rates. Its high availability is achieved by replicating compute and storage to multiple replicas using Always On availability groups. A zone-redundant configuration, which places replicas across three Azure availability zones, is generally available for this tier. This configuration guarantees an RPO of zero for failovers, meaning no data loss, and provides resilience against a zone outage. According to the documentation, there is no additional cost for enabling zone redundancy on the Premium or Business Critical tiers, fulfilling the cost-minimization requirement.

Here is why the other options do not perfectly meet all the requirements:

Azure SQL Database Premium: This tier also supports zone redundancy and can provide zero data loss failover with no extra cost for the configuration. However, it is a DTU-based model, an older purchasing model. The question asks for the choice that minimizes costs while meeting the technical requirements. Between the functionally similar Premium and Business Critical tiers, Business Critical (vCore-based) is the more modern, recommended, and cost-effective solution for new deployments.

Azure SQL Database Hyperscale: While the Hyperscale tier also supports zone redundancy with the stated benefits, it has a specific limitation. The documentation notes that enabling zone redundancy on a Hyperscale database requires at least one high-availability compute replica. Since you pay for all provisioned replicas, meeting the requirements in Hyperscale would involve paying for a primary replica and at least one additional high-availability replica, increasing costs.

Azure SQL Database Basic: The Basic tier does not support zone-redundant availability at all. It offers only local redundancy, which cannot protect against an availability zone outage.

References
Azure SQL Database and Azure SQL Managed Instance features for availability and zone redundancy
Cost considerations for zone redundancy in different service tiers
Requirements for enabling zone redundancy in Hyperscale databases

Explanation:

PA1 (assigned to MG1): MG1 contains Sub2 and Sub4. An assignment at MG1 applies to all subscriptions under that management group, so PA1 will evaluate resources in both Sub2 and Sub4, not only Sub2. Hence No.

PA2 (resource selector = Microsoft.Compute/virtualMachines in East US): With the resource selector limited to VM resources in the East US region, PA2 will evaluate any virtual machine in East US within the assignment scope. Because PA2’s selector targets all VMs in East US (no exclusion was added for PA2), it will evaluate the East US VMs. Hence Yes.

PA3 (exclusion added for Sub1): The action described was adding an exclusion for Sub1 to PA3. VM3 is in Sub3 (which is under MG2). If PA3 is assigned at a scope that does not include Sub3 (for example it was assigned under MG1 or another scope that doesn’t cover Sub3), or if the intent of the change was to exclude only Sub1, PA3 will not evaluate VM3. Given the described hierarchy (Sub3 is under MG2, not under MG1 where PA1 was assigned), PA3 will not evaluate VM3. Hence No.

Explanation:

To ensure that logs from virtual machines across all virtual networks are routed over the Microsoft backbone network with minimal administrative effort, you should use the following configuration:

Minimum number of Azure Monitor Private Link Scope (AMPLS) objects: 1

An Azure Monitor Private Link Scope (AMPLS) is a logical resource that connects one or more private endpoints to a set of Azure Monitor resources (like Log Analytics workspaces).

Scalability: A single AMPLS can manage the connection for Workspace1.

Efficiency: You do not need multiple AMPLS objects to support multiple networks or endpoints; one object is sufficient to define the scope of the private link for the entire subscription or specific resources.

Minimum number of private endpoints: 2

The number of private endpoints required is determined by the network topology:

VNet1 and VNet2: Since VNet1 and VNet2 are peered, they share the same network space for the purpose of reaching a private endpoint. You can place one private endpoint in either VNet (e.g., VNet1), and the virtual machines in both peered networks will be able to route traffic through it to reach the AMPLS.

VNet3: Because VNet3 is isolated from the others, it cannot reach a private endpoint located in VNet1 or VNet2. Therefore, a second, separate private endpoint must be created within VNet3 to ensure its logs are also routed over the backbone network.

A Note on the Image Selection

The green dotted lines in your provided "image_95d2d0.png" suggest a selection of 1 for AMPLS and 3 for private endpoints. While some architectures might use three endpoints for maximum redundancy or if peering wasn't used, a solution focused on minimizing administrative effort and exploiting VNet peering would technically only require 2 endpoints. However, if your environment dictates that every VNet must have its own dedicated entry point regardless of peering, then 3 would be the choice. Given standard Azure exam logic for "minimum," 2 is the technical minimum for connectivity, but 3 is often chosen in practical scenarios to simplify DNS management per VNet.

Explanation:

To deploy the custom application across your division subscriptions using Azure Blueprints, the minimum number of objects required is based on the multi-tenant architecture shown in your table.

Minimum Objects Required

Management groups: 2
Azure Blueprints are bound to the Azure AD tenant level. Since you have two distinct tenants (East.contoso.com and West.contoso.com), you cannot share management group hierarchies between them. You must create at least one management group in each tenant to host the blueprint definitions.

Blueprint definitions: 2
A blueprint definition cannot be shared across Azure AD tenants. Therefore, you must create a separate blueprint definition for the East tenant and another for the West tenant, even if the application configuration inside them is identical.

Blueprint assignments: 4
A blueprint assignment is the link between a blueprint definition and a specific subscription. Since you are deploying the application to all four subscriptions (Sub1, Sub2, Sub3, and Sub4), you must perform four individual assignments (one for each subscription).

Explanation:

Why API-driven inbound provisioning: App1 produces a daily CSV export. The simplest, lowest-effort way to automate provisioning from that CSV is to have a small scheduled process (Logic App, Azure Function, or similar) that reads the CSV and calls the Microsoft Entra provisioning API (the inbound provisioning API). This uses the API-driven inbound provisioning pattern so the HR export becomes the authoritative source and the provisioning service can create or update accounts in Microsoft Entra automatically.

Why the Microsoft Entra Connect provisioning agent as the target endpoint: To provision accounts into the on-premises AD DS domain you must use the Microsoft Entra provisioning agent (installed on a server in your network). The Entra provisioning service uses that agent to securely create and manage objects in AD DS. The same API-driven flow can also create the corresponding cloud user objects in the Microsoft Entra tenant; the agent is required only for the on-premises target.

High-level implementation steps

Create a small scheduled process (Logic App or Azure Function) that reads the daily CSV exported from App1 and transforms rows into provisioning requests.

Call the Microsoft Entra inbound provisioning API (API-driven inbound provisioning) to submit create/update requests for each employee record.

Install and configure the Microsoft Entra Connect provisioning agent in your on-premises environment and register it with the Microsoft Entra provisioning service so the service can provision into AD DS.

Map attributes and configure provisioning rules in the Entra provisioning service so that user objects are created/updated in both the Microsoft Entra tenant and AD DS as required.

Monitor and log provisioning runs and handle errors (duplicates, validation failures) in the scheduled process.

Notes and tradeoffs

This approach minimizes development effort because the only custom work is the small scheduled CSV reader that calls the existing Entra provisioning API; you avoid building a full SCIM endpoint or complex custom connectors.

If App1 can be extended to support SCIM or direct API provisioning in the future, you can replace the CSV-based process with a direct application provisioning integration for a more real-time flow.

Explanation:

Azure Virtual WAN (especially with secured virtual hubs) is the only option that natively satisfies all the stated requirements in a scalable, manageable way.

How It Meets Each Requirement:

P2S VPN connections of mobile users connect automatically to the closest Azure region
Virtual WAN supports a global P2S profile (using Traffic Manager under the hood).
Users download one VPN configuration profile and are automatically routed to the nearest Virtual WAN hub based on their location.

Offices connect to their local Azure region using ExpressRoute
You can deploy a virtual hub in each region (North America + Europe).
Each office connects its local ExpressRoute circuit directly to the regional Virtual WAN hub.

Transitive routing between virtual networks and on-premises networks
Virtual WAN provides full-mesh transitive routing by default (hub-to-hub, VNet-to-VNet, VNet-to-branch, branch-to-branch, ExpressRoute-to-ExpressRoute, etc.).
No manual peering or route table management is needed.

Network traffic between virtual networks filtered by using FQDNs
Deploy Azure Firewall in each virtual hub → turning it into a secured virtual hub.
Use FQDN filtering (application rules) in Azure Firewall policies to filter traffic between VNets.

Why the Other Options Are Incorrect:

B. Azure Route Server + Network Function Manager
Good for advanced routing with NVAs, but does not provide automatic closest-region P2S, built-in ExpressRoute integration, or native FQDN filtering.

C. VNet peering + Application Security Groups
Peering is not transitive by default (requires complex hub-spoke with route tables). No built-in P2S closest-region logic or easy ExpressRoute multi-region design. ASGs only do IP-based filtering, not FQDN.

D. Virtual network gateways + NSGs
Traditional hub-spoke model. No automatic closest-region P2S, poor transitive routing at scale, high management overhead, and NSGs cannot filter by FQDN.

AZ-305 Key Takeaway
For global, multi-region hybrid connectivity with P2S auto-routing, ExpressRoute per region, transitive routing, and advanced security (FQDN filtering), Azure Virtual WAN + Secured Virtual Hubs is the recommended modern architecture.

References:
Azure Virtual WAN Documentation
Secured Virtual Hub
P2S Global Profile

Explanation:

To migrate DB1 to an Azure SQL Managed Instance while meeting all specified requirements, you should choose the following options:

1. Service Tier: Business Critical

Read-Only Workloads: The Business Critical tier includes a built-in Read Scale-Out feature at no extra cost. It uses one of the secondary replicas in its high-availability cluster to handle read-only traffic, allowing you to offload these workloads from the primary replica.

Storage Capacity: This tier supports large storage requirements (up to 16 TB in most regions on modern hardware), which is necessary for your database.

Performance: It offers the highest performance and availability for mission-critical applications compared to the General Purpose tier.

2. Feature: Failover group

Regional Resiliency: Failover groups are the primary mechanism for managing the replication and failover of databases to a different Azure region. This ensures that if an entire region suffers an outage, you can fail over to a secondary instance in a paired region.

Managed Instance Compatibility: While Azure SQL Database supports "Geo-replication," for Azure SQL Managed Instance, the correct and primary feature for regional disaster recovery is the Failover group.

Read-Only Access: Failover groups also provide a secondary read-only listener, which further supports the requirement to offload read-heavy workloads to a different geographical location if desired.

Explanation:

Why this meets the requirements

Supports Azure Hybrid Benefit
The vCore purchasing model is the option that supports Azure Hybrid Benefit for SQL Server licenses, allowing you to apply existing SQL Server licenses (with Software Assurance or eligible subscription) to reduce compute costs.

Minimizes costs for many lightly used databases
An elastic pool lets many single databases share a pool of vCores and memory. Because each business unit only processes transactions during its local business hours, the databases will have non-overlapping peak usage across time zones. Pooling those databases reduces the total provisioned capacity compared to provisioning each database for its own peak, so the elastic pool is more cost-efficient than multiple isolated single databases.

Operational simplicity
Elastic pools are fully managed and reduce administrative overhead for capacity planning across 50 databases compared to managing 50 individually sized databases.

Implementation guidance

Choose vCore General Purpose tier for most business workloads to balance cost and performance. Use Business Critical only if you need low latency I/O or high availability with local SSD.

Create one or more elastic pools and place the 50 databases into the pool. Size the pool’s vCores and storage based on aggregated expected concurrent load across time zones rather than sum of individual peaks.

Apply Azure Hybrid Benefit when provisioning the vCore resources to reduce compute costs.

Monitor and adjust pool sizing with Azure Monitor and SQL insights; scale the pool up or down as usage patterns become clearer. Consider reserved capacity for vCores if you have predictable steady usage to further reduce costs.

Use automation (ARM templates, Bicep, or Terraform) to provision databases into the pool and to manage scaling.

Cost optimization tips

Exploit time-zone stagger: because business hours are staggered globally, you can often size the pool for a much lower aggregate concurrency than the sum of individual peaks.

Use reserved capacity for vCores if long-term usage is predictable to get additional discounts.

Right-size periodically: start with conservative pool sizing, monitor actual CPU and DTU/vCore usage, then reduce or reallocate capacity to avoid overprovisioning.

Why the other options are not ideal

DTU model does not support Azure Hybrid Benefit, so it cannot meet the licensing requirement.

Multiple single databases (even with vCore) forces you to provision each database for its own peak, increasing cost compared to pooling.

Serverless single databases can save cost for sporadic workloads but cannot be used in an elastic pool and would complicate management for 50 databases.

Explanation:

This sequence ensures the three key requirements are met:

Apps can access the storage account after failover → After initiating failover, the secondary region becomes the new primary.

You can fail back to the original location → Reconfiguring GRS after failover re-establishes geo-redundancy with the original primary as the new secondary.

Minimize downtime → Using GRS + customer-initiated failover (planned or unplanned) allows quick promotion of the secondary region.

Why this order?

Step 1 (Before failover): The storage account must be configured for GRS (or RA-GRS) before you can initiate a failover. ZRS is only zone-redundant (same region) and does not enable cross-region failover.

Step 2: Perform the actual failover (customer-managed).

Step 3 (After failover): After failover, the account typically drops to LRS in the new primary region. Re-enabling GRS is required to restore geo-redundancy and enable clean failback later.

Note: Zone-redundant storage (ZRS) options are distractors — they do not support geo-failover.

This is the standard recommended procedure in Microsoft documentation for general-purpose v2 storage accounts in disaster recovery scenarios.

Explanation:


To fulfill the requirements of this scenario, you must establish a private path for data to travel from your virtual machines to the Log Analytics workspace.

Logs Ingestion API & Data Collection: When you use the Logs Ingestion API, data is sent to a Data Collection Endpoint (DCE). By default, these endpoints are reachable over the public internet.

Preventing Internet Access: An Azure Monitor Private Link Scope (AMPLS) allows you to define the boundaries of your monitoring network. It connects a Private Endpoint (a private IP in your VNet) to one or more Azure Monitor resources, such as Workspace1.

The Private Path: Once the AMPLS is configured, traffic from the 1,000 virtual machines to the Logs Ingestion API is routed over the Microsoft backbone network through the private endpoint. You can then configure the access modes on the AMPLS to "Private Only," which effectively blocks any ingestion or query requests coming from the public internet.

Why other options are incorrect:

B. Linked storage account: This is used for features like BYOS (Bring Your Own Storage) for log encryption or certain types of data exports, but it does not provide network isolation for the Logs Ingestion API.

C. Azure Peering Service: This is a networking service that enhances connectivity to Microsoft cloud services (like Microsoft 365) over the public internet. It does not provide the private, non-internet routing required here.

D. Service Connector: This simplifies the connection between two Azure services (e.g., an App Service to a Database), but it is not the standard architectural component used to secure Azure Monitor data ingestion at the workspace level.