12 real AZ-305 sample questions, each with an explanation of why every option is right or 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
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 Identity, Governance, and Monitoring Solutionsmedium
Your Azure Monitor estate ingests about 60 GB per day of operational data and about 50 GB per day of Microsoft Sentinel data into two separate Log Analytics workspaces. Finance asks you to recommend a design change that lowers ingestion cost without breaking the WAF Cost Optimization commitment to the workload. Which option should you propose?
- AMerge both workloads into one Log Analytics workspace on the 100 GB per day commitment tier.check_circle Correct
- BMove Microsoft Sentinel data to Azure Storage immutable containers and query it on demand.
- CKeep both workspaces and set each one to the 100 GB per day commitment tier independently.
- DExport both workspaces to Azure Data Explorer and decommission the Log Analytics workspaces.
Combining workloads to reach 100 GB per day unlocks Azure Monitor and Sentinel commitment-tier discounts. The design guidance gives the canonical 50+50 example: combining operational and security data into one workspace lets the customer hit the 100 GB per day commitment tier, with a documented 15 percent Azure Monitor discount and 50 percent Sentinel discount. Sentinel-enabled workspaces also extend retention to three months at no extra cost.
Why A is correct: Correct. The design guidance gives the canonical 50+50 example: combining operational and security data into one workspace lets the customer hit the 100 GB per day commitment tier, with a documented 15 percent Azure Monitor discount and 50 percent Sentinel discount.
Why B is wrong: Storage is a destination for archive use cases; it does not run KQL natively and breaks the Sentinel analytics, hunting, and incident experience.
Why C is wrong: Commitment tiers commit to a per-workspace daily volume; neither workspace reaches 100 GB alone, so commitment-tier discounts cannot be claimed twice.
Why D is wrong: ADX is a valid long-term store, but losing the Log Analytics workspace removes Sentinel native ingest, alert rules, and workbook templates.
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
An OLTP workload on Azure SQL Database is projected to reach 60 TB within 18 months and needs near-instant database restores regardless of size. Backup and restore SLAs are tighter than the storage-copy times observed today on Business Critical. Which Azure SQL Database service tier best satisfies the size and restore constraints?
- AProvision a Hyperscale database with the required number of HA replicas.check_circle Correct
- BProvision a Business Critical database at the maximum vCore configuration.
- CProvision a General Purpose database at the maximum vCore configuration.
- DProvision a Premium DTU database sized at the highest available DTU level.
Hyperscale is the only Azure SQL Database tier that scales to 128 TB with snapshot-based restore that is fast regardless of database size. Hyperscale separates compute, the log service, page servers, and Azure Storage, so storage scales to 128 TB independently of compute. Backups are storage snapshots that complete in seconds regardless of database size, and restores reuse those snapshots, satisfying the size ceiling and fast-restore SLA at the same time.
Why A is correct: Correct. Hyperscale separates compute, the log service, page servers, and Azure Storage, so storage scales to 128 TB independently of compute.
Why B is wrong: Business Critical caps at 4 TB of data per database, well below the 60 TB target, and restore time grows with database size because storage is integrated with compute.
Why C is wrong: General Purpose caps at 4 TB and depends on Azure Premium remote storage with 5-10 ms latency; it cannot reach 60 TB and does not deliver fast snapshot-based restore.
Why D is wrong: The Premium DTU tier caps at 4 TB and does not offer the decoupled storage architecture that enables size-independent backup and restore.
lock_openFree sampleDesign Business Continuity Solutionsmedium
You are sizing Azure SQL Database HADR for a workload tracked under the WAF Reliability pillar that requires zero data loss in-region, less-than-one-minute RTO across regions, and a low-cost option for non-critical databases that tolerates minutes-to-hours RTO. Which three options match the documented HADR table? (Select 3 answers)
- AZone redundancy provides RTO typically less than 30 seconds and RPO 0 for in-region high availability.check_circle Correct
- BFailover groups with customer-managed policy provide RTO typically less than 60 seconds, RPO at or above 0.check_circle Correct
- CGeo-restore provides RTO typically minutes or hours and RPO typically minutes or hours dependent on backup size.check_circle Correct
- DActive geo-replication provides an RTO of 24 hours and an RPO of 24 hours across every Azure SQL Database tier.
- ESingle-database PITR provides an RTO of less than 5 seconds and an RPO of 0 across any regional outage.
Zone-redundant HA, failover groups, and geo-restore are three distinct RTO/RPO tiers in the SQL HADR table. The Azure SQL HADR comparison table lists three tiers: zone redundancy at typically <30s RTO and RPO 0; failover groups (or active geo-replication) at typically <60s RTO and RPO 0+; geo-restore at typically minutes-to-hours for both RTO and RPO. Each maps cleanly to one of the design constraints in the stem.
Why A is correct: Correct. Zone redundancy provides RTO typically less than 30 seconds and RPO 0 for in-region high availability is one of the keyed answers. The Azure SQL HADR comparison table lists three tiers: zone redundancy at typically <30s RTO and RPO 0; failover groups (or active geo-replication) at typically <60s RTO and RPO 0+; geo-restore at typically minutes-to-hours for both RTO and RPO.
Why B is correct: Correct. Failover groups with customer-managed policy provide RTO typically less than 60 seconds, RPO at or above 0 is one of the keyed answers. The Azure SQL HADR comparison table lists three tiers: zone redundancy at typically <30s RTO and RPO 0; failover groups (or active geo-replication) at typically <60s RTO and RPO 0+; geo-restore at typically minutes-to-hours for both RTO and RPO.
Why C is correct: Correct. Geo-restore provides RTO typically minutes or hours and RPO typically minutes or hours dependent on backup size is one of the keyed answers. The Azure SQL HADR comparison table lists three tiers: zone redundancy at typically <30s RTO and RPO 0; failover groups (or active geo-replication) at typically <60s RTO and RPO 0+; geo-restore at typically minutes-to-hours for both RTO and RPO.
Why D is wrong: Active geo-replication is a continuous-replication option with sub-60-second RTO targets, not a 24/24 design point.
Why E is wrong: Point-in-time restore is for accidental-deletion recovery, not a region-outage RTO/RPO option in the HADR table.
lock_openFree sampleDesign Business Continuity Solutionshard
Your design enables Cosmos DB multiple write regions on the Business Critical tier with a WAF Reliability pillar RPO target under 15 minutes and an RTO under 5 minutes. Which three documented behaviours apply to this configuration? (Select 3 answers)
- AStrong consistency cannot be configured when multiple write regions are enabled on the account.check_circle Correct
- BNo downtime is expected provided SDKs target PreferredRegions or ApplicationRegions correctly.check_circle Correct
- CSession, consistent prefix, and eventual consistency tolerate under 15 minutes of data loss on region failure.check_circle Correct
- DWrite conflicts cannot occur because Cosmos automatically locks the global partition during each write.
- EMulti-write region accounts rely on availability zones to deliver an RPO of 0 during any region outage.
Multi-write Cosmos drops Strong consistency, expects no downtime with SDK preferences set, and has <15-minute RPO for Session/Prefix/Eventual. Cosmos DB reliability documentation states multi-write configurations do not support strong consistency, have no expected downtime when SDKs are configured with PreferredRegions or ApplicationRegions, and have a less-than-15-minute RPO for Session/prefix/eventual during a region failure. Write conflicts are possible by design.
Why A is correct: Correct. Strong consistency cannot be configured when multiple write regions are enabled on the account is one of the keyed answers. Cosmos DB reliability documentation states multi-write configurations do not support strong consistency, have no expected downtime when SDKs are configured with PreferredRegions or ApplicationRegions, and have a less-than-15-minute RPO for Session/prefix/eventual during a region failure.
Why B is correct: Correct. No downtime is expected provided SDKs target PreferredRegions or ApplicationRegions correctly is one of the keyed answers. Cosmos DB reliability documentation states multi-write configurations do not support strong consistency, have no expected downtime when SDKs are configured with PreferredRegions or ApplicationRegions, and have a less-than-15-minute RPO for Session/prefix/eventual during a region failure.
Why C is correct: Correct. Session, consistent prefix, and eventual consistency tolerate under 15 minutes of data loss on region failure is one of the keyed answers. Cosmos DB reliability documentation states multi-write configurations do not support strong consistency, have no expected downtime when SDKs are configured with PreferredRegions or ApplicationRegions, and have a less-than-15-minute RPO for Session/prefix/eventual during a region failure.
Why D is wrong: Cosmos documentation explicitly states that with multiple write regions, write conflicts might arise; there is no global partition lock.
Why E is wrong: Strong consistency (which gives RPO 0) is unavailable in multi-write configurations; multi-write does not deliver RPO 0 during a region outage.
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.
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.
