4 of the 13 questions we have for this objective, shown with the answer and the reasoning.
Implement security for servers and virtual machines (VMs)
Vireo Payments processes card data on a VM named vm-hsm-proxy. A new regulatory requirement states that the VM's memory must be encrypted and isolated from the hypervisor and from Microsoft operators, and that the OS disk encryption key must be released only to that VM's trusted execution environment after attestation, using a key the company controls in Azure Key Vault Premium. The team will redeploy the VM to meet the requirement.
What should you deploy?
- AA Trusted launch VM with encryption at host enabled and a disk encryption set with a customer-managed key.Trusted launch protects the boot chain but does not encrypt memory or isolate it from the hypervisor, and encryption at host keys are not bound to VM attestation.
- BA confidential VM (for example a DCasv5-series size) with confidential OS disk encryption, using a disk encryption set with encryption type ConfidentialVmEncryptedWithCustomerKey that references an exportable RSA-HSM key with a release policy in Key Vault Premium.Confidential VMs run on AMD SEV-SNP or Intel TDX hardware that encrypts memory, and confidential OS disk encryption binds the disk key to the VM's TPM so the customer key is released only after successful attestation.
- CA Trusted launch VM with Azure Disk Encryption using a key encryption key in Key Vault Premium.Azure Disk Encryption encrypts the disk inside the guest but has no attestation-based key release and does not address memory encryption.
- DA confidential VM with a disk encryption set of type EncryptionAtRestWithCustomerKey.That encryption type applies ordinary server-side encryption with a customer key; it does not provide confidential OS disk encryption bound to the VM's trusted execution environment.
Why: The security type decision follows the threat model. Trusted launch addresses boot integrity; confidential VMs go further by running in a hardware-based trusted execution environment that encrypts memory and isolates it from the hypervisor and the cloud operator. Confidential OS disk encryption extends this to the OS disk: the disk key is bound to the VM's vTPM and, when a customer-managed key is used, the disk encryption set must use the ConfidentialVmEncryptedWithCustomerKey type with an exportable RSA-HSM key in Key Vault Premium or Managed HSM that carries a secure key release policy. The traps are mixing standard customer-managed key types with a confidential VM, or assuming Trusted launch plus disk encryption meets a memory-isolation requirement.
Implement security for servers and virtual machines (VMs)
Dunmore Textiles has 300 Windows Server and Linux machines in two on-premises datacenters. The company wants to apply Azure Policy, Azure Machine Configuration, and Microsoft Defender for Servers to these machines exactly as it does for Azure VMs. The onboarding must be automated through the existing configuration management tool and must use a non-interactive identity that holds the least privilege needed to connect machines.
Which two actions should you perform? Each correct answer presents part of the solution.
- ARegister the Microsoft.HybridCompute, Microsoft.GuestConfiguration, and Microsoft.HybridConnectivity resource providers in the target subscription.Azure Arc-enabled servers depend on these resource providers being registered in the subscription before the Connected Machine agent can create the machine resources.
- BCreate a service principal, assign it the Azure Connected Machine Onboarding role on the target resource group, and run the generated onboarding script that installs the Azure Connected Machine agent with azcmagent connect.The Azure Connected Machine Onboarding role grants only the permissions needed to connect machines, and the script with the service principal supports non-interactive, at-scale onboarding through a configuration management tool.
- CInstall the Azure Monitor Agent on each machine and point it at a Log Analytics workspace.The Azure Monitor Agent collects telemetry but does not project the machine into Azure Resource Manager; without the Connected Machine agent there is no Arc resource for policy or Defender to target.
- DAssign the service principal the Contributor role on the subscription.Contributor far exceeds what onboarding requires and violates the least privilege constraint; the Azure Connected Machine Onboarding role is purpose-built for this.
- ECreate an Azure Migrate project and run the discovery appliance in each datacenter.Azure Migrate discovers and assesses servers for migration; it does not install the Connected Machine agent or make the servers manageable through Arc.
Why: Azure Arc-enabled servers extend Azure management to machines outside Azure by installing the Azure Connected Machine agent, which creates a Microsoft.HybridCompute/machines resource in a resource group. Once the resource exists, Azure Policy, Machine Configuration, and Defender for Servers treat it like an Azure VM. At-scale onboarding uses a service principal with the Azure Connected Machine Onboarding role, which can connect machines but cannot manage other resources, and requires the HybridCompute, GuestConfiguration, and HybridConnectivity resource providers to be registered first. The trap is confusing monitoring agents with the Arc agent: the Azure Monitor Agent is an extension deployed to an Arc server afterward, not a substitute for it.
Implement security for servers and virtual machines (VMs)
Sablewood Robotics runs 150 Azure VMs. Thirty of them are appliance-style VMs supplied by a vendor who prohibits installing any agent or extension. The security team must obtain vulnerability findings, software inventory, exposed secrets, and malware detection for all 150 VMs, including the appliance VMs, from Microsoft Defender for Cloud.
What should you do?
- AEnable Defender for Servers Plan 1 on the subscription and turn on the Endpoint protection setting.Plan 1 relies on the Defender for Endpoint agent for vulnerability findings and does not include agentless scanning, so the appliance VMs would remain uncovered.
- BEnable Defender for Servers Plan 2 on the subscription and turn on the Agentless scanning for machines setting.Agentless scanning takes disk snapshots out of band and analyzes them for vulnerabilities, software inventory, secrets, and, with Plan 2, malware, providing coverage without any component inside the VM.
- CEnable Defender CSPM on the subscription only.Defender CSPM provides agentless vulnerability, inventory, and secrets scanning, but agentless malware scanning requires Defender for Servers Plan 2.
- DDeploy the Azure Monitor Agent with a data collection rule for security events to every VM.The Azure Monitor Agent is an agent, which the vendor prohibits, and it collects logs rather than scanning disks for vulnerabilities or malware.
Why: Agentless scanning in Defender for Cloud snapshots the VM disks and analyzes them in an isolated Microsoft environment, producing vulnerability assessment, software inventory, secrets scanning, and malware scanning without touching the running guest. The feature is included in Defender for Servers Plan 2 and in Defender CSPM, but the malware scanning component is exclusive to Plan 2. Because the scenario demands malware detection for agentless machines, Plan 2 with the agentless scanning toggle enabled is the answer. The trap is Defender CSPM alone, which covers three of the four requirements, or Plan 1, which has no agentless scanning at all.
Implement security for servers and virtual machines (VMs)
Northgate Energy deploys new Generation 2 Windows Server VMs for its SCADA historian. Security requires that the boot loader and kernel are verified against trusted signatures at startup, that boot measurements are stored in a tamper-resistant location, and that Microsoft Defender for Cloud raises a recommendation if the boot chain is altered. The team must configure this at deployment time with built-in VM settings.
What should you configure?
- ASecurity type Standard, and enable Azure Disk Encryption on the OS disk.Standard security type has no secure boot or vTPM, and disk encryption protects data at rest; it does not verify the boot chain.
- BSecurity type Trusted launch, with secure boot and vTPM enabled and integrity monitoring enabled.Trusted launch provides secure boot to verify signed boot components, a vTPM to store boot measurements, and integrity monitoring through the Guest Attestation extension, which reports boot integrity to Defender for Cloud.
- CSecurity type Confidential virtual machines with confidential OS disk encryption.Confidential VMs add hardware-based memory encryption and require specific VM sizes; the scenario's requirements are met by Trusted launch without the added constraints and cost.
- DSecurity type Trusted launch with vTPM enabled and secure boot disabled.Without secure boot, unsigned boot components are not blocked, and integrity monitoring requires both secure boot and vTPM to be enabled.
Why: Trusted launch is the security type for Generation 2 Azure VMs that defends against boot kits and rootkits. Secure boot ensures only signed boot loaders, kernels, and drivers run; the vTPM is a virtualized TPM 2.0 that stores boot measurements; and integrity monitoring uses the Guest Attestation extension to attest those measurements to Microsoft Azure Attestation and surface failures as Defender for Cloud recommendations. All three settings are chosen when the VM is created. Confidential VMs are the trap: they add memory encryption for a different threat model and need DC- or EC-series sizes, which the scenario does not require.