|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.manage-monitoring-ai-ready-infrastructure.knowledge-check |
| 3 | +title: "Module assessment" |
| 4 | +metadata: |
| 5 | + title: "Knowledge check" |
| 6 | + description: "Test your understanding of Azure Monitor implementation by answering these scenario-based questions. Consider how you would apply monitoring concepts to real-world infrastructure management challenges." |
| 7 | + ms.date: 02/02/2026 |
| 8 | + author: wwlpublish |
| 9 | + ms.author: bradj |
| 10 | + ms.topic: unit |
| 11 | + module_assessment: false |
| 12 | +durationInMinutes: 5 |
| 13 | +content: "Choose the best response for each of the following questions." |
| 14 | +quiz: |
| 15 | + questions: |
| 16 | + - content: "Your operations team manages 50 virtual machines running AI training workloads. You need to track memory usage inside the VMs to detect when training processes consume excessive resources. Which metric collection method provides the visibility you require?" |
| 17 | + choices: |
| 18 | + - content: "Platform metrics collected automatically by Azure Monitor, which include memory available bytes for all virtual machines" |
| 19 | + isCorrect: false |
| 20 | + explanation: "Incorrect. Platform metrics don't include memory usage inside the virtual machine's operating system—they only track resource consumption at the Azure infrastructure level like CPU percentage and disk IOPS." |
| 21 | + - content: "Guest OS metrics collected by the Azure Diagnostics extension installed on each virtual machine" |
| 22 | + isCorrect: true |
| 23 | + explanation: "Correct. Guest OS metrics provide visibility into memory usage and process-level performance counters. The Azure Diagnostics extension must be installed on each VM to collect these metrics." |
| 24 | + - content: "Custom metrics published from your training application using the Application Insights SDK" |
| 25 | + isCorrect: false |
| 26 | + explanation: "Incorrect. Custom metrics would work but require modifying your training application code to publish metrics, adding unnecessary complexity when guest OS metrics provide the needed data automatically once the diagnostics extension is installed." |
| 27 | + - content: "You create an alert rule that fires when storage account transaction latency exceeds 500 milliseconds. During testing, you notice the alert fires briefly every hour during backup operations, generating notifications your team ignores. How should you reduce alert fatigue while maintaining visibility into genuine latency issues?" |
| 28 | + choices: |
| 29 | + - content: "Increase the latency threshold to 1000 milliseconds and reduce the evaluation frequency to 15 minutes" |
| 30 | + isCorrect: false |
| 31 | + explanation: "Incorrect. Increasing the threshold to 1000 milliseconds would hide real latency issues that occur between 500-1000ms, potentially missing performance degradation that affects user experience." |
| 32 | + - content: "Create an alert processing rule that suppresses notifications during the 10-minute backup window each hour" |
| 33 | + isCorrect: true |
| 34 | + explanation: "Correct. An alert processing rule with time-based suppression eliminates notifications for expected latency spikes during backups while preserving the alert rule for genuine performance problems outside the backup window." |
| 35 | + - content: "Disable the alert rule entirely and rely on user reports to detect storage performance problems" |
| 36 | + isCorrect: false |
| 37 | + explanation: "Incorrect. Disabling the alert entirely removes proactive monitoring, forcing your team into reactive mode where storage problems surface only after users complain, increasing mean time to detection and business impact." |
| 38 | + - content: "After receiving an alert about high CPU usage on a virtual machine, you need to identify which process consumed the most resources during the spike. Which Kusto Query Language (KQL) query pattern provides this information?" |
| 39 | + choices: |
| 40 | + - content: "Query the AzureDiagnostics table filtering for Level equals 'Error' to find failures that caused the CPU spike" |
| 41 | + isCorrect: false |
| 42 | + explanation: "Incorrect. The AzureDiagnostics table contains error logs but doesn't provide process-level performance data—errors might correlate with high CPU but won't tell you which process was responsible." |
| 43 | + - content: "Query the Perf table filtering for CounterName equals '% Processor Time' and summarize by process name" |
| 44 | + isCorrect: true |
| 45 | + explanation: "Correct. Querying the Perf table for processor time counters by process name provides the granular resource consumption data needed to identify which specific process caused the CPU spike." |
| 46 | + - content: "Query the SecurityEvent table to detect unauthorized access attempts that might have triggered resource-intensive operations" |
| 47 | + isCorrect: false |
| 48 | + explanation: "Incorrect. The SecurityEvent table tracks authentication and access events, useful for security investigations but irrelevant for diagnosing resource consumption patterns that cause CPU saturation." |
0 commit comments