Tag: SC-500

Microsoft Certification, Cybersecurity, Cloud computing, azure, security, SC-500 October 10, 2026

Extend security controls to hybrid and multicloud servers by using Azure Arc (SC-500 Exam Prep)

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)
      --> Extend security controls to hybrid and multicloud servers by using Azure Arc

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

Organizations frequently operate servers in several locations:

Azure
On-premises datacenters
Branch offices
Edge locations
Other cloud providers, such as Amazon Web Services or Google Cloud
Virtualized environments such as VMware or Hyper-V

Managing security consistently across these environments can be difficult. Each platform may have different management tools, identity systems, monitoring solutions, patching processes, and security configurations.

Azure Arc-enabled servers extends Azure management, governance, monitoring, and security capabilities to physical servers and virtual machines running outside Azure. After a server is connected to Azure Arc, it is represented as an Azure resource and can be managed through Azure Resource Manager, the Azure portal, Azure CLI, Azure PowerShell, and Azure APIs.

For the SC-500 exam, the important concept is that Azure Arc does not move the server into Azure. Instead, it creates a secure management relationship between the external server and Azure so that Azure services can apply security controls to that server.

What Is Azure Arc-Enabled Servers?

Azure Arc-enabled servers is an Azure service that allows organizations to connect:

Windows physical servers
Linux physical servers
Windows virtual machines
Linux virtual machines

These machines can be hosted:

On-premises
In another cloud provider
In a datacenter
At an edge location
In a supported virtualized environment

When connected, each machine receives an Azure representation with an Azure resource ID. The resource can be placed in an Azure resource group and managed using Azure governance and security services.

Important distinction

Azure Arc-enabled servers is designed for servers outside Azure. It is not intended to provide Azure Arc management for ordinary Azure VMs, which are already native Azure resources.

Why Azure Arc Is Important for Security

Without Azure Arc, an organization may need separate security processes for each environment:

Environment	Possible management approach
Azure	Azure portal and Defender for Cloud
On-premises	Local management tools
AWS	AWS security and management tools
GCP	GCP security and management tools
Edge	Custom monitoring and administration

This can result in:

Inconsistent security baselines
Different patching schedules
Unmonitored servers
Excessive administrative permissions
Incomplete asset inventories
Delayed vulnerability remediation
Different compliance reports
Security gaps between cloud and datacenter environments

Azure Arc provides a common Azure control plane for supported external servers. This allows organizations to extend services such as:

Microsoft Defender for Cloud
Microsoft Defender for Servers
Microsoft Defender for Endpoint
Microsoft Sentinel
Azure Policy
Azure Machine Configuration
Azure Monitor
Azure Update Manager
Azure Automation
Azure Resource Graph

The exact capabilities depend on the service, operating system, region, licensing, and supported configuration.

Azure Arc Architecture

The Azure Connected Machine agent

To connect a server to Azure Arc, the Azure Connected Machine agent must be installed on the server.

The agent:

Establishes the relationship between the server and the Azure subscription.
Registers the machine as an Azure resource.
Provides a managed identity for the machine.
Communicates with Azure over outbound connections.
Enables extensions and other Azure services.
Helps evaluate or enforce configuration settings on the server.

The Azure representation becomes the control point through which authorized Azure users and services manage the connected machine.

Azure is the source of truth

Management actions are generally initiated against the Azure representation of the server. For example, an administrator may use Azure to:

Install a monitoring extension
Enable Microsoft Defender for Servers
Assign an Azure Policy
Apply a machine configuration
Enable update management
Configure an approved extension

The Azure control plane evaluates the request against applicable permissions and policies before the action is sent to the agent.

This is important because Azure RBAC and Azure Policy can govern who is allowed to perform management operations on the connected server.

How the Connected Machine Agent Communicates

Azure Arc-enabled servers primarily use outbound communication from the server to Azure.

Azure does not normally initiate inbound connections into the organization’s network to manage the server. Communication between the agent and Azure is encrypted using TLS.

Security benefits of outbound communication

This design can reduce the need to:

Open inbound management ports
Expose servers directly to the internet
Create inbound firewall rules for Azure management
Publish RDP or SSH endpoints

The organization must still allow the required outbound endpoints through its firewall or proxy.

Network planning considerations

Before onboarding a server, verify:

DNS resolution works.
The server can reach required Azure endpoints.
Outbound HTTPS traffic is permitted.
Proxy settings are configured if required.
TLS inspection is compatible with the agent and extensions.
Extensions have access to any additional endpoints they require.

Some extensions have their own network requirements beyond the base Azure Arc agent requirements.

Public and Private Connectivity

Azure Arc-enabled servers can use public Azure endpoints or supported private endpoint configurations.

Public endpoint connectivity

With public connectivity:

The server makes outbound connections to Azure.
Traffic is encrypted.
Required Azure endpoints must be allowed through the organization’s firewall or proxy.

This is often the simplest deployment model.

Private endpoint connectivity

Private endpoints can allow Azure Arc traffic to travel through private connectivity such as:

ExpressRoute
Site-to-site VPN

Private endpoints can provide more granular control over which machines are allowed to communicate with Azure Arc services.

However, private endpoints do not eliminate every public endpoint requirement. For example, Microsoft Entra ID does not provide a private endpoint in the same way as Azure Arc services, and some extensions may still require public connectivity.

Important limitation

Using a private endpoint for Azure Arc does not mean that every remote-management method becomes private. For example, SSH and Windows Admin Center access have separate requirements and are not automatically provided through an Azure Arc private endpoint.

Azure Arc and Microsoft Defender for Cloud

Azure Arc is commonly used to onboard non-Azure servers into Microsoft Defender for Cloud.

The general process is:

Connect the external server to Azure Arc.
Register the server in an Azure subscription.
Enable the appropriate Microsoft Defender for Cloud plan.
Deploy required security agents or extensions.
Review recommendations, alerts, and security posture.
Remediate identified issues.

Once connected to Azure Arc and covered by the appropriate Defender for Servers plan, an external server can appear in Defender for Cloud alongside native Azure resources.

Security capabilities that may be extended

Depending on licensing and configuration, organizations can use Defender for Cloud to provide:

Security posture management
Security recommendations
Vulnerability assessment
Threat detection
Microsoft Defender for Endpoint integration
File Integrity Monitoring
Just-in-time VM access where supported
Regulatory compliance assessments
Security alerts
Cloud workload protection

Not every Defender capability is automatically available merely because a server is connected to Azure Arc. The required Defender plan and supporting agents or extensions must be configured.

Azure Arc and Microsoft Defender for Servers

Microsoft Defender for Servers extends security protection to supported servers outside Azure when they are connected through Azure Arc.

Defender for Servers Plan 1

Plan 1 provides core server protection capabilities, including Microsoft Defender for Endpoint integration where supported.

Defender for Servers Plan 2

Plan 2 includes additional capabilities, such as:

File Integrity Monitoring
Just-in-time VM access
Additional vulnerability and security capabilities
Additional cloud workload protection features

The exact feature set should always be checked against the current service configuration and licensing model.

Exam distinction

Azure Arc provides the connection and Azure resource representation.

Microsoft Defender for Servers provides the server security capabilities.

They are related, but they are not the same service.

Azure Arc and Microsoft Defender for Endpoint

Microsoft Defender for Endpoint can provide endpoint protection and detection capabilities for supported Arc-enabled servers.

Capabilities may include:

Endpoint detection and response
Threat detection
Vulnerability management
Security monitoring
Investigation support
Automated response capabilities, depending on licensing and configuration

Azure Arc helps Defender for Cloud identify and manage the external server, while Defender for Endpoint provides endpoint-level security telemetry and protection.

Azure Arc and Microsoft Sentinel

Microsoft Sentinel is a cloud-native security information and event management and security orchestration, automation, and response solution.

Azure Arc can help onboard hybrid and multicloud servers so that their security events can be collected and analyzed in Microsoft Sentinel.

A typical architecture may include:

Azure Arc connects the server to Azure.
A supported monitoring or security agent is installed.
Server logs and security events are collected.
Data is sent to a Log Analytics workspace.
Microsoft Sentinel analyzes the data.
Analytics rules detect suspicious activity.
Incidents, automation rules, and playbooks support response.

This provides a centralized view of security events across Azure, on-premises, and other cloud environments.

Example

An organization has:

Windows servers in Azure
Linux servers in an on-premises datacenter
AWS virtual machines
A central Microsoft Sentinel workspace

Azure Arc can provide the Azure connection for the non-Azure servers. Microsoft Sentinel can then correlate events from all environments to detect activity that might not be suspicious when viewed in isolation.

Azure Arc and Azure Policy

Azure Policy can be used to govern Arc-enabled servers.

Policy assignments can evaluate:

Whether required extensions are installed
Whether security agents are deployed
Whether specific configurations are present
Whether servers meet organizational standards
Whether resources are located in approved resource groups
Whether required tags or metadata are present

Azure Policy can be assigned at scopes such as:

Management group
Subscription
Resource group
Individual resource

Example policy requirements

An organization might require that all Arc-enabled production servers:

Have Microsoft Defender for Endpoint installed
Send security data to an approved Log Analytics workspace
Use a specific security configuration
Have required tags
Belong to an approved resource group
Use a supported operating system version

Azure Policy helps maintain consistent governance across servers that otherwise run in different environments.

Azure Machine Configuration

Azure Machine Configuration, previously associated with Guest Configuration, can audit or enforce settings inside Arc-enabled servers.

It can be used to evaluate operating-system and machine-level settings, such as:

Password policies
Security options
Registry settings
File configurations
Services
Installed software
Operating-system configuration
Compliance with organizational baselines

Azure Policy versus Machine Configuration

Capability	Azure Policy	Azure Machine Configuration
Primary focus	Azure resource governance	Settings inside the guest operating system
Example	Require a security extension	Require a specific password policy
Scope	Azure resource hierarchy	Machine configuration
Typical result	Resource compliance state	Guest configuration compliance state

Azure Policy can assign or evaluate machine configuration policies against Arc-enabled servers.

Azure Arc Extensions

Extensions allow Azure services and other supported capabilities to be installed or configured on an Arc-enabled server.

Examples include extensions for:

Monitoring
Security
Configuration
Automation
Update management
Custom scripts
Dependency analysis

Security considerations for extensions

Extensions can perform powerful operations on the server. Therefore, organizations should:

Limit who can install extensions.
Use extension allowlists where appropriate.
Review extension publishers and functionality.
Keep extensions updated.
Remove unnecessary extensions.
Monitor extension installation and configuration changes.
Apply Azure Policy to control extension deployment.

A compromised or overly privileged account could potentially use an extension to make changes on the server. For this reason, extension management should be treated as a privileged operation.

Azure Arc Managed Identity

The Connected Machine agent provides a managed identity for the connected server.

A managed identity can allow the server or supported applications to authenticate to Azure services without storing credentials such as:

Passwords
Client secrets
Certificates
Access keys

For example, a supported application running on an Arc-enabled server may use its managed identity to access an Azure resource according to its assigned permissions.

Benefits

Managed identities can:

Reduce credential storage
Reduce secret rotation requirements
Support Azure RBAC
Improve auditability
Reduce the risk of exposed credentials

Least-privilege requirement

A managed identity should receive only the permissions required for its tasks. Assigning broad roles such as Owner or Contributor unnecessarily increases risk.

Azure Arc Onboarding Methods

The onboarding process generally includes:

Select the Azure subscription and resource group.
Select the Azure region.
Prepare the server.
Install the Azure Connected Machine agent.
Authenticate the onboarding operation.
Register the server with Azure Arc.
Verify the connection.
Apply security services and policies.

Authentication options

Depending on the deployment method, onboarding may use:

Interactive user authentication
A service principal
Other supported authentication methods

Service principal security

When using a service principal for onboarding at scale:

Grant only the required permissions.
Avoid broad subscription-wide roles where possible.
Protect client secrets.
Rotate credentials regularly.
Prefer certificate-based or managed identity approaches when supported.
Do not place secrets directly in scripts or source-control repositories.
Restrict who can create and use onboarding credentials.

Microsoft identifies protection and rotation of onboarding credentials as a customer responsibility.

Organizing Arc-Enabled Servers

The subscription, resource group, and management-group hierarchy affects who can manage connected servers.

A recommended design is to organize servers according to:

Environment
Business unit
Data sensitivity
Administrative ownership
Compliance requirements
Production versus nonproduction status
Geographic or regulatory boundaries

Example structure

			
Management Group
└── Hybrid Security
    ├── Production Servers Subscription
    │   ├── Critical Servers Resource Group
    │   └── Application Servers Resource Group
    └── Nonproduction Servers Subscription
        ├── Development Resource Group
        └── Testing Resource Group

		

This structure allows administrators to apply different:

RBAC assignments
Azure Policy assignments
Defender plans
Monitoring configurations
Compliance requirements

Why resource placement matters

Azure RBAC permissions inherited from a subscription or resource group can grant users access to connected servers. Therefore, placing highly sensitive servers in a broadly administered resource group may unintentionally expand administrative access.

Protecting Tier 0 and Highly Sensitive Servers

Tier 0 assets may include:

Active Directory domain controllers
Certificate authorities
Privileged identity infrastructure
Highly sensitive application servers
Systems that control other security systems

Connecting these systems to Azure Arc can provide valuable security visibility, but it also introduces an additional management control plane.

Recommended precautions

For sensitive servers:

Use a dedicated subscription where practical.
Minimize persistent administrators.
Review inherited RBAC permissions.
Review management-group policies.
Restrict extension deployment.
Disable unnecessary agent functionality.
Monitor all management operations.
Keep the Connected Machine agent updated.
Ensure onboarding credentials are protected.
Apply only required security and management services.

Microsoft specifically recommends extra care when connecting Tier 0 assets because subscription and management-group administrators may be able to grant themselves access to the Arc-enabled server resource.

Agent and Extension Updates

The Connected Machine agent and its extensions are security-sensitive components.

Organizations should establish processes to:

Monitor agent versions
Apply agent updates
Update extensions
Remove obsolete extensions
Test updates before broad deployment
Monitor failed updates
Confirm that security agents remain operational

Keeping the operating system updated remains the customer’s responsibility. Azure Arc does not automatically make the underlying operating system secure.

Azure Update Manager or other supported update-management capabilities can help coordinate operating-system updates across Arc-enabled servers.

Shared Responsibility Model

Security for Arc-enabled servers is shared between Microsoft and the customer.

Microsoft responsibilities

Microsoft is responsible for:

Securing the Azure service
Protecting system metadata stored in Azure
Operating the Azure management platform
Publishing agent updates
Documenting security features and limitations

Customer responsibilities

The customer is responsible for:

Securing the physical or virtual server
Managing operating-system security
Managing RBAC access
Protecting onboarding credentials
Updating the agent and extensions
Configuring network access
Applying security policies
Reviewing security recommendations
Determining regulatory compliance
Securing the infrastructure hosting the server

Connecting a server to Azure Arc does not transfer responsibility for the guest operating system or underlying infrastructure to Microsoft.

Common Security Mistakes

Mistake 1: Treating Azure Arc as an endpoint-protection product

Azure Arc provides management connectivity and resource representation. Endpoint protection normally requires Defender for Endpoint or another supported security solution.

Mistake 2: Assuming onboarding automatically enables every Defender capability

The appropriate Defender plan, agents, extensions, and configuration are still required.

Mistake 3: Assigning excessive RBAC permissions

Subscription and resource-group administrators may gain broad control over Arc-enabled servers. Use least privilege and carefully designed resource groups.

Mistake 4: Storing service principal secrets in scripts

Onboarding scripts containing credentials can expose the organization to credential theft. Use secure credential handling and rotate credentials regularly.

Mistake 5: Allowing unrestricted extension installation

Extensions can perform privileged actions. Control extension deployment and use allowlists when appropriate.

Mistake 6: Assuming private endpoints remove all network requirements

Private endpoints may reduce exposure, but Microsoft Entra ID and some extensions may still require access to other endpoints.

Mistake 7: Ignoring the underlying server

Azure Arc does not replace:

Operating-system patching
Local firewall configuration
Endpoint protection
Application security
Backup
Identity hardening
Physical security
Network segmentation

Example: Securing an On-Premises Linux Server

An organization has an on-premises Linux server hosting a critical application.

The organization wants to:

Register the server in Azure
Apply a security baseline
Monitor security events
Detect vulnerabilities
Centralize security alerts
Restrict administrative access

A possible implementation is:

Install the Azure Connected Machine agent.
Register the server in an approved Azure subscription and resource group.
Enable Microsoft Defender for Servers Plan 2 if required.
Deploy the required Defender for Endpoint and monitoring components.
Connect the relevant logs to Microsoft Sentinel.
Assign Azure Policy for required configuration.
Apply Azure Machine Configuration policies.
Review Defender for Cloud recommendations.
Remediate vulnerabilities and configuration issues.
Monitor agent and extension health.
Review RBAC assignments regularly.
Protect the onboarding credentials and update processes.

This design extends Azure security management without moving the Linux server into Azure.

Example: Securing AWS Virtual Machines

An organization runs application servers in AWS but wants centralized security monitoring in Azure.

A typical approach is:

Connect the AWS environment to Microsoft Defender for Cloud using the supported multicloud connector.
Allow the connector to deploy or onboard the required Azure Arc components.
Verify that the AWS machines appear as Arc-enabled servers.
Enable the appropriate Defender for Servers plan.
Deploy required security agents or extensions.
Review Defender for Cloud recommendations and alerts.
Send relevant security events to Microsoft Sentinel.
Use Azure Policy and machine configuration to evaluate required settings.

The multicloud connector can simplify onboarding by handling the Azure Arc deployment for supported AWS and GCP scenarios.

Exam-Focused Comparison

Service or feature	Primary purpose
Azure Arc-enabled servers	Connect and manage external servers through Azure
Azure Connected Machine agent	Establishes and maintains the server-to-Azure relationship
Microsoft Defender for Cloud	Centralized security posture management and workload protection
Microsoft Defender for Servers	Security protection for supported servers
Microsoft Defender for Endpoint	Endpoint detection, response, and vulnerability capabilities
Microsoft Sentinel	Centralized security event analysis and response
Azure Policy	Governance and compliance at the Azure resource level
Azure Machine Configuration	Audit or enforce settings inside the guest operating system
Azure Monitor	Monitoring, metrics, and logs
Azure Update Manager	Update management across supported machines
Azure RBAC	Controls who can manage Arc-enabled resources

Key Exam Takeaways

Remember these points for the SC-500 exam:

Azure Arc-enabled servers extends Azure management and security capabilities to servers outside Azure.
The Azure Connected Machine agent must be installed on the external server.
An Arc-enabled server becomes an Azure resource with an Azure resource ID.
Azure Arc is not the same as Microsoft Defender for Cloud.
Defender for Cloud and Defender for Servers provide security capabilities after the appropriate plans and agents are configured.
Microsoft Defender for Endpoint provides endpoint protection and detection capabilities.
Microsoft Sentinel can collect and correlate security events from Arc-enabled servers.
Azure Policy can govern Arc-enabled server resources.
Azure Machine Configuration evaluates or enforces settings inside the guest operating system.
Arc communication is primarily outbound from the server to Azure and is encrypted using TLS.
Private endpoints are optional and do not eliminate every public endpoint requirement.
Onboarding credentials and service principal secrets must be protected and rotated.
Extensions are powerful and should be controlled.
RBAC permissions inherited from subscriptions and resource groups can affect access to connected servers.
Tier 0 servers require additional planning and restrictive management controls.
Azure Arc does not replace operating-system security, endpoint protection, patching, or network security.

Practice Exam Questions

Question 1

An organization runs Linux servers in an on-premises datacenter and wants to manage them through Azure Resource Manager without moving them into Azure.

Which service should the organization use?

A. Azure Arc-enabled servers
B. Azure Bastion
C. Azure Virtual Desktop
D. Azure Load Balancer

Answer: A

Explanation: Azure Arc-enabled servers represents supported physical and virtual servers outside Azure as Azure resources that can be managed through Azure Resource Manager.

Question 2

What component must be installed on an on-premises server before it can be connected to Azure Arc-enabled servers?

A. Microsoft Sentinel agent only
B. Azure Connected Machine agent
C. Azure Application Gateway agent
D. Azure Storage Explorer

Answer: B

Explanation: The Azure Connected Machine agent establishes the relationship between the external server and the Azure subscription.

Question 3

Which statement best describes the normal network communication model for Azure Arc-enabled servers?

A. Azure requires inbound RDP access to every connected server
B. Azure connects to the server through an inbound SSH tunnel by default
C. The Connected Machine agent primarily establishes outbound encrypted connections to Azure
D. The server must expose all management ports to the public internet

Answer: C

Explanation: Azure Arc primarily uses outbound communication from the server to Azure. The communication is encrypted using TLS, reducing the need for inbound management access.

Question 4

An organization wants to evaluate whether Arc-enabled servers comply with a required password policy and operating-system security configuration.

Which capability is most appropriate?

A. Azure Load Balancer health probes
B. Azure Resource Locks
C. Azure Machine Configuration
D. Azure Traffic Manager

Answer: C

Explanation: Azure Machine Configuration evaluates or enforces settings inside the guest operating system, such as password policies and security configuration.

Question 5

An organization connects its on-premises servers to Azure Arc and then enables Microsoft Defender for Servers Plan 2.

Which additional capability may be available through Plan 2?

A. File Integrity Monitoring and just-in-time VM access
B. Automatic conversion of the server into an Azure VM
C. Replacement of the server’s operating system
D. Automatic creation of a public IP address for the server

Answer: A

Explanation: Defender for Servers Plan 2 includes additional capabilities such as File Integrity Monitoring and just-in-time VM access, subject to supported configurations.

Question 6

A security team wants to centralize and correlate security events from Azure VMs, on-premises servers, and AWS virtual machines.

Which service should be used for centralized security information and event management?

A. Azure DNS
B. Microsoft Sentinel
C. Azure Resource Manager locks
D. Azure Container Registry

Answer: B

Explanation: Microsoft Sentinel can collect, analyze, correlate, and respond to security events from multiple environments, including Arc-enabled servers.

Question 7

An administrator wants to prevent users from installing unauthorized extensions on Arc-enabled servers.

Which control should be considered?

A. Azure Policy and Azure Arc extension controls
B. Azure CDN caching rules
C. Azure Front Door routing rules
D. Azure Storage lifecycle management

Answer: A

Explanation: Extensions can perform powerful operations on connected servers. Azure Policy and available Arc agent security controls can help restrict or govern extension deployment.

Question 8

An organization is onboarding hundreds of servers using a service principal.

Which action best protects the onboarding process?

A. Assign the service principal the Owner role on every subscription
B. Store the client secret in a publicly accessible script
C. Grant only required permissions and protect and rotate the credentials
D. Disable Azure RBAC after onboarding is complete

Answer: C

Explanation: Onboarding credentials should be protected, granted only the permissions required, and rotated regularly. Excessive permissions and exposed secrets create significant security risks.

Question 9

A company wants to isolate highly sensitive domain controllers that are connected through Azure Arc from ordinary application servers.

Which design is most appropriate?

A. Place all servers in one broadly administered resource group
B. Use a dedicated subscription or tightly controlled resource hierarchy with minimal persistent administrators
C. Give every administrator the Owner role
D. Disable all Azure Policy assignments

Answer: B

Explanation: Tier 0 assets require careful control of inherited permissions and management access. A dedicated subscription or tightly controlled hierarchy can reduce the number of users and policies able to manage the servers.

Question 10

Which statement correctly distinguishes Azure Arc-enabled servers from Microsoft Defender for Cloud?

A. Azure Arc provides endpoint antivirus, while Defender for Cloud only registers resources
B. Azure Arc connects and represents external servers in Azure, while Defender for Cloud provides security posture and workload protection capabilities
C. Azure Arc is used only for Azure VMs, while Defender for Cloud is used only for on-premises servers
D. Azure Arc replaces Azure Policy and Microsoft Sentinel

Answer: B

Explanation: Azure Arc provides the connection and Azure resource representation for supported external servers. Defender for Cloud provides security posture management and workload protection capabilities after the appropriate plans and configurations are enabled.

Go to the SC-500 Exam Prep Hub main page

Microsoft Certification, Cloud computing, azure, security, SC-500 October 10, 2026

Onboard servers to Defender for Servers in Defender for Cloud, including hybrid and multicloud scenarios (SC-500 Exam Prep)

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)
      --> Onboard servers to Defender for Servers in Defender for Cloud, including hybrid and multicloud scenarios

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.

Introduction

Secure compute (20–25%) → Implement security for servers and virtual machines (VMs)

This topic focuses on how to onboard servers to Microsoft Defender for Servers through Microsoft Defender for Cloud, including servers running in:

Microsoft Azure
On-premises datacenters
Amazon Web Services (AWS)
Google Cloud Platform (GCP)
Other supported hybrid environments

The goal is to extend security posture management, vulnerability assessment, endpoint detection and response, and other workload protection capabilities beyond Azure.

1. What Is Microsoft Defender for Servers?

Microsoft Defender for Servers is a cloud workload protection plan in Microsoft Defender for Cloud that helps protect Windows and Linux servers and virtual machines.

It provides capabilities such as:

Security recommendations
Vulnerability assessment
Microsoft Defender for Endpoint integration
Endpoint detection and response (EDR)
Threat detection and investigation
File Integrity Monitoring
Agentless software inventory
Agentless secret scanning
Agentless malware scanning
Security configuration assessment
Regulatory compliance reporting
Just-in-time VM access in supported scenarios
Security posture visibility across hybrid and multicloud environments

Defender for Servers can protect servers running in Azure, on-premises environments, AWS, and GCP.

However, Defender for Servers does not replace operating-system hardening, patch management, identity security, network segmentation, or application security. It extends Microsoft’s security management and protection capabilities to supported servers.

2. Understanding the Main Components

Several services work together when protecting non-Azure servers.

Microsoft Defender for Cloud

Defender for Cloud provides:

Cloud security posture management
Security recommendations
Regulatory compliance dashboards
Workload protection plans
Security alerts
Centralized security visibility

Defender for Cloud is the primary management experience where you enable Defender for Servers and review recommendations and alerts.

Azure Arc-Enabled Servers

Azure Arc-enabled servers allows a physical or virtual server outside Azure to become an Azure resource.

After onboarding:

The server receives an Azure resource ID.
It can be placed in an Azure resource group.
Azure RBAC can be applied.
Azure Policy can evaluate the resource.
Azure extensions can be deployed.
Defender for Cloud can use the server as part of its protected server inventory.

Azure Arc provides the management connection between the external server and Azure.

Azure Connected Machine Agent

The Azure Connected Machine agent is installed on the server.

The agent:

Establishes the server’s relationship with Azure.
Communicates outbound to Azure.
Provides the Azure resource identity.
Enables supported extensions.
Allows Azure services to evaluate and manage the connected machine.
Helps Defender for Cloud deploy required security components.

Azure does not generally initiate inbound management connections into the customer’s network. The agent establishes outbound communication to Azure over encrypted connections.

Microsoft Defender for Endpoint

Defender for Servers integrates with Microsoft Defender for Endpoint to provide endpoint protection and EDR capabilities.

Defender for Endpoint can provide:

Antivirus and antimalware protection
Attack surface reduction
Threat detection
Behavioral analysis
Threat hunting
Automated investigation and response
Endpoint security alerts

Defender for Servers Plan 1 and Plan 2 provide Defender for Endpoint capabilities through the Defender for Cloud integration.

3. Defender for Servers Plan 1 and Plan 2

Defender for Servers provides two primary paid plans.

Plan 1

Plan 1 is the entry-level plan and focuses primarily on endpoint protection through Microsoft Defender for Endpoint integration.

Important capabilities include:

Microsoft Defender for Endpoint integration
Endpoint detection and response
Antivirus and antimalware capabilities
Threat detection and investigation
Attack surface reduction
Security recommendations

Plan 2

Plan 2 includes the capabilities of Plan 1 and adds advanced server protection and assessment capabilities.

Depending on the supported server type and scenario, Plan 2 can provide capabilities such as:

File Integrity Monitoring
Just-in-time VM access
Agentless scanning
Advanced vulnerability assessment
Agentless software inventory
Agentless secret scanning
Agentless malware scanning
Additional security posture assessments
System updates and patch-management capabilities

The exact feature availability depends on the operating system, cloud environment, onboarding method, and current Defender for Cloud support matrix.

Exam Tip

Do not assume that every Defender for Servers feature is available for every server type.

For example:

Some Azure VM features are not available for Arc-enabled servers.
Some features available for Azure VMs are not available for AWS or GCP machines.
Some Plan 2 capabilities require Azure Arc.
Direct Defender for Endpoint onboarding does not provide the complete set of Defender for Servers capabilities.

4. Azure VMs Versus Hybrid and Multicloud Servers

Azure Virtual Machines

Azure VMs are already Azure resources. Defender for Cloud can associate them directly with the subscription and resource group where they exist.

The onboarding process generally involves:

Enable Defender for Servers for the subscription.
Select Plan 1 or Plan 2.
Configure the required agent or agentless capabilities.
Verify that the VM is protected.

On-Premises Servers

On-premises servers should generally be onboarded as Azure Arc-enabled servers.

The server remains physically in the organization’s datacenter, but Azure represents it as a resource for management and security purposes.

AWS and GCP Servers

AWS and GCP environments can be connected to Defender for Cloud through native cloud connectors.

For complete server protection, AWS and GCP machines are generally onboarded as Azure Arc-enabled machines. Microsoft recommends onboarding AWS and GCP machines as Arc-enabled servers to take advantage of the full Defender for Servers capability set.

5. High-Level Onboarding Architecture

The typical hybrid or multicloud architecture is:

			
On-premises / AWS / GCP Server
            |
            | Azure Connected Machine agent
            |
            v
     Azure Arc-enabled server
            |
            v
     Microsoft Defender for Cloud
            |
            +--> Defender for Servers
            |
            +--> Microsoft Defender for Endpoint
            |
            +--> Vulnerability Assessment
            |
            +--> Azure Policy / Machine Configuration
            |
            +--> Azure Monitor / Log Analytics
            |
            +--> Microsoft Sentinel

		

The Azure Arc agent provides the connection, while Defender for Cloud provides the security management and protection experience.

6. Planning Before Onboarding

Before onboarding servers, plan the following.

Subscription and Resource Group Design

Decide:

Which Azure subscription will contain the connected servers
Which resource groups will be used
Whether servers should be grouped by environment, business unit, application, or ownership
Which administrators need access
Whether Tier 0 or highly sensitive servers require a dedicated subscription or resource group

Resource groups can be used to apply access control and organize servers according to operational responsibility.

Azure Region and Data Residency

The Azure region selected for Arc-enabled servers affects where resource metadata and certain security-related data are processed or stored.

Before onboarding, evaluate:

Regulatory requirements
Data residency requirements
Internal security policies
Cross-border data transfer restrictions
Log storage locations
Defender for Cloud and Defender for Endpoint data-handling requirements

CSPM capabilities are generally agentless, while workload protection capabilities can require agents and extensions. Therefore, data residency planning must consider both the Azure service and the agents deployed to the server.

Supported Operating Systems

Verify that the server’s:

Operating system
Version
Architecture
Installed dependencies
Network configuration

are supported by Azure Arc and Defender for Servers.

An unsupported operating system can prevent successful onboarding or limit available protection features.

Network Connectivity

The server must be able to communicate outbound to required Azure endpoints.

Review:

Firewall rules
Proxy configuration
DNS resolution
TLS inspection
Outbound port 443 access
Private endpoint requirements
AWS or GCP connector-specific endpoints

Most Arc communication is outbound and encrypted using TLS. Extensions may require additional endpoints beyond those required by the core Arc agent.

7. Required Permissions and Identity

Azure Permissions

The person or automation process performing onboarding needs sufficient permissions to:

Register or use the required resource providers
Create Azure Arc resources
Place resources in the target resource group
Enable Defender for Cloud plans
Configure extensions or related services

Use the principle of least privilege. Avoid granting subscription-wide Owner access when a narrower role is sufficient.

Onboarding Credentials

Onboarding credentials must be protected because they can be used to create or connect resources in Azure.

Best practices include:

Use a dedicated onboarding identity.
Use least-privilege permissions.
Avoid embedding credentials in scripts or source code.
Protect service principal secrets.
Rotate credentials regularly.
Prefer short-lived or federated authentication where supported.
Remove temporary onboarding permissions after deployment.
Store secrets in a secure secret-management service.

Local Server Permissions

Installing the Azure Connected Machine agent generally requires administrative privileges on the server.

After installation, the agent’s service model is designed to avoid requiring a permanently privileged domain service account. Microsoft documents different service-account behavior for Windows and Linux, and domain-joined service accounts or alternate user identities are not supported for the agent service model.

8. Onboarding On-Premises Servers

A typical on-premises onboarding process is:

Step 1: Prepare the Environment

Confirm:

Azure subscription availability
Target resource group
Azure region
Supported operating system
Required outbound connectivity
Appropriate Azure permissions
Defender for Cloud configuration

Step 2: Install the Azure Connected Machine Agent

Install the Azure Connected Machine agent on the server.

The agent can be installed:

Manually
Through scripted deployment
Through configuration-management tools
At scale using supported automation methods

Step 3: Authenticate the Machine

Use an approved onboarding method, such as:

Interactive authentication
Service principal authentication
Other supported automated authentication methods

The authentication method should be selected based on the scale of deployment and the organization’s identity-management standards.

Step 4: Connect the Server to Azure

After successful authentication, the server appears as an Azure Arc-enabled server.

It receives:

An Azure resource ID
A resource group association
A location
A managed identity
A connection status

Step 5: Enable Defender for Servers

Enable Defender for Servers for the subscription or appropriate scope.

Select Plan 1 or Plan 2 based on the required capabilities and licensing needs.

Step 6: Verify Protection

Verify:

The server appears in Defender for Cloud.
The Arc connection is healthy.
Defender for Endpoint is onboarded where required.
Vulnerability assessment is active.
Security recommendations are being generated.
Security alerts can be viewed.
Required extensions are provisioned successfully.

Microsoft provides a workflow for connecting on-premises machines to Defender for Cloud through Azure Arc and verifying the Defender for Endpoint integration.

9. Onboarding AWS Servers

AWS servers are generally connected through a native AWS connector in Defender for Cloud.

The process typically includes:

Connect the AWS account to Defender for Cloud.
Configure the required AWS IAM permissions.
Select the subscriptions and regions to protect.
Enable the appropriate Defender for Cloud plans.
Configure Azure Arc onboarding for supported EC2 instances.
Install or provision the Azure Connected Machine agent.
Enable Defender for Servers.
Verify security coverage.

AWS Systems Manager Agent can be used to help provision the Azure Arc agent automatically on supported AWS EC2 instances.

For full Defender for Servers functionality, AWS machines generally require:

Azure Arc agent
Microsoft Defender for Endpoint integration
Vulnerability assessment
Required agentless scanning capabilities
Appropriate AWS and Azure permissions
Required outbound network access

AWS and GCP server support is not identical. For example, some network-based security alerts and just-in-time access capabilities have different availability depending on the cloud platform.

10. Onboarding GCP Servers

GCP servers are connected through a native GCP connector in Defender for Cloud.

The process typically includes:

Connect the GCP project to Defender for Cloud.
Configure the required GCP permissions.
Select the projects and resources to protect.
Enable the required Defender for Cloud plans.
Configure Azure Arc onboarding.
Install or provision the Azure Connected Machine agent.
Enable Defender for Servers.
Verify that the server appears in Defender for Cloud.

The GCP OS Config agent can be used to help provision the Azure Arc agent automatically on supported Google Compute Engine instances.

Required components can include:

Azure Arc agent
Microsoft Defender for Endpoint
Vulnerability assessment
Agentless scanning
GCP IAM permissions
Required outbound network connectivity

GCP and AWS machines can both receive Defender for Servers protection, but feature support must be checked against the current support matrix.

11. Direct Defender for Endpoint Onboarding Versus Azure Arc

Some non-Azure servers can be onboarded directly to Microsoft Defender for Endpoint.

However, direct onboarding is not equivalent to onboarding through Azure Arc.

Direct Defender for Endpoint onboarding can provide endpoint protection and EDR capabilities, but some Defender for Servers Plan 2 capabilities still require Azure Arc.

Microsoft documents that directly onboarded servers receive Plan 1 capabilities and selected additional capabilities, while some Plan 2 features require Arc-enabled onboarding.

Use Azure Arc When You Need:

Azure resource representation
Azure RBAC
Azure Policy
Machine Configuration
Azure extensions
Defender for Servers capabilities that require Arc
Centralized hybrid and multicloud inventory
Azure management and governance
Integration with other Azure services

Use Direct Defender for Endpoint Onboarding When:

Endpoint protection is the primary requirement
Azure Arc is not appropriate for the scenario
The required Defender for Servers features do not depend on Arc
The organization wants direct EDR onboarding

For exam questions, carefully distinguish between Defender for Endpoint onboarding and Defender for Servers onboarding through Azure Arc.

12. Vulnerability Assessment

Defender for Servers can provide vulnerability assessment through supported capabilities, including:

Microsoft Defender Vulnerability Management
Integrated vulnerability assessment solutions
Agentless vulnerability scanning in supported scenarios

Vulnerability assessment helps identify:

Missing security updates
Vulnerable software
Unsupported software
Misconfigured applications
Security weaknesses that attackers could exploit

The assessment method depends on the server type, operating system, Defender for Servers plan, and current feature support.

Agent-Based Assessment

An agent-based solution runs on the server and can collect detailed information about software and vulnerabilities.

Agentless Assessment

Agentless assessment can analyze supported resources without installing a traditional scanning agent on the operating system.

Agentless capabilities may be available for:

Software inventory
Vulnerability assessment
Secret scanning
Malware scanning
Other supported assessments

Agentless features are not universally available across all operating systems and cloud environments.

13. Microsoft Defender for Endpoint Integration

Defender for Servers uses Microsoft Defender for Endpoint to provide endpoint protection.

The integration can provide:

Endpoint detection and response
Antivirus
Threat intelligence
Behavioral detections
Automated investigation and response
Threat hunting
Attack surface reduction
Security alerts

When Defender for Endpoint detects a threat, the alert can be surfaced in Defender for Cloud. Security teams can pivot to the Defender for Endpoint experience for deeper investigation.

This integration is particularly useful when an organization wants one endpoint security platform across Azure, on-premises, AWS, and GCP servers.

14. Security Recommendations and Compliance

After servers are connected, Defender for Cloud can evaluate their security posture.

Recommendations can address:

Missing operating-system updates
Weak security configurations
Missing endpoint protection
Vulnerable software
Unprotected servers
Insecure network configurations
Missing disk encryption
File integrity concerns
Security baseline deviations

Defender for Cloud can also provide regulatory compliance dashboards and reports.

The compliance dashboard does not automatically mean that the organization is compliant. It provides an assessment of how resources compare with selected regulatory standards and security controls.

15. Azure Policy and Machine Configuration

Azure Policy can be used to govern Arc-enabled servers.

Examples include:

Require specific tags.
Restrict allowed resource locations.
Audit whether servers are connected.
Audit security configuration.
Enforce configuration requirements.
Deploy required extensions.
Identify noncompliant machines.

Azure Machine Configuration, formerly associated with guest configuration, can evaluate and enforce settings inside supported servers.

Examples include:

Password policy settings
Security baseline settings
Required services
Registry settings
File permissions
Operating-system configuration
Compliance with organizational standards

Azure Policy evaluates the Azure resource and can use machine configuration to assess settings inside the operating system.

Important Security Consideration

Extensions can perform powerful operations on a connected machine. Therefore:

Restrict who can deploy extensions.
Use RBAC carefully.
Limit extension permissions.
Review inherited policy assignments.
Use local agent security controls where stronger restrictions are required.

For highly sensitive or Tier 0 servers, Microsoft recommends stronger isolation, dedicated subscriptions, limited persistent administration, and careful review of inherited access and policies.

16. Network Requirements

The Azure Connected Machine agent normally communicates outbound to Azure.

Common requirements include:

DNS resolution
Outbound HTTPS connectivity
Port 443 access
Access to required Azure endpoints
Proxy configuration when applicable
Trusted TLS certificates
Firewall allowlists

For AWS and GCP deployments, additional cloud-specific endpoints may be required.

TLS Inspection

TLS inspection can work if:

The server trusts the inspection certificate.
The inspection device does not interfere with the connection.
Required extensions do not use certificate pinning.

Some extensions may use certificate pinning, which can cause failures when traffic is intercepted or modified.

Private Endpoints

Private endpoints can be used for supported scenarios to restrict traffic paths.

However:

Not every Arc endpoint supports private endpoints.
Microsoft Entra ID may still require firewall exceptions.
SSH and Windows Admin Center access over a private endpoint are not automatically supported by the Arc connection.
Extension-specific connectivity requirements may remain.

17. Monitoring and Logging

Defender for Servers should be monitored after onboarding.

Check:

Arc agent connection status
Last heartbeat
Defender for Endpoint health
Extension provisioning status
Vulnerability assessment status
Policy compliance
Security recommendations
Security alerts
Log ingestion
Data collection configuration

Azure Monitor and Log Analytics can be used for supported monitoring and logging scenarios.

Microsoft Sentinel can provide centralized security information and event management across:

Azure
On-premises servers
AWS
GCP
Microsoft Defender for Cloud
Microsoft Defender for Endpoint
Other security products

Defender for Cloud integrates with Microsoft Sentinel so that security alerts can be centralized for investigation, correlation, and automated response.

18. Common Onboarding Problems

Problem 1: The Server Does Not Appear in Azure

Possible causes include:

Invalid onboarding credentials
Insufficient Azure permissions
Failed agent installation
Unsupported operating system
Blocked outbound connectivity
Incorrect subscription or resource group
Failed authentication

Problem 2: The Arc Agent Is Connected but Defender for Servers Is Not Active

Possible causes include:

Defender for Servers is not enabled for the correct subscription.
The server is associated with a different subscription.
The required plan has not been selected.
The Defender for Endpoint extension failed.
The server is not supported for the selected capability.
Licensing or provisioning has not completed.

Problem 3: Defender for Endpoint Is Not Onboarded

Check:

Extension provisioning status
Operating-system support
Outbound connectivity
Proxy and TLS inspection
Defender for Endpoint licensing
Conflicting endpoint security software
Local administrative permissions

Problem 4: Vulnerability Data Is Missing

Possible causes include:

Vulnerability assessment is not enabled.
The required agent or extension failed.
The server is not supported.
The assessment has not completed its initial scan.
Network access is blocked.
The selected Defender for Servers plan does not include the required capability.

Problem 5: Policy Reports Noncompliance

Possible causes include:

The server does not meet the assigned configuration.
The policy assignment is inherited.
The machine configuration extension is missing.
The policy has not evaluated recently.
The server is disconnected.
The policy definition does not support the operating system.

19. Best Practices

Use a Standardized Onboarding Process

Create a repeatable process that includes:

Inventory the server.
Confirm support.
Assign the target subscription and resource group.
Validate network access.
Use least-privilege onboarding credentials.
Install the Arc agent.
Enable Defender for Servers.
Verify protection.
Apply policies and security baselines.
Monitor the server continuously.

Onboard at Scale

For large environments, use:

Automation
Infrastructure as code
Configuration-management tools
AWS Systems Manager
GCP OS Config
Standardized deployment scripts
Centralized policy assignments

Protect Onboarding Credentials

Do not store service principal secrets in:

Source code
Public repositories
Unencrypted scripts
Shared documents
Local administrator profiles

Restrict Administrative Access

Use:

Azure RBAC
Privileged Identity Management
Just-in-time access where supported
Separate administrator roles
Dedicated subscriptions for sensitive resources
Resource-group-level permissions

Monitor Agent and Extension Health

A connected server is not necessarily a fully protected server. Confirm that the required security extensions and Defender for Endpoint components are installed and healthy.

Validate Feature Availability

Always verify whether a feature is supported for:

Azure VMs
Arc-enabled servers
AWS machines
GCP machines
Windows
Linux
Plan 1
Plan 2

20. Key Exam Takeaways

Remember these points:

Defender for Servers protects supported Windows and Linux servers across Azure, on-premises, AWS, and GCP.
Azure Arc is the primary connection method for non-Azure servers when full Defender for Servers capabilities are required.
The Azure Connected Machine agent establishes the server’s relationship with Azure.
Azure Arc-enabled servers become Azure resources with resource IDs and resource-group placement.
Defender for Endpoint provides core EDR capabilities.
Plan 2 includes additional advanced capabilities, but feature availability varies by environment.
Direct Defender for Endpoint onboarding is not equivalent to full Azure Arc onboarding.
AWS and GCP connectors provide cloud-level visibility, while Arc enables deeper server-level protection.
Azure Policy and Machine Configuration help govern and assess server configuration.
Outbound network connectivity and endpoint allowlisting are essential.
Onboarding credentials must be protected and assigned least-privilege permissions.
A connected Arc server must still be monitored for agent, extension, Defender, and policy health.

Practice Exam Questions

Question 1

An organization has 200 Windows servers running in an on-premises datacenter. The organization wants to manage them through Azure and use Defender for Servers capabilities that require Azure resource representation.

What should the organization do?

A. Install only the Microsoft Defender Antivirus client on each server.
B. Onboard the servers as Azure Arc-enabled servers and enable Defender for Servers.
C. Move all servers into Azure Virtual Machines.
D. Connect the servers only to Microsoft Sentinel.

Answer: B

Explanation: Azure Arc-enabled servers allows on-premises servers to become Azure resources. Defender for Servers can then provide security posture and workload protection capabilities without requiring the servers to be moved into Azure.

Question 2

A company wants to protect AWS EC2 instances with Defender for Servers and obtain the broadest supported set of server protection capabilities.

Which component is generally required for the EC2 instances?

A. Azure Bastion
B. Azure Application Gateway
C. Azure VPN Gateway
D. Azure Arc-enabled servers

Answer: D

Explanation: AWS machines should generally be onboarded as Azure Arc-enabled servers to obtain the full set of supported Defender for Servers capabilities. Azure Arc provides the connection between the AWS machine and Azure.

Question 3

Which component establishes the relationship between a non-Azure server and Azure?

A. Azure Connected Machine agent
B. Microsoft Sentinel connector
C. Azure Firewall
D. Azure Resource Graph query

Answer: A

Explanation: The Azure Connected Machine agent is installed on the non-Azure server and establishes its connection to Azure Arc.

Question 4

An administrator directly onboards an on-premises server to Microsoft Defender for Endpoint. The administrator expects every Defender for Servers Plan 2 capability to become available.

Is this expectation correct?

A. Yes. Direct Defender for Endpoint onboarding always provides every Defender for Servers feature.
B. Yes, but only if the server is running Windows Server.
C. No. Some Defender for Servers capabilities still require Azure Arc onboarding.
D. No. Defender for Endpoint cannot protect on-premises servers.

Answer: C

Explanation: Direct Defender for Endpoint onboarding can provide endpoint protection and EDR, but some Defender for Servers Plan 2 capabilities require Azure Arc-enabled onboarding.

Question 5

An organization wants to evaluate security settings inside the operating system of Arc-enabled servers.

Which capability is most appropriate?

A. Azure Resource Graph only
B. Azure Machine Configuration
C. Azure DNS
D. Azure Front Door

Answer: B

Explanation: Azure Machine Configuration can evaluate and, in supported scenarios, enforce settings inside the operating system of Arc-enabled servers.

Question 6

Which network requirement is most commonly necessary for the Azure Connected Machine agent?

A. Inbound TCP port 3389 from Azure
B. Inbound TCP port 22 from Azure
C. Outbound HTTPS connectivity to required Azure endpoints
D. A public IP address assigned to every server

Answer: C

Explanation: Arc communication is generally outbound and encrypted over HTTPS. The server does not normally require inbound RDP or SSH access from Azure for the Arc connection.

Question 7

An organization connects its GCP project to Defender for Cloud. It wants server-level protection for supported Google Compute Engine instances.

What should it plan to deploy?

A. Azure Arc agent and the required Defender for Servers components
B. Azure Bastion on every GCP VM
C. Azure Application Gateway in the GCP project
D. Azure VPN Gateway on every GCP VM

Answer: A

Explanation: The Azure Arc agent connects supported GCP machines to Azure and allows Defender for Cloud to deploy the extensions and components required for Defender for Servers.

Question 8

Which statement best describes the difference between Defender for Cloud CSPM and Defender for Servers workload protection?

A. CSPM always requires the Microsoft Defender for Endpoint agent.
B. Defender for Servers is only available for Azure VMs.
C. CSPM evaluates security posture, while Defender for Servers provides server workload protection and may require agents or extensions.
D. CSPM and Defender for Servers are identical capabilities with different names.

Answer: C

Explanation: CSPM focuses on security posture and can be agentless in multicloud scenarios. Defender for Servers provides workload protection capabilities that can require Azure Arc, Defender for Endpoint, vulnerability assessment, or other components.

Question 9

A server appears as connected in Azure Arc, but no Defender for Endpoint alerts or vulnerability information are appearing.

What should the administrator check first?

A. Whether Azure Front Door is enabled
B. Whether Defender for Servers is enabled for the correct subscription and the required extensions are healthy
C. Whether the server has an Azure public IP address
D. Whether Azure Bastion is deployed

Answer: B

Explanation: An Arc connection alone does not guarantee that Defender for Servers protection is active. The administrator should verify the Defender for Servers plan, subscription association, Defender for Endpoint provisioning, vulnerability assessment, and extension health.

Question 10

An organization is onboarding highly sensitive Tier 0 servers through Azure Arc. Which approach best follows security best practices?

A. Use a dedicated subscription, minimize persistent administrative access, and review inherited policies and permissions.
B. Grant all administrators the Owner role at the tenant root scope.
C. Allow unrestricted extension deployment by all resource users.
D. Store onboarding credentials in a shared script repository.

Answer: A

Explanation: Highly sensitive servers should be isolated where practical, managed using least privilege, and protected from unnecessary administrative access and uncontrolled extension deployment. Onboarding credentials should also be securely managed.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Implement and manage agentless scanning for VMs in Defender for Servers (SC-500 Exam Prep)

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)
      --> Implement and manage agentless scanning for VMs in Defender for Servers

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

Microsoft Defender for Servers is a workload protection plan in Microsoft Defender for Cloud that helps protect Windows and Linux servers running in:

Azure
Amazon Web Services
Google Cloud Platform
On-premises environments
Other environments connected through Azure Arc

One of its important capabilities is vulnerability assessment. Vulnerability assessment identifies operating-system and software weaknesses, outdated applications, missing security updates, and other conditions that could expose a server to attack.

Defender for Servers supports two primary vulnerability-scanning approaches:

Agent-based scanning
Agentless scanning

Understanding the difference between these approaches, when agentless scanning is available, how to enable it, and how its results are used is important for the SC-500 exam.

What Is Agentless Scanning?

Agentless scanning assesses a virtual machine without requiring a vulnerability-scanning agent to be installed inside the guest operating system.

Instead of depending entirely on an operating-system agent, agentless scanning uses cloud-level access and inspection capabilities to collect information about supported machines. This can include information about:

Operating-system configuration
Installed software
Vulnerable applications
Security posture
Machine configuration
Potential exposure to known vulnerabilities

Agentless scanning is particularly useful when:

Installing another agent is undesirable.
The organization already uses a different endpoint security product.
A machine cannot easily support an additional agent.
The organization wants broader visibility into machine posture.
The organization needs to assess supported cloud machines without relying exclusively on an in-guest sensor.

Agentless scanning is not a replacement for every endpoint security capability. It primarily improves assessment and visibility. It does not provide the same continuous in-guest detection and response functionality as Microsoft Defender for Endpoint.

Defender for Servers Plans

Agentless scanning is closely associated with Defender for Servers Plan 2.

Defender for Servers Plan 1

Plan 1 primarily provides core server protection capabilities, including integration with Microsoft Defender for Endpoint.

Important capabilities include:

Endpoint detection and response
Endpoint protection
Software inventory through the integrated endpoint security experience
Agent-based vulnerability assessment through Defender for Endpoint
Security recommendations and alerts in Defender for Cloud

Plan 1 does not provide the full set of Plan 2 agentless assessment capabilities.

Defender for Servers Plan 2

Plan 2 includes the capabilities of Plan 1 and adds more advanced server protection and assessment features, including:

Agentless machine scanning
Additional Microsoft Defender Vulnerability Management capabilities
Compliance and security posture assessment
Operating-system configuration assessment
Operating-system update assessment
File Integrity Monitoring
Additional malware and secrets-scanning capabilities in supported scenarios
Premium vulnerability-management capabilities

The exact capabilities available can vary by operating system, cloud environment, machine type, and supported integration. Therefore, an exam question may require checking not only the selected plan but also whether the machine and environment support the feature.

Microsoft documentation identifies agentless scanning as a Plan 2 capability, while agent-based scanning through Defender for Endpoint is available with both Plan 1 and Plan 2.

Agent-Based Versus Agentless Scanning

Characteristic	Agent-based scanning	Agentless scanning
Requires an in-guest agent	Yes	No vulnerability-scanning agent is required
Common integration	Microsoft Defender for Endpoint	Defender for Servers Plan 2 capabilities
Available with Plan 1	Yes, through Defender for Endpoint	No
Available with Plan 2	Yes	Yes
Provides endpoint detection and response	Through Defender for Endpoint	No
Useful when another EDR is installed	May create overlap or require careful planning	Often useful for supported cloud machines
Data freshness	Often more continuous or current	Depends on collection and assessment process
Coverage	Depends on sensor health and onboarding	Depends on supported machine and cloud scenario
Primary value	In-guest protection and vulnerability visibility	Agentless posture and vulnerability visibility

Agent-Based Scanning

Agent-based scanning uses the Microsoft Defender for Endpoint sensor. The sensor collects endpoint information and supports capabilities such as:

Endpoint detection and response
Software inventory
Vulnerability assessment
Threat detection
Security alerts
Investigation and response

Agent-based scanning is generally valuable when the organization wants continuous endpoint protection and detailed in-guest telemetry.

However, it requires the sensor to be installed, onboarded, supported, and healthy. If the sensor is missing or malfunctioning, vulnerability results may be incomplete or unavailable.

Agentless Scanning

Agentless scanning does not require the same in-guest vulnerability-scanning agent. It can provide vulnerability and posture information for supported machines, including some machines where another endpoint detection product is being used.

Agentless scanning is especially useful when:

The organization does not want to deploy the Defender for Endpoint sensor.
A third-party EDR is already installed.
The machine is a supported Azure virtual machine.
The organization needs additional visibility without modifying the guest operating system.

Agentless scanning does not eliminate all requirements. The machine must still be supported, within the correct Defender for Servers scope, and accessible through the required Azure or connected-cloud mechanisms.

Microsoft Defender Vulnerability Management

Defender for Servers integrates with Microsoft Defender Vulnerability Management, commonly abbreviated as MDVM.

MDVM helps organizations discover and prioritize weaknesses by using information such as:

Vulnerable software
Missing updates
Software versions
Known vulnerabilities
Exposure information
Security recommendations
Remediation priorities

The vulnerability data can be surfaced through the Microsoft Defender security experience and Microsoft Defender for Cloud.

The purpose is not simply to produce a list of Common Vulnerabilities and Exposures (CVEs). The broader goal is to help security teams determine:

Which machines are vulnerable?
Which applications are affected?
How serious is the vulnerability?
Is the vulnerable machine exposed?
Which remediation should be performed first?
Has the vulnerability been remediated?

Plan 2 provides access to additional premium Defender Vulnerability Management capabilities in supported scenarios. These may include advanced assessment and prioritization capabilities such as certificate assessment, security-baseline assessment, and other premium vulnerability-management features.

How Agentless Scanning Works

At a high level, the process is:

Defender for Servers Plan 2 is enabled for the appropriate scope.
Agentless scanning is enabled or remains enabled by default.
Defender for Cloud identifies supported machines within that scope.
Cloud-level assessment mechanisms collect supported machine information.
Defender Vulnerability Management analyzes the collected information.
Vulnerabilities and recommendations are displayed in Defender for Cloud and related Defender experiences.
Administrators remediate the findings.
The environment is rescanned or reassessed to confirm improvement.

Agentless scanning is an assessment capability. It does not automatically install operating-system updates or repair every vulnerability.

For example, if an agentless scan identifies an outdated version of an application, the scan reports the issue. The organization must still:

Update the application.
Remove the application.
Change the configuration.
Replace the virtual machine.
Apply a compensating control.
Accept or formally mitigate the risk.

Enabling Defender for Servers

Defender for Servers is enabled from the environment settings in Microsoft Defender for Cloud.

A typical portal workflow is:

Open Microsoft Defender for Cloud.
Select Environment settings.
Select the relevant:
- Azure subscription
- AWS account
- GCP project
Select Defender plans.
Locate Servers.
Turn the plan on.
Select Plan 1 or Plan 2.
Save the configuration.

The portal may default to a particular plan depending on the current experience. Always verify that the selected plan is the one required by the scenario.

For agentless scanning, the relevant environment must use Defender for Servers Plan 2. Vulnerability assessment is enabled by default when Defender for Servers Plan 1 or Plan 2 is enabled, but the available scanning method depends on the selected plan and environment.

Recommended Scope

Microsoft recommends enabling Defender for Servers at the subscription level when possible.

Subscription-level enablement provides:

Consistent coverage
Easier administration
More predictable licensing
Centralized policy management
Fewer accidentally unprotected machines

Resource-level configuration can be used for exceptions, but it should be applied deliberately. Plan 2 cannot generally be enabled at the individual resource level in the same way as Plan 1; resource-level options may allow Plan 2 to be disabled where appropriate.

Configuring Vulnerability Assessment Settings

After enabling Defender for Servers, vulnerability-assessment settings can be configured from the Defender for Cloud environment settings.

A typical configuration path is:

Open Microsoft Defender for Cloud.
Select Environment settings.
Select the subscription or connected environment.
Open Defender for Servers.
Locate the monitoring or configuration settings.
Find Vulnerability assessment for machines.
Select Edit configuration.
Choose the required scanning configuration.
Apply or save the changes.

Agentless scanning is enabled by default in supported Plan 2 scenarios. However, administrators should verify:

The correct plan is enabled.
The machine is in scope.
The operating system is supported.
The cloud environment is supported.
Required permissions are available.
Required connectivity and onboarding prerequisites are satisfied.
The machine is not excluded by policy or resource-level settings.

Microsoft documentation indicates that agentless scanning is available with Plan 2 and is enabled by default in supported Plan 2 or Defender CSPM scenarios.

Agentless Scanning and Defender CSPM

Agentless scanning can also be available through Defender CSPM, depending on the supported scenario.

Defender CSPM provides cloud security posture management capabilities, while Defender for Servers provides workload protection for servers.

The two services can overlap in certain assessment capabilities. When troubleshooting or designing a solution, determine whether the capability is being provided by:

Defender for Servers Plan 2
Defender CSPM
Defender for Endpoint
Another integrated vulnerability scanner

Do not assume that enabling one plan automatically provides every feature for every machine type.

What Happens When Both Agent-Based and Agentless Scanning Are Available?

In some environments, a machine may be assessed through more than one method.

When both agent-based and agentless results are available, Defender for Cloud generally prioritizes the agent-based results because they are expected to provide fresher endpoint information.

This is important because an agent-based sensor may have more current knowledge of:

Installed software
Running processes
Software changes
Endpoint configuration
Recently remediated vulnerabilities

Agentless results can still be valuable, particularly for machines without a healthy agent or for supported machines where agentless coverage is intentionally used.

The important exam concept is:

Agentless scanning expands coverage, but agent-based results may take precedence when both methods are available.

Using Third-Party Vulnerability Scanners

Organizations may already use a third-party vulnerability-management product, such as Qualys or Rapid7.

Defender for Servers supports certain bring-your-own-license, or BYOL, vulnerability-assessment integrations.

When a third-party scanner is configured:

The partner scanner may provide the primary vulnerability results.
Defender for Cloud can display the partner’s findings.
Agentless scanning may still help assess machines that do not have the partner agent or do not have complete partner findings.
Results and precedence depend on the configured scanner and supported integration.

Avoid deploying multiple vulnerability scanners without a clear design. Multiple scanners can create:

Duplicate findings
Conflicting severity values
Increased resource consumption
Confusing remediation ownership
Unclear source-of-truth decisions

A good design should identify:

Which scanner is authoritative
Which machines are covered by each scanner
How duplicate findings are handled
Which team owns remediation
How exceptions are documented

Agentless Scanning in Hybrid and Multicloud Environments

Defender for Servers supports more than Azure virtual machines.

Azure Virtual Machines

Azure VMs can be protected through the Azure subscription where Defender for Servers is enabled.

The VM must be:

In the correct subscription
Supported by the selected plan
Running a supported operating system
Included in the relevant monitoring scope

AWS and GCP

AWS accounts and GCP projects can be connected to Defender for Cloud.

The recommended approach generally uses Azure Arc-enabled servers to represent and manage connected machines. This provides a consistent Azure control-plane experience for security assessment and management.

The general process is:

Connect the AWS account or GCP project to Defender for Cloud.
Enable the required Defender plan.
Onboard supported machines through the connected-cloud integration.
Verify that the machines appear in Defender for Cloud.
Confirm that the required protection and assessment capabilities are active.

On-Premises Servers

For on-premises servers, Azure Arc is recommended when full Defender for Servers functionality is required.

Directly installing Microsoft Defender for Endpoint on an on-premises machine can provide Plan 1-style endpoint protection functionality. However, it does not necessarily provide the complete set of Defender for Servers Plan 2 capabilities.

For example, under certain scenarios, Plan 2 adds premium vulnerability-management features beyond the basic Defender for Endpoint functionality, but the full set of Plan 2 capabilities requires the supported Defender for Cloud and Azure Arc integration.

The key exam distinction is:

Azure Arc is the preferred connection mechanism for obtaining the broadest Defender for Servers capabilities on non-Azure and on-premises servers.

Permissions

Proper permissions are required to configure and view vulnerability assessment.

A common permission distinction is:

Owner at the resource-group level may be required to deploy or configure the scanner.
Security Reader can view security findings and recommendations but does not have permission to make configuration changes.

The exact permissions depend on the operation being performed. For example:

Viewing recommendations
Enabling a Defender plan
Changing monitoring settings
Deploying required extensions
Configuring a workspace
Remediating a recommendation

These may require different roles.

Use least privilege rather than assigning Owner broadly to security analysts.

Relationship Between Agentless Scanning and EDR

Agentless scanning and endpoint detection and response serve different purposes.

Agentless Scanning

Agentless scanning focuses on assessment and visibility, such as:

Vulnerable software
Machine posture
Configuration weaknesses
Missing updates
Security recommendations

EDR

EDR is provided through Microsoft Defender for Endpoint and focuses on detecting and responding to threats on the endpoint.

EDR capabilities include:

Suspicious-process detection
Behavioral detection
Endpoint alerts
Investigation
Threat hunting
Automated response
Isolation and containment
Evidence collection

Agentless scanning does not replace EDR. A machine can have agentless vulnerability assessment and still require an endpoint protection and detection solution.

EDR Configuration Assessment

Defender for Cloud can assess certain endpoint protection and EDR-related configuration conditions in supported Plan 2 scenarios.

Recommendations may identify conditions such as:

Antivirus protection being disabled
Antivirus being partially configured
Outdated security intelligence
A full or quick scan not having run recently
Endpoint protection settings that do not meet expected requirements

These recommendations help identify machines that may technically have endpoint protection installed but are not adequately configured.

For example, a machine may have antivirus installed but still be at risk because:

Real-time protection is disabled.
Security signatures are outdated.
A required scan has not run.
The endpoint sensor is unhealthy.
The machine is not properly onboarded.

EDR configuration assessment should therefore be treated as a validation and hardening capability, not merely an installation check.

Log Analytics Requirements

Some Defender for Servers Plan 2 capabilities require a Log Analytics workspace or related data-collection configuration.

This is especially important for:

File Integrity Monitoring
Certain data-ingestion benefits
Supported security data collection
Some assessment and monitoring scenarios

Plan 2 may include a free daily data-ingestion benefit for eligible data, but the benefit is not automatic for every data source. The environment must be configured correctly, including the required workspace and supported collection mechanism.

For example, an organization may enable Plan 2 but still fail to receive the expected benefit because:

No Log Analytics workspace is configured.
The machine is not associated with the required workspace.
Azure Monitor Agent is not configured.
The required data collection rule is missing.
The collected data is not eligible for the benefit.

When troubleshooting, distinguish between:

The Defender plan being enabled.
The machine being onboarded.
The required workspace existing.
The correct agent or collection method being configured.
The data actually being collected.

Monitoring and Validating Agentless Scanning

After enabling agentless scanning, validate the configuration rather than assuming it is working.

Check the following:

1. Plan Status

Confirm that Defender for Servers Plan 2 is enabled for the correct subscription or connected environment.

2. Machine Coverage

Verify that the target VM appears in Defender for Cloud and is not excluded by:

Resource-level settings
Azure Policy
Subscription configuration
Unsupported configuration
Scope filters

3. Operating-System Support

Confirm that the operating system and machine type are supported by the selected scanning method.

4. Scanning Configuration

Verify that agentless scanning is enabled where required.

5. Data Freshness

Check when vulnerability information was last updated. Old results may indicate:

Scanning has not completed.
The machine is not reachable through the required mechanism.
The machine is no longer active.
The assessment process is delayed.
The machine is not properly onboarded.

6. Agent Health

If agent-based scanning is also expected, verify the health and onboarding status of the Defender for Endpoint sensor.

7. Findings

Review:

Vulnerability severity
Affected software
Affected machines
Recommended remediation
Exposure information
Whether the finding is current or stale

Common Troubleshooting Scenarios

Scenario 1: The VM Does Not Appear as Protected

Possible causes include:

Defender for Servers is disabled.
The wrong subscription was selected.
The VM is excluded at the resource level.
The machine is unsupported.
The connected AWS or GCP environment is not configured correctly.
Azure Arc onboarding has not completed.

Scenario 2: No Vulnerability Results Are Available

Possible causes include:

Agentless scanning is not enabled.
The machine is not supported.
The machine is not in scope.
The scan has not completed.
Required permissions are missing.
Required connectivity is unavailable.
A third-party scanner is the configured source of results.
The Defender for Endpoint sensor is missing or unhealthy.
The machine is not properly onboarded.

Scenario 3: Agent-Based Results Are Missing

Check:

Defender for Endpoint onboarding
Sensor health
Supported operating system
Network connectivity
Licensing and plan configuration
Whether the machine is reporting to the expected Defender environment

Scenario 4: Agentless Scanning Is Expected but Unavailable

Check:

Whether Plan 2 is enabled
Whether the machine is a supported cloud or connected-server scenario
Whether the machine is connected through the required integration
Whether resource-level settings override subscription-level settings
Whether Defender CSPM or another scanner is providing the capability

Scenario 5: File Integrity Monitoring or Data-Ingestion Benefits Are Missing

Check:

Plan 2 status
Log Analytics workspace configuration
Azure Monitor Agent
Data collection rules
Machine association with the workspace
Eligibility of the collected data

Best Practices

Enable at the Correct Scope

Enable Defender for Servers at the subscription level where practical. Use resource-level exceptions only when there is a documented business or technical reason.

Use Azure Arc for Non-Azure Servers

Use Azure Arc to obtain a consistent management and security experience for on-premises, AWS, and GCP servers.

Avoid Unnecessary Scanner Duplication

If a third-party scanner is already deployed, decide whether it will remain authoritative or whether Defender Vulnerability Management will be used as the primary source.

Monitor Coverage Continuously

Do not assume that a one-time successful onboarding means the machine remains protected. Monitor:

Last-seen time
Agent health
Scan freshness
Coverage status
Security recommendations
EDR alerts

Separate Detection From Assessment

Use vulnerability assessment to identify weaknesses and EDR to detect and respond to active threats. Both capabilities may be required.

Use Least Privilege

Give administrators only the permissions required to configure plans, deploy extensions, view findings, or remediate issues.

Prioritize Findings

Prioritize vulnerabilities using more than CVSS severity alone. Consider:

Internet exposure
Exploit availability
Business criticality
Attack paths
Privileged access
Sensitive data
Compensating controls
Whether exploitation has been observed

Validate Prerequisites

Before enabling a feature, verify:

Plan
Scope
Supported operating system
Cloud environment
Arc status
Required permissions
Workspace requirements
Network connectivity
Existing scanner integrations

Exam-Focused Summary

Remember these key points:

Agentless scanning is primarily associated with Defender for Servers Plan 2.
Agent-based vulnerability scanning through Defender for Endpoint is available with Plan 1 and Plan 2.
Agentless scanning does not require the same in-guest vulnerability-scanning agent.
Agentless scanning does not replace EDR.
Defender for Endpoint provides endpoint detection and response.
Defender Vulnerability Management provides vulnerability and software assessment.
Azure Arc is recommended for full Defender for Servers functionality on non-Azure and on-premises servers.
AWS and GCP environments are connected through Defender for Cloud, generally with Arc-enabled machines.
When both scanning methods are available, agent-based results may take precedence because they are generally fresher.
Third-party scanners such as Qualys or Rapid7 may provide the primary vulnerability results when configured.
Scanning identifies vulnerabilities; it does not automatically patch every machine.
Plan 2 features may require Log Analytics, Azure Monitor Agent, or other prerequisites.
Security Reader can view findings, while configuration and deployment operations require additional permissions.

Practice Exam Questions

Question 1

An organization wants to assess supported Azure virtual machines for software vulnerabilities without installing a vulnerability-scanning agent inside the guest operating system. Which Defender for Servers plan should the organization select?

A. Defender for Servers Plan 1
B. Defender for Servers Plan 2
C. Microsoft Defender for Storage
D. Microsoft Defender for APIs

Answer: B

Explanation: Agentless scanning for supported machines is a Defender for Servers Plan 2 capability. Plan 1 provides core server protection and agent-based vulnerability assessment through Defender for Endpoint, but it does not provide the full Plan 2 agentless-scanning capability.

Question 2

A company uses a third-party endpoint detection and response product on its Azure virtual machines. The company wants vulnerability visibility without deploying the Microsoft Defender for Endpoint sensor to every machine. Which approach is most appropriate for supported machines?

A. Enable Defender for Servers Plan 2 and use agentless scanning
B. Enable only Defender for Servers Plan 1
C. Disable all endpoint protection products
D. Install Azure Bastion on every virtual machine

Answer: A

Explanation: Defender for Servers Plan 2 agentless scanning can provide vulnerability and posture visibility for supported machines without relying exclusively on the Microsoft Defender for Endpoint sensor. It does not replace the organization’s EDR solution.

Question 3

Where should an administrator normally begin when enabling Defender for Servers for an Azure subscription?

A. Azure Storage account networking settings
B. Microsoft Sentinel data connectors
C. Microsoft Defender for Cloud Environment settings
D. Microsoft Entra authentication methods

Answer: C

Explanation: Defender for Servers is enabled through Microsoft Defender for Cloud. The administrator selects Environment settings, chooses the subscription or connected environment, opens Defender plans, enables Servers, selects Plan 1 or Plan 2, and saves the configuration.

Question 4

An organization has on-premises Windows and Linux servers and wants the broadest supported Defender for Servers functionality, including cloud-based security management. What should the organization generally use to connect the servers?

A. Azure Bastion
B. Azure Arc-enabled servers
C. Azure Application Gateway
D. Microsoft Entra Domain Services

Answer: B

Explanation: Azure Arc is the recommended connection mechanism for on-premises and other non-Azure servers when the organization wants the broader Defender for Servers experience. Direct Defender for Endpoint onboarding can provide endpoint functionality, but it does not necessarily provide the full Defender for Servers Plan 2 experience.

Question 5

Which statement correctly describes the relationship between agent-based and agentless vulnerability scanning?

A. Agentless scanning always provides more current endpoint data than agent-based scanning
B. Agent-based scanning requires the Defender for Endpoint sensor, while agentless scanning does not require the same in-guest vulnerability-scanning agent
C. Agent-based scanning is available only with Defender for Servers Plan 2
D. Agentless scanning provides full endpoint detection and response

Answer: B

Explanation: Agent-based scanning uses the Defender for Endpoint sensor. Agentless scanning uses supported cloud-level assessment capabilities and does not require the same in-guest vulnerability-scanning agent. Agentless scanning does not provide full EDR functionality.

Question 6

A security administrator enables Defender for Servers Plan 2 but cannot find File Integrity Monitoring data for a VM. Which prerequisite should the administrator check first?

A. Whether the VM has an Azure public IP address
B. Whether Azure Bastion is deployed
C. Whether the VM is assigned a Microsoft Entra user
D. Whether the required Log Analytics workspace and data-collection configuration are present

Answer: D

Explanation: File Integrity Monitoring and certain Plan 2 data-ingestion capabilities require appropriate Log Analytics and data-collection configuration. The administrator should verify the workspace, Azure Monitor Agent, data collection rules, and machine association.

Question 7

An organization has configured a supported third-party vulnerability scanner through a bring-your-own-license integration. What should administrators expect?

A. The third-party scanner may provide the primary vulnerability results
B. Defender for Servers automatically disables all third-party scanner results
C. Agentless scanning is available only with Plan 1
D. EDR alerts are converted into storage-account recommendations

Answer: A

Explanation: Supported third-party scanners, such as Qualys or Rapid7, may provide the primary vulnerability results when configured. Agentless scanning may still help cover supported machines without the partner agent or without complete partner findings.

Question 8

A security analyst needs to view vulnerability findings and recommendations but should not be able to change Defender for Servers configuration. Which role is most appropriate?

A. Owner
B. Contributor
C. Security Reader
D. Global Administrator

Answer: C

Explanation: Security Reader is intended for viewing security information, including recommendations and findings. Configuration and deployment operations generally require more permissions, such as Owner or another appropriately scoped administrative role.

Question 9

Defender for Cloud reports that a VM has an EDR configuration issue. Which condition could produce this type of recommendation?

A. The VM has no attached data disk
B. Antivirus protection is disabled or security signatures are outdated
C. The VM is located in a virtual network with a subnet
D. The VM has an Azure resource tag

Answer: B

Explanation: EDR and endpoint-protection configuration assessments can identify conditions such as disabled or partially configured antivirus protection, outdated signatures, or scans that have not run recently. These recommendations help identify machines that may have endpoint protection installed but are not adequately configured.

Question 10

A VM has both agent-based and agentless vulnerability results available. Which result is generally given precedence when both methods provide data?

A. Agent-based results, because they generally provide fresher endpoint information
B. Agentless results, because they always replace agent-based results
C. Results from Azure Bastion
D. Results from Microsoft Sentinel only

Answer: A

Explanation: When both methods are available, agent-based results are generally shown because they are expected to provide fresher endpoint information. Agentless scanning remains useful for expanding coverage and assessing supported machines that do not have a healthy or compatible agent.

Go to the SC-500 Exam Prep Hub main page

Microsoft Certification, Cloud computing, azure, security, SC-500 October 10, 2026October 10, 2026

Configure security features on a VM, including secure boot, virtual Trusted Platform Module (vTPM), integrity monitoring, and security type (SC-500 Exam Prep)

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

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Enforce security configuration of Azure-managed servers by using Azure Machine Configuration (SC-500 Exam Prep)

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)
      --> Enforce security configuration of Azure-managed servers by using Azure Machine Configuration

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 Machine Configuration is an Azure governance capability that allows organizations to audit and enforce operating-system settings as code on Azure virtual machines and Azure Arc-enabled servers.

It extends Azure Policy beyond the configuration of Azure resources and into the guest operating system. This makes it possible to establish consistent security baselines, identify machines that do not comply with those baselines, and—when appropriate—automatically correct noncompliant settings.

Azure Machine Configuration is especially useful when an organization manages a large number of Windows and Linux servers across Azure, on-premises environments, other cloud providers, or edge locations.

Why Azure Machine Configuration Is Important

Traditional Azure Policy evaluates many aspects of Azure resources, such as:

Whether a virtual machine uses a particular operating system
Whether a resource has required tags
Whether a storage account allows public access
Whether a virtual machine uses a supported security configuration

However, many important security settings exist inside the guest operating system, including:

Password and account policies
Windows security options
Linux configuration files
Services that must be enabled or disabled
Required applications or packages
File permissions
Audit settings
Operating-system security baseline settings
Organization-specific configuration requirements

Azure Machine Configuration allows these settings to be represented as machine configuration assignments and evaluated through Azure Policy.

This provides a consistent process to:

Define the desired configuration.
Assign the configuration to a scope.
Evaluate machines against the configuration.
Report compliance or noncompliance.
Correct configuration drift when enforcement is enabled.

Azure Machine Configuration and Azure Policy

Azure Machine Configuration works closely with Azure Policy.

Azure Policy determines:

Which machines are in scope
Which configuration should be evaluated
Whether the configuration is audited or enforced
How compliance is reported
Whether remediation should be deployed

Azure Machine Configuration evaluates the actual operating-system settings on the machine.

The relationship can be summarized as follows:

Component	Primary responsibility
Azure Policy	Assigns and governs the configuration
Machine Configuration	Evaluates or applies guest OS settings
Machine Configuration extension	Enables configuration management on Azure VMs
Azure Arc Connected Machine agent	Provides the required capability for Arc-enabled servers
Managed identity	Allows the Azure VM to authenticate to the machine configuration service
Azure Policy Compliance	Displays compliance results

Azure Machine Configuration policies can be assigned at the management group, subscription, or resource-group level. This supports centralized governance across an entire server estate.

Supported Machine Types

Azure Machine Configuration can be used with:

Azure virtual machines
Azure virtual machine scale sets, where supported
Azure Arc-enabled servers
Servers running Windows
Servers running Linux

For Azure VMs, the Machine Configuration extension and a system-assigned managed identity are required.

For Azure Arc-enabled servers, the required functionality is provided through the Azure Connected Machine agent rather than the Azure VM extension.

This allows an organization to use a similar compliance model for:

Azure-hosted servers
On-premises servers
Servers hosted in another cloud
Edge servers connected through Azure Arc

Required Prerequisites

Before assigning machine configuration policies, verify the following prerequisites.

1. Register the Resource Provider

The Microsoft.GuestConfiguration resource provider must be registered for the subscription.

When machine configuration policies are assigned through the Azure portal—or when the subscription is enrolled in Microsoft Defender for Cloud—the provider may be registered automatically. It can also be registered manually through the Azure portal, Azure PowerShell, or Azure CLI.

2. Deploy the Machine Configuration Extension

Azure virtual machines require the Machine Configuration or Guest Configuration extension.

The extension:

Downloads applicable machine configuration assignments
Retrieves configuration dependencies
Evaluates the guest operating system
Applies configuration settings when enforcement is enabled
Reports configuration results

The extension can be deployed individually or at scale by assigning the prerequisite policy initiative:

Deploy prerequisites to enable Guest Configuration policies on virtual machines

The exact policy initiative name may vary slightly as Microsoft updates the service and terminology.

3. Enable a Managed Identity

Azure VMs require a system-assigned managed identity for machine configuration.

The identity allows the VM to authenticate to the machine configuration service without requiring administrators to store credentials on the server.

The prerequisite initiative can automatically create a system-assigned managed identity when one does not already exist.

4. Verify Connectivity

The machine must be able to communicate with the required Azure services.

Network restrictions involving:

Network security groups
Azure Firewall
Proxy servers
Outbound filtering
Private networking
DNS configuration

can prevent the extension from downloading assignments or reporting results.

5. Verify Extension and Agent Versions

For machine configuration packages that apply settings, the Azure VM Guest Configuration extension must meet the supported minimum version. Microsoft currently identifies version 1.26.24 or later for Azure VMs in its custom-policy documentation.

Machine Configuration Enforcement Modes

Azure Machine Configuration supports different ways to manage configuration.

Audit

Audit mode evaluates the machine and reports whether it complies with the desired configuration.

It does not change the machine.

Use Audit mode when:

Establishing an initial security baseline
Discovering configuration drift
Assessing the impact of a new policy
Testing a configuration before enforcement
Identifying exceptions
Preparing for a compliance audit

For example, an audit policy might determine whether Windows servers meet the Azure compute security baseline.

Apply and Monitor

Apply and Monitor applies the configuration and then continues monitoring the machine for changes.

This mode is useful when the organization wants the desired configuration to be established and then monitored for drift.

Apply and AutoCorrect

Apply and AutoCorrect applies the desired configuration and attempts to correct changes that cause the machine to become noncompliant.

This mode is appropriate when a setting must remain consistent and automatic correction is acceptable.

However, automatic correction should be used carefully. Some settings can affect:

Application compatibility
Network connectivity
Authentication
System startup
Legacy workloads
Custom operating-system behavior

Microsoft’s machine configuration tooling supports policy definitions that audit or apply custom configuration packages, including policies generated with the New-GuestConfigurationPolicy PowerShell cmdlet.

Audit First, Enforce Second

A recommended implementation approach is to begin with auditing.

Phase 1: Discover

Identify:

Which machines are in scope
Which operating systems are used
Which applications depend on current settings
Which machines are production systems
Which machines are exceptions
Which security standards must be followed

Phase 2: Audit

Assign the desired baseline in Audit mode.

Review:

Overall compliance
Individual noncompliant machines
Individual failed settings
Configuration conflicts
Unsupported systems
Required exceptions

Phase 3: Remediate

Correct problems manually or through controlled remediation.

For example:

Update an insecure configuration
Install a required package
Disable an unnecessary service
Correct file permissions
Change a security option
Document an approved exception

Phase 4: Enforce

After testing, change the assignment to an enforcement mode.

This reduces the risk that a new configuration will unexpectedly disrupt production workloads.

Built-In Security Baselines

Microsoft provides built-in machine configuration policies for common security requirements.

Examples include:

Windows machines should meet requirements for the Azure compute security baseline
Linux machines should meet requirements for the Azure compute security baseline
Windows machines should use a specified time zone
Linux machines should have specified applications installed
Other operating-system configuration policies

Built-in definitions can be discovered in:

Azure portal → Policy → Definitions

Use filters such as:

Category: Guest Configuration
Policy type: Built-in

A policy definition can be inspected to review:

Its purpose
Supported platforms
Parameters
Version
Policy effect
Required resources
Configuration details

Built-in security baseline policies can be assigned to Azure VMs and, where supported, Azure Arc-enabled servers.

Azure Compute Security Baselines

Security baselines provide a recommended collection of operating-system settings intended to improve the security posture of Windows and Linux machines.

They may include requirements related to:

Account policies
Authentication
Audit policies
Security options
Network security
System services
File permissions
Operating-system behavior

The baseline should not automatically be treated as a universal configuration for every workload. Organizations should evaluate whether particular settings are compatible with:

Business applications
Legacy systems
Domain controllers
Specialized appliances
High-availability systems
Custom Linux distributions
Regulatory requirements
Operational procedures

The current Azure Machine Configuration experience supports customizable security baselines. Administrators can select, exclude, or modify rules and export the resulting settings as a reusable JSON artifact.

Custom Machine Configurations

Built-in policies may not satisfy every organizational requirement.

A custom machine configuration can be used when an organization needs to enforce settings such as:

A required registry value
A specific Linux configuration-file value
A required service state
A required package or application
A particular file permission
A specific security option
An organization-specific hardening requirement

A custom configuration generally involves the following process:

Define the desired configuration.
Create a machine configuration package.
Test the package.
Publish the package to an accessible location.
Create a machine configuration policy definition.
Assign the policy.
Review compliance results.
Remediate or enforce as required.

The configuration package must be accessible to the target machine. When a package is stored in Azure Storage, the appropriate identity and permissions must be configured so that the machine can retrieve it securely.

Custom machine configuration policy definitions commonly use effects such as:

AuditIfNotExists
DeployIfNotExists

The DeployIfNotExists effect can be used to deploy a machine configuration assignment when the required assignment does not exist.

Policy Assignment Scope

A machine configuration policy can be assigned at different scopes.

Management Group

Use a management-group assignment when the configuration should apply across multiple subscriptions.

Subscription

Use a subscription assignment when all or most machines in a subscription should follow the same baseline.

Resource Group

Use a resource-group assignment when the policy should apply to a specific workload or server group.

Exclusions

Exclusions may be necessary for:

Unsupported operating systems
Development machines
Legacy applications
Specialized servers
Disaster-recovery systems
Approved exceptions

Exclusions should be documented and reviewed periodically. An exclusion should not become a permanent way to avoid addressing a known security issue.

Compliance Reporting

After a policy is assigned, compliance information can be reviewed through Azure Policy.

Administrators can identify:

Compliant machines
Noncompliant machines
Machines that have not yet evaluated
Failed configuration settings
Policy assignment status
Remediation status

Machine configuration can also provide per-setting results through the machine’s guest assignments or through the compliance details associated with the Azure Policy assignment.

Compliance reporting is useful for:

Security operations
Internal audits
Regulatory reporting
Vulnerability remediation
Configuration-drift management
Executive security dashboards

Azure Machine Configuration Compared with Other Security Controls

Azure Machine Configuration is not a replacement for every security service.

Security control	Primary purpose
Azure Machine Configuration	Audit and enforce operating-system configuration
Azure Policy	Govern Azure resource configuration and policy compliance
Microsoft Defender for Cloud	Assess security posture and provide recommendations
Microsoft Defender for Servers	Provide server protection, vulnerability assessment, and threat detection capabilities
Azure VM disk encryption	Protect data stored on VM disks
Just-in-time VM access	Reduce exposure of management ports
Azure Bastion	Provide managed remote access without exposing public RDP or SSH ports
Azure Update Manager	Manage operating-system updates
Microsoft Sentinel	Collect, analyze, and respond to security events

A secure VM strategy normally combines several of these controls rather than relying on Machine Configuration alone.

Common Implementation Mistakes

Mistake 1: Enforcing Before Auditing

Applying a baseline immediately can cause unexpected application or connectivity issues.

Better approach: Begin with Audit mode, review failures, test remediation, and then enforce.

Mistake 2: Assuming Azure Policy Automatically Changes Guest Settings

Not every Azure Policy definition changes the operating system.

Better approach: Confirm whether the policy audits configuration, deploys a configuration assignment, or applies settings inside the guest OS.

Mistake 3: Forgetting the Extension

An Azure VM may be in policy scope but still be unable to evaluate guest configuration if the required extension is missing.

Better approach: Deploy the machine configuration prerequisites before assigning configuration policies.

Mistake 4: Forgetting Managed Identity

The VM needs an appropriate identity to communicate with the machine configuration service.

Better approach: Verify that the required system-assigned managed identity is enabled.

Mistake 5: Ignoring Network Restrictions

Outbound network controls can prevent configuration downloads and compliance reporting.

Better approach: Verify DNS, outbound connectivity, firewall rules, proxy settings, and required service access.

Mistake 6: Treating Every Baseline Setting as Universally Appropriate

A baseline may contain settings that conflict with a specialized application.

Better approach: Test settings, document exceptions, and customize the baseline when necessary.

Mistake 7: Confusing Configuration Compliance with Threat Detection

Machine Configuration determines whether settings match a desired state. It does not replace endpoint detection and response or malware protection.

Better approach: Combine configuration enforcement with Defender for Cloud, Defender for Servers, patching, network security, and monitoring.

Recommended Implementation Pattern

A practical enterprise implementation can follow this sequence:

Register Microsoft.GuestConfiguration.
Identify Azure VMs and Arc-enabled servers.
Deploy the machine configuration prerequisites.
Enable required managed identities.
Select a built-in Windows or Linux security baseline.
Customize the baseline if necessary.
Assign the baseline in Audit mode.
Review compliance results.
Remediate failed settings.
Document approved exceptions.
Test enforcement on a pilot group.
Enable Apply and Monitor or Apply and AutoCorrect.
Monitor compliance continuously.
Review baseline versions and update policies as requirements change.

Exam-Focused Summary

For the SC-500 exam, remember these key points:

Azure Machine Configuration manages guest operating-system settings.
Azure Policy provides the assignment and governance framework.
Azure VMs require the Machine Configuration extension and a managed identity.
Azure Arc-enabled servers use the Arc Connected Machine agent.
Machine Configuration supports both Azure and hybrid servers.
Audit mode reports configuration state without changing the machine.
Apply and Monitor applies configuration and monitors for drift.
Apply and AutoCorrect attempts to restore the desired configuration.
Built-in security baselines are available for Windows and Linux.
Custom configurations can address organization-specific requirements.
Audit before enforcing.
Network connectivity and identity configuration are common troubleshooting areas.
Machine Configuration is complementary to Defender for Cloud, disk encryption, JIT VM access, and other security controls.

Practice Exam Questions

Question 1

An organization wants to determine whether its Azure Windows VMs comply with a required operating-system security baseline. The organization does not want to change any settings yet.

Which approach should be used?

A. Apply and AutoCorrect
B. Audit mode
C. Azure VM disk encryption
D. Just-in-time VM access

Answer: B

Explanation: Audit mode evaluates the machine and reports compliance without changing the operating system. This is the recommended starting point before enforcing a new baseline.

Question 2

An administrator wants to manage guest operating-system configuration on Azure virtual machines. Which combination is required for Azure VMs?

A. Azure Bastion and a public IP address
B. Microsoft Sentinel and a Log Analytics workspace
C. Defender for Servers and Azure Firewall
D. Machine Configuration extension and a system-assigned managed identity

Answer: D

Explanation: Azure VMs require the Machine Configuration extension and a system-assigned managed identity. The extension evaluates or applies configuration, while the identity allows the VM to authenticate to the machine configuration service.

Question 3

A company needs to apply the same operating-system security baseline to Azure VMs and on-premises servers connected through Azure Arc.

Which service provides this capability?

A. Azure Machine Configuration
B. Azure Bastion
C. Azure Load Balancer
D. Azure VM Image Builder

Answer: A

Explanation: Azure Machine Configuration supports guest operating-system auditing and enforcement across Azure VMs and Azure Arc-enabled servers.

Question 4

An organization wants a configuration assignment to correct a server setting and continue monitoring the machine for future configuration drift.

Which enforcement mode is most appropriate?

A. Audit
B. Disabled
C. Apply and Monitor
D. Deny

Answer: C

Explanation: Apply and Monitor applies the desired configuration and then monitors the machine for changes. Audit only reports the state, while Deny is an Azure Policy effect and not a Machine Configuration enforcement mode.

Question 5

A security team wants to assign a built-in Windows security baseline to all applicable virtual machines in a subscription.

Where should the team locate the built-in policy definition?

A. Azure portal → Virtual Machines → Extensions
B. Azure portal → Policy → Definitions
C. Azure portal → Microsoft Entra ID → Enterprise applications
D. Azure portal → Network Watcher → Topology

Answer: B

Explanation: Built-in Machine Configuration policies can be discovered under Azure Policy → Definitions. The Guest Configuration category can be used to filter relevant definitions.

Question 6

A custom machine configuration package is published and assigned to a VM, but the VM cannot retrieve the package.

Which issue should be investigated first?

A. Outbound connectivity, identity permissions, and package accessibility
B. Whether the VM has a public IP address
C. Whether Azure Bastion is deployed
D. Whether the VM uses a load balancer

Answer: A

Explanation: The machine must be able to access the configuration package and authenticate appropriately. Network restrictions, missing identity permissions, or an inaccessible package location can prevent evaluation or enforcement.

Question 7

An organization wants to apply a custom configuration assignment automatically when a target machine does not already have the assignment.

Which Azure Policy effect is commonly used for this purpose?

A. Audit
B. Deny
C. Disabled
D. DeployIfNotExists

Answer: D

Explanation: DeployIfNotExists can deploy a machine configuration assignment when the required assignment is missing. This is different from auditing whether the configuration is compliant.

Question 8

An administrator enables a machine configuration policy, but the VM never reports compliance. The VM is in scope and has the required policy assignment.

Which configuration is most likely to require verification?

A. The VM’s display resolution
B. The VM’s managed identity and Machine Configuration extension
C. The VM’s backup retention period
D. The VM’s DNS label

Answer: B

Explanation: The Machine Configuration extension and managed identity are essential for Azure VMs. If either is missing or incorrectly configured, the VM may not be able to retrieve assignments or report results.

Question 9

A security baseline contains a setting that would disrupt a legacy application. The organization still wants to enforce the rest of the baseline.

What is the best approach?

A. Disable all machine configuration policies
B. Ignore the failed compliance results
C. Customize the baseline or document an approved exception for the specific setting
D. Replace Azure Machine Configuration with Azure Bastion

Answer: C

Explanation: Baselines should be tested and adapted to workload requirements. Organizations can customize supported baseline settings or document approved exceptions rather than disabling the entire security program.

Question 10

Which statement best describes Azure Machine Configuration?

A. It replaces endpoint detection and response
B. It encrypts all data stored on Azure VM disks
C. It provides remote desktop access without exposing management ports
D. It audits and enforces desired operating-system configuration on supported machines

Answer: D

Explanation: Azure Machine Configuration focuses on guest operating-system configuration and compliance. It complements, but does not replace, endpoint protection, disk encryption, remote-access security, patching, and threat monitoring.

Go to the SC-500 Exam Prep Hub main page

Microsoft Certification, Cybersecurity, Cloud computing, azure, security, SC-500 October 10, 2026

Detect misconfigurations and runtime risks in container workloads by using Defender for Containers (SC-500 Exam Prep)

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 application platform services
      --> Detect misconfigurations and runtime risks in container workloads by using Defender for Containers

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

Containers provide an efficient way to package and deploy applications, but containerized workloads introduce security considerations that differ from those of traditional virtual machines.

Containers can contain vulnerable software packages, run with excessive privileges, use insecure configurations, expose unnecessary network interfaces, or be compromised while running. Kubernetes environments introduce additional risks involving clusters, nodes, workloads, identities, network policies, and configuration.

Microsoft Defender for Containers is a Microsoft Defender for Cloud workload protection plan designed to help organizations identify and protect container workloads across their cloud and Kubernetes environments.

For the SC-500 exam, an important distinction is that Defender for Containers addresses both security posture/misconfiguration risks and runtime threats. It can help security teams identify weaknesses before deployment and detect suspicious activity while container workloads are running.

1. Why Container Security Is Different

A traditional VM security model focuses heavily on:

Operating-system vulnerabilities
Disk encryption
Network exposure
Administrative access
Malware
OS configuration

Container environments introduce additional layers.

A typical containerized application can involve:

Container image → Container registry → Kubernetes cluster → Nodes → Pods → Containers → Application

Each layer can introduce security risks.

For example:

The container image may contain a vulnerable package.
The image may contain unnecessary software.
The registry may permit unauthorized access.
A Kubernetes cluster may have an insecure configuration.
A pod may run with excessive privileges.
A container may run as root.
A workload may communicate with unexpected destinations.
An attacker may attempt to execute commands inside a running container.

Defender for Containers provides security capabilities across these layers.

2. What Defender for Containers Provides

Defender for Containers combines several security capabilities, including:

Vulnerability assessment
Security posture management
Kubernetes security recommendations
Runtime threat detection
Host-level threat detection
Container image scanning
Kubernetes environment monitoring
Security alerts and recommendations through Defender for Cloud

The precise capabilities available depend on the environment, such as:

Azure Kubernetes Service (AKS)
Azure Container Registry (ACR)
Azure Arc-enabled Kubernetes
Other supported Kubernetes environments

The important SC-500 concept is to understand which security problem Defender for Containers is designed to address.

3. Container Image Vulnerabilities

One of the most important container-security principles is:

A container is only as secure as the image from which it is created.

A container image can contain:

Vulnerable operating-system packages
Vulnerable application libraries
Outdated frameworks
Unnecessary packages
Known CVEs
Misconfigured components

If a vulnerable image is deployed repeatedly, the same vulnerability can exist across many running containers.

Defender for Containers can integrate with supported container registries to identify vulnerabilities in container images.

This allows organizations to detect vulnerabilities before the image is deployed into production.

Example

Suppose an organization builds:

customer-api:v4

The image contains an outdated OpenSSL package with a known critical vulnerability.

Without image scanning:

Build → Push → Deploy → Vulnerability discovered later

With vulnerability assessment:

Build → Scan → Identify vulnerability → Remediate → Rebuild → Deploy

This shifts security toward the development and deployment stages rather than waiting for a running workload to be compromised.

4. Vulnerability Assessment vs. Runtime Protection

These two concepts are easy to confuse on the SC-500 exam.

Vulnerability assessment

Answers:

“Does this image or workload contain known security vulnerabilities?”

Examples:

Vulnerable package
Known CVE
Outdated component

Runtime threat detection

Answers:

“Is something suspicious happening in this running environment?”

Examples:

Unexpected process execution
Suspicious command execution
Possible privilege escalation
Suspicious network activity
Container escape behavior
Malicious activity

A workload can have:

No known vulnerabilities but still be attacked.
Known vulnerabilities but no active attack.

Therefore, vulnerability assessment and runtime threat detection complement one another.

5. Kubernetes Security Posture

Kubernetes introduces a large number of configuration options.

Security problems can arise from:

Excessive permissions
Weak authentication or authorization
Insecure pod configurations
Containers running as root
Privileged containers
Missing security controls
Insecure network configurations
Excessive access to Kubernetes APIs
Misconfigured cluster components

Defender for Containers can provide recommendations that help organizations identify and remediate Kubernetes security weaknesses.

These recommendations contribute to the organization’s overall cloud security posture.

6. Runtime Threat Detection

Detecting configuration problems before deployment is important, but organizations must also monitor workloads while they are running.

Runtime protection looks for suspicious activity occurring within the container environment.

Examples include:

Suspicious process execution
Unexpected shell activity
Abnormal command execution
Attempts to access sensitive resources
Suspicious network behavior
Potential privilege escalation
Possible container escape attempts

When suspicious behavior is detected, Defender for Cloud can generate security alerts.

Security teams can then investigate the alert and determine whether the activity represents:

A legitimate administrative operation
An application behavior
A configuration problem
A compromised workload
A potential attack

7. Defender for Containers and Defender for Cloud

Defender for Containers is enabled and managed through Microsoft Defender for Cloud.

Defender for Cloud provides a centralized location for:

Security recommendations
Security alerts
Secure Score
Regulatory compliance
Workload protection
Security posture management

The Defender for Containers plan provides container-specific security capabilities.

A useful way to remember the relationship is:

Defender for Cloud = security management platform

Defender for Containers = container/Kubernetes workload protection

This distinction is important for SC-500 questions.

8. Azure Kubernetes Service (AKS)

Azure Kubernetes Service is a managed Kubernetes service in Azure.

Defender for Containers provides security capabilities specifically designed for AKS environments.

A security team might use Defender for Containers to identify:

Cluster configuration weaknesses
Vulnerable container images
Kubernetes configuration problems
Runtime threats
Suspicious activity affecting workloads

This provides security visibility across the Kubernetes environment rather than focusing solely on the underlying VM nodes.

9. Container Registries and Microsoft Defender for Containers

Container images are commonly stored in a container registry before deployment.

In Azure, Azure Container Registry (ACR) is a common location for private container images.

Security should therefore be applied before an image reaches production.

A common security workflow is:

Developer creates an image.
Image is pushed to a registry.
Image is scanned for vulnerabilities.
Vulnerabilities are identified.
Developers remediate vulnerable components.
A new image is built.
The image is scanned again.
The approved image is deployed.

This approach is an example of integrating security into the software-development lifecycle.

10. Misconfiguration Detection

Not every security problem is a vulnerability.

A misconfiguration occurs when a resource is configured in a way that creates unnecessary security risk.

Examples include:

A container running with unnecessary privileges
A workload running as root when it doesn’t need to
Excessive Kubernetes permissions
An insecure cluster configuration
Missing recommended security controls
Insecure container settings

This distinction is important:

Problem	Example
Vulnerability	Container includes a package with a known CVE
Misconfiguration	Container runs with excessive privileges
Runtime threat	Attacker executes suspicious commands in a running container

Defender for Containers can help identify all three categories through different capabilities.

11. Container Runtime Security

Runtime security is especially important because vulnerabilities and misconfigurations don’t necessarily mean that an attack is occurring.

For example, suppose a container has a known vulnerability.

That is a security weakness.

If an attacker exploits the vulnerability and starts executing commands inside the container, that becomes a runtime security event.

The security lifecycle therefore looks like:

Identify weakness → Remediate weakness → Monitor workload → Detect attack → Investigate → Respond

Defender for Containers contributes to multiple stages of this lifecycle.

12. The Importance of Least Privilege

Container workloads should follow the principle of least privilege.

A container should have only the:

Permissions
Capabilities
Resources
Network access
Kubernetes privileges

that it actually needs.

Running containers with unnecessary privileges increases the potential impact of a compromise.

For example, a web application that only needs to listen on an application port generally should not require unrestricted host-level privileges.

Similarly, Kubernetes identities should receive only the permissions required to perform their functions.

Defender for Containers can identify recommendations related to insecure Kubernetes configurations and workload security.

13. Security Recommendations vs. Security Alerts

Another important SC-500 distinction is between recommendations and alerts.

Security recommendation

A recommendation generally indicates:

“This configuration or security posture should be improved.”

Examples:

Vulnerable container image
Kubernetes security recommendation
Missing security configuration

Security alert

An alert generally indicates:

“Suspicious or malicious activity has been detected.”

Examples:

Suspicious process
Potential attack
Malicious activity
Possible container compromise

A recommendation does not necessarily mean an attack is occurring.

An alert indicates that security investigation may be required.

14. Defender for Containers vs. Defender for Servers

These services can overlap in environments where Kubernetes nodes are themselves servers, but they have different primary focuses.

Capability	Defender for Containers	Defender for Servers
Container image vulnerabilities	Yes	Not the primary focus
Kubernetes security	Yes	Not the primary focus
Container runtime threats	Yes	Not the primary focus
VM/server security	Not the primary focus	Yes
Server vulnerability management	Limited/related	Yes
Server endpoint protection	Not the primary focus	Yes

For the exam, focus on the workload being protected.

If the question centers on:

Kubernetes clusters, pods, containers, container images, or container runtime activity

think:

Defender for Containers

If the question centers on:

Azure VMs, operating systems, server vulnerabilities, or server endpoint protection

think:

Defender for Servers

15. Defender for Containers and DevSecOps

Container security should ideally be integrated throughout the development lifecycle.

A mature approach can include:

Development

Developers follow secure coding and container-building practices.

Build

Container images are built using approved base images.

Scan

Images are assessed for known vulnerabilities.

Registry

Only approved images are stored and deployed.

Deployment

Kubernetes policies and security configurations are evaluated.

Runtime

Running workloads are monitored for suspicious activity.

Response

Security alerts are investigated and remediated.

This is often referred to as shift-left security because security testing occurs earlier in the development lifecycle.

16. Common Exam Scenarios

Scenario 1: Vulnerable image

A security administrator needs to determine whether container images contain known vulnerabilities.

Think: Vulnerability assessment/image scanning.

Scenario 2: Kubernetes configuration

An administrator needs to identify insecure Kubernetes configurations.

Think: Defender for Containers security posture recommendations.

Scenario 3: Suspicious container activity

An attacker may have gained access to a running container and is executing suspicious commands.

Think: Runtime threat detection.

Scenario 4: Container registry security

An organization wants to identify vulnerabilities in images stored in its container registry.

Think: Container image vulnerability assessment.

Scenario 5: Kubernetes workload protection

An organization wants security monitoring specifically designed for AKS and Kubernetes workloads.

Think: Defender for Containers.

17. Best Practices

1. Scan images before deployment

Don’t wait until a vulnerable container is running in production.

2. Use trusted base images

Start with maintained and appropriately hardened images.

3. Keep images small

Removing unnecessary packages reduces the attack surface.

4. Remediate vulnerabilities

Scanning is valuable only if vulnerabilities are acted upon.

5. Follow least privilege

Avoid unnecessary container and Kubernetes privileges.

6. Monitor runtime behavior

A secure image can still be compromised.

7. Review Defender for Cloud recommendations

Security posture should be continuously improved rather than assessed only once.

8. Investigate security alerts

Runtime alerts can indicate an active compromise or attempted attack.

9. Integrate security into CI/CD

Security checks should occur before deployment.

10. Combine security controls

Defender for Containers should be part of a broader security architecture that includes:

Identity and access controls
Network security
Vulnerability management
Secrets management
Logging and monitoring
Security incident response
Secure software development practices

18. Key Takeaways for the SC-500 Exam

Remember these concepts:

Defender for Containers protects containerized and Kubernetes workloads.
It is managed through Microsoft Defender for Cloud.
It helps identify container image vulnerabilities.
It provides Kubernetes security recommendations.
It helps detect runtime threats.
A vulnerability is not the same thing as a runtime attack.
A misconfiguration is not necessarily evidence of an active attack.
Recommendations generally identify security weaknesses that should be addressed.
Alerts identify suspicious or potentially malicious activity.
Container image security should occur before deployment.
Runtime monitoring remains necessary after deployment.
Least privilege is important for containers and Kubernetes identities.
Defender for Containers and Defender for Servers have different primary focuses.
Container security should be incorporated throughout the DevSecOps lifecycle.

Practice Exam Questions

Question 1

A security team wants to identify known vulnerabilities in packages contained within images before the images are deployed to an AKS cluster.

Which Defender for Containers capability best addresses this requirement?

A. Runtime threat detection
B. Kubernetes audit logging
C. Container image vulnerability assessment
D. Just-in-time VM access

Answer: C

Explanation: Container image vulnerability assessment identifies known vulnerabilities in software components contained in container images. The goal is to discover weaknesses before vulnerable images are deployed.

Question 2

A company has deployed an application to AKS. Security administrators want to detect suspicious commands being executed inside running containers.

Which capability should they use?

A. Runtime threat detection
B. Azure Policy resource locks
C. Azure Backup
D. Azure VM disk encryption

Answer: A

Explanation: Runtime threat detection is designed to identify suspicious behavior occurring while container workloads are running. Suspicious command or process execution can be an indicator of compromise.

Question 3

A security administrator discovers that several Kubernetes workloads are configured to run with unnecessarily high privileges. The administrator wants a service that can identify Kubernetes security posture weaknesses and provide recommendations.

Which service should the administrator use?

A. Azure Bastion
B. Microsoft Defender for Containers
C. Microsoft Defender for Storage
D. Azure Key Vault

Answer: B

Explanation: Defender for Containers provides security posture capabilities for Kubernetes environments, including recommendations that can help identify insecure workload and cluster configurations.

Question 4

A developer pushes a container image containing a package with a known critical CVE to a supported container registry. The security team wants to detect the vulnerability before the image is deployed.

What should the security team implement?

A. Microsoft Sentinel automation rules
B. Azure Bastion
C. Container image vulnerability assessment
D. Just-in-time VM access

Answer: C

Explanation: Image vulnerability assessment is designed to identify known vulnerabilities in container images. JIT VM access and Azure Bastion address administrative access to VMs, not vulnerabilities within container images.

Question 5

Which statement best describes the difference between a container vulnerability and a runtime threat?

A. A vulnerability represents a known weakness, while a runtime threat involves suspicious activity occurring while the workload is running.
B. A vulnerability always means the container has already been compromised.
C. A runtime threat only applies to virtual machines.
D. A vulnerability can only occur in Kubernetes configuration files.

Answer: A

Explanation: A vulnerability is a weakness that could potentially be exploited. Runtime threat detection focuses on suspicious or malicious behavior occurring in an active workload. A vulnerable workload is not necessarily already compromised.

Question 6

An organization wants to improve the security of its AKS environment. Defender for Cloud reports several recommendations concerning Kubernetes configuration and workload security.

What do these recommendations primarily represent?

A. Evidence that every affected workload has been compromised
B. Security posture weaknesses that should be reviewed and remediated
C. Proof that the cluster has been infected with malware
D. Evidence that Azure networking is unavailable

Answer: B

Explanation: Security recommendations identify security weaknesses or configuration improvements. They should be investigated and remediated, but a recommendation does not necessarily indicate an active attack.

Question 7

A company wants to reduce the likelihood that a compromised container can affect other resources. Which principle should guide the configuration of container and Kubernetes permissions?

A. Full administrative access
B. Public network exposure
C. Shared administrator credentials
D. Least privilege

Answer: D

Explanation: Least privilege limits a workload to the permissions and capabilities it actually needs. This reduces the potential impact if the workload is compromised.

Question 8

A security team needs to protect Kubernetes workloads, detect container runtime threats, and identify container image vulnerabilities.

Which Microsoft Defender for Cloud workload protection plan is most appropriate?

A. Defender for Storage
B. Defender for Servers
C. Defender for Containers
D. Defender for Key Vault

Answer: C

Explanation: Defender for Containers is specifically designed to provide security capabilities for containerized and Kubernetes workloads, including image vulnerability assessment, posture management, and runtime protection.

Question 9

An organization has both Azure VMs and AKS clusters. The security team wants to select the appropriate Defender workload protection capability based on the resource being protected.

Which mapping is most appropriate?

A. AKS and containers → Defender for Containers; Azure VMs and servers → Defender for Servers
B. AKS and containers → Defender for Storage; Azure VMs → Defender for Key Vault
C. AKS and containers → Azure Bastion; Azure VMs → Defender for Storage
D. AKS and containers → Defender for Key Vault; Azure VMs → Defender for Containers

Answer: A

Explanation: Defender for Containers focuses on container and Kubernetes workloads, while Defender for Servers focuses on server and VM protection. Selecting the workload-specific plan is important when designing Defender for Cloud protection.

Question 10

A company wants to incorporate container security into its development lifecycle. Which approach provides the most comprehensive security strategy?

A. Scan containers only after a production incident
B. Perform image scanning before deployment and combine it with Kubernetes security posture management and runtime threat detection
C. Disable runtime monitoring after an image passes vulnerability scanning
D. Rely exclusively on the container registry’s authentication mechanism

Answer: B

Explanation: Container security should cover the lifecycle from image creation through deployment and runtime. Image scanning identifies known vulnerabilities, posture management identifies configuration weaknesses, and runtime detection helps identify active suspicious behavior. Passing an image scan does not guarantee that the running workload will never be compromised.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Implement and configure security controls for Azure Kubernetes Service (AKS) (SC-500 Exam Prep)

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 application platform services
      --> Implement and configure security controls for Azure Kubernetes Service (AKS)

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.

Introduction

Azure Kubernetes Service (AKS) provides a managed Kubernetes platform for running containerized applications in Azure. Because AKS hosts potentially sensitive workloads and provides access to Azure resources, securing an AKS environment requires controls at several layers:

Cluster and API server access
Identity and authorization
Pod and container security
Network segmentation
Secrets and credential protection
Container image security
Policy and compliance enforcement
Threat detection and runtime protection
Cluster and node security

For the SC-500 exam, it is important to understand which security control addresses which threat and how the controls work together.

1. Understanding the AKS Security Model

AKS security should be viewed as a layered defense model.

Security layer	Examples of controls
Identity	Microsoft Entra ID, managed identities, Microsoft Entra Workload ID
Authorization	Kubernetes RBAC, Azure RBAC
API server	Private cluster, authorized IP ranges
Network	Network policies, NSGs, Azure Firewall, WAF
Pod/container	Pod Security Standards, security contexts, non-root containers
Secrets	Azure Key Vault, Secrets Store CSI Driver
Images	Vulnerability scanning, trusted images, image lifecycle management
Governance	Azure Policy for Kubernetes
Threat protection	Microsoft Defender for Containers
Monitoring	Defender for Cloud, Azure Monitor, Microsoft Sentinel
Platform	Kubernetes/node upgrades and security patches

No individual control provides complete protection. A secure AKS implementation combines multiple layers.

Microsoft’s current AKS security guidance specifically emphasizes authentication and authorization, Azure Policy, Defender for Containers, secure pod traffic, protection of sensitive credentials, and keeping Kubernetes and node operating systems updated.

2. Secure Access to the AKS API Server

The Kubernetes API server is the primary management interface for an AKS cluster.

An attacker who obtains unauthorized access to the API server may be able to:

Deploy malicious workloads
Modify existing workloads
Access cluster resources
Retrieve sensitive configuration
Change Kubernetes objects
Potentially move laterally through workloads

Therefore, protecting API-server access is one of the most important AKS security tasks.

Microsoft Entra ID Authentication

Microsoft recommends integrating AKS with Microsoft Entra ID for authentication.

Instead of maintaining independent local identities for Kubernetes users, Microsoft Entra ID becomes the centralized identity provider.

This provides benefits such as:

Centralized identity management
Group-based access
Multifactor authentication
Conditional Access
Privileged Identity Management
Centralized identity lifecycle management

Microsoft Entra ID handles authentication — determining who the user is.

Kubernetes RBAC or Azure RBAC can then handle authorization — determining what that authenticated identity is allowed to do.

Exam distinction

Authentication = Who are you?
Authorization = What are you allowed to do?

This distinction is frequently important in security scenarios.

3. Kubernetes RBAC and Azure RBAC

AKS supports both Kubernetes RBAC and Azure RBAC-based authorization models.

Kubernetes RBAC

Kubernetes RBAC controls permissions to Kubernetes resources.

For example, a user might be allowed to:

View pods
Create deployments
Modify services

but not:

Create cluster-wide roles
Modify namespaces
Access sensitive resources

Kubernetes RBAC uses objects such as:

Roles
ClusterRoles
RoleBindings
ClusterRoleBindings

Azure RBAC

Azure RBAC controls access to Azure resources through Azure Resource Manager.

For example, Azure RBAC can determine whether an administrator can:

Manage an AKS cluster
Modify Azure networking
Access Azure Key Vault
Modify Azure Storage

AKS also supports Azure RBAC for Kubernetes authorization, allowing Azure identities and Azure RBAC concepts to participate in authorization decisions for Kubernetes resources.

Least privilege

The objective is to give administrators, developers, applications, and services only the permissions they require.

Avoid giving users or applications cluster-admin privileges unless there is a compelling operational requirement.

4. Protecting the AKS API Server

There are two important approaches to restricting access to the AKS API server.

Private AKS Cluster

A private AKS cluster uses a private endpoint for API-server communication.

This can prevent the Kubernetes API server from being directly accessible over the public internet.

A private cluster is particularly useful when:

Cluster administration must remain on private networks.
The organization has strict network segmentation requirements.
The cluster handles sensitive workloads.
Administrative traffic must remain within controlled network boundaries.

Microsoft’s current guidance recommends private AKS clusters when stronger segmentation of API-server traffic is required.

Authorized IP Ranges

A public AKS API server can instead be restricted using authorized IP ranges.

This approach allows access only from specified public IP addresses.

For example:

			
Allowed:
Corporate office public IP
CI/CD build-agent IP
Security administration network
Blocked:
All other internet addresses

		

Important distinction

Requirement	Appropriate control
Keep API server private	Private AKS cluster
Restrict public API endpoint to known IPs	Authorized IP ranges
Control what authenticated users can do	RBAC

5. Secure Pod-to-Pod Communication with Network Policies

By default, pods can communicate with one another unless restrictions are implemented.

This can create excessive lateral-movement opportunities.

For example:

			
Frontend Pod
     |
     v
API Pod
     |
     v
Database Pod

		

The desired security architecture might allow:

			
Frontend ---> API
API -------> Database

but prevent:

			
Frontend ---> Database
Database ---> Frontend
Unrelated Pod ---> Database

Kubernetes Network Policies

AKS supports Kubernetes network policies that can control traffic between pods.

Policies can use criteria such as:

Namespace
Pod labels
Ports
Traffic direction

Microsoft describes network policies as a cloud-native way to control pod traffic, while NSGs are more appropriate for controlling traffic at the Azure/node network layer.

Example

Suppose an organization has:

			
namespace: frontend
namespace: backend
namespace: database

A network policy can permit:

			
frontend → backend
backend → database

while denying:

frontend → database

This implements micro-segmentation within the Kubernetes environment.

6. Network Security Groups vs. Network Policies

This distinction is important for the exam.

Control	Primary purpose
NSG	Controls network traffic at Azure networking layers
Kubernetes Network Policy	Controls pod-to-pod traffic
Azure Firewall	Centralized network traffic inspection and filtering
WAF	Protects web applications from HTTP/HTTPS attacks
Private Link	Provides private connectivity to supported Azure PaaS services

A network policy is not a replacement for an NSG.

Instead, they operate at different layers.

7. Secure Pod and Container Execution

A compromised container can become a significant security problem if it has excessive privileges.

A fundamental principle is:

Run containers with the minimum privileges they require.

Avoid unnecessarily running containers as root.

Security Context

Kubernetes security contexts can restrict how containers and pods operate.

Examples include:

Running as a specific user
Controlling group ownership
Restricting privilege escalation
Controlling Linux capabilities
Applying filesystem restrictions

Microsoft recommends using pod security contexts and minimizing privileges.

Example concept

Instead of:

			
Container
   |
   └── root privileges
          |
          └── Full access to privileged operations

		

prefer:

			
Container
   |
   └── Non-root identity
          |
          └── Only required permissions

		

This reduces the potential impact of a container compromise.

8. Pod Security Standards

Kubernetes provides Pod Security Standards (PSS) to define security expectations for workloads.

The standards provide different levels of restriction.

The important security concept is that organizations can prevent workloads from violating defined security requirements.

For example, an organization might require workloads to:

Avoid privileged containers
Avoid running as root
Restrict privilege escalation
Use appropriate security contexts

Current AKS security guidance also incorporates Pod Security Standards and deployment safeguards into the security baseline for AKS Automatic, while AKS Standard provides greater flexibility and generally requires more explicit configuration.

9. Protecting Secrets and Credentials

Never place sensitive credentials directly into:

Application source code
Container images
Configuration files committed to source control
Plain-text deployment manifests

Examples of sensitive information include:

Database passwords
API keys
Connection strings
Certificates
Access tokens

Instead, Azure Key Vault can be used as a centralized secret store.

10. Microsoft Entra Workload ID

Microsoft Entra Workload ID allows an application running in an AKS pod to authenticate to Azure resources without embedding long-lived credentials in the application.

For example:

			
AKS Pod
   |
   | Federated identity
   v
Microsoft Entra ID
   |
   v
Azure Key Vault

		

The workload can then access Azure resources according to the permissions granted to its identity.

Microsoft Entra Workload ID uses Kubernetes service-account tokens and OpenID Connect (OIDC) federation to establish trust with Microsoft Entra ID.

Why is this better?

Without workload identity:

			
Application
   |
   └── Stored secret
          |
          └── Risk of exposure

		

With workload identity:

			
Application
   |
   └── Federated identity
          |
          v
     Microsoft Entra ID
          |
          v
     Azure resource

		

This reduces the need to distribute and rotate long-lived credentials.

11. Azure Key Vault and the Secrets Store CSI Driver

AKS can integrate with Azure Key Vault using the Secrets Store CSI Driver and its Azure Key Vault provider.

This allows a pod to retrieve secrets, keys, or certificates from Key Vault.

The general architecture is:

                Azure Key Vault
                      |
                      |
             Secrets Store CSI
                      |
                      v
                  AKS Pod
                      |
                      v
                Application

This keeps sensitive values out of container images and application source code.

Microsoft’s current AKS guidance recommends using Key Vault with the Secrets Store CSI Driver, including Microsoft Entra Workload ID where appropriate.

12. Container Image Security

Container security begins before a container is deployed.

A vulnerable image can introduce vulnerabilities into every pod that uses it.

Organizations should therefore:

Use trusted container registries.
Scan images for vulnerabilities.
Keep base images updated.
Remove unnecessary packages.
Rebuild images when critical vulnerabilities are discovered.
Avoid embedding secrets in images.
Control which images can be deployed.

For Azure workloads, Azure Container Registry (ACR) can be integrated into the AKS security architecture.

Microsoft recommends using Microsoft Entra-based authentication for AKS-to-ACR access rather than relying unnecessarily on stored imagePullSecrets.

13. Microsoft Defender for Containers

Microsoft Defender for Containers provides security capabilities for containerized environments, including AKS.

It can provide:

Container image vulnerability assessment
Security posture recommendations
Runtime threat detection
Security alerts
Kubernetes configuration insights
Monitoring of workloads and cluster activity

For AKS, Defender for Containers integrates with Azure services and can collect runtime security signals from AKS environments.

Think of Defender for Containers as covering multiple stages

			
Build
  |
  v
Container Image
  |
  | Vulnerability assessment
  v
Deployment
  |
  | Configuration/posture checks
  v
Running Workload
  |
  | Runtime monitoring/threat detection
  v
Security Alert

		

This is different from Azure Policy.

Defender for Containers vs. Azure Policy

Capability	Defender for Containers	Azure Policy
Security recommendations	Yes	Yes, for policy compliance
Vulnerability assessment	Yes	No
Runtime threat detection	Yes	No
Policy enforcement	Some security controls	Yes
Governance/compliance	Yes	Yes
Admission/policy controls	Supports security gating capabilities	Core capability

A useful exam rule is:

Defender for Containers detects and protects; Azure Policy governs and enforces.

14. Azure Policy for AKS

Azure Policy can extend governance into Kubernetes.

The Azure Policy add-on for AKS uses policy enforcement mechanisms to apply governance to Kubernetes resources such as:

Pods
Containers
Namespaces

Azure Policy can centrally define and report compliance for Kubernetes clusters.

The Azure Policy implementation extends Gatekeeper/OPA capabilities to provide centralized policy management.

Example

An organization might establish a policy:

Containers must not run with privileged mode enabled.

A deployment violating the policy can be identified or, depending on the policy and enforcement configuration, prevented.

This is particularly valuable in large organizations where manually reviewing every Kubernetes manifest is impractical.

15. Policy as a Security Guardrail

Consider a development team that deploys this workload:

			
Deployment
   |
   +-- Container A
   |      └── Privileged = true
   |
   +-- Container B
          └── Runs as root

		

Instead of relying solely on developers to detect these risks, Azure Policy can establish organizational guardrails.

Conceptually:

			
Developer
    |
    v
Kubernetes Deployment
    |
    v
Policy Evaluation
    |
    +---- Compliant ------> Deploy
    |
    +---- Noncompliant ---> Audit / Deny

		

This is an example of preventive governance.

16. AKS Automatic vs. AKS Standard

Current AKS documentation distinguishes between AKS Automatic and AKS Standard.

AKS Automatic provides a more opinionated security baseline, while AKS Standard provides greater configuration flexibility.

AKS Automatic includes several security controls preconfigured, including:

Azure RBAC for Kubernetes authorization
API server virtual network integration
Workload identity and OIDC issuer
Deployment safeguards
Baseline Pod Security Standards in enforce mode
Image cleaner
Security restrictions around managed system node pools

AKS Standard supports these capabilities but generally gives the customer greater responsibility for configuring and operating them.

Exam takeaway

Do not assume that every AKS security feature is automatically configured identically in every AKS deployment.

Always consider:

Which AKS mode is being used, and which controls have actually been enabled?

17. Restricting Access to the Instance Metadata Service

A compromised pod may attempt to access Azure instance metadata endpoints to obtain information or credentials.

AKS security guidance recommends using network policies to restrict pod access to the instance metadata endpoint where appropriate.

This is another example of defense in depth.

Even if an attacker compromises a container, network controls can limit what the compromised workload can reach.

18. Keeping AKS and Nodes Updated

Security controls are not effective if the underlying Kubernetes environment contains known vulnerabilities.

Organizations should:

Keep AKS on supported Kubernetes versions.
Upgrade node images.
Apply security patches.
Remove obsolete node images.
Monitor Kubernetes version support.
Test upgrades before production rollout.

Microsoft specifically identifies maintaining current Kubernetes and node OS security updates as an important AKS security practice.

A security strategy therefore includes both:

			
Configuration Security
+
Patch Security
+
Runtime Security

		

19. A Layered AKS Security Architecture

A secure AKS environment can be visualized as follows:

                       Internet
                           |
                           v
                    WAF / Firewall
                           |
                           v
                    AKS Ingress
                           |
              +------------+------------+
              |                         |
              v                         v
        Frontend Pods              API Pods
              |                         |
              +-----------+-------------+
                          |
                   Network Policy
                          |
                          v
                     Data Pods
                          |
                          v
                    Azure Services
                          |
                    Key Vault / SQL /
                    Storage / APIs


        ┌──────────────────────────────────────┐
        │          Security Controls           │
        │                                      │
        │ Microsoft Entra ID / RBAC            │
        │ Microsoft Entra Workload ID          │
        │ Azure Policy                         │
        │ Defender for Containers              │
        │ Key Vault                            │
        │ Network Policies                     │
        │ Pod Security Standards               │
        │ Private API Server / IP restrictions │
        │ Kubernetes/node updates              │
        └──────────────────────────────────────┘

The important concept is that these controls complement one another.

20. Common AKS Security Design Scenarios

Scenario 1: Protect the API server from the public internet

Requirement: Administrative access to the API server must remain on private networks.

Best choice: Use a private AKS cluster.

Scenario 2: Public API server but only corporate IPs should connect

Requirement: The organization must retain a public endpoint but restrict its sources.

Best choice: Configure authorized IP ranges.

Scenario 3: Developers should authenticate using corporate identities

Requirement: Avoid separate Kubernetes user accounts.

Best choice: Integrate AKS with Microsoft Entra ID.

Scenario 4: Frontend pods should not communicate directly with database pods

Requirement: Implement pod-level network segmentation.

Best choice: Use Kubernetes network policies.

Scenario 5: An application needs Key Vault access

Requirement: Avoid storing a client secret inside the container.

Best choice: Use Microsoft Entra Workload ID and grant the workload the required Key Vault permissions.

Scenario 6: Retrieve secrets without embedding them in the container image

Requirement: Applications need database credentials stored centrally.

Best choice: Use Azure Key Vault with the Secrets Store CSI Driver, with an appropriate workload identity/authentication mechanism.

Scenario 7: Prevent developers from deploying privileged containers

Requirement: Establish an organization-wide Kubernetes security guardrail.

Best choice: Use Azure Policy for Kubernetes with an appropriate policy definition.

Scenario 8: Detect a vulnerable container image and suspicious runtime behavior

Requirement: Security operations needs visibility into vulnerabilities and runtime threats.

Best choice: Use Microsoft Defender for Containers.

21. AKS Security Control Decision Matrix

Security requirement	Primary control
Authenticate administrators	Microsoft Entra ID
Restrict Kubernetes permissions	Kubernetes RBAC
Azure resource permissions	Azure RBAC
Private API-server connectivity	Private AKS cluster
Restrict public API access	Authorized IP ranges
Control pod-to-pod traffic	Network Policy
Restrict container privileges	Pod security/security context
Protect Azure workload credentials	Microsoft Entra Workload ID
Store secrets centrally	Azure Key Vault
Make Key Vault secrets available to pods	Secrets Store CSI Driver
Enforce organizational Kubernetes policies	Azure Policy
Detect container vulnerabilities	Defender for Containers
Detect runtime threats	Defender for Containers
Protect web applications	WAF
Protect broader network traffic	Azure Firewall / NSGs
Maintain supported software	AKS/Kubernetes/node upgrades

22. Key Exam Concepts to Remember

For SC-500, remember these relationships:

Microsoft Entra ID

Authenticates users and identities.

Kubernetes RBAC

Controls permissions within Kubernetes.

Azure RBAC

Controls Azure resource access and can participate in AKS authorization.

Private AKS cluster

Keeps API-server connectivity private.

Authorized IP ranges

Restrict which public IP addresses can reach the API server.

Network policies

Control pod-to-pod network communication.

Pod security

Limits what containers and pods can do.

Microsoft Entra Workload ID

Allows workloads to authenticate to Azure resources without embedding long-lived credentials.

Azure Key Vault

Provides centralized protection and management of secrets, keys, and certificates.

Secrets Store CSI Driver

Allows Kubernetes workloads to retrieve secrets from external secret stores such as Key Vault.

Azure Policy

Provides centralized governance and policy enforcement for Kubernetes resources.

Defender for Containers

Provides container security posture, vulnerability assessment, runtime protection, and threat detection capabilities.

23. Best Practices Checklist

A strong AKS security implementation should consider:

Use Microsoft Entra ID for cluster authentication.
Apply least privilege through RBAC.
Avoid unnecessary cluster-admin permissions.
Consider a private AKS cluster for sensitive environments.
Use authorized IP ranges when a public API endpoint is required.
Implement network policies to restrict pod-to-pod traffic.
Avoid running containers as root where possible.
Minimize Linux capabilities and privilege escalation.
Use Pod Security Standards and appropriate security contexts.
Use Microsoft Entra Workload ID for workload-to-Azure authentication.
Store secrets in Azure Key Vault rather than source code or images.
Use the Secrets Store CSI Driver where appropriate.
Scan container images for vulnerabilities.
Use trusted container registries and keep images current.
Enable Azure Policy for centralized governance.
Use Defender for Containers for security posture and runtime protection.
Keep Kubernetes and node images supported and patched.
Monitor security alerts and compliance continuously.
Treat AKS security as a layered defense rather than a single feature.

Practice Exam Questions

Question 1

An organization deploys an AKS cluster containing sensitive financial workloads. Security policy requires that communication with the Kubernetes API server remain on private networks and not traverse a public API endpoint.

Which solution should you implement?

A. Configure Kubernetes network policies
B. Configure an AKS private cluster
C. Configure authorized IP ranges
D. Configure Azure Policy

Answer: B

Explanation: A private AKS cluster provides private connectivity to the Kubernetes API server. Network policies control pod traffic, while authorized IP ranges restrict sources to a public API endpoint. Azure Policy provides governance rather than making the API server private.

Question 2

A company wants developers to authenticate to AKS by using their existing corporate identities. The security team also wants to take advantage of Microsoft Entra security capabilities such as multifactor authentication and Conditional Access.

Which solution should be implemented?

A. Microsoft Entra ID integration
B. Kubernetes service accounts only
C. Azure Firewall
D. Network Security Groups

Answer: A

Explanation: Microsoft Entra ID provides centralized authentication for AKS users and integrates with Microsoft identity security capabilities. Kubernetes service accounts serve different workload-oriented purposes, while Azure Firewall and NSGs are network controls.

Question 3

An AKS cluster contains frontend, API, and database pods. The security team requires that frontend pods communicate with API pods, API pods communicate with database pods, but frontend pods must not communicate directly with database pods.

Which control should you use?

A. Azure RBAC
B. Azure Key Vault
C. Kubernetes network policies
D. Microsoft Entra Workload ID

Answer: C

Explanation: Kubernetes network policies control traffic between pods based on characteristics such as namespaces, labels, ports, and traffic direction. This makes them appropriate for implementing pod-level network segmentation.

Question 4

An application running in an AKS pod needs to access Azure Key Vault. The security team does not want developers to store a client secret or other long-lived credential in the container.

Which solution provides the most appropriate identity mechanism?

A. Store the secret in the Docker image
B. Store the credential in a Kubernetes ConfigMap
C. Use a Kubernetes NetworkPolicy
D. Use Microsoft Entra Workload ID

Answer: D

Explanation: Microsoft Entra Workload ID enables an AKS workload to federate its Kubernetes identity with Microsoft Entra ID and obtain access to Azure resources without embedding long-lived application credentials.

Question 5

A security administrator wants to prevent developers from deploying privileged containers into production AKS clusters. The administrator wants the requirement centrally governed across multiple clusters.

Which solution is most appropriate?

A. Azure Policy for Kubernetes
B. Azure Key Vault
C. Azure Firewall
D. Microsoft Entra Workload ID

Answer: A

Explanation: Azure Policy for Kubernetes provides centralized governance and enforcement for Kubernetes resources such as pods, containers, and namespaces. It can be used to establish organizational security guardrails.

Question 6

A security operations team wants to identify vulnerabilities in container images and detect suspicious activity occurring in running AKS workloads.

Which Microsoft security service is designed for this purpose?

A. Azure Policy
B. Microsoft Defender for Containers
C. Azure Resource Manager
D. Azure Private Link

Answer: B

Explanation: Microsoft Defender for Containers provides capabilities including container image vulnerability assessment, security posture insights, runtime security signals, and threat detection for supported AKS environments.

Question 7

An organization has an AKS cluster with a public API server. The organization does not want to migrate to a private cluster, but it needs to ensure that only the organization’s approved public IP addresses can access the API server.

Which control should be configured?

A. Kubernetes RBAC
B. Azure Key Vault
C. Authorized IP ranges
D. Pod Security Standards

Answer: C

Explanation: Authorized IP ranges restrict access to a public AKS API server to specified source IP addresses. Kubernetes RBAC controls what authenticated identities can do after access is established; it does not restrict the network source.

Question 8

A security engineer wants to prevent an application in one AKS namespace from communicating with workloads in another namespace unless explicitly permitted.

Which security control should the engineer prioritize?

A. Azure RBAC
B. Azure Policy
C. Microsoft Entra ID
D. Kubernetes network policy

Answer: D

Explanation: Kubernetes network policies can restrict pod traffic using namespaces, labels, ports, and other selectors. They are designed specifically for controlling pod-to-pod network communication.

Question 9

An application stores a database password inside its container image. The security team wants to remove the credential from the image and retrieve it securely at runtime from Azure Key Vault.

Which combination is most appropriate?

A. Azure Key Vault and the Secrets Store CSI Driver
B. Azure Firewall and NSGs
C. Azure Policy and Azure RBAC only
D. Private AKS cluster and authorized IP ranges

Answer: A

Explanation: Azure Key Vault provides centralized secret storage, while the Secrets Store CSI Driver with its Azure Key Vault provider allows AKS workloads to retrieve secret contents from Key Vault. Microsoft Entra Workload ID can also be used to provide the workload’s identity to Key Vault.

Question 10

A company wants to implement defense in depth for an AKS environment. The security architecture must restrict pod communication, prevent excessively privileged workloads, detect container vulnerabilities, and provide runtime threat detection.

Which combination provides the best overall solution?

A. Azure RBAC, Azure Storage, and Azure DNS
B. Network policies, pod security controls, Azure Policy, and Defender for Containers
C. Azure Firewall alone
D. Microsoft Entra ID alone

Answer: B

Explanation: No single AKS security feature provides all of these capabilities. Network policies provide pod-level segmentation, pod security controls reduce workload privileges, Azure Policy provides centralized governance/enforcement, and Defender for Containers provides vulnerability and runtime security capabilities. Together they provide layered defense in depth.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026

Implement and configure security controls for Azure Container Registry (SC-500 Exam Prep)

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 application platform services
      --> Implement and configure security controls for Azure Container Registry

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.

Introduction

Azure Container Registry (ACR) is a managed private registry service for storing and managing container images and other OCI artifacts. Because container images are ultimately executed as workloads, protecting the registry is an important part of securing the container supply chain.

For the SC-500 exam, the key security areas to understand include:

Authentication and authorization
Azure RBAC and repository-level access
Managed identities
Network security
Private endpoints
Disabling unnecessary public access
Container image vulnerability assessment
Image signing and verification
Administrative account security
Azure Policy
Secure integration with AKS and other Azure services

ACR supports Docker images and other OCI-compatible content, and provides Azure-based identity and RBAC capabilities for controlling access.

1. Why Azure Container Registry Security Matters

A container registry is a critical component of the software supply chain.

Consider the following process:

			
Developer
    |
    v
Source Code
    |
    v
Container Build
    |
    v
Container Image
    |
    v
Azure Container Registry
    |
    v
AKS / Container Apps / Other Runtime

		

If an attacker compromises the registry, they may be able to:

Push malicious images.
Replace legitimate images.
Delete images.
Access proprietary application code contained in images.
Introduce vulnerable dependencies.
Distribute compromised images to production workloads.

Therefore, ACR security needs to protect both:

Who can access the registry

and

What content is allowed to move through the registry and into production.

2. ACR Authentication vs. Authorization

One of the most important concepts for the exam is the difference between authentication and authorization.

Authentication

Authentication answers:

Who are you?

ACR can authenticate users and applications through mechanisms including Microsoft Entra identities, service principals, managed identities, and other supported authentication methods.

Authorization

Authorization answers:

What are you allowed to do?

Azure RBAC determines what an authenticated identity can do with the registry and its contents.

For example:

			
Microsoft Entra identity
        |
        | Authentication
        v
Azure Container Registry
        |
        | Authorization
        v
AcrPull / AcrPush /
Repository Reader / Writer

		

This distinction is fundamental to understanding ACR security.

3. Use Microsoft Entra ID and Azure RBAC

For most enterprise scenarios, use Microsoft Entra-based authentication and Azure RBAC rather than sharing registry administrator credentials.

ACR provides built-in roles designed for common registry operations.

Important roles include:

Role	Purpose
AcrPull	Pull artifacts from a registry
AcrPush	Push and pull artifacts
AcrDelete	Delete repositories, tags, or manifests
AcrQuarantineReader	Read/pull quarantined artifacts
AcrQuarantineWriter	Manage quarantined artifacts

The important security principle is least privilege.

For example:

			
Production application
       |
       +---- AcrPull
       |
       +---- Cannot push
       |
       +---- Cannot delete

		

A deployment identity that only needs to retrieve images should not receive AcrPush merely because that role is convenient.

Microsoft’s current role documentation confirms that AcrPull provides pull access while AcrPush provides both push and pull access.

4. Repository-Level Access with Azure ABAC

A particularly important current ACR capability is Azure attribute-based access control (ABAC) for repository permissions.

Traditional registry-wide permissions can be too broad.

For example:

			
Developer A
    |
    +---- AcrPull
            |
            +---- frontend
            +---- backend
            +---- database
            +---- internal-tools

		

Perhaps the developer should only be able to pull from:

frontend

ABAC can provide more granular repository-level authorization.

With an ABAC-enabled registry, roles such as:

Container Registry Repository Reader
Container Registry Repository Writer
Container Registry Repository Contributor

can be scoped using conditions to specific repositories or repository prefixes.

For example:

			
Developer A
     |
     +---- Repository Reader
             |
             +---- frontend/*

		

This follows the principle of least privilege much more closely than granting registry-wide access.

Current ACR documentation states that ABAC repository permissions can use conditions to scope permissions to individual repositories or repository prefixes.

Important exam consideration

When a registry uses RBAC + ABAC Repository Permissions, legacy roles such as AcrPull, AcrPush, and AcrDelete are not honored for repository data access in the same way. The corresponding ABAC-enabled repository roles should be used.

Therefore, do not automatically assume:

AcrPull is always the correct role for every ACR configuration.

First determine whether the registry uses traditional RBAC or RBAC + ABAC repository permissions.

5. Managed Identities

Applications and Azure services often need to pull images from ACR.

A common security mistake is to store a username and password or long-lived credential in application configuration.

A better approach is to use a managed identity where the consuming Azure service supports it.

Conceptually:

			
Azure Service
      |
      | Managed Identity
      v
Microsoft Entra ID
      |
      | Authorized token
      v
Azure Container Registry
      |
      v
Container Image

		

The identity can be assigned the minimum required ACR permissions.

For example, if a service only needs to pull images:

			
Managed Identity
       |
       +---- AcrPull

The identity does not need AcrPush.

Microsoft documents managed identity authentication for ACR specifically as a way to access private registries without placing credentials in application code.

6. Separate Push and Pull Permissions

A secure CI/CD architecture should separate responsibilities.

For example:

			
Build Pipeline
      |
      +---- Push
      |
      v
Azure Container Registry
      |
      +---- Pull
      |
      v
Production Environment

		

The build pipeline might require push permissions, while the production workload only requires pull permissions.

Giving the production workload push permissions unnecessarily increases the potential impact of a compromised workload.

Microsoft’s ACR best-practice guidance recommends assigning different identities appropriate permissions for different operations, such as push permissions for build pipelines and pull permissions for deployment identities.

7. Disable the ACR Administrator Account When It Isn’t Required

ACR provides an administrator account for scenarios where it is needed, but it should not normally be the preferred enterprise authentication mechanism.

The administrator account represents a powerful shared credential and does not provide the same identity-level governance as Microsoft Entra-based access.

For enterprise environments, consider disabling the administrator account and using Microsoft Entra identities and RBAC instead.

Azure provides built-in policy definitions that can audit or modify registries to disable the local administrator account.

Security principle

Prefer:

			
Individual/service identity
        +
Azure RBAC
        +
Least privilege

		

over:

Shared administrator credential

8. Anonymous Pull Access

ACR normally requires authentication to pull content.

ACR also supports anonymous pull access, which makes registry content available to unauthenticated clients.

This can be appropriate when intentionally distributing public container images.

However, it is generally inappropriate for private enterprise images.

If anonymous pull is enabled:

			
Unauthenticated client
        |
        v
Azure Container Registry
        |
        v
Publicly pullable images

		

This can expose proprietary images or data.

Microsoft notes that anonymous pull applies to all repositories in the registry, making this setting particularly important to evaluate carefully.

Exam rule

If the requirement is:

“Only authenticated identities should be able to pull images.”

Disable anonymous pull.

9. Network Security for Azure Container Registry

Identity security alone is not enough.

An organization can also restrict where network connections to ACR can originate.

Potential controls include:

Public network access restrictions
IP-based network rules
Virtual network integration/network rules where supported
Azure Private Link
Private endpoints

The security objective is to reduce unnecessary exposure.

10. Private Endpoints and Azure Private Link

For highly sensitive registries, organizations can use an ACR private endpoint.

Conceptually:

                    Azure VNet
                       |
              +--------+--------+
              |                 |
          AKS Cluster       Build System
              |                 |
              +--------+--------+
                       |
                 Private Endpoint
                       |
                       v
              Azure Container Registry

The registry can then be accessed using a private IP through the Azure virtual network.

This is particularly useful when:

Production workloads use private networking.
Public network access should be eliminated.
Registry access must remain inside controlled networks.
Data leakage risks need to be reduced.

Current Azure Policy definitions include controls for configuring ACR private endpoints and disabling public network access.

11. Public Network Access

An organization may choose to disable public network access to ACR.

This creates a stronger network boundary:

			
Internet
   |
   X
   |
   X---- Public ACR access disabled
   |
Private Azure Network
   |
   v
Private Endpoint
   |
   v
ACR

		

This does not replace authentication and authorization.

Instead:

Network controls determine where the registry can be reached; identity controls determine who can use it.

Defense in depth uses both.

12. Trusted Azure Services

Network restrictions can sometimes interfere with Azure services that need to access a registry.

ACR supports a mechanism that allows selected trusted Azure services to access network-restricted registries in supported scenarios.

This is important when a registry has:

Private endpoints
IP restrictions
Other network restrictions

and a Microsoft service needs access to registry content.

For example, Microsoft Defender for Cloud may need to pull images to perform vulnerability assessment.

Microsoft documents a trusted-services mechanism for supported network-restricted ACR scenarios.

Exam consideration

If you restrict ACR networking and a Microsoft service can no longer perform an expected operation, determine whether that service requires a trusted-service exception or another supported connectivity configuration.

13. Encrypting ACR Data at Rest

ACR data is encrypted at rest by default using service-managed encryption.

For scenarios requiring greater control over encryption keys, supported ACR configurations can use customer-managed keys (CMKs).

Conceptually:

			
Azure Container Registry
        |
        | Encryption at rest
        v
Customer-managed key
        |
        v
Azure Key Vault

		

Customer-managed keys can be useful for organizations with:

Regulatory requirements
Key-management requirements
Internal encryption policies
Requirements for customer control over the encryption key lifecycle

Azure Policy includes built-in controls that can audit or deny registries that do not use customer-managed keys where required.

14. Container Image Vulnerability Assessment

A container image can contain vulnerabilities even when the application itself was developed securely.

For example:

			
Application
     |
     +-- Vulnerable operating-system package
     |
     +-- Vulnerable library
     |
     +-- Outdated framework
     |
     +-- Known CVE

		

Microsoft Defender for Cloud can scan ACR images for known vulnerabilities.

When vulnerabilities are found, Defender for Cloud can provide recommendations for remediation.

After an image is replaced with a remediated version, Defender can rescan the image.

15. Vulnerability Scanning vs. Image Signing

These concepts are easy to confuse.

Vulnerability scanning asks:

Does this image contain known security vulnerabilities?

Image signing asks:

Can I verify that this image came from a trusted publisher and has not been altered?

These address different risks.

Security question	Control
Does the image contain known CVEs?	Vulnerability assessment
Who published the image?	Image signing
Has the signed artifact been modified?	Signature verification
Should this image be allowed into production?	Policy/admission controls

A mature container security architecture can use both.

16. Image Signing and Supply Chain Security

Container images are part of the software supply chain.

An attacker could attempt to:

Compromise a build system.
Modify an image.
Push the modified image.
Deploy the malicious image into production.

Image signing helps establish:

Authenticity — the artifact came from a trusted publisher.
Integrity — the artifact has not been altered since signing.

Current Azure guidance uses Notation, based on the Notary Project, for signing and verifying OCI artifacts. A signature can be verified before an artifact is consumed or deployed.

17. Notation and Artifact Signing

A current approach is:

			
Build Image
    |
    v
Azure Container Registry
    |
    v
Sign Image
    |
    v
Deploy
    |
    v
Verify Signature
    |
    +---- Valid -----> Allow
    |
    +---- Invalid ---> Block

		

Azure Artifact Signing can be used with Notation to sign container images.

Azure Key Vault can also participate in certificate-based signing scenarios.

Microsoft’s current guidance identifies Artifact Signing as an alternative to using Azure Key Vault for the signing service, with Artifact Signing providing managed certificate lifecycle capabilities.

18. Verifying Images Before AKS Deployment

Image signing becomes particularly powerful when combined with AKS policy enforcement.

A security architecture can require:

Only container images with valid signatures from trusted publishers may run.

Conceptually:

			
Developer
    |
    v
Signed Image
    |
    v
ACR
    |
    v
AKS Deployment
    |
    v
Signature Verification
    |
    +---- Trusted -----> Run
    |
    +---- Untrusted ---> Reject

		

Microsoft’s current ACR signing guidance describes using Notation, Ratify, and Azure Policy to verify image signatures for AKS deployments.

19. Azure Policy for ACR

Azure Policy can be used to establish organizational security requirements for container registries.

Examples of policy requirements include:

Disable anonymous authentication.
Disable the ACR administrator account.
Disable public network access.
Require private endpoints.
Require customer-managed keys.
Require vulnerability remediation.
Disable repository-scoped access tokens where organizational policy requires it.
Disable certain authentication mechanisms.

Current built-in ACR policy definitions include controls for these areas.

This allows organizations to move from:

Security recommendation

to:

Governance rule

and, where appropriate:

Preventive enforcement

20. ACR Security and AKS

ACR and AKS are commonly used together.

A secure architecture might look like this:

                 Developer
                     |
                     v
                Build Pipeline
                     |
               Push Image
                     |
                     v
          +----------------------+
          | Azure Container      |
          | Registry             |
          |                      |
          | RBAC / ABAC          |
          | Private Endpoint     |
          | Vulnerability Scan   |
          | Image Signing        |
          +----------+-----------+
                     |
                     | Pull
                     v
              +-------------+
              |     AKS     |
              |             |
              | Azure Policy|
              | Ratify      |
              +-------------+
                     |
                     v
              Running Pods

Each component addresses a different security concern.

21. ACR Security for CI/CD Pipelines

CI/CD pipelines require special attention because they frequently have elevated registry permissions.

A common secure design is:

			
Developer
    |
    v
Source Repository
    |
    v
CI Pipeline
    |
    | Push permission
    v
ACR
    |
    | Pull permission
    v
CD / AKS

		

The CI identity might have:

Push + Pull

while the production workload has:

Pull only

This prevents a compromised production workload from automatically obtaining the ability to modify images.

22. Avoid Secrets in Container Images

Never embed registry credentials inside a container image.

For example, avoid:

			
Dockerfile
   |
   +-- USERNAME=...
   +-- PASSWORD=...

Why?

Because anyone who can obtain the image may potentially extract those values.

Instead, use:

Microsoft Entra authentication
Managed identities
Workload identities
Key Vault
Secure CI/CD authentication mechanisms

The principle is:

Credentials should be external to the image whenever possible.

23. ACR Security Control Decision Matrix

Requirement	Recommended control
Authenticate developers	Microsoft Entra ID
Pull-only access	AcrPull
Push and pull access	AcrPush
Repository-specific access	ABAC repository permissions
Azure workload access	Managed identity
Prevent unauthenticated pulls	Disable anonymous pull
Remove shared admin credentials	Disable ACR admin account
Restrict network access	Network rules/private networking
Eliminate public exposure	Private endpoint + disable public access
Protect data at rest with customer-controlled keys	Customer-managed key
Detect known CVEs	Defender vulnerability assessment
Establish artifact authenticity	Image signing
Verify signed images	Notation / verification tooling
Enforce signed-image deployment	Azure Policy + signature verification
Enforce registry security configuration	Azure Policy

24. Common Exam Scenarios

Scenario 1: AKS only needs to pull images

An AKS workload needs to pull images from ACR but must not be able to push images.

Best choice: Assign the identity the minimum pull permission, such as AcrPull in an RBAC-only registry, or the appropriate ABAC-enabled repository reader role in an ABAC-enabled registry.

Scenario 2: Build pipeline needs to publish images

A CI/CD pipeline builds images and pushes them to ACR.

Best choice: Give the pipeline identity appropriate push permissions.

Do not give production workloads the same permissions simply because they use the same registry.

Scenario 3: Only one repository should be accessible

A developer should access only:

frontend/*

but not:

			
backend/*
database/*

Best choice: Use ACR’s ABAC repository permissions to scope access to the appropriate repository or repository prefix.

Scenario 4: No public registry access

A company requires the production registry to be accessible only from its Azure virtual network.

Best choice: Use a private endpoint/Private Link and disable public network access as appropriate.

Scenario 5: Detect vulnerable images

Security operations wants to identify known CVEs in images stored in ACR.

Best choice: Use Microsoft Defender for Cloud’s container image vulnerability assessment capabilities.

Scenario 6: Ensure images haven’t been tampered with

The organization wants to verify that production images came from approved publishers and were not altered.

Best choice: Implement container image signing and signature verification.

Scenario 7: Prevent anonymous access

The registry contains proprietary application images.

Best choice: Disable anonymous pull access.

25. Common Mistakes to Avoid

Mistake 1: Giving every developer AcrPush

If a developer only needs to pull images, AcrPush is excessive.

Use least privilege.

Mistake 2: Using the administrator account everywhere

The ACR admin account should not become the default enterprise authentication mechanism.

Mistake 3: Assuming network security replaces identity security

A private endpoint does not eliminate the need for authentication and authorization.

Mistake 4: Confusing vulnerability scanning with signing

A vulnerability scan does not prove that an image came from a trusted publisher.

Likewise, a valid signature does not mean an image contains no vulnerabilities.

Mistake 5: Granting registry-wide access when repository-level access is sufficient

Use repository-level ABAC permissions where the scenario requires granular access.

Mistake 6: Forgetting production pull-only requirements

Production workloads normally should not need permission to modify the images they consume.

26. Key SC-500 Takeaways

For the exam, remember these relationships:

Microsoft Entra ID
→ Provides identity-based authentication.

Azure RBAC
→ Determines what an identity can do.

AcrPull
→ Pull artifacts from an RBAC-only registry.

AcrPush
→ Push and pull artifacts in an RBAC-only registry.

ABAC repository permissions
→ Provide more granular repository-specific authorization.

Managed identity
→ Allows supported Azure resources to access ACR without storing credentials.

Private endpoint
→ Provides private connectivity to ACR.

Disable public network access
→ Prevents access through the public network where supported/configured.

Disable anonymous pull
→ Requires authentication for image pulls.

Defender for Cloud
→ Provides container image vulnerability assessment and security recommendations.

Image signing
→ Establishes artifact authenticity and integrity.

Notation
→ Provides current tooling for signing and verifying OCI artifacts.

Azure Policy
→ Provides centralized governance and enforcement of ACR security requirements.

Practice Exam Questions

Question 1

A company has an Azure Container Registry that stores proprietary production images. The security team requires that unauthenticated users must not be able to pull any image from the registry.

Which configuration should you implement?

A. Disable anonymous pull access
B. Enable the ACR administrator account
C. Assign AcrPush to all users
D. Enable public network access

Answer: A

Explanation: Anonymous pull allows unauthenticated clients to pull registry content. Disabling anonymous pull ensures that clients must authenticate before pulling images. RBAC should then determine what authenticated identities are authorized to access.

Question 2

A production application needs to retrieve container images from ACR. The application does not need to push, delete, or modify images. The organization wants to avoid storing registry credentials in application configuration.

Which approach provides the best solution?

A. Use a managed identity with pull-only permissions
B. Store the ACR administrator password in the application settings
C. Give the application AcrPush
D. Enable anonymous pull

Answer: A

Explanation: A managed identity allows a supported Azure resource to authenticate to ACR without embedding credentials in application code. The identity should receive only the permissions required to pull images.

Question 3

A company uses an ACR registry with Azure RBAC + ABAC Repository Permissions. A developer should be able to pull images only from the frontend repository and must not access backend.

Which approach should be used?

A. Assign Owner at the subscription level
B. Assign AcrPush at the registry level
C. Assign an ABAC-enabled repository reader role with a condition restricting access to frontend
D. Enable anonymous pull and rely on repository naming conventions

Answer: C

Explanation: ABAC repository permissions allow an ACR role assignment to be constrained to specific repositories or repository prefixes. This provides much more precise least-privilege access than registry-wide permissions.

Question 4

A security team wants to prevent the production ACR from being reachable through the public internet. AKS and build systems that require access to the registry operate within an Azure virtual network.

Which solution should the team consider?

A. Enable anonymous pull
B. Assign AcrPush to the AKS cluster
C. Enable the ACR administrator account
D. Configure an ACR private endpoint and restrict or disable public network access

Answer: D

Explanation: An ACR private endpoint provides private connectivity through Azure Private Link. Combining private connectivity with appropriate public network restrictions can prevent unintended public exposure.

Question 5

A security operations team wants to identify known CVEs in container images stored in ACR and receive recommendations for remediation.

Which service should they use?

A. Microsoft Defender for Cloud
B. Azure DNS
C. Azure Private Link
D. Microsoft Entra ID

Answer: A

Explanation: Microsoft Defender for Cloud can perform container image vulnerability assessment for supported ACR scenarios and provide recommendations when vulnerabilities are identified.

Question 6

A development organization wants to ensure that only images produced by an approved build organization can be deployed into production. It also wants to detect whether an image has been altered after it was signed.

Which security capability directly addresses these requirements?

A. Azure RBAC
B. Container image signing and signature verification
C. Anonymous pull access
D. Network Security Groups

Answer: B

Explanation: Image signing establishes artifact authenticity and integrity. Signature verification can confirm that an image was signed by a trusted publisher and has not been altered since signing.

Question 7

A CI/CD service builds container images and publishes them to ACR. A production AKS workload only needs to retrieve those images.

Which permission model follows the principle of least privilege?

A. Give both identities AcrPush
B. Give both identities Owner
C. Give the CI/CD identity push permissions and the production workload pull-only permissions
D. Give the production workload the ACR administrator account

Answer: C

Explanation: The build pipeline needs to publish images, while the production workload only needs to consume them. Separating push and pull permissions reduces the potential impact of a compromised production workload.

Question 8

An organization wants Azure Policy to identify ACR instances that do not have their local administrator account disabled.

What is the primary purpose of this policy?

A. Detect container image vulnerabilities
B. Enforce or audit registry security configuration
C. Sign container images
D. Encrypt container images during execution

Answer: B

Explanation: Azure Policy provides centralized governance and can audit or modify supported ACR configurations. Disabling the local administrator account is a registry configuration requirement, not a vulnerability-scanning or image-signing function.

Question 9

A company has disabled public access to an ACR through network restrictions. Microsoft Defender for Cloud is expected to scan images in the registry, but the scans are failing because the service cannot access the registry.

What should the security engineer investigate first?

A. Whether supported trusted-service access/network configuration is enabled for the restricted registry
B. Whether anonymous pull is enabled
C. Whether every developer has AcrPush
D. Whether the registry administrator account is enabled

Answer: A

Explanation: Defender for Cloud needs to access images to perform vulnerability scanning. When ACR is protected by network restrictions, the organization should verify the supported trusted-service/network configuration that allows the Microsoft service to access the registry.

Question 10

An organization wants to establish a complete security process for production container images. The requirements are:

Detect known vulnerabilities.
Verify image authenticity.
Prevent unauthorized images from being deployed.
Limit who can modify images.

Which combination provides the strongest solution?

A. Anonymous pull, public network access, and AcrPush
B. Vulnerability assessment, image signing/verification, Azure Policy enforcement, and least-privilege RBAC/ABAC
C. ACR administrator account and public IP restrictions only
D. Azure DNS and Network Security Groups only

Answer: B

Explanation: These controls address different stages of the container supply chain. Vulnerability assessment identifies known security weaknesses, signing and verification establish authenticity and integrity, Azure Policy can enforce organizational deployment/governance requirements, and RBAC/ABAC limits who can modify or access registry content. Together they provide defense in depth.

Final Word

This topic is especially important for SC-500 because it ties identity, least privilege, network security, vulnerability management, governance, and software supply-chain security together. The biggest distinctions to remember are AcrPull vs. AcrPush, RBAC vs. ABAC repository permissions, private endpoint vs. identity controls, vulnerability scanning vs. image signing, and Azure Policy vs. Defender for Cloud.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Implement and configure security controls for Azure Container Instances and Azure Container Apps (SC-500 Exam Prep)

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 application platform services
      --> Implement and configure security controls for Azure Container Instances and Azure Container Apps

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.

Introduction

Azure provides several ways to run containerized workloads. Two important services are:

Azure Container Instances (ACI) — a serverless container service designed for running containers or container groups without managing virtual machines or a Kubernetes cluster.
Azure Container Apps (ACA) — a managed application platform designed for containerized applications, microservices, APIs, background jobs, and event-driven workloads.

From a security perspective, both services support important controls around identity, authentication, secrets, networking, container images, and workload isolation. However, the implementation details differ.

Azure Container Instances (ACI) and Azure Container Apps (ACA) provide different levels of abstraction and therefore expose different security controls. The key for the SC-500 exam is understanding which security mechanism belongs to which service and how to combine identity, secrets, networking, image security, and workload isolation.

For the SC-500 exam, you should be able to determine:

How to authenticate containers to Azure resources.
How to avoid embedding credentials in container images.
How to secure container image retrieval.
How to restrict network exposure.
How to secure inbound application traffic.
How to protect secrets.
How to use Microsoft Entra ID and managed identities.
How Azure Container Apps environments provide security boundaries.
When to use private networking.
How security controls differ between ACI and Azure Container Apps.

1. Azure Container Instances vs. Azure Container Apps

Although both services run containers, they address different workload requirements.

Capability	Azure Container Instances	Azure Container Apps
Primary purpose	Run isolated containers/container groups	Run containerized applications and microservices
Orchestration	No orchestration required	Managed application platform
Kubernetes management	Not required	Kubernetes-based platform, managed by Azure
Application ingress	Basic networking capabilities	Rich application ingress capabilities
Revisions	No application revision model	Built-in revisions
Autoscaling	Limited compared with ACA	Built-in application scaling
Managed identities	Yes	Yes
Private networking	VNet integration supported	Environment/VNet-based architecture
Private ACR authentication	Supported	Supported
Confidential containers	Supported	Not the same ACI confidential-container model
Built-in application authentication	Limited	Built-in authentication/authorization
Best fit	Short-lived jobs, isolated containers, simple workloads	APIs, microservices, web applications, event-driven applications

ACI is often appropriate when you simply need to run a container without managing an orchestration platform. Azure Container Apps provides more application-level security and networking capabilities for long-running applications and microservices.

2. Secure Azure Container Instances

2.1 Use managed identities instead of embedded credentials

One of the most important security practices for ACI is to avoid placing Azure credentials inside:

Container images
Source code
Configuration files
Dockerfiles
Plain-text environment variables

ACI supports managed identities, allowing a container group to authenticate to Azure resources that support Microsoft Entra authentication without embedding credentials in the container.

For example, an ACI workload might need to access:

Azure Key Vault
Azure Storage
Azure Container Registry
Other Azure services supporting Microsoft Entra authentication

The basic pattern is:

ACI container → Managed identity → Microsoft Entra ID → Azure resource

The Azure resource is then protected through Azure RBAC or the applicable authorization mechanism.

Why this matters

Suppose a developer puts an Azure service principal password into a Docker image:

			
Docker image
   |
   +-- application
   +-- connection string
   +-- client secret

		

Anyone who gains access to the image may potentially obtain the credential.

A managed identity removes the need to distribute that credential with the container.

3. Use managed identity for ACR image pulls

ACI can use a managed identity to authenticate to Azure Container Registry (ACR) when pulling private container images.

This is particularly valuable when the ACR itself is protected using a private endpoint.

The architecture can look like:

                 Azure VNet
                     |
       +-------------+-------------+
       |                           |
       |                        Private
       |                       Endpoint
       |                           |
   ACI Container  ------------>  ACR
       |
       |
 Managed Identity
       |
 Microsoft Entra ID

ACI can therefore retrieve a private image without storing an ACR username and password in the container configuration. Microsoft specifically documents managed-identity-based ACR authentication for ACI, including scenarios where ACR access is restricted through a private endpoint.

Exam point

If the question asks:

“How should an ACI container securely authenticate to a private Azure Container Registry?”

A strong answer is:

Use a managed identity and grant that identity the required ACR permissions.

Do not choose an embedded registry password when a managed identity is available.

4. Secure ACI environment variables

ACI supports environment variables for passing configuration information to containers.

However, there is an important distinction between ordinary environment variables and secure environment variables.

A regular environment variable can expose its value through container configuration.

A secure environment variable uses the secureValue property. Its value isn’t exposed through the container’s properties, although the running application can access it from inside the container.

For example:

			
environmentVariables:
  - name: APP_MODE
    value: "production"
  - name: DATABASE_PASSWORD
    secureValue: "secret-value"

		

The second value is protected from being displayed through the container properties.

Important security consideration

Secure environment variables are better than placing secrets directly into an image, but for production architectures, centralized secret management such as Azure Key Vault is generally preferable when practical.

5. ACI secret volumes

ACI also supports secret volumes.

A secret volume allows secrets to be mounted as files inside the container.

For example:

			
/mnt/secrets/
    database-password
    api-key

Secret volumes are currently supported for Linux containers.

This can be useful when an application expects credentials or configuration to be provided as files rather than environment variables.

Exam distinction

Remember:

Secure environment variables → sensitive values exposed to the application as environment variables.
Secret volumes → sensitive values mounted as files.
Managed identity → eliminates the need for stored Azure credentials when the target service supports Microsoft Entra authentication.
Azure Key Vault → centralized service for protecting secrets, keys, and certificates.

6. Protect container images

Container security begins before the container is deployed.

A compromised or vulnerable image can introduce risk even if the container’s networking and identity controls are configured correctly.

Microsoft recommends using a private registry, scanning container images for vulnerabilities, and protecting credentials used to access containers and registries.

A common architecture is:

			
Developer / CI/CD
       |
       v
Azure Container Registry
       |
       | vulnerability scanning
       | access controls
       |
       v
ACI / Azure Container Apps

		

Security controls should include:

Private container registries
Microsoft Entra authentication
Managed identities
Least-privilege registry permissions
Image vulnerability scanning
Secure CI/CD pipelines
Regular image updates
Avoidance of embedded credentials

Important distinction

Image vulnerability scanning and image signing solve different problems.

Control	Primary purpose
Vulnerability scanning	Identify known vulnerabilities such as CVEs
Image signing	Establish image authenticity/integrity
Private registry	Restrict registry access
Managed identity	Securely authenticate workloads
Network controls	Restrict network exposure

A signed image can still contain a vulnerability.

7. Network security for Azure Container Instances

ACI can be integrated with an Azure virtual network.

This allows containers to participate in private network architectures rather than exposing every workload directly to the public internet.

A common security architecture is:

                Azure VNet
                    |
       +------------+-------------+
       |                          |
   ACI subnet                Private services
       |                          |
       +-------- Private ----------+
                connectivity

Network design should follow least privilege:

Use private networking where appropriate.
Avoid unnecessary public exposure.
Restrict access to required destinations.
Use appropriate NSG and routing controls where supported by the architecture.
Protect backend services with private endpoints when appropriate.

For sensitive workloads, the objective should be to minimize the number of public endpoints.

8. Confidential containers in ACI

For workloads requiring particularly strong protection of data while it is being processed, Azure Container Instances supports confidential container deployments.

Confidential containers use a trusted execution environment (TEE) to provide hardware-based confidentiality and integrity protections.

This is particularly relevant when an organization has requirements involving:

Highly sensitive data
Data-in-use protection
Strong workload isolation
Regulatory requirements
Protection from certain infrastructure-level threats

Exam concept

Confidential containers address a different security problem than encryption at rest.

Think of the three states of data:

Data state	Typical protection
At rest	Encryption
In transit	TLS
In use	Confidential computing / TEE

9. Secure Azure Container Apps

Azure Container Apps provides additional application-level security capabilities beyond the basic container execution model.

A Container Apps environment acts as a security boundary around container apps and jobs. The environment has a virtual network, either one created and managed by Azure or one supplied by the customer.

This makes the environment an important architectural security boundary.

A typical architecture is:

                 Container Apps Environment
                 ---------------------------
                 |                         |
             Frontend                   Backend
           Container App              Container App
                 |                         |
                 +-------- Internal -------+
                          traffic

A useful security design is to place related applications in the same environment while separating workloads that require stronger isolation.

For example:

Production environment
Development environment
Test environment

Separating environments can reduce the possibility of accidental cross-environment access and configuration drift.

10. Managed identities in Azure Container Apps

Azure Container Apps supports both:

System-assigned managed identities
User-assigned managed identities

A system-assigned identity is associated with the lifecycle of the container app.

A user-assigned identity is an independent Azure resource and can be assigned to multiple resources.

System-assigned identity

A good choice when:

One application needs its own identity and the identity should have the same lifecycle as the application.

User-assigned identity

A good choice when:

An identity needs to exist independently of a particular application or potentially be reused.

11. Managed identities for Azure Container Registry

Container Apps can use managed identity to pull images from a private Azure Container Registry.

This eliminates the need to put registry credentials into application configuration.

A particularly strong design is to use a dedicated identity for container registry access, separate from the identity used by the application itself when appropriate.

This supports better separation of duties and least privilege.

For example:

                Azure Container Apps
                       |
            +----------+----------+
            |                     |
      Workload Identity       ACR Identity
            |                     |
            v                     v
      Key Vault / APIs          ACR

The application doesn’t need the same permissions required to pull images.

12. Protect secrets in Container Apps

Container Apps provides application-level secrets.

Secrets can be referenced by revisions and can also be referenced from Azure Key Vault.

For production workloads, a preferred pattern is:

			
Container App
      |
Managed Identity
      |
      v
 Azure Key Vault
      |
      v
   Secret

		

The managed identity is granted permission to retrieve the required secret.

For example, Microsoft documents using the Key Vault Secrets User role for a managed identity that needs to retrieve secrets from Key Vault.

Why Key Vault is preferable

Instead of:

			
Container App
   |
   +-- password
   +-- API key
   +-- connection string

		

use:

			
Container App
      |
Managed Identity
      |
      v
Key Vault
      |
      +-- password
      +-- API key
      +-- connection string

		

This provides centralized secret management and reduces the need to distribute credentials.

13. Understand Container Apps secret lifecycle

An important exam detail is that Container Apps secrets are application-scoped rather than revision-specific.

Multiple revisions can reference the same secret. Changing a secret doesn’t automatically create a new revision. Existing revisions may need to be restarted or a new revision deployed so that the updated value is loaded.

This distinction is important in questions involving secret rotation.

Example

Suppose Revision 1 and Revision 2 both use:

DATABASE_PASSWORD

The administrator changes the secret.

The change does not automatically mean that every running revision instantly reloads the new value.

The application must be restarted or a new revision deployed as appropriate.

14. Secure Container Apps ingress

Container Apps provides configurable ingress.

Ingress can be:

External
Internal

External ingress exposes the application through the environment’s inbound endpoint.

Internal ingress restricts application access to the appropriate internal environment/network boundary.

Security principle

Do not make every microservice publicly accessible.

For example:

			
Internet
   |
   v
Frontend API
   |
   | internal
   v
Order Service
   |
   | internal
   v
Database Service

		

Only the component that genuinely needs internet exposure should use external ingress.

15. Enforce HTTPS

Container Apps supports HTTP and HTTPS traffic through its ingress configuration.

The allowInsecure setting determines whether insecure HTTP connections are allowed. For secure applications, disable insecure connections so that traffic is protected using HTTPS.

The security principle is straightforward:

Do not permit unencrypted application traffic when the workload requires protected communications.

This is particularly important for:

Authentication tokens
Session information
Personally identifiable information
API requests
Credentials
Sensitive business data

16. Built-in authentication and authorization

Azure Container Apps includes built-in authentication and authorization capabilities, sometimes referred to as Easy Auth.

It can integrate with Microsoft Entra ID and other supported identity providers.

This is useful when an application needs to protect an externally accessible endpoint without requiring the application developers to implement the entire authentication mechanism themselves.

For example:

			
User
 |
 v
Container Apps ingress
 |
 v
Authentication layer
 |
 +---- unauthenticated --> sign-in
 |
 +---- authenticated ----> Application

		

The built-in authentication layer runs separately from the application code and can pass authenticated identity information to the application.

Exam distinction

Do not confuse:

Managed identity

with:

Container Apps built-in authentication

Managed identity is primarily about the application authenticating to other Azure resources.

Built-in authentication is primarily about users or clients authenticating to the Container App.

17. Client certificate authentication

For higher-assurance application scenarios, Container Apps supports client certificate authentication/mutual TLS scenarios.

With mTLS, both sides participate in certificate-based authentication:

			
Client certificate
       |
       v
Container App
       |
Server certificate
       |
       v
Authenticated TLS connection

		

This can provide stronger service-to-service or client-to-service authentication than relying solely on a shared secret.

18. Private endpoints for Container Apps

For environments requiring private access, Azure Container Apps supports private endpoints.

A private endpoint provides private connectivity to the Container Apps environment through an Azure virtual network.

When using a private endpoint, public network access can be disabled so that connectivity occurs through the controlled private network path.

Private endpoint architectures also require appropriate private DNS configuration.

A simplified architecture is:

			
Corporate network
       |
 VPN / ExpressRoute
       |
 Azure VNet
       |
 Private Endpoint
       |
 Container Apps Environment
       |
 Container App

		

This is preferable to exposing a sensitive application directly to the public internet.

19. Control outbound traffic

Security isn’t limited to inbound traffic.

A compromised container may attempt to communicate with malicious external infrastructure.

For Container Apps environments integrated with a customer-managed VNet, outbound traffic can be controlled using mechanisms such as:

Azure Firewall
User-defined routes
Network security groups where applicable
Private endpoints
Destination allowlists

Microsoft recommends using Azure Firewall with UDRs when centralized outbound inspection and control are required.

The security objective is:

Allow workloads to communicate only with destinations they actually need.

20. Network security groups and Container Apps

When using a customer-managed virtual network, NSGs can provide additional traffic controls.

However, an important architectural distinction is that the automatically generated Microsoft-managed VNet for a Container Apps environment isn’t equivalent to a customer-managed VNet that you can freely modify.

For security-sensitive architectures requiring extensive network control, use an appropriate customer-managed networking design. Microsoft notes that a Microsoft-managed VNet can’t be manipulated in the same way as a customer-managed VNet, such as adding NSGs or forcing traffic through an egress firewall.

This is an excellent SC-500 scenario distinction.

21. Peer-to-peer encryption

Container Apps environments can support encryption for peer-to-peer application traffic.

When enabled, traffic between applications can use TLS encryption within the environment. Microsoft notes that enabling peer-to-peer encryption can have performance implications and that built-in peer-to-peer encryption provides authentication of applications but not application-level authorization between them.

Therefore:

Encryption does not automatically mean authorization.

An application may still need its own authorization controls to determine whether another application is permitted to perform a particular operation.

22. Protect container images in Container Apps

The same container supply-chain principles that apply to ACI apply to Container Apps.

Use:

Private ACR
Managed identities
Least-privilege registry access
Image vulnerability scanning
Secure CI/CD
Trusted image sources
Image signing where appropriate
Current base images
Minimal container images

A container application should not automatically trust an image simply because it came from a registry.

The registry itself must also be protected.

23. Resource limits and denial-of-service considerations

Container Apps supports resource allocation and scaling controls.

Appropriate CPU, memory, replica, and scaling limits can reduce the impact of resource exhaustion and help prevent one workload from consuming disproportionate resources.

Microsoft’s current Container Apps security guidance specifically recommends appropriate scaling and resource limits and monitoring scaling events for unusual patterns.

For exam questions, remember:

Availability is part of security.

Security isn’t only about confidentiality and authentication.

24. ACI security architecture

A strong ACI architecture might look like this:

                 Azure Container Registry
                         |
                  Managed Identity
                         |
                         v
                  Private Endpoint
                         |
                    Azure VNet
                         |
                         v
                +----------------+
                | ACI Container  |
                |     Group      |
                +----------------+
                         |
                  Managed Identity
                         |
             +-----------+-----------+
             |                       |
             v                       v
         Key Vault                Storage

Security controls include:

Private registry
Managed identity
Private networking
Least-privilege RBAC
Secure secrets
Image scanning
Optional confidential containers
Appropriate monitoring

25. Container Apps security architecture

A stronger application-oriented architecture could look like:

                         Internet
                            |
                            v
                    External Ingress
                            |
                     Authentication
                            |
                            v
                    Frontend/API App
                            |
                       Internal
                        ingress
                            |
                            v
                     Backend App
                            |
                  Managed Identity
                            |
              +-------------+-------------+
              |                           |
              v                           v
          Key Vault                    Azure SQL

Security controls include:

External/internal ingress
Microsoft Entra authentication
Managed identities
Key Vault
Private endpoints
HTTPS
Network segmentation
Azure Firewall where appropriate
Image security
Resource/scaling controls
Environment separation

26. ACI vs. Container Apps security decision matrix

Requirement	ACI	Container Apps
Run an isolated container quickly	Excellent	Good
Run container groups	Excellent	Different application model
Managed identity	Yes	Yes
Private ACR authentication	Yes	Yes
Secret management	Secure values/secret volumes/Key Vault patterns	Built-in secrets + Key Vault references
Built-in user authentication	Limited	Yes
Internal/external application ingress	More basic	Extensive
Application revisions	No	Yes
Microservices	Possible	Excellent
Confidential containers	Yes	Different model
Private endpoint	Networking options available	Supported for workload-profile environments
Advanced application routing	Limited	Strong
Built-in autoscaling	Limited	Strong
Application-level security controls	More responsibility on workload	More platform capabilities

27. Common SC-500 mistakes to avoid

Mistake 1: Putting credentials into a container image

Never place passwords, API keys, registry credentials, or Azure service principal secrets in a Dockerfile or container image.

Use managed identities or a secure secret-management solution.

Mistake 2: Assuming a private registry makes an application secure

A private registry controls access to the image repository.

It does not automatically:

Authenticate users to the application
Secure application traffic
Protect secrets
Prevent vulnerabilities in the image

Security must be layered.

Mistake 3: Confusing managed identity with user authentication

Managed identity:

Container → Azure resource

Built-in authentication:

User/client → Container App

This distinction is frequently tested in scenario questions.

Mistake 4: Making every Container App externally accessible

Microservices that don’t require internet access should generally use internal communication rather than external ingress.

Mistake 5: Assuming encryption provides authorization

TLS protects communications.

It does not determine whether a caller is authorized to perform an operation.

Authentication and authorization are separate controls.

Mistake 6: Assuming image scanning means an image is trusted

Scanning identifies known vulnerabilities.

It does not prove that an image came from an authorized publisher.

Image signing addresses authenticity and integrity.

Mistake 7: Forgetting outbound traffic

A secure workload must consider both:

Inbound traffic
Outbound traffic

Azure Firewall and controlled routing can help enforce outbound policies in appropriate Container Apps network architectures.

28. Key SC-500 takeaways

For this topic, remember these core relationships:

Azure Container Instances

Managed identity
→ Authenticate to Azure resources without embedded credentials.

Managed identity + ACR
→ Secure private image pulls.

Secure environment variables / secret volumes
→ Protect sensitive runtime values.

VNet integration
→ Provide private networking options.

Confidential containers
→ Protect sensitive workloads using hardware-backed trusted execution environments.

Azure Container Apps

Environment
→ Security boundary for container apps and jobs.

Managed identity
→ Credential-free access to Azure resources.

Key Vault
→ Centralized secret management.

Internal ingress
→ Keep backend applications from unnecessary internet exposure.

External ingress
→ Expose applications that genuinely require external access.

Built-in authentication
→ Protect externally accessible applications with identity providers such as Microsoft Entra ID.

Private endpoint
→ Provide private connectivity to the Container Apps environment.

Azure Firewall + UDR
→ Control and inspect outbound traffic when the network architecture supports it.

HTTPS
→ Protect application traffic in transit.

Resource/scaling limits
→ Help protect availability and reduce resource-exhaustion risk.

Practice Exam Questions

Question 1

A company runs an Azure Container Instance that needs to pull a private image from Azure Container Registry. The security team doesn’t want registry usernames or passwords stored in the deployment configuration.

What should you implement?

A. A registry administrator username embedded in the container image

B. An anonymous ACR pull configuration

C. A managed identity assigned to the ACI container group with the required ACR permissions

D. A public container registry

Answer: C

Explanation: ACI supports managed identities for authenticating to ACR. The identity can be granted the required permissions, eliminating the need to store registry credentials in the container configuration. This is especially useful when the registry is private.

Question 2

An organization runs a backend API in Azure Container Apps. The API should be accessible only by other applications within the Container Apps environment and must not be directly accessible from the public internet.

Which configuration should you use?

A. External ingress with unrestricted access

B. Internal ingress

C. External ingress with HTTP only

D. Disable the Container Apps environment’s virtual network

Answer: B

Explanation: Internal ingress is designed for applications that should be reachable internally rather than exposed through public ingress. Container Apps supports both external and internal ingress configurations.

Question 3

A Container App needs to retrieve a database password stored in Azure Key Vault. The organization doesn’t want the password embedded in the application image or deployment scripts.

What is the most appropriate approach?

A. Store the password in a Dockerfile

B. Store the password in a regular environment variable

C. Assign a managed identity to the Container App and use it to retrieve the Key Vault secret

D. Make the Key Vault publicly accessible

Answer: C

Explanation: Container Apps supports managed identities and Key Vault secret references. The managed identity can be granted the required Key Vault permissions, allowing the application to retrieve secrets without embedding credentials.

Question 4

A security architect wants to protect a highly sensitive ACI workload from certain infrastructure-level threats and wants hardware-backed protection for data while it is being processed.

Which capability should the architect evaluate?

A. Azure Storage firewall

B. Azure Bastion

C. Azure Firewall

D. Confidential containers

Answer: D

Explanation: Confidential containers on ACI use a trusted execution environment to provide hardware-based confidentiality and integrity protections. This specifically addresses protection of sensitive workloads while they are running.

Question 5

An organization has several Container Apps. One application needs permission to read secrets from Azure Key Vault, but it should not have broad permissions to other Azure resources.

Which security principle should be applied?

A. Grant the managed identity only the minimum required Key Vault permissions

B. Assign Owner to the container application

C. Store the Key Vault password inside the container image

D. Enable anonymous access to Key Vault

Answer: A

Explanation: Least privilege requires granting only the permissions needed by the workload. Managed identities combined with narrowly scoped RBAC permissions provide a credential-free and least-privilege approach.

Question 6

A company exposes a Container App through external ingress. The security team requires users to authenticate using Microsoft Entra ID before they can access the application.

Which capability should you configure?

A. A system-assigned identity for the application’s outbound calls

B. Built-in Container Apps authentication and authorization

C. An ACR private endpoint

D. A secret volume

Answer: B

Explanation: Container Apps provides built-in authentication and authorization capabilities that can integrate with Microsoft Entra ID and other identity providers. Managed identity is instead primarily used by the application when authenticating to Azure resources.

Question 7

An organization needs to ensure that an HTTP application in Azure Container Apps does not accept unencrypted HTTP connections.

Which ingress setting should be configured?

A. Enable external ingress

B. Enable internal ingress

C. Set allowInsecure to false

D. Enable session affinity

Answer: C

Explanation: The allowInsecure ingress setting controls whether insecure HTTP connections are permitted. For a secure application, allowInsecure should remain disabled so that HTTPS is enforced.

Question 8

A company wants to prevent direct public access to a sensitive Azure Container Apps environment. The workload-profile environment should be reachable through an Azure virtual network using private connectivity.

Which capability is most appropriate?

A. Public external ingress

B. A private endpoint with public network access disabled

C. Anonymous authentication

D. A public IP address assigned to each container

Answer: B

Explanation: Container Apps supports private endpoints for workload-profile environments. Public network access can be disabled so that connectivity uses the private endpoint and controlled network path. Appropriate private DNS configuration is also required.

Question 9

A security team wants an application running in Azure Container Apps to authenticate to Azure Storage without storing a storage account key in the application.

Which solution provides the strongest fit?

A. Managed identity with appropriate Azure RBAC permissions

B. Store the storage account key in the container image

C. Enable anonymous access to the storage account

D. Store the storage key in a public environment variable

Answer: A

Explanation: Managed identity allows the application to authenticate to Azure resources without maintaining credentials in application code or configuration. Appropriate Azure RBAC permissions should then be assigned to the identity.

Question 10

A security engineer changes a secret used by several revisions of an Azure Container App. The engineer expects all running revisions to immediately begin using the new secret value.

What should the engineer understand?

A. Every secret change automatically creates a new revision

B. Secrets are permanently associated with the revision that originally created them

C. Secret changes automatically delete all older revisions

D. Secrets are application-scoped, and running revisions may need to be restarted or a new revision deployed to consume the updated value

Answer: D

Explanation: Container Apps secrets are scoped to the application rather than a specific revision. Changing a secret doesn’t automatically create a new revision. Existing running revisions may need to be restarted or a new revision deployed so the updated secret value is loaded.

Final Word

For SC-500, the most important mental model for this topic is:

Secure the image → secure the identity → secure the secrets → secure the network → secure the application endpoint → monitor the workload.

For ACI, concentrate on managed identities, secure image retrieval, secure environment variables and secret volumes, virtual-network integration, private ACR access, and confidential containers.

For Azure Container Apps, concentrate on environment security boundaries, managed identities, Key Vault integration, internal versus external ingress, built-in authentication, HTTPS, private endpoints, outbound traffic control, and application/network isolation.

The exam is likely to test these controls through scenario-based decisions, so focus less on memorizing isolated features and more on identifying which control solves which security problem.

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security October 10, 2026October 10, 2026

Implement and configure security controls for Azure Functions, including authentication and network access (SC-500 Exam Prep)

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 application platform services
      --> Implement and configure security controls for Azure Functions, including authentication and network access

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.

Introduction

Azure Functions is a serverless compute service that allows organizations to execute code in response to events without managing the underlying server infrastructure.

From a security perspective, an Azure Function should not be treated simply as “code that runs in Azure.” A secure Function App requires controls across several layers:

Authentication
Authorization
Managed identities
Secrets and credentials
Inbound network access
Outbound network access
Private endpoints
Virtual network integration
Access restrictions
Secure connections to dependent Azure services
Least-privilege Azure RBAC

For the SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads exam, it is particularly important to understand the difference between:

Authenticating callers to a Function App

and

Authenticating a Function App to other Azure resources.

These are separate security problems and are commonly tested through scenario-based questions.

1. Azure Functions Security Architecture

A secure Function App can be thought of as having several security boundaries:

                    Internet / Client
                           |
                           v
                +----------------------+
                | Authentication /     |
                | Authorization        |
                +----------------------+
                           |
                           v
                +----------------------+
                | Network Access       |
                | Restrictions         |
                +----------------------+
                           |
                           v
                +----------------------+
                | Azure Function App   |
                +----------------------+
                    /            \
                   /              \
                  v                v
        Managed Identity       VNet Integration
                |                    |
                v                    v
       Azure Resources       Private Resources

The controls solve different problems:

Security concern	Primary control
Who can call the Function?	Authentication/authorization
What can the caller do?	Application authorization/RBAC
How does the Function access Azure resources?	Managed identity
Which networks can reach the Function?	Access restrictions/private endpoints
How does the Function reach private resources?	VNet integration
How is traffic kept off the public internet?	Private endpoints/private networking
How are Azure management operations controlled?	Azure RBAC

Understanding these distinctions is fundamental to this SC-500 topic.

2. Authentication vs. Authorization

Authentication and authorization are related but different.

Authentication

Authentication answers:

Who are you?

For example:

Is this user authenticated with Microsoft Entra ID?
Is this application presenting a valid token?
Is this client certificate valid?

Authorization

Authorization answers:

What are you allowed to do?

For example:

Can this user call the API?
Can this identity access a particular database?
Can this application read a particular Key Vault secret?

A secure Function App generally needs both.

			
Client
   |
   | Authentication
   v
"Who are you?"
   |
   v
Authenticated identity
   |
   | Authorization
   v
"What can you access?"

		

3. Function-Level Authentication

Azure Functions provides several mechanisms for controlling access to functions.

For HTTP-triggered functions, the function’s authorization level can be configured as:

Anonymous
Function
Admin

The authorization level is separate from the broader App Service authentication/authorization capability.

This distinction is important.

Anonymous

An HTTP request can invoke the function without providing a function key.

This should be used only when the function is intentionally public or when another security layer provides the required protection.

Function

The caller must provide a function key.

Function keys are intended to help control access to specific functions or the function app, but they should not be treated as a replacement for strong identity-based authentication for applications requiring user or application identity.

Admin

The caller requires the host-level master/admin key.

Because this key has extensive privileges, it should be protected carefully and should not be distributed to ordinary clients.

4. Function Keys Are Not the Same as Microsoft Entra Authentication

This is an important SC-500 distinction.

A function key essentially proves:

“The caller possesses the required secret.”

Microsoft Entra authentication provides an identity-based authentication mechanism.

For applications requiring:

User identity
Application identity
Conditional Access
Centralized identity management
Token-based authentication
Enterprise authorization

Microsoft Entra ID is generally the stronger architectural choice.

5. Built-In Authentication and Authorization

Azure Functions runs on the Azure App Service platform, so it can use the platform’s built-in authentication and authorization capabilities, commonly called App Service Authentication or Easy Auth.

These capabilities can authenticate users or clients before requests reach the Function code. Microsoft Entra ID is one of the supported identity providers.

A simplified flow is:

			
Client
   |
   | HTTP request
   v
Azure Functions
   |
   v
Authentication layer
   |
   +---- Not authenticated ----> Authentication challenge
   |
   +---- Authenticated --------> Function

		

This means developers don’t necessarily have to implement the entire authentication protocol themselves.

6. Requiring Authentication

For a protected HTTP Function App, the authentication configuration can require authentication rather than allowing unauthenticated requests.

This creates a security boundary in front of the application.

For example:

			
Internet
   |
   v
Authentication
   |
   +---- Unauthenticated --> Denied/challenged
   |
   +---- Authenticated ----> Function

		

This is useful for:

Enterprise APIs
Internal applications
Business applications
APIs consumed by authenticated applications
Functions that expose sensitive information

The Function’s own application-level authorization logic can then determine what an authenticated identity is allowed to do.

7. Microsoft Entra ID Authentication

Microsoft Entra ID can be used to authenticate users and applications calling a Function App.

For example:

			
User/Application
       |
       | Microsoft Entra token
       v
Function App
       |
       | Validate token
       v
Authenticated caller

		

This provides a much stronger identity model than simply distributing a shared function key to every consumer.

The application can then use claims and identity information to implement appropriate authorization.

8. Authentication Does Not Automatically Grant Authorization

An authenticated user isn’t necessarily authorized to perform every operation.

For example:

			
User
 |
 | Valid Entra token
 v
Function
 |
 +-- Read customer data       YES
 |
 +-- Delete customer data     NO

		

Authentication establishes identity.

Authorization determines what that identity is permitted to do.

This distinction is particularly important when designing APIs.

9. Managed Identities

Managed identity is one of the most important security features for Azure Functions.

A managed identity allows the Function App to authenticate to supported Microsoft Entra-protected Azure resources without storing credentials in application code or configuration.

Azure manages the identity, eliminating the need for you to provision and rotate a secret.

The architecture is:

			
Azure Function
      |
      | Managed Identity
      v
Microsoft Entra ID
      |
      | Access token
      v
Azure Resource

		

Examples of resources a Function might access include:

Azure Key Vault
Azure Storage
Azure SQL Database
Azure Service Bus
Azure App Configuration
Other Microsoft Entra-protected services

10. System-Assigned vs. User-Assigned Managed Identity

Azure Functions supports both major types of managed identity.

System-assigned managed identity

The identity is created as part of the Function App’s lifecycle.

If the Function App is deleted, its system-assigned identity is also removed.

This is useful when:

The identity belongs exclusively to one Function App.

User-assigned managed identity

A user-assigned managed identity is an independent Azure resource.

It can be assigned to multiple resources and has its own lifecycle.

This is useful when:

An identity needs to be managed independently or potentially shared across multiple resources.

Microsoft’s current Functions guidance also identifies user-assigned identities as more flexible for identity-based connections.

11. Managed Identity and Azure Key Vault

Suppose a Function needs a database password.

A poor architecture would be:

			
Function App
   |
   +-- database password

A better architecture is:

			
Function App
      |
Managed Identity
      |
      v
Microsoft Entra ID
      |
      v
Azure Key Vault
      |
      v
Secret

		

The Function doesn’t need to store a Key Vault password.

Instead, its managed identity receives only the permissions it needs.

This follows the principle of:

Least privilege + credential elimination

12. Managed Identity and Azure SQL

A Function can also use a managed identity to access Azure SQL Database.

For example:

			
Function App
     |
Managed Identity
     |
     v
Microsoft Entra ID
     |
     v
Azure SQL Database

		

The managed identity is granted the appropriate database permissions.

This eliminates the need to store a SQL username and password in the Function’s configuration.

This is a common SC-500 scenario:

“The application must access Azure SQL without storing database credentials.”

The preferred answer is generally:

Use a managed identity with appropriate permissions.

13. Identity-Based Connections

Azure Functions can use identity-based connections instead of connection strings containing secrets.

Microsoft’s current Functions guidance recommends managed identities with Microsoft Entra ID whenever possible because this approach eliminates secrets.

For example, rather than:

			
StorageConnection =
DefaultEndpointsProtocol=https;
AccountName=...;
AccountKey=...

the Function can use an identity-based connection where supported.

This reduces the risk associated with:

Credential theft
Credential leakage
Secret rotation
Secrets appearing in deployment files
Secrets appearing in source control

14. Protect Function Application Settings

Function Apps commonly use application settings to store configuration.

Sensitive values should not be casually placed into configuration files or source control.

Examples of sensitive values include:

API keys
Connection strings
Passwords
Client secrets
Access tokens

Prefer:

Managed identity
Microsoft Entra authentication
Azure Key Vault
Identity-based connections

when supported by the scenario.

The overall goal is:

Minimize long-lived secrets.

15. Network Security for Azure Functions

Authentication answers:

Who can call the Function?

Network security answers:

From where can the Function be reached?

These are separate controls.

Azure Functions provides several networking mechanisms, including:

Access restrictions
Private endpoints
Service endpoints
Virtual network integration
Network security groups for appropriate outbound scenarios
User-defined routes
NAT Gateway
App Service Environment options

The exact capabilities depend on the Functions hosting plan. Current Functions networking guidance distinguishes capabilities across Flex Consumption, Consumption, Premium, Dedicated/App Service Environment, and Container Apps hosting.

16. Access Restrictions

Access restrictions allow you to control inbound access to a Function App.

You can create rules based on factors such as:

IP addresses
IP ranges
Virtual network subnets
Service tags

Rules are evaluated according to their priority.

When access restrictions contain rules, an implicit deny-all behavior exists after the configured rules unless the unmatched rule behavior is otherwise configured.

For example:

			
Rule 100
Corporate subnet       ALLOW
Rule 200
Trusted application IP ALLOW
Default
Everything else        DENY

		

This is useful when a Function should be reachable only from known networks.

17. IP Restrictions vs. Authentication

These controls solve different problems.

IP restrictions

Control:

Where the request originates.

Authentication

Controls:

Who the caller is.

A strong security design can use both.

For example:

			
Request
   |
   +--> Network restriction
   |       |
   |       +-- Not allowed --> DENY
   |
   +--> Authentication
           |
           +-- Not authenticated --> DENY
           |
           +-- Authenticated --> Function

		

This is defense in depth.

18. Private Endpoints

A private endpoint provides private connectivity to a Function App through Azure Private Link.

The private endpoint receives a private IP address from a virtual network.

This allows clients on an appropriate private network to access the Function without relying on its public endpoint.

Conceptually:

			
Corporate Network
       |
 VPN / ExpressRoute
       |
       v
Azure VNet
       |
       v
Private Endpoint
       |
       v
Azure Function

		

This is particularly useful for:

Internal APIs
Sensitive applications
Enterprise workloads
Hybrid applications
Workloads that must not be publicly accessible

19. Private Endpoint vs. VNet Integration

This distinction is extremely important for SC-500.

Private endpoint

Primarily controls:

Inbound connectivity to the Function App.

VNet integration

Primarily controls:

Outbound connectivity from the Function App.

Think of it this way:

             INBOUND
                |
                v
         Private Endpoint
                |
          Function App
                |
                v
          VNet Integration
                |
             OUTBOUND

Azure’s current networking guidance explicitly separates inbound private endpoints from outbound virtual network integration.

20. Virtual Network Integration

VNet integration allows a Function App to access resources in an Azure virtual network.

This is primarily an outbound capability.

For example:

                 Azure VNet
                     |
        +------------+------------+
        |                         |
        v                         v
Function App                Private SQL
        |
        |
   VNet Integration

The Function can use VNet integration to reach:

Private endpoints
Resources in the same VNet
Peered VNets
Service-endpoint-protected resources
Resources reachable over ExpressRoute

Regional VNet integration is the recommended current approach where applicable.

21. VNet Integration Does Not Automatically Make the Function Private

This is an important exam trap.

Suppose you configure:

Function App → VNet integration

That does not automatically mean:

Internet → Function App is blocked.

VNet integration is primarily about outbound traffic.

If the goal is to prevent public inbound access, consider:

Private endpoint
Public network access configuration
Access restrictions
Appropriate network architecture

22. Combining Private Endpoint and VNet Integration

For a highly secured Function App, you may need both.

For example:

                    Corporate Network
                           |
                           v
                        Azure VNet
                           |
                    +------+------+
                    |             |
                    v             |
             Private Endpoint     |
                    |             |
                    v             |
              Function App        |
                    |             |
                    | VNet        |
                    | Integration |
                    v             |
              Private Database <---+

Here:

The private endpoint controls inbound private access.
VNet integration allows the Function to access private resources.
The database can itself be protected by a private endpoint.
Managed identity can provide authentication.

This creates multiple independent security layers.

23. DNS and Private Endpoints

Private networking isn’t complete merely because a private endpoint exists.

DNS must resolve the service name to the private endpoint’s address.

For example:

			
Function / Client
      |
      | DNS lookup
      v
private DNS zone
      |
      v
10.x.x.x
      |
      v
Private Endpoint

		

Azure Functions networking guidance notes that appropriate DNS configuration is required when using private endpoints.

Therefore, a scenario involving:

“The private endpoint exists, but the Function cannot connect”

should prompt you to investigate:

Private DNS
DNS resolution
VNet connectivity
Network security rules
Routing

24. Service Endpoints

Service endpoints can be used with supported Azure services to restrict access to selected virtual network subnets.

For Functions, service endpoints can also participate in inbound access restriction scenarios.

However, service endpoints and private endpoints are not the same.

Service endpoint

Extends a virtual network identity to a supported Azure service and allows access to be restricted to selected subnets.

Private endpoint

Provides a private IP address in the virtual network through Azure Private Link.

For modern highly isolated architectures, private endpoints are often preferred when eliminating public exposure is the objective.

25. Outbound Traffic Control

Securing inbound access isn’t enough.

A compromised Function could potentially attempt to communicate with:

Malicious external services
Unapproved APIs
Command-and-control infrastructure
Unauthorized data destinations

VNet integration can route outbound traffic through an Azure virtual network.

NSGs can control outbound traffic on the integration subnet, and user-defined routes can direct traffic through desired network paths.

For example:

			
Function App
     |
VNet Integration
     |
     v
Integration Subnet
     |
     v
Azure Firewall
     |
     +---- Approved destinations
     |
     +---- Blocked destinations

		

This provides centralized control over outbound traffic.

26. NAT Gateway for Predictable Outbound IP

In scenarios where an external service requires an allowlist of public IP addresses, a NAT Gateway can provide a predictable outbound public IP.

The architecture can look like:

			
Function App
     |
VNet Integration
     |
Integration Subnet
     |
NAT Gateway
     |
Static Public IP
     |
Internet

		

This is useful when:

A partner API requires IP allowlisting.
A third-party service permits only known source IPs.
Security teams need a predictable egress address.

A NAT Gateway addresses outbound source IP consistency, not inbound application authentication.

27. Private Access to Dependent Azure Services

A common secure architecture is to protect both the Function and the resources it accesses.

For example:

             Private Network
                   |
          +--------+--------+
          |                 |
          v                 v
   Private Endpoint   Private Endpoint
          |                 |
          v                 v
    Azure Function       Azure SQL
                            |
                       Managed Identity

This provides two separate protections:

Network protection

Private connectivity prevents unnecessary public exposure.

Identity protection

Managed identity controls which Function is authorized to access the database.

This is stronger than relying on network location alone.

28. Protecting Storage Used by Functions

Azure Functions often relies on Azure Storage for platform operations and triggers.

Security considerations include:

Restricting storage network access
Using private endpoints where appropriate
Using identity-based connections where supported
Applying least-privilege access
Avoiding unnecessary storage account keys
Protecting the Function’s host storage

Current Functions guidance supports identity-based connections for supported host and binding scenarios, with capabilities depending on the hosting plan.

29. Function App Authentication and Network Security Work Together

Consider a financial API.

A strong architecture could be:

			
Corporate Application
        |
        | Private network
        v
   Private Endpoint
        |
        v
   Azure Function
        |
   Entra Authentication
        |
        v
    Authorization
        |
        v
 Managed Identity
        |
        v
   Azure SQL

		

Each layer answers a different security question:

Question	Control
Can the request reach the Function?	Private endpoint/network controls
Who is calling?	Microsoft Entra authentication
What can the caller do?	Authorization
How does Function access SQL?	Managed identity
Where is SQL located?	Private networking
What permissions does Function have?	Least-privilege RBAC/database permissions

30. Authentication and Authorization for APIs

Azure Functions are frequently used to implement APIs.

A secure API should consider:

Authentication

Use Microsoft Entra ID or another appropriate identity provider.

Authorization

Determine what authenticated identities can access.

Network security

Restrict which networks can reach the API.

Transport security

Use HTTPS.

Application security

Validate:

Input
Tokens
Claims
Permissions
Request size
Application state

The platform’s authentication layer is not a substitute for sound application authorization logic.

31. Don’t Confuse Azure RBAC with Application Authorization

Azure RBAC controls access to Azure resources and management operations.

For example:

Who can configure the Function App?

Application authorization answers a different question:

Which authenticated application user can call /deleteCustomer?

Therefore:

			
Azure RBAC
     |
     +-- Azure resource management
     
Application authorization
     |
     +-- Application/API operations

		

Both may be necessary.

32. Secure Deployment and Administration

Security should also cover who can modify the Function App.

Azure RBAC can control administrative operations such as:

Creating Function Apps
Modifying configuration
Changing networking
Assigning identities
Managing deployment settings

Follow least privilege when assigning administrative roles.

A developer who needs to deploy application code doesn’t necessarily need unrestricted subscription-level permissions.

33. Defense in Depth for Azure Functions

A mature Function security architecture might contain all of the following:

                Client
                  |
            HTTPS / TLS
                  |
                  v
       Network restrictions
                  |
                  v
         Private Endpoint
                  |
                  v
        Entra Authentication
                  |
                  v
          Authorization
                  |
                  v
          Azure Function
                  |
          Managed Identity
                  |
                  v
          Azure Key Vault
                  |
                  v
         Private Database

No single control is expected to solve every security problem.

This is the essence of defense in depth.

34. Common SC-500 Exam Traps

Trap 1: VNet integration means private inbound access

Incorrect.

VNet integration primarily provides outbound connectivity.

For private inbound access, consider a private endpoint or appropriate access restrictions.

Trap 2: Private endpoint authenticates users

Incorrect.

A private endpoint provides network-level private connectivity.

You may still need Microsoft Entra authentication and authorization.

Trap 3: Function keys are equivalent to Entra ID

Incorrect.

Function keys are shared secrets.

Microsoft Entra ID provides identity-based authentication and is generally more appropriate for enterprise identity scenarios.

Trap 4: Managed identity authenticates users

Incorrect.

Managed identity is primarily used by the Function App to authenticate to Azure resources.

Trap 5: Authentication means authorization

Incorrect.

A successfully authenticated caller may still lack permission to perform a particular operation.

Trap 6: Network restrictions replace authentication

Incorrect.

A request originating from an approved network isn’t necessarily from an authorized user.

Use defense in depth.

Trap 7: Private endpoint controls outbound traffic

Incorrect.

The private endpoint is used for inbound access to the Function App.

VNet integration handles outbound connectivity.

35. Azure Functions Security Decision Matrix

Requirement	Recommended control
Authenticate users to an HTTP Function	Microsoft Entra ID / App Service authentication
Authenticate applications to a Function API	Microsoft Entra ID / appropriate token-based authentication
Restrict callers by source IP	Access restrictions
Allow access only from a VNet	Appropriate private networking/service endpoint/access restriction design
Eliminate public inbound exposure	Private endpoint + appropriate public network configuration
Allow Function to access private Azure resources	VNet integration
Authenticate Function to Azure SQL	Managed identity
Authenticate Function to Key Vault	Managed identity
Avoid storing Azure credentials	Managed identity
Control outbound traffic	VNet integration + NSGs/UDRs/firewall as appropriate
Provide predictable outbound IP	NAT Gateway
Protect Function management operations	Azure RBAC
Centralize secrets	Azure Key Vault
Authenticate without custom authentication code	App Service Authentication

36. End-to-End Secure Function Architecture

Consider an enterprise Function that exposes an internal API and accesses sensitive data.

A strong architecture might be:

                         Corporate Users
                               |
                         VPN / ExpressRoute
                               |
                               v
                         Azure VNet
                               |
                       Private Endpoint
                               |
                               v
                     +------------------+
                     |  Azure Function  |
                     +------------------+
                         |          |
                         |          |
              Entra Auth |          | Managed Identity
                         |          |
                         v          v
                  Authorization   Key Vault
                                    |
                                    |
                                    v
                              Azure SQL
                                    ^
                                    |
                              Private Endpoint

The security controls work together:

Private Endpoint limits network exposure.
Microsoft Entra ID authenticates callers.
Authorization controls what authenticated callers can do.
Managed Identity authenticates the Function to Azure services.
Key Vault protects secrets.
Azure SQL private endpoint minimizes database exposure.
Azure RBAC controls management access.
VNet integration provides private outbound connectivity.

37. Key Takeaways for the SC-500 Exam

The most important concepts to remember are:

Authentication

Use Microsoft Entra ID and App Service Authentication when you need strong identity-based authentication for Function callers.

Authorization

Authentication does not automatically grant permission to perform operations.

Managed identity

Use managed identities whenever possible to eliminate credentials from Function code and configuration.

Private endpoint

Think:

Private inbound access.

VNet integration

Think:

Private outbound connectivity.

Access restrictions

Think:

Allow or deny inbound traffic based on IP addresses, subnets, service endpoints, or service tags.

Key Vault

Think:

Centralized protection of secrets, keys, and certificates.

Azure RBAC

Think:

Management-plane and Azure-resource authorization.

Defense in depth

The strongest architecture combines identity, network, application, and resource-level controls rather than relying on one security feature.

Practice Exam Questions

Question 1

A company has an Azure Function that exposes an internal business API. The security team requires that users authenticate using Microsoft Entra ID before they can access the API.

Which solution should you implement?

A. Enable a system-assigned managed identity on the Function App

B. Enable anonymous access and validate the user’s IP address

C. Store a shared function key in the client application

D. Configure App Service Authentication/Authorization with Microsoft Entra ID

Answer: D

Explanation: App Service Authentication/Authorization, also known as Easy Auth, can require callers to authenticate using Microsoft Entra ID before requests reach the Function application. A managed identity serves a different purpose: it allows the Function to authenticate to other Azure resources.

Question 2

An Azure Function needs to read secrets from Azure Key Vault. The security team prohibits storing client secrets or passwords in the Function App configuration.

What should you implement?

A. An anonymous HTTP trigger

B. A managed identity assigned to the Function App with appropriate Key Vault permissions

C. A function key stored in Key Vault

D. A public Key Vault endpoint without authentication

Answer: B

Explanation: A managed identity allows the Function to authenticate to Microsoft Entra-protected resources such as Key Vault without storing credentials in the application. The identity should receive only the permissions it needs.

Question 3

A Function App must access an Azure SQL Database that is accessible only through a private endpoint. Which networking capability should the Function use to reach the private database?

A. An inbound access restriction

B. A public IP address on the Function

C. Virtual network integration

D. App Service Authentication

Answer: C

Explanation: VNet integration provides outbound connectivity from a Function App into an Azure virtual network. It allows the Function to reach private endpoints and other resources reachable through the virtual network.

Question 4

A company wants its Azure Function to be accessible only through a private IP address in an Azure virtual network. Public access to the Function must be eliminated.

Which capability is most appropriate?

A. Function-level authentication keys

B. NAT Gateway

C. VNet integration only

D. A private endpoint with appropriate public network access restrictions

Answer: D

Explanation: A private endpoint provides private inbound connectivity to the Function through an Azure virtual network. VNet integration alone is primarily an outbound networking feature and doesn’t make the Function’s inbound endpoint private.

Question 5

An organization wants to allow an Azure Function to receive requests only from two corporate subnets. Requests from all other networks should be denied.

Which feature should the security engineer configure?

A. Function App access restrictions

B. Managed identity

C. Microsoft Entra application registration only

D. NAT Gateway

Answer: A

Explanation: Access restrictions provide priority-ordered inbound allow/deny rules and can use IP addresses and virtual network subnets. When rules are configured, an implicit deny-all behavior exists after the configured rules unless the unmatched behavior is otherwise configured.

Question 6

A developer says, “We enabled VNet integration, so our Function App can no longer be reached from the internet.”

Why is this statement incorrect?

A. VNet integration is used only for DNS

B. VNet integration is primarily an outbound networking capability and does not by itself make the Function’s inbound endpoint private

C. VNet integration automatically disables Microsoft Entra authentication

D. VNet integration applies only to Azure Storage

Answer: B

Explanation: VNet integration primarily allows outbound access from the Function App into a virtual network and resources reachable through it. Private inbound access requires an appropriate private endpoint or other inbound access-control mechanism.

Question 7

A security architect needs a Function App to access Azure SQL without storing a database username and password. The database should authorize the Function based on its Azure identity.

Which solution should be used?

A. Anonymous access to Azure SQL

B. A function key

C. A managed identity with appropriate Microsoft Entra/database permissions

D. A public SQL endpoint with a hard-coded password

Answer: C

Explanation: Azure Functions supports managed identity authentication to Azure SQL. The identity can be granted the appropriate database permissions, eliminating the need to store a username and password in the Function.

Question 8

A Function App is receiving authenticated requests from Microsoft Entra users. One authenticated user should be allowed to read customer information but must not be allowed to delete customer records.

Which control is primarily responsible for making this distinction?

A. Private endpoint

B. VNet integration

C. Authentication

D. Authorization

Answer: D

Explanation: Authentication establishes who the caller is. Authorization determines what that authenticated identity is permitted to do. The application must therefore enforce the appropriate permissions for operations such as reading and deleting customer records.

Question 9

A company needs all outbound traffic from a Function App to pass through a centralized network security device so that destinations can be inspected and controlled.

Which architecture is most appropriate?

A. VNet integration combined with appropriate routing and a network security device such as Azure Firewall

B. A private endpoint on the Function App only

C. App Service Authentication

D. Function-level authorization keys

Answer: A

Explanation: VNet integration provides the outbound path into the virtual network. Network routing, NSGs, user-defined routes, and an appropriate firewall architecture can then be used to control outbound traffic. A private endpoint primarily addresses inbound connectivity to the Function.

Question 10

A security team is reviewing a Function App architecture. The application currently uses a private endpoint for inbound access and a managed identity for access to Azure Key Vault. The team wants the Function to access an Azure SQL Database through a private endpoint as well.

Which additional capability is required for the Function to reach the SQL private endpoint?

A. Anonymous authentication

B. Function-level admin authorization

C. Virtual network integration

D. A second public IP address

Answer: C

Explanation: The Function needs outbound connectivity into the virtual network containing or providing access to the SQL private endpoint. VNet integration provides this outbound connectivity. The existing private endpoint on the Function controls inbound access to the Function itself, while managed identity controls authorization to Key Vault.

Final Exam Review

For SC-500, remember this simple model:

                  WHO?
                   |
            Authentication
                   |
                   v
                Function
                   |
                  WHAT?
                   |
             Authorization
                   |
          +--------+--------+
          |                 |
       INBOUND           OUTBOUND
          |                 |
 Private Endpoint      VNet Integration
 Access Restrictions        |
          |                 |
          |             Private Resources
          |                 |
          +--------+--------+
                   |
             Managed Identity
                   |
                   v
          Azure Resources

The four concepts most worth memorizing are:

Authentication → Who can call the Function?

Authorization → What can the caller do?

Private endpoint/access restrictions → Who or what can reach the Function?

VNet integration → Where can the Function connect outbound?

And whenever a question says “without storing credentials”, immediately consider managed identity.

Go to the SC-500 Exam Prep Hub main page