12 real AZ-305 sample questions, each with a worked explanation and a rationale for every option, right and wrong. No account, no card. This is the reasoning the AZ-305 tests: knowing why the tempting answer is wrong, not just spotting the right one.
The real AZ-305 is Typically 40 to 60 questions questions in 120 minutes, pass mark 700 / 1000. For a domain-by-domain breakdown and a study plan, read the AZ-305 study guide. The full bank has 258 questions.
lock_openFree sampleDesign Infrastructure Solutionsmedium
A team migrates a 12-minute end-of-day report function from on-premises to Azure Functions. The current draft uses the legacy Consumption plan. What is the documented maximum function timeout on that plan?
- AUnbounded execution duration up to 60 minutes on the Consumption plan.
- B10 minutes maximum on the Consumption plan, with a 5-minute default.check_circle Correct
- C30 minutes maximum on the Consumption plan, matching other serverless plans.
- D230 seconds maximum on any HTTP-triggered Function regardless of plan.
Legacy Consumption tops out at 10 minutes per execution; everything longer needs Flex Consumption, Premium, or Dedicated. The Functions hosting comparison table lists the legacy Consumption plan with a 5-minute default and 10-minute maximum timeout. A 12-minute job will not fit and the team should choose Flex Consumption, Premium, or Dedicated for an unbounded timeout.
Why A is wrong: Unbounded execution is documented for Flex Consumption, Premium, Dedicated, and Container Apps, not the legacy Consumption plan.
Why B is correct: Correct. The Functions hosting comparison table lists the legacy Consumption plan with a 5-minute default and 10-minute maximum timeout.
Why C is wrong: 30 minutes is the default timeout on the other plans, not the maximum on Consumption.
Why D is wrong: 230 seconds is the HTTP-trigger response limit imposed by the Azure Load Balancer; it is not the overall function timeout for non-HTTP triggers.
lock_openFree sampleDesign Infrastructure Solutionshard
A team must run a Functions workload with an unbounded execution timeout and predictable monthly billing on an existing App Service plan. What configuration is required to achieve the unbounded timeout in that hosting mode?
- ASet the functionTimeout setting in host.json to an empty string.
- BEnable Always On on the App Service plan that hosts the function app.check_circle Correct
- CConvert the App Service plan to Isolated to remove the timeout cap.
- DSwitch the function app to the legacy Consumption plan and disable cold start.
Dedicated-plan Functions need Always On to get the unbounded execution timeout. On the Dedicated (App Service) plan, the Functions hosting documentation says the maximum timeout is unbounded but requires Always On to be enabled (with a 10-minute grace period during platform updates). Without Always On, the function host can idle out and break long-running workloads.
Why A is wrong: host.json controls timeout values within plan limits; it does not bypass the platform's Always-On requirement on the Dedicated plan.
Why B is correct: Correct. On the Dedicated (App Service) plan, the Functions hosting documentation says the maximum timeout is unbounded but requires Always On to be enabled (with a 10-minute grace period during platform updates).
Why C is wrong: Isolated is the ASE plan family; the unbounded timeout is governed by Always On, not by the plan tier.
Why D is wrong: Consumption is the plan with the hard 10-minute maximum; switching to it makes the timeout worse, not better, and Consumption has no Always-On switch.
lock_openFree sampleDesign Infrastructure Solutionsmedium
A team plans a Batch pool that will burst to 1,200 dedicated cores. What is the documented default core limit they need to raise to support that target?
- A200 dedicated cores and 200 low-priority cores per Batch account by default.
- B900 dedicated cores and 100 low-priority cores per Batch account by default.check_circle Correct
- C5,000 dedicated cores and 5,000 low-priority cores per Batch account by default.
- D1,500 dedicated cores and 500 low-priority cores per Batch account by default.
Batch default quota is 900 dedicated and 100 low-priority cores per account; raise via support. The Batch overview and the compute decision tree both list the default core limit as 900 dedicated cores and 100 low-priority cores. Both limits can be raised through a support request, which is what the team needs to do to reach 1,200 dedicated cores.
Why A is wrong: Those numbers do not match the documented Batch defaults; the canonical pair is 900 dedicated and 100 low-priority.
Why B is correct: Correct. The Batch overview and the compute decision tree both list the default core limit as 900 dedicated cores and 100 low-priority cores.
Why C is wrong: 5,000 is the AKS node cap on Standard/Premium tier; it is not the Batch core limit.
Why D is wrong: Those are not the documented Batch default limits; the canonical pair is 900 dedicated and 100 low-priority.
lock_openFree sampleDesign Identity, Governance, and Monitoring Solutionsmedium
Your organisation is deploying an AI agent on Microsoft Foundry and wants end-to-end observability of token consumption, latency, error rates, and quality scores aligned to WAF Performance Efficiency. Which design path should you recommend?
- AWire Foundry traces directly to a Log Analytics workspace and skip Application Insights entirely.
- BStart tracing in Foundry, then add Azure Monitor OpenTelemetry Distro with the Foundry SDK.check_circle Correct
- CUse the JavaScript SDK alongside the Foundry SDK to capture agent traces in the browser layer.
- DRun a self-hosted Microsoft Agent Framework instance for tracing instead of using Application Insights.
Foundry-hosted agents use Foundry tracing plus the OpenTelemetry Distro with the Foundry SDK. The Application Insights documentation describes the managed-hosting (Azure AI Foundry) path as starting with tracing setup in Foundry, then using the Azure Monitor OpenTelemetry Distro with the Foundry SDK for app-side instrumentation. Application Insights provides built-in dashboards that surface token consumption, latency, error rates, and quality scores.
Why A is wrong: Application Insights is the documented unified experience for AI-agent observability across Foundry, Copilot Studio, and third-party frameworks; bypassing it forfeits the prebuilt agent dashboards.
Why B is correct: Correct. The Application Insights documentation describes the managed-hosting (Azure AI Foundry) path as starting with tracing setup in Foundry, then using the Azure Monitor OpenTelemetry Distro with the Foundry SDK for app-side instrumentation.
Why C is wrong: The JavaScript SDK is a browser path that does not capture server-side agent traces or Foundry SDK signals.
Why D is wrong: The Microsoft Agent Framework is the documented self-hosting path; for Foundry-hosted agents, the unified APM experience lives in Application Insights.
lock_openFree sampleDesign Identity, Governance, and Monitoring Solutionsmedium
Which scenarios justify creating an additional Log Analytics workspace rather than consolidating into a single shared workspace? (Select 3 answers)
- ATwo business units must be billed separately and already sit in different subscriptions.check_circle Correct
- BOperational data in the same table must follow different retention policies per source.check_circle Correct
- CThe customer has two Microsoft Entra tenants and most data sources target the same tenant only.check_circle Correct
- DThe current Log Analytics workspace receives 9 GB per day and the team wants to pay less per GB.
- ETwo AKS clusters in the same region collect container logs and Prometheus metrics for one team.
Per-tenant residency, per-source retention divergence in the same table, and split billing are documented multi-workspace drivers. The design-criteria table lists separate billing (subscription split), per-source retention differences in the same table, and per-tenant residency among the documented drivers for adding workspaces. Cost arbitrage below the 100 GB per day commitment-tier threshold and routine shared-region tooling are not on the list.
Why A is correct: Correct. Two business units must be billed separately and already sit in different subscriptions is one of the keyed answers. The design-criteria table lists separate billing (subscription split), per-source retention differences in the same table, and per-tenant residency among the documented drivers for adding workspaces.
Why B is correct: Correct. Operational data in the same table must follow different retention policies per source is one of the keyed answers. The design-criteria table lists separate billing (subscription split), per-source retention differences in the same table, and per-tenant residency among the documented drivers for adding workspaces.
Why C is correct: Correct. The customer has two Microsoft Entra tenants and most data sources target the same tenant only is one of the keyed answers. The design-criteria table lists separate billing (subscription split), per-source retention differences in the same table, and per-tenant residency among the documented drivers for adding workspaces.
Why D is wrong: Commitment tiers start at 100 GB per day; at 9 GB per day, splitting workspaces does not unlock a discount and adds management overhead.
Why E is wrong: Container Insights and managed Prometheus from multiple clusters can share a single Log Analytics workspace and a single Azure Monitor workspace without conflict.
lock_openFree sampleDesign Identity, Governance, and Monitoring Solutionsmedium
An architect is designing the Log Analytics topology for a workload that runs entirely in one Microsoft Entra tenant and one Azure region with no regulated data residency. Operations and security teams share ownership and want WAF Operational Excellence pillar OE:07 satisfied with the least management overhead. Which workspace design should you recommend?
- AProvision one shared Log Analytics workspace and use table-level RBAC where needed.check_circle Correct
- BProvision a dedicated workspace per resource type and federate queries across them.
- CProvision a workspace per subscription so billing splits cleanly between platform and workload owners.
- DProvision separate workspaces for operational and security data in different regions for resilience.
Start with one Log Analytics workspace; only split when a documented design criterion forces it. The Log Analytics workspace design guidance states the design should always start with a single workspace and add more only when a documented driver (regulatory region, billing split, retention divergence, tenant boundary) applies. None of those drivers are present here, so the lowest-overhead WAF-aligned answer is a single workspace with table-level RBAC where ownership boundaries need enforcement.
Why A is correct: Correct. The Log Analytics workspace design guidance states the design should always start with a single workspace and add more only when a documented driver (regulatory region, billing split, retention divergence, tenant boundary) applies.
Why B is wrong: Per-resource-type workspaces explode operational overhead and complicate cross-table joins without satisfying any of the documented design criteria.
Why C is wrong: Split billing is a valid driver only when separate billing parties exist; the scenario describes one workload with no billing split.
Why D is wrong: Multi-region resilience is a separate design driver and adds egress and management cost when the workload runs in a single region without that requirement.
lock_openFree sampleDesign Data Storage Solutionshard
A financial-services architect is configuring failover-group policy for a mission-critical Azure SQL Database deployment. Internal recovery procedures require humans to make the call to fail over so business continuity owners stay in control of timing. Which failover policy aligns with this requirement?
- ASet the failover policy to Microsoft-managed (automatic) with the default grace period.
- BSet the failover policy to customer-managed (manual) and document the human-driven runbook.check_circle Correct
- CSet the failover policy to Microsoft-managed with a zero-hour grace period for fastest failover.
- DDisable failover groups and rely on per-database active geo-replication failovers.
Customer-managed failover policy is the recommended default; Microsoft-managed only fires for widespread regional outages. Customer-managed failover keeps the decision with the customer; the documentation explicitly recommends this policy so the business retains control over when failover happens. Microsoft-managed failover triggers only during widespread regional outages and only after the grace period, and it removes that control.
Why A is wrong: Microsoft-managed failover only triggers during widespread regional outages and removes human control over when failover happens, contrary to the requirement.
Why B is correct: Correct. Customer-managed failover keeps the decision with the customer; the documentation explicitly recommends this policy so the business retains control over when failover happens.
Why C is wrong: A zero-hour grace period still hands the failover decision to Microsoft; the requirement is human-controlled timing.
Why D is wrong: Active geo-replication failover is also manual but loses the listener endpoint and the group abstraction that the architect explicitly relies on.
lock_openFree sampleDesign Data Storage Solutionshard
A primary Azure SQL Database is provisioned at P6 (1,000 DTU) and sustains 50 percent log I/O. To prevent the system from throttling the primary's transaction-log rate, what is the minimum geo-secondary compute size you should configure?
- AProvision the geo-secondary at P1 (125 DTU) and accept higher replication lag.
- BProvision the geo-secondary at P4 (500 DTU) or higher to absorb the sustained log I/O.check_circle Correct
- CProvision the geo-secondary at S0 (10 DTU) since secondaries do not run user reads.
- DMatch the geo-secondary to P6 (1,000 DTU) since geo-secondaries must mirror the primary exactly.
Geo-secondary minimum compute is the primary's compute multiplied by sustained log-I/O percentage; under-sizing throttles the primary. The documented log-I/O estimation says the geo-secondary minimum is the primary's compute scaled by the sustained log-write percentage. For a P6 primary at 50 percent log I/O, the secondary must be at least P4 (500 DTU). An under-provisioned secondary triggers HADR throttling and causes the primary's log rate to be limited until the secondary catches up.
Why A is wrong: A 125-DTU secondary is far below the half-the-primary heuristic and will throttle the primary's log rate as soon as the secondary cannot keep up.
Why B is correct: Correct. The documented log-I/O estimation says the geo-secondary minimum is the primary's compute scaled by the sustained log-write percentage.
Why C is wrong: Standard service tiers cannot pair with a Premium primary; both replicas must share the same service tier.
Why D is wrong: Geo-secondaries must share the service tier; the documented minimum is half the DTUs when log I/O is sustained at 50 percent, not a strict match.
lock_openFree sampleDesign Data Storage Solutionsmedium
A compliance policy requires that monthly Azure SQL Database backups be retained for seven years. The current configuration retains only the default seven days of point-in-time backups. Which feature should be configured to meet the seven-year retention requirement?
- AIncrease the point-in-time-restore retention to the maximum 35 days.
- BEnable long-term retention (LTR) and configure a yearly retention policy on the database.check_circle Correct
- CSwitch backup storage redundancy from LRS to RA-GRS for cross-region durability.
- DExport a `.bacpac` to Blob storage manually each month and document the location.
PITR is 1 to 35 days; LTR extends retention up to 10 years for compliance windows. PITR retention is capped at 35 days. Long-term retention extends retention for full backups up to 10 years, with configurable weekly, monthly, and yearly retention policies stored in Azure Blob storage. LTR is the documented mechanism for multi-year compliance retention on Azure SQL Database.
Why A is wrong: PITR retention caps at 35 days and does not satisfy a seven-year requirement.
Why B is correct: Correct. PITR retention is capped at 35 days.
Why C is wrong: Storage redundancy changes data placement but does not extend the retention window beyond the configured PITR period.
Why D is wrong: Manual exports are not the platform feature designed for this use case and lose the integrated restore experience that LTR retains.
lock_openFree sampleDesign Business Continuity Solutionsmedium
A workload owner asks you to tighten ASR's crash-consistent recovery-point cadence from every 5 minutes to every 60 seconds to meet a tighter internal RPO target. The application can tolerate an RTO of 30 minutes. Which response matches the documented ASR design?
- ALower the crash-consistent recovery-point frequency to 60 seconds on the replication policy and reapply it to the protected items.
- BDecline the request; ASR creates crash-consistent recovery points every five minutes and the setting cannot be modified.check_circle Correct
- CSwitch the workload to Hyper-V replication, where Azure Site Recovery supports a 30-second crash-consistent interval for Azure VM A2A.
- DConfigure multi-VM consistency on the replication group; that overrides the five-minute crash-consistent default.
ASR crash-consistent recovery points are fixed at five minutes; only app-consistent cadence is configurable. The ASR documentation states that crash-consistent recovery points are created every five minutes by default and that this setting cannot be modified. Workloads needing tighter cadence must look beyond ASR replication policy settings.
Why A is wrong: The crash-consistent five-minute interval is fixed; only app-consistent snapshot frequency and recovery-point retention are configurable on the replication policy.
Why B is correct: Correct. The ASR documentation states that crash-consistent recovery points are created every five minutes by default and that this setting cannot be modified.
Why C is wrong: The 30-second cadence applies to Hyper-V-to-Azure (H2A) replication, not to Azure VM A2A; mixing the two breaks the AZ-305 design.
Why D is wrong: Multi-VM consistency only synchronises recovery points across machines in the group; it does not change the underlying crash-consistent interval.
lock_openFree sampleDesign Business Continuity Solutionshard
A SQL transaction processing VM sustains 80 MB/s of data churn and the workload owner wants A2A protection with an RPO of 5 minutes and RTO of 30 minutes to satisfy the WAF Reliability pillar. Which Azure Site Recovery capability enables the design?
- ASwitch the replication policy to the Premium tier; the default tier caps churn at 25 MB/s and Premium raises it to 100 MB/s.
- BEnable Azure Site Recovery High Churn so the VM can be protected with data churn up to 100 MB/s.check_circle Correct
- CPair ASR with Azure Backup to offload the high-churn change feed into the Recovery Services vault during replication.
- DReduce the cache storage account replication from GRS to LRS to free I/O headroom for higher churn.
ASR High Churn enables A2A for VMs with data churn up to 100 MB/s. The ASR documentation states that Azure Site Recovery has an option of High Churn, enabling disaster recovery for Azure VMs with data churn up to 100 MB/s. This is the documented design path for I/O-intensive workloads that would otherwise exceed standard A2A limits.
Why A is wrong: ASR does not have replication-policy tiers labelled Premium or Default; the documented capability for high-churn workloads is the High Churn option.
Why B is correct: Correct. The ASR documentation states that Azure Site Recovery has an option of High Churn, enabling disaster recovery for Azure VMs with data churn up to 100 MB/s.
Why C is wrong: Azure Backup does not extend ASR's churn ceiling; the two services are independent in this design.
Why D is wrong: Cache storage redundancy choice does not unlock the High Churn behaviour; the High Churn option is the documented mechanism.
lock_openFree sampleDesign Business Continuity Solutionsmedium
Your three-tier application replicates through ASR A2A with multi-VM consistency enabled to keep web, app, and database tiers crash-consistent against an RPO of 5 minutes. Which network configuration is required between the protected VMs?
- AAllow outbound traffic on port 443 only; multi-VM consistency reuses the standard ASR Mobility service channel.
- BAllow outbound traffic on port 20004 between the VMs in the replication group, including Linux VMs that need it opened manually.check_circle Correct
- CAllow outbound traffic on port 9354 to the Service Bus endpoint between the VMs to synchronise the replication group.
- DAllow outbound traffic on port 5671; AMQP-secure carries the multi-VM consistency heartbeat between protected VMs.
Multi-VM consistency requires port 20004 outbound between protected VMs. The A2A architecture page states that if multi-VM consistency is enabled, machines in the replication group communicate over port 20004 and that firewalls must not block this. Linux VMs in the group require port 20004 to be opened manually in line with the distribution's guidance.
Why A is wrong: Port 443 covers Mobility-service-to-ASR-service traffic, but multi-VM consistency uses port 20004 for inter-VM coordination inside the replication group.
Why B is correct: Correct. The A2A architecture page states that if multi-VM consistency is enabled, machines in the replication group communicate over port 20004 and that firewalls must not block this.
Why C is wrong: Port 9354 covers Service Bus AMQP, not the multi-VM consistency channel; the documented port is 20004.
Why D is wrong: 5671 is not the documented multi-VM consistency port; 20004 is.
Examworthy is not affiliated with or endorsed by Microsoft. All questions are original, blueprint-aligned practice material. We never reproduce live exam items. AZ-305 and related marks belong to their respective owners.
