Courseiva

AZ-305 Practice Question: Design identity, governance, and monitoring solutions

You are designing a monitoring solution for an Azure function app that processes messages from Azure Service Bus. The function app is critical and must be highly available. You need to monitor for poison messages and trigger an alert when the dead-letter queue count exceeds 100. What should you use?

⚠ Common exam trap

The trap here is that candidates may overthink and choose Log Analytics (Option C) for its querying flexibility, but the question specifically asks for a threshold-based alert on a single metric, which is exactly what Azure Monitor metric alerts are designed for.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Azure Monitor metric alert on the dead-letter message count

Azure Monitor metric alerts can directly monitor the 'Dead-letter message count' metric for a Service Bus namespace or entity. When this count exceeds 100, the alert triggers, enabling automated response to poison messages without additional query overhead. This is the most efficient and native monitoring solution for real-time threshold-based alerts on Service Bus metrics.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✗

    Azure Service Bus Explorer

    Why it's wrong here

    Azure Service Bus Explorer is a standalone desktop tool used by developers/administrators to visually inspect queues, topics, subscriptions, and dead-letter queues. It allows manual browsing and even resubmitting or purging messages, but it is not an automated monitoring service. It has no built-in alerting or notification capability, so it cannot proactively trigger actions when dead-letter counts rise. You would need to open the tool manually to see the count, which defeats the purpose of an automated monitoring solution.

  • ✓

    Azure Monitor metric alert on the dead-letter message count

    Why this is correct

    An Azure Monitor metric alert can directly target the Service Bus namespace and use the 'Deadlettered Messages' metric (available at queue and subscription levels) to detect when messages are routed to the dead-letter queue. This alert can be configured with a threshold (e.g., a count over 100) and a frequency (e.g., every 5 minutes), and it can trigger action groups that send email, SMS, or webhook calls. Metric alerts are low-latency, simple to configure, and do not require diagnostic settings or log ingestion, making them the most direct and efficient way to monitor dead-letter counts in real time. This is the correct choice because it fulfills the requirement to alert proactively without extra layers.

  • ✗

    Azure Log Analytics workspace querying Service Bus logs

    Why it's wrong here

    A Log Analytics workspace can be used to query Service Bus diagnostic logs and metrics (e.g., via the AzureDiagnostics table) to perform deep analysis of dead-lettered messages, including their timestamps, origins, and error patterns. To generate alerts, you would need to write a log search alert rule, which uses KQL, has higher latency than metric alerts, and requires diagnostic settings to be enabled for the namespace (sending logs/metrics to Log Analytics). This approach is more suitable for retrospective troubleshooting and correlation than for a simple threshold-based monitoring alert. While it can technically work, metric alerts are the better architectural choice because they are purpose-built for real-time threshold monitoring and avoid the extra cost and complexity of log ingestion.

  • ✗

    Azure Application Insights availability tests

    Why it's wrong here

    Azure Application Insights availability tests are designed to monitor the availability and responsiveness of web endpoints by sending synthetic HTTP requests from multiple locations. They can detect if a URL returns an error code or if a response exceeds a timeout threshold, which helps identify web service outages or performance degradation. However, they have no direct mechanism to inspect Azure Service Bus queues, their metrics, or dead-letter messages, as those are asynchronous messaging resources accessed via network protocols, not HTTP endpoints. Therefore, availability tests are entirely irrelevant to the requirement of alerting on dead-letter message count and would fail to provide any meaningful signal about queue health.

About these practice questions

This AZ-305 question is part of Courseiva's 795-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This AZ-305 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the AZ-305 exam.