Practice Test #3

Answer: A (Pass). From the exhibit, we can read the relevant details needed to determine allowed state transitions: the Alerts list shows Alert state values (New, Acknowledged, Closed) and the toolbar includes the “Change state” action. That is enough information to answer the sub-questions about whether a given alert instance’s state can be changed and to what. This is a standard Azure Monitor alerts management scenario (not a trick about classic alerts vs. new alerts). The presence of multiple states in the grid and the explicit “Change state” control indicates the portal supports modifying alert state for selected alerts. Therefore, it’s reasonable to proceed and answer rather than fail. Why not B: Choosing Fail would mean you cannot determine the answer, but the screenshot provides the key fields (Alert state and Fired time) required by the prompts.

The Alert1 instance fired at 11:23:52 is currently in the Acknowledged state. In Azure Monitor, alert processing states are workflow states, and an acknowledged alert can be moved either back to New (to reopen/reset handling) or forward to Closed. Therefore, the correct choice is that it can be changed to New or Closed. The other options are incorrect because the alert state is editable, and Acknowledged is not limited to only one next state.

The Alert2 instance fired at 11:23:24 is currently in the Closed state. In Azure Monitor, a closed alert is not terminal; it can be reopened by changing it to New or moved to Acknowledged if someone is taking ownership again. Therefore, the correct answer is New or Acknowledged. The other options are too restrictive because Closed alerts can still have their workflow state updated from the portal.

Yes. VM1 can have Update Management enabled because it is running a supported general-purpose OS (Windows or a supported Linux distribution) as indicated in the table. Enabling Update Management is primarily an onboarding/configuration step: the VM is connected to an Automation account and Log Analytics workspace and the required agent/extension is installed/configured. Since VM1 is running, it can also immediately complete agent installation and begin reporting update compliance. The alternative (No) would only be correct if VM1 were an unsupported OS/image type (for example, a network appliance or an image that cannot run the required agent/extension) or if the scenario explicitly stated blocked outbound connectivity to required Azure endpoints. Neither condition applies here for VM1.

No. VM2 cannot have Update Management enabled because the OS/image type shown for VM2 in the table is not supported by Azure Update Management (classic). Update Management requires a supported Windows/Linux OS that can run the Microsoft Monitoring Agent/Log Analytics agent (or the required VM extension path used by the solution) and can communicate with Azure Automation/Log Analytics. If VM2 is a specialized appliance/locked-down marketplace image (common in these questions), it won’t support the agent/extension model needed for assessment and patch orchestration. Even though VM2 is running, power state does not override OS support requirements. Therefore, “Yes” would be incorrect because the platform cannot onboard an unsupported OS to Update Management.

Yes. VM3 can have Update Management enabled even though it is stopped. This is a frequent exam nuance: enabling/onboarding Update Management is a control-plane configuration that can be applied to an Azure VM regardless of whether it is currently running. What you cannot do while it is stopped is complete real-time assessment, install the agent/extension (if not already present), or execute update deployments—those require the VM to be powered on and able to communicate outbound to Azure endpoints. As long as VM3’s OS in the table is a supported Windows/Linux OS, the correct answer is Yes for enablement. “No” would only be correct if the OS were unsupported or if the question asked whether updates can be deployed while stopped.

Yes. VM4 can have Update Management enabled because it is running a supported OS per the table. With the VM running, onboarding can install/configure the required agent/extension and start collecting update compliance data immediately. Update Management is designed for ongoing patch governance and reporting, which supports the Secure Compute pillar: maintaining OS patch levels, reducing vulnerability exposure, and providing auditability. The “No” option would only apply if VM4 were an unsupported OS/appliance image or if prerequisites were explicitly missing (for example, no connectivity to Azure Automation/Log Analytics endpoints, or policy restrictions preventing extension installation). Given the table indicates a supported VM OS, enabling Update Management is valid.

Storage1 cannot be used. Although Storage1 is in the correct region (East US), its storage account type is listed as “Blob”. In Azure, a BlobStorage account (legacy “Blob” type) is not a supported destination type for Azure SQL Database auditing. SQL auditing requires a supported Azure Storage account type such as General-purpose v1 (Storage) or General-purpose v2 (StorageV2) with standard performance. The access tier (Cool) is not the deciding factor here; tiering applies to blob data lifecycle/cost and does not by itself block auditing. The key issue is the account kind/type. Therefore, even with correct region and resource group, Storage1 is not eligible as an audit log destination.

Storage2 can be used. Storage2 is in East US, which matches SQL1’s region (East US). Region alignment is required for Azure SQL Database auditing to Storage. Additionally, Storage2 is a General purpose v1 account, which is a supported storage account type for SQL auditing. The fact that Storage2 is in a different resource group (RG2) does not prevent its use as an auditing destination. Auditing configuration is based on permissions and supported destination characteristics (region/type), not resource group co-location. Also, the “Access tier (default): Not applicable” is expected for GPv1 accounts and does not affect auditing eligibility. Therefore, Storage2 is a valid audit log destination.

Storage3 cannot be used. Storage3 is a General purpose v2 account (supported type), but it is located in West Europe. SQL1 is in East US. Azure SQL Database auditing to a Storage account requires the storage account to be in the same region as the SQL resource being audited. Even though Storage3 is in the same resource group as SQL1 (RG1), resource group alignment does not override the regional requirement. Cross-region storage destinations are not supported for SQL auditing, and attempting to configure this would fail or be blocked. The access tier (Hot) is not the issue; the region mismatch is. Therefore, Storage3 is not eligible.

Only Storage2 can be used as the audit log destination. Evaluate each storage account against the two main requirements: supported storage account type and same-region placement. - Storage1 (East US) fails because its account type is “Blob” (BlobStorage), which is not supported for Azure SQL auditing destinations. - Storage2 (East US) passes: it is General purpose v1 (supported) and in the same region as SQL1. - Storage3 fails due to region mismatch (West Europe vs East US), even though it is GPv2. Therefore, the correct selection is “Storage2 only.”

Only Analytics1 can be used. Analytics1 is the Log Analytics workspace that matches SQL1 for this auditing configuration scenario. Analytics3 is in West Europe, so it does not match SQL1’s East US region. Analytics2 is not selected as a valid destination in this question, so the correct answer is Analytics1 only.