AZ-104 Monitor and Maintain Azure Resources Practice Question
An administrator enabled diagnostic settings on an Azure Storage account using the resource-specific schema. A coworker then ran a query against AzureDiagnostics and got no rows, even though failed blob writes occurred during the last hour. What is the best fix?
⚠ Common exam trap
Many candidates assume all diagnostic logs land in the AzureDiagnostics table by default, overlooking that the resource-specific schema redirects logs to dedicated tables, leading them to incorrectly choose Option A or fail to query the correct table.
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
✓
Query the storage account's dedicated resource-specific log table and filter for failed write operations.
When a diagnostic setting is configured with the resource-specific schema, Azure routes logs to dedicated tables (e.g., StorageBlobLogs) rather than the legacy AzureDiagnostics table. Querying AzureDiagnostics returns no rows because the logs are not stored there. The correct fix is to query the appropriate resource-specific log table (e.g., StorageBlobLogs) and filter for failed write operations, as this table contains the detailed, schema-specific data for the storage account's blob operations.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Switch the diagnostic setting back to the legacy AzureDiagnostics schema so all logs land there.
Why it's wrong here
Switching back to the legacy AzureDiagnostics schema would require changing the diagnostic setting and waiting for new logs to flow, while any existing logs already written to the resource-specific table remain inaccessible from AzureDiagnostics. More importantly, Microsoft recommends resource-specific mode because it provides a dedicated schema with strongly typed columns; reverting is a config change that adds latency and is not the immediate troubleshooting step you need. The fastest path is to query the StorageBlobLogs (or analogous) table that is already being populated.
When this WOULD be correct
If the diagnostic setting was configured with the 'Send to Log Analytics workspace' destination and the 'AzureDiagnostics' schema (legacy mode), then querying AzureDiagnostics would be correct. This option is correct when the diagnostic setting explicitly uses the legacy schema.
- ✓
Query the storage account's dedicated resource-specific log table and filter for failed write operations.
Why this is correct
When resource-specific diagnostic mode is enabled, logs no longer land in AzureDiagnostics for that resource. The correct action is to query the dedicated storage log table produced by the diagnostic setting, then filter for the failed write status and time window. This aligns the query with the actual schema that is collecting the data.
- ✗
Use the Azure Activity log because blob write failures are always control-plane events.
Why it's wrong here
The Azure Activity log captures only control-plane events such as create, update, or delete operations on the storage account itself — not data-plane I/O like a Put Blob write. A failed blob write is a data-plane operation, so its details, including the specific error code and status, are absent from the Activity log. To see failed writes, you must inspect the resource logs emitted by the storage service, which contain request-level information such as OperationName, StatusText, and response time.
When this WOULD be correct
This option would be correct if the question asked about a control-plane operation, such as 'A user failed to create a new storage account' or 'An administrator deleted a storage account.' In those cases, the Activity log would contain the relevant failure events.
- ✗
Create a metric alert on storage capacity because that metric includes failed requests.
Why it's wrong here
Capacity metrics for Azure Storage report the amount of data stored (for example, BlobCapacity) and reflect utilization over time, not request outcomes. While the Transaction metric does include response types like ClientOtherErrors, setting an alert on capacity will not surface individual failed write operations or pinpoint which storage operation failed. Metrics aggregate values and lack the granular per-request schema (e.g., ObjectKey, AuthenticationType, etc.) needed to diagnose specifically why a write failed.
When this WOULD be correct
If the question asked for a way to be notified when storage account capacity exceeds a threshold (e.g., 80% full), creating a metric alert on the 'Used Capacity' metric would be the correct solution.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The AZ-104 exam frequently reuses these exact scenarios with slightly different constraints.
✓Query the storage account's dedicated resource-specific log table and filter for failed write operations.Correct answer▾
Why this is correct
When resource-specific diagnostic mode is enabled, logs no longer land in AzureDiagnostics for that resource. The correct action is to query the dedicated storage log table produced by the diagnostic setting, then filter for the failed write status and time window. This aligns the query with the actual schema that is collecting the data.
✗Switch the diagnostic setting back to the legacy AzureDiagnostics schema so all logs land there.Wrong answer — click to see why▾
Why this is wrong here
When resource-specific schema is enabled, logs are sent to dedicated tables (e.g., StorageBlobLogs), not to AzureDiagnostics. Querying AzureDiagnostics returns no rows because logs are no longer stored there.
★ When this WOULD be the correct answer
If the diagnostic setting was configured with the 'Send to Log Analytics workspace' destination and the 'AzureDiagnostics' schema (legacy mode), then querying AzureDiagnostics would be correct. This option is correct when the diagnostic setting explicitly uses the legacy schema.
Why candidates choose this
Candidates may be familiar with the legacy AzureDiagnostics table and assume all Azure logs land there, not realizing that resource-specific tables are used when that schema is selected.
✗Use the Azure Activity log because blob write failures are always control-plane events.Wrong answer — click to see why▾
Why this is wrong here
Blob write failures are data-plane events, not control-plane events. The Azure Activity log only captures control-plane operations (e.g., creating a storage account), not data-plane operations like blob writes.
★ When this WOULD be the correct answer
This option would be correct if the question asked about a control-plane operation, such as 'A user failed to create a new storage account' or 'An administrator deleted a storage account.' In those cases, the Activity log would contain the relevant failure events.
Why candidates choose this
Candidates may confuse control-plane and data-plane operations, or mistakenly think that all Azure failures are logged in the Activity log, especially when they are unfamiliar with diagnostic settings and resource-specific tables.
✗Create a metric alert on storage capacity because that metric includes failed requests.Wrong answer — click to see why▾
Why this is wrong here
Metric alerts on storage capacity do not include failed requests; they monitor capacity metrics like used storage. Failed blob writes are data-plane operations logged in diagnostic logs, not captured by capacity metrics.
★ When this WOULD be the correct answer
If the question asked for a way to be notified when storage account capacity exceeds a threshold (e.g., 80% full), creating a metric alert on the 'Used Capacity' metric would be the correct solution.
Why candidates choose this
Candidates may confuse 'metric alerts' with 'log alerts' or think that capacity metrics aggregate all request failures, not realizing that capacity metrics only track storage usage, not operation outcomes.
Analysis generated from the official AZ-104blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Go deeper
Related to this question
Learn chapter
Managed Identities for Azure Resources
Key term
Diagnostic setting
A Diagnostic setting is a configuration in Azure that controls where and how resource logs and metrics are collected, stored, and streamed for monitoring and analysis.
Key term
Storage account
A cloud storage account is a container that holds a set of cloud storage services and their data, providing a unique namespace and access policies for storing and managing unstructured data.
About these practice questions
Courseiva writes every AZ-104 question from scratch — 1,049 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This AZ-104 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-104 exam.