Professional-level certification covering design of identity, governance, monitoring, data storage, business continuity, and infrastructure solutions on Azure, with a worked explanation on every practice question.
Free sample questions
No account needed. Every question has a worked explanation, just like the full bank.
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
A workload owner reports periodic CPU spikes on Azure VMs and asks for a design that starts from a fleet-wide host signal and drills into in-guest processes. Which design captures both layers and aligns with WAF Operational Excellence?
- ARely on the free host metrics alone and ignore in-guest data because the Azure platform already collects them.
- BKeep host metrics for fleet-wide CPU and enable enhanced monitoring with Azure Monitor Agent for guest visibility.check_circle Correct
- CDisable the host-level metrics path and route only the guest data through Azure Monitor Agent on the VM.
- DUse the legacy Azure Diagnostics Extension on the VM for guest data instead of Azure Monitor Agent.
Host metrics are free fleet-wide signals; enhanced monitoring with Azure Monitor Agent adds the guest-process drill-down. The VM monitoring overview separates host metrics (CPU, network, disk, free) from guest metrics (process and application detail, requires enhanced monitoring). Enabling enhanced monitoring installs Azure Monitor Agent and lights up the Monitor view, which gives the SRE team the host-to-guest drill path.
Why A is wrong: Host metrics do not surface in-guest process or application detail; the SRE team would have no drill-down path.
Why B is correct: Correct. The VM monitoring overview separates host metrics (CPU, network, disk, free) from guest metrics (process and application detail, requires enhanced monitoring).
Why C is wrong: Host metrics provide free fleet-wide load signals; disabling them removes the cheap top-down view.
Why D is wrong: The Azure Diagnostics Extension is a separate older Windows guest tool and is not the documented modern path for VM enhanced monitoring.
Frequently asked questions
- How many questions are on the AZ-305 exam?
- The Designing Microsoft Azure Infrastructure Solutions (AZ-305) (AZ-305) exam has Typically 40 to 60 questions questions and runs for 120 minutes. The format is multiple choice, multiple response, and case studies, at a pearson vue testing center or online proctored.
- What score do I need to pass AZ-305?
- The pass mark is 700 / 1000. Examworthy gives you a per-domain readiness score so you can see which domains are holding you back before you book.
- How much does the AZ-305 exam cost?
- The exam costs 165 USD to sit. Practising on Examworthy is free to start, with a worked explanation on every question.
- How does Examworthy help me prepare for AZ-305?
- Every practice question carries a worked explanation and a per-distractor rationale, mapped to the official blueprint domains. You learn why each answer is right or wrong, not just the letter.
- Is Examworthy affiliated with Microsoft?
- No. Examworthy is not affiliated with or endorsed by Microsoft. Our questions are original, blueprint-aligned practice material; we never reproduce live exam items.
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.
