This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for servers and virtual machines (VMs)
      --> Configure security features on a VM, including secure boot, virtual Trusted Platform Module (vTPM), integrity monitoring, and security type

Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Azure virtual machines can be exposed to threats that operate below the operating-system level, including:

Bootkits
Rootkits
Kernel-level malware
Unauthorized boot components
Attempts to compromise the boot process
Theft or misuse of cryptographic keys and credentials

Azure provides Trusted Launch to help protect supported Generation 2 virtual machines against these threats. Trusted Launch combines several security technologies:

Secure Boot
Virtual Trusted Platform Module (vTPM)
Boot integrity monitoring
A VM security type that defines the security configuration

These capabilities work together to establish trust in the VM’s boot process and to detect changes or failures in the boot chain.

What Is Trusted Launch?

Trusted Launch is a security configuration for supported Generation 2 Azure virtual machines and virtual machine scale sets.

It helps protect the VM before and during operating-system startup by ensuring that trusted boot components are used and that the integrity of the boot process can be assessed.

Trusted Launch is not an antivirus product and does not replace:

Microsoft Defender for Endpoint
Microsoft Defender for Servers
Vulnerability assessment
Network security controls
Disk encryption
Identity and access controls

Instead, Trusted Launch provides an additional layer of protection against low-level attacks.

Trusted Launch is supported for Windows and Linux VMs where the required image, VM size, architecture, and other prerequisites are supported. Newly created supported Generation 2 VMs generally use Trusted Launch by default, although administrators should verify the actual security configuration.

The Main Trusted Launch Components

1. Secure Boot

Secure Boot is a firmware-level security feature that allows only trusted, digitally signed boot components to execute.

During startup, Secure Boot validates components such as:

Boot loaders
Operating-system kernels
Kernel drivers
Other components involved in the boot process

If a component is not signed by a trusted publisher or fails validation, the VM may fail to boot.

Security benefit

Secure Boot helps prevent:

Bootkits
Rootkits
Unauthorized boot loaders
Modified or malicious boot components
Some forms of low-level persistence

Important limitation

Secure Boot does not inspect every application that runs after the operating system starts. It primarily protects the boot process.

A VM can have Secure Boot enabled and still be vulnerable to:

Application vulnerabilities
Weak passwords
Excessive permissions
Network attacks
Malicious scripts
Vulnerable installed software

Compatibility consideration

Secure Boot requires compatible operating-system images, kernels, and drivers. Custom unsigned drivers or kernels may prevent the VM from booting when Secure Boot is enabled.

Therefore, before enabling Secure Boot, verify that:

The VM is Generation 2.
The operating system supports Secure Boot.
Required drivers are signed.
Custom boot components are compatible.
The VM image is supported for Trusted Launch.

2. Virtual Trusted Platform Module

A virtual Trusted Platform Module, or vTPM, is a virtualized TPM 2.0 device assigned to the VM.

The vTPM provides a protected location for:

Cryptographic keys
Certificates
Secrets
Boot measurements
Attestation-related information

The vTPM also measures important components of the boot chain, including:

UEFI firmware
Boot loader
Operating system
System components
Drivers

These measurements can be used to determine whether the VM started in a trusted state.

Security benefit

vTPM supports:

Boot integrity measurement
Remote attestation
Secure storage of keys and secrets
Trust-based security decisions
Certain encryption capabilities

vTPM does not equal disk encryption

Enabling vTPM does not automatically encrypt all data on the VM’s disks.

Disk encryption is a separate capability. For example:

vTPM supports protection and measurement of keys and boot components.
Azure Disk Encryption or other disk-encryption technologies protect data at rest.
Confidential VM disk encryption provides additional protections in supported scenarios.

A common exam distractor is the claim that enabling vTPM automatically encrypts the operating-system disk. That is incorrect.

3. Boot Integrity Monitoring

Boot integrity monitoring uses attestation to verify the integrity of the VM’s boot sequence.

The process generally involves:

Secure Boot and vTPM are enabled.
The VM records measurements of the boot process.
The Guest Attestation extension communicates with an Azure Attestation endpoint.
The measurements are evaluated.
Defender for Cloud can report the attestation status.
Alerts or recommendations can be generated when integrity checks fail.

Boot integrity monitoring helps determine whether the VM booted using an expected and trusted configuration.

What it can detect

Depending on the supported scenario, integrity monitoring can identify:

Boot-chain changes
Unauthorized boot components
Attestation failures
Problems with the Guest Attestation extension
VM configurations that do not meet expected security requirements

An attestation failure does not automatically prove that malware is present. It indicates that the VM’s expected trust or integrity state could not be verified and should be investigated.

4. Guest Attestation Extension

The Guest Attestation extension enables the VM to participate in boot integrity monitoring.

For a Trusted Launch VM, the usual prerequisites include:

Secure Boot enabled
vTPM enabled
A supported VM configuration
The Guest Attestation extension installed
Required communication with the Azure Attestation service

The extension is responsible for collecting or submitting information needed for attestation.

If Secure Boot and vTPM are enabled but the Guest Attestation extension is missing, Defender for Cloud may recommend installing it.

Network considerations

The Guest Attestation extension must be able to communicate with the required Azure Attestation endpoint.

Network security groups, firewalls, proxies, or TLS inspection can interfere with this communication.

If the extension fails to provision or integrity monitoring is unavailable, check:

Outbound network access
Firewall rules
Network security group rules
Proxy configuration
Required service tags or endpoint access
Extension provisioning status

VM Security Types

Azure VM security type determines the security features and trust model used by the VM.

The most important security types for this topic are:

Standard
Trusted launch
Confidential virtual machines, where supported

Standard Security Type

The Standard security type represents the traditional VM security configuration.

A Standard VM does not automatically provide the Trusted Launch combination of:

Secure Boot
vTPM
Boot integrity monitoring

Standard security may be appropriate when:

The VM image is not compatible with Trusted Launch.
The workload requires unsupported boot components.
A legacy application requires a particular VM configuration.
The VM does not support Generation 2.
The organization has another documented reason not to use Trusted Launch.

However, Standard security provides less protection against boot-level threats than Trusted Launch.

Trusted Launch Security Type

The Trusted launch security type enables the Trusted Launch security model.

For supported VMs, Trusted Launch normally uses:

Secure Boot
vTPM
Optional or recommended boot integrity monitoring through Guest Attestation

Trusted Launch is designed to protect against advanced attacks involving the boot process and low-level system components.

The security type is not simply a label. It determines whether the VM can use the Trusted Launch security features.

Confidential VM Security Type

Confidential virtual machines provide stronger protection for data while it is being processed.

Confidential VMs use hardware-based trusted execution environments to help protect data in use from access by unauthorized components of the virtualization stack.

Depending on the supported configuration, confidential VMs can provide:

Hardware-based memory isolation
Confidential OS disk encryption
Secure key release
Hardware-backed attestation
Protection of data while in use

Confidential VMs address a different threat model from Trusted Launch.

Trusted Launch versus Confidential VMs

Feature	Trusted Launch	Confidential VM
Protects boot process	Yes	Yes, with supported configuration
Secure Boot	Yes	Supported in applicable configurations
vTPM	Yes	Supported in applicable configurations
Boot integrity monitoring	Yes, through attestation	Uses confidential-computing attestation capabilities
Protects data in use	Not its primary purpose	Yes
Hardware-based confidential execution	Not its primary purpose	Yes
Primary focus	Boot integrity and platform trust	Data confidentiality during processing

For the SC-500 exam, do not confuse Trusted Launch with confidential computing. Trusted Launch primarily establishes trust in the VM’s startup process, while confidential computing adds protection for data while it is being processed.

Generation 1 and Generation 2 VMs

Trusted Launch is designed for Generation 2 VMs.

Generation 1 VMs use older BIOS- and MBR-based boot architectures and do not support Secure Boot or vTPM in the same way.

Therefore:

A Generation 1 VM cannot simply enable Trusted Launch without conversion or migration.
A Generation 2 VM may be eligible to use Trusted Launch if its image and size are supported.
Existing Generation 1 VMs may need to be migrated or upgraded to a supported Generation 2 Trusted Launch configuration.

Before attempting an upgrade, evaluate:

Operating-system support
Boot architecture
VM size
OS disk configuration
Marketplace or custom image support
Application compatibility
Backup and rollback requirements

The upgrade process should be tested before being applied to production workloads.

Configuring Trusted Launch on a New VM

When creating a new VM, use a supported:

Generation 2 image
VM size
Operating system
Architecture
Region and deployment configuration

In the Azure portal, the security configuration is typically available during VM creation.

The general process is:

Open Create a virtual machine.
Select a supported Generation 2 image.
Choose a compatible VM size.
Open the security or management configuration section.
Set the security type to Trusted launch.
Confirm that Secure Boot is enabled.
Confirm that vTPM is enabled.
Enable or configure integrity monitoring where available.
Review the configuration.
Create the VM.

When using Azure CLI, the relevant settings include the Trusted Launch security type and the Secure Boot and vTPM options.

A representative configuration is:

			
az vm create \
  --resource-group myResourceGroup \
  --name myVM \
  --image Canonical:UbuntuServer:18_04-lts-gen2:latest \
  --admin-username azureuser \
  --generate-ssh-keys \
  --security-type TrustedLaunch \
  --enable-secure-boot true \
  --enable-vtpm true

		

The exact image reference and supported values depend on the operating system and current Azure requirements.

Configuring Trusted Launch on an Existing VM

Trusted Launch can be enabled on supported existing Generation 2 VMs.

A typical portal workflow is:

Open the VM in the Azure portal.
Select Settings.
Select Configuration.
Locate Security type.
Change the security type to Trusted launch.
Enable Secure Boot.
Enable vTPM.
Save the configuration.
Verify the resulting security settings.
Configure Guest Attestation or integrity monitoring if required.

Not every existing VM can be converted directly. The VM may need:

A supported Generation 2 image
A compatible VM size
A supported operating system
A supported disk configuration
A restart or redeployment
A migration from Generation 1 to Generation 2

Do not assume that changing the security type alone is sufficient for every VM.

Enabling Integrity Monitoring

For a supported Trusted Launch VM, integrity monitoring can be enabled through the VM configuration.

A typical workflow is:

Open the VM in the Azure portal.
Select Settings.
Select Configuration.
Locate the security type or integrity-monitoring setting.
Select Integrity monitoring.
Save the changes.
Verify that the Guest Attestation extension is installed.
Review the VM’s attestation status in Defender for Cloud.

Integrity monitoring requires Secure Boot and vTPM to be enabled. The Guest Attestation extension cannot provide the expected boot-integrity functionality if the required Trusted Launch components are not enabled.

Defender for Cloud Integration

Microsoft Defender for Cloud can assess Trusted Launch configurations and provide recommendations.

Potential recommendations include:

Enable Secure Boot.
Enable vTPM.
Install the Guest Attestation extension.
Correct boot integrity monitoring configuration.
Investigate a VM attestation failure.

Defender for Cloud may also report the status of boot integrity monitoring and alert when an attestation check fails.

The integration provides security posture visibility, but it does not guarantee that every VM is protected against every threat.

Enforcing Trusted Launch at Scale

Organizations with many VMs should avoid relying only on manual configuration.

Azure Policy can help enforce security requirements at scale.

Possible policy objectives include:

Audit VMs that do not use Trusted Launch.
Audit supported VMs with Secure Boot disabled.
Audit supported VMs with vTPM disabled.
Require or encourage Trusted Launch for new deployments.
Identify VMs that lack required attestation configuration.

A policy can be used in different modes:

Audit — identifies noncompliant resources.
Deny — prevents deployments that violate the policy.
DeployIfNotExists — deploys a required component when supported.
Modify — changes supported resource properties when applicable.

Use caution with automatic enforcement. A Deny policy can prevent legitimate deployments if it does not account for:

Unsupported VM sizes
Unsupported operating systems
Legacy workloads
Generation 1 VMs
Custom unsigned drivers
Special application requirements

A practical rollout often follows this sequence:

Audit existing VMs.
Identify exceptions.
Test Trusted Launch with representative workloads.
Remediate eligible VMs.
Document exceptions.
Enforce the standard for new deployments.
Monitor policy compliance continuously.

Troubleshooting Trusted Launch

Secure Boot Cannot Be Enabled

Possible causes include:

The VM is Generation 1.
The operating system is unsupported.
The image is not compatible with Secure Boot.
An unsigned driver or kernel is installed.
The VM size does not support the configuration.
The VM uses an unsupported disk or image configuration.

vTPM Cannot Be Enabled

Possible causes include:

The VM is not Generation 2.
The selected image is unsupported.
The VM size does not support Trusted Launch.
The VM uses an incompatible configuration.
The VM must be migrated or redeployed.

Guest Attestation Extension Fails

Check:

Secure Boot is enabled.
vTPM is enabled.
The VM is a supported Trusted Launch VM.
The extension is installed correctly.
The extension is provisioned successfully.
Outbound access to the Azure Attestation endpoint is allowed.
Firewall, NSG, proxy, or TLS inspection rules are not blocking communication.

Integrity Monitoring Is Unavailable

Possible causes include:

The VM is not using Trusted Launch.
Secure Boot or vTPM is disabled.
The Guest Attestation extension is missing.
The operating system or VM configuration is unsupported.
The VM cannot reach the attestation service.
The attestation process has not completed.
Defender for Cloud has not yet received updated status.

The VM Does Not Boot After Enabling Secure Boot

Possible causes include:

An unsigned kernel or driver
An incompatible boot loader
An unsupported custom image
A boot component that is not trusted
A configuration change that was not tested

Before enabling Secure Boot on production systems, test the configuration on a clone or nonproduction VM.

Security Best Practices

Prefer Trusted Launch for Supported VMs

Use Trusted Launch for supported Generation 2 VMs unless there is a documented compatibility or business reason not to.

Enable Secure Boot and vTPM Together

Secure Boot validates boot components, while vTPM measures the boot process and supports attestation. They provide complementary protections.

Enable Integrity Monitoring

Secure Boot and vTPM provide the foundation, but integrity monitoring adds visibility into whether the VM actually booted in an expected state.

Use Supported Images

Prefer supported marketplace images or appropriately prepared Azure Compute Gallery images.

Test Custom Drivers and Kernels

Custom unsigned drivers and kernels may be incompatible with Secure Boot.

Use Azure Policy

Use Azure Policy to identify or enforce Trusted Launch adoption consistently.

Monitor Defender for Cloud Recommendations

Review recommendations for:

Disabled Secure Boot
Disabled vTPM
Missing Guest Attestation extension
Failed boot integrity checks

Do Not Treat Trusted Launch as Complete VM Security

Trusted Launch should be combined with:

Disk encryption
Microsoft Defender for Servers
Microsoft Defender for Endpoint
Just-in-time VM access
Network security groups
Azure Firewall where appropriate
Patch management
Least-privilege access
Secure administration practices
Backup and recovery controls

Exam-Focused Summary

Remember the following:

Trusted Launch protects supported Generation 2 VMs against bootkits, rootkits, and low-level malware.
Secure Boot allows only trusted signed boot components to execute.
vTPM stores keys and measurements and supports boot attestation.
Boot integrity monitoring uses attestation to evaluate the VM’s boot chain.
The Guest Attestation extension supports integrity monitoring.
Secure Boot and vTPM are prerequisites for Guest Attestation-based boot integrity monitoring.
Trusted Launch is a VM security type, not merely an individual setting.
Generation 1 VMs do not support Trusted Launch in their original configuration.
Changing the security type may require a supported Generation 2 image, VM size, and operating system.
vTPM does not automatically encrypt the VM’s disks.
Trusted Launch is different from confidential computing.
Defender for Cloud can provide recommendations and alerts related to Trusted Launch configuration and attestation.
Azure Policy can help enforce Trusted Launch adoption at scale.
Secure Boot may prevent a VM from booting if it uses unsigned drivers or kernels.

Practice Exam Questions

Question 1

An administrator wants to protect an Azure VM against bootkits and rootkits by allowing only trusted boot components to execute. Which feature should the administrator enable?

A. Microsoft Sentinel
B. Azure Bastion
C. File Integrity Monitoring
D. Secure Boot

Answer: D

Explanation: Secure Boot validates boot loaders, operating-system components, and drivers so that only trusted signed components can execute during startup.

Question 2

Which Azure VM security type provides the security configuration that combines Secure Boot and vTPM?

A. Standard
B. Trusted launch
C. Basic
D. Spot

Answer: B

Explanation: Trusted launch is the VM security type designed to provide Secure Boot, vTPM, and related boot-integrity capabilities for supported Generation 2 VMs.

Question 3

What is the primary purpose of a virtual Trusted Platform Module?

A. To filter inbound network traffic
B. To replace Microsoft Defender for Endpoint
C. To store keys and measurements and support attestation
D. To automatically patch the operating system

Answer: C

Explanation: A vTPM provides a protected virtual TPM 2.0 instance that stores cryptographic material and boot measurements and supports attestation. It does not provide network filtering, EDR, or automatic patching.

Question 4

A security engineer enables Secure Boot and vTPM on a supported Trusted Launch VM and wants Defender for Cloud to monitor boot integrity. What additional component may be required?

A. Azure Bastion
B. Azure Firewall
C. Microsoft Sentinel agent
D. Guest Attestation extension

Answer: D

Explanation: The Guest Attestation extension supports boot integrity monitoring by submitting measurements for attestation. Secure Boot and vTPM must already be enabled.

Question 5

Which statement about Generation 1 VMs is correct?

A. Generation 1 VMs support Trusted Launch without modification
B. Generation 1 VMs use an older boot architecture and do not directly support Trusted Launch
C. Generation 1 VMs automatically have Secure Boot enabled
D. Generation 1 VMs include a vTPM by default

Answer: B

Explanation: Trusted Launch is designed for Generation 2 VMs. Generation 1 VMs use older BIOS- and MBR-based architectures and generally require migration or conversion to a supported Generation 2 configuration.

Question 6

An organization enables vTPM on a VM. The administrator then claims that all data on the VM’s operating-system disk is now encrypted. How should this claim be evaluated?

A. Correct, because vTPM automatically encrypts every disk
B. Correct, but only for Generation 1 VMs
C. Incorrect, because vTPM does not itself provide complete disk encryption
D. Incorrect, because vTPM disables disk encryption

Answer: C

Explanation: vTPM protects keys and measurements and supports attestation. Disk encryption is a separate capability, such as Azure Disk Encryption or supported confidential VM disk encryption.

Question 7

A Trusted Launch VM’s Guest Attestation extension fails to provision. Which issue is most likely relevant?

A. The VM has too many data disks
B. The VM has no public IP address
C. The VM has an Azure tag with an incorrect value
D. Network controls are blocking communication with the Azure Attestation endpoint

Answer: D

Explanation: Guest Attestation requires communication with the Azure Attestation service. NSGs, firewalls, proxies, or TLS inspection can prevent the extension from functioning correctly.

Question 8

A company wants to identify supported VMs that do not use Trusted Launch before enforcing the requirement. Which Azure service should it use?

A. Azure Policy in audit mode
B. Azure DNS
C. Azure Load Balancer
D. Azure Storage lifecycle management

Answer: A

Explanation: Azure Policy in audit mode can identify VMs that do not meet the organization’s Trusted Launch requirements without immediately blocking deployments.

Question 9

Which statement best describes boot integrity monitoring?

A. It automatically installs missing operating-system updates
B. It verifies the VM’s boot state through attestation and can report integrity failures
C. It encrypts all application data in memory
D. It replaces endpoint detection and response

Answer: B

Explanation: Boot integrity monitoring uses attestation to evaluate the VM’s boot chain and can provide recommendations or alerts when the expected integrity state cannot be verified.

Question 10

A Linux VM uses a custom unsigned kernel. The administrator enables Secure Boot, and the VM no longer starts. What is the most likely explanation?

A. Secure Boot requires all network traffic to use a private endpoint
B. vTPM prevents Linux VMs from starting
C. Secure Boot may reject unsigned boot components
D. Trusted Launch requires Azure Bastion

Answer: C

Explanation: Secure Boot validates boot components and may prevent startup when an unsigned custom kernel or driver is used. The administrator should verify compatibility before enabling Secure Boot on custom images.

Go to the SC-500 Exam Prep Hub main page