10.4 Trusted Launch, VM Security Features & Machine Configuration
Key Takeaways
- Trusted Launch combines Secure Boot, vTPM, and boot integrity monitoring to protect Generation 2 (and upgraded) VMs against bootkits and rootkits.
- Secure Boot blocks untrusted bootloaders and kernel-mode drivers; vTPM provides a virtual TPM 2.0 for measured boot and key protection outside the guest.
- Integrity monitoring uses the Guest Attestation extension so Defender for Cloud can remotely attest that the VM booted healthily.
- VM security type choices—Standard, Trusted launch, or Confidential—must match image generation, size support, and threat model; confidential computing is not identical to Trusted Launch.
- Azure Machine Configuration (formerly Guest Configuration) audits and enforces OS baselines inside Azure and Arc-enabled machines via Policy assignments, extension, and managed identity.
Blueprint Features You Must Configure on a VM
SC-500 calls out configuring security features on a VM—including Secure Boot, virtual Trusted Platform Module (vTPM), integrity monitoring, and security type—and enforcing security configuration of Azure-managed servers with Azure Machine Configuration. These controls sit above disk encryption and remote access: they protect boot integrity and guest configuration drift.
Trusted Launch Overview
Trusted Launch is Azure’s foundational compute security stack for modern VMs. It defends against persistent boot-level malware (bootkits/rootkits) by combining:
- Secure Boot
- vTPM
- Boot integrity monitoring (remote attestation via Guest Attestation)
Trusted Launch targets Generation 2 VMs (UEFI). Microsoft has also documented upgrade paths to bring eligible Gen1 VMs forward to Gen2 + Trusted Launch after guest OS volume preparation—know that upgrades may require deallocate and validation steps.
When you create a VM in the portal, Security type can be set to Trusted launch virtual machines, after which checkboxes for Secure Boot, vTPM, and Integrity monitoring appear.
Secure Boot
Secure Boot ensures the VM boots only signed, trusted boot components—UEFI firmware path, bootloader, kernel, and early drivers validated against trusted signatures. If an attacker plants an unsigned malicious bootloader, Secure Boot blocks it.
Exam facts:
- Strongly recommended for production Trusted Launch VMs unless you intentionally run custom unsigned kernels/drivers (rare; document exceptions).
- Defender for Cloud can raise a recommendation to enable Secure Boot on capable VMs where it is off.
- Secure Boot alone does not encrypt disks and does not replace EDR.
Scenario: Linux VM with only Microsoft-signed marketplace image and no custom kernel modules. → Enable Secure Boot.
Scenario: Research VM loads unsigned experimental drivers. → Secure Boot may need to stay off, but treat as elevated risk and isolate the workload.
vTPM (Virtual Trusted Platform Module)
vTPM is a virtualized TPM 2.0-compliant module dedicated to the VM and hosted in a protected environment outside the guest. It enables:
- Measured boot — hashes of boot chain components stored in Platform Configuration Registers (PCRs).
- Key protection — secrets sealed to TPM state.
- Attestation — cryptographic proof the platform booted as expected.
Without vTPM, advanced attestation and some health signals are unavailable. Defender for Cloud recommends enabling vTPM on Trusted Launch–capable VMs where it is disabled because vTPM underpins guest attestation and advanced threat pattern detection.
vTPM is not BitLocker by itself—BitLocker/CMK/encryption-at-host remain separate—but TPM capabilities support guest encryption and measured boot scenarios.
Integrity Monitoring (Boot Integrity / Guest Attestation)
Boot integrity monitoring lets Azure and Defender for Cloud remotely attest that the VM’s boot chain is healthy. Implementation details examiners care about:
- Requires Trusted Launch with Secure Boot and vTPM enabled.
- Deploys the Guest Attestation extension (explicit configuration; automatic extension upgrade is available).
- Defender for Cloud surfaces attestation health assessments and recommendations if the extension is missing even when Secure Boot and vTPM are on.
- Attestation failures can indicate boot-chain tampering, misconfiguration, or extension health issues—investigate before forcing production traffic back.
CLI mental model: create/update VM with Trusted Launch, --enable-secure-boot true, --enable-vtpm true, and enable integrity monitoring / Guest Attestation.
Security Type: Standard vs Trusted Launch vs Confidential
| Security type | Intent | Typical features |
|---|---|---|
| Standard | Classic VM security baseline | No Trusted Launch boot protections |
| Trusted launch | Foundational boot integrity | Secure Boot, vTPM, integrity monitoring |
| Confidential | Protect data in use with hardware TEEs | Confidential computing sizes; confidential disk encryption options; stronger host isolation story |
Choosing on the exam:
- “Protect against rootkits/bootkits; attest healthy boot” → Trusted launch + enable all three features when possible.
- “Protect memory from host operators while processing highly sensitive data” → Confidential VM sizes/security type.
- “Legacy Gen1 image with no upgrade path yet” → may remain Standard until migration; plan upgrade.
- Do not treat Trusted Launch and Confidential as synonyms—they solve related but different threats.
Arm64 Trusted Launch exists on supported Cobalt-class sizes with Arm64 Gen2 images—only mention if the stem specifies architecture.
Defender for Cloud Integration with Trusted Launch
Expect recommendations such as:
- Enable Secure Boot.
- Enable vTPM.
- Install Guest Attestation extension for integrity monitoring.
- Attestation health assessment status for monitored VMs.
Policy initiatives can auto-configure prerequisites (managed identity + Guest Attestation) for Trusted Launch VMs. Pair these with encryption-at-host and NSG/Bastion controls for a complete compute hardening story.
Azure Machine Configuration (Guest Configuration)
Azure Machine Configuration—formerly Azure Policy Guest Configuration—provides native audit and enforcement of operating system settings as code for:
- Azure VMs
- Azure Arc-enabled servers (hybrid/multicloud/edge)
It answers: “Is the guest OS configured to our baseline?”—password policies, security options, firewall profiles, MCSB compute baselines, custom DSC-like configurations, and more.
How it works (components)
- Machine Configuration extension on the machine (plus system-assigned managed identity for secure platform communication).
- Policy assignments (built-in or custom) in category Guest Configuration / Machine Configuration.
- Assignments that define the desired state (audit or deploy/remediate depending on definition).
- Compliance results in Azure Policy, Resource Graph, and Guest Assignments views.
Defender for Servers linkage
With Defender for Servers Plan 2, Defender for Cloud assesses OS configuration against Microsoft Cloud Security Benchmark (MCSB) compute baselines. That assessment depends on Machine Configuration data. Prerequisites called out in docs:
- Plan 2 enabled for those OS baseline recommendations.
- Machine Configuration extension present.
- Supported Windows/Linux on Azure or Arc.
Foundational posture may still surface some signals, but the exam association to remember is: Plan 2 + Machine Configuration → OS baseline misconfiguration recommendations.
Enforcement scenarios
| Goal | Machine Configuration approach |
|---|---|
| Audit Windows security baseline | Assign built-in baseline policy; review non-compliant settings |
| Enforce firewall profile settings | Use baseline/custom configuration with remediation where supported |
| Hybrid servers same baseline as Azure | Arc-enable machines; same policy assignment scope |
| Prerequisite rollout at scale | Deploy Machine Configuration prerequisite initiative (extension + identity) before baselines |
Exam trap: Azure Policy without Machine Configuration only sees Azure Resource Manager properties—not in-guest registry/security options. If the stem requires inside the OS, answer Machine Configuration / Guest Configuration.
Putting Features Together: Scenario Drill
Scenario 1 — Regulated Gen2 web tier
Security type: Trusted launch; Secure Boot on; vTPM on; integrity monitoring on; encryption at host; Bastion + JIT; Defender for Servers Plan 2; Machine Configuration MCSB baselines.
Scenario 2 — Confidential analytics
Security type: Confidential VM size; confidential OS disk encryption; still consider identity/network controls; Trusted Launch features may differ by confidential platform—do not blindly assume every Trusted Launch checkbox maps 1:1.
Scenario 3 — On-prem file servers
Arc onboard → Defender for Servers → Machine Configuration baselines → EDR via MDE. Trusted Launch is an Azure VM security type concept; physical servers use firmware TPM/Secure Boot on-premises plus Arc configuration management—not the Azure portal “Trusted launch” toggle.
Scenario 4 — Feature selection question
“Which feature proves the VM booted with a trusted chain to Defender for Cloud?” → Integrity monitoring / Guest Attestation (with Secure Boot + vTPM).
“Which feature blocks unsigned bootloaders?” → Secure Boot.
“Which feature provides a TPM 2.0 for measurements?” → vTPM.
“Which feature enforces password complexity inside Windows?” → Machine Configuration policy assignment—not Secure Boot.
Common Exam Traps
- Trap: Enabling only Secure Boot and claiming full Trusted Launch attestation. You need vTPM + Guest Attestation for integrity monitoring.
- Trap: Using Machine Configuration synonymously with host NSG rules. NSGs are network; Machine Configuration is guest OS state.
- Trap: Saying Confidential VMs are required for Secure Boot. Secure Boot is a Trusted Launch feature on supported Gen2 VMs without requiring confidential sizes.
- Trap: Forgetting managed identity for the Machine Configuration / Guest Attestation extensions.
- Trap: Expecting Trusted Launch on unsupported images/sizes—always check Gen2 + region + size support.
Chapter Synthesis: Secure Servers Checklist
When an SC-500 case study asks you to “secure the server fleet,” assemble:
- Disk encryption — SSE baseline; encryption at host for temp/cache; CMK via DES when required; migrate off ADE.
- Access — Bastion without public management IPs; JIT for time-boxed ports; never standing Internet RDP/SSH.
- Hybrid coverage — Arc + Defender for Servers plan selection (P1 EDR vs P2 agentless/JIT/FIM).
- Boot & guest hardening — Trusted Launch trio + Machine Configuration baselines.
Master these four layers and you can answer the majority of Implement security for servers and virtual machines items under Secure compute.
A Gen2 Azure VM must block untrusted bootloaders and provide TPM-based measured boot with remote attestation visible to Defender for Cloud. Which combination should you enable?
Which Azure capability audits and can enforce operating system security baseline settings inside Windows and Linux machines, including Azure Arc-enabled servers?
An exam item asks which Trusted Launch component stores boot-chain measurements and enables cryptographic attestation as a virtual TPM 2.0. What is the correct feature?
A workload must protect data while it is processed in memory from higher-privilege host threats, not only ensure Secure Boot. Which security type direction is most appropriate?