Category: Cloud computing

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

Evaluate compliance against security frameworks by using Defender for Cloud (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:
Manage and monitor security posture (20–25%)
   --> Manage security posture by using Defender for Cloud
      --> Evaluate compliance against security frameworks by using Defender for Cloud

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

Cloud security is not limited to protecting resources from attacks. Organizations must also demonstrate that their cloud environments are configured and operated in accordance with applicable security frameworks, industry standards, regulatory requirements, and organizational policies.

For example, an organization might need to evaluate its Azure environment against:

Microsoft Cloud Security Benchmark (MCSB)
NIST
ISO 27001
PCI DSS
CIS Benchmarks
SOC requirements
HIPAA
FedRAMP
CMMC
GDPR
NIS2
Other industry-specific or regional frameworks

Microsoft Defender for Cloud provides a Regulatory compliance experience that helps organizations assess their cloud resources against supported security standards, identify compliance gaps, investigate failing controls, remediate issues, and communicate compliance status.

For the SC-500 exam, it is important to understand the relationship between:

Security Standard → Compliance Control → Assessment → Recommendation → Remediation → Compliance Posture

1. What Is Regulatory Compliance?

Regulatory compliance is the process of ensuring that an organization satisfies applicable legal, regulatory, industry, and security requirements.

In cloud environments, compliance can involve requirements related to:

Identity and access management
Data protection
Encryption
Network security
Logging and monitoring
Vulnerability management
Configuration management
Incident response
Business continuity
Physical security
Privacy
Data retention

A security framework may contain hundreds of individual requirements.

Defender for Cloud helps organizations translate those requirements into technical security controls that can be evaluated against cloud resources.

2. Defender for Cloud Regulatory Compliance

The Regulatory compliance dashboard in Defender for Cloud provides an interactive view of compliance posture against assigned security standards.

The dashboard allows security teams to:

View assigned standards
Review compliance controls
Identify failed assessments
Investigate affected resources
Review remediation recommendations
Track compliance posture
Generate compliance reports
Monitor compliance over time
Work with manual assessments and attestations
Integrate compliance information with Microsoft Purview Compliance Manager

Microsoft describes security standards in Defender for Cloud as representations of industry standards, regulatory standards, and benchmarks.

3. Security Standards

A security standard represents a framework, benchmark, or regulatory requirement against which an environment can be evaluated.

Examples include:

Category	Example
Security benchmark	Microsoft Cloud Security Benchmark
Industry benchmark	CIS
Security framework	NIST
International standard	ISO 27001
Payment security	PCI DSS
Healthcare	HIPAA
Government	FedRAMP
Financial services	SWIFT
Privacy	GDPR
Cybersecurity regulation	NIS2

The exact standards available depend on the cloud environment and Microsoft’s current supported standards.

Current Defender for Cloud documentation lists standards including NIST CSF, NIST SP 800-53, PCI DSS, CIS, ISO 27001, HIPAA, FedRAMP, CMMC, GDPR, NIS2, DORA, and others across supported Azure, AWS, and GCP environments.

4. Microsoft Cloud Security Benchmark

The Microsoft Cloud Security Benchmark (MCSB) is particularly important for the SC-500 exam.

MCSB provides Microsoft security recommendations and technical guidance for cloud environments.

It covers security areas such as:

Network security
Identity management
Privileged access
Data protection
Logging
Incident response
Vulnerability management
Endpoint security
Application security
Cloud governance

When Defender for Cloud is enabled, the MCSB is automatically used as the default security benchmark for Azure environments.

Exam Tip

If a question asks which benchmark is automatically available when Defender for Cloud is enabled for Azure, think:

Microsoft Cloud Security Benchmark (MCSB).

5. Security Standards vs. Security Controls

A security standard is not simply one large requirement.

A standard is broken down into controls.

For example:

			
Security Standard
       |
       +--- Identity Control
       |
       +--- Network Security Control
       |
       +--- Data Protection Control
       |
       +--- Logging Control
       |
       +--- Vulnerability Control

		

Each control represents a logical group of related security requirements.

Defender for Cloud evaluates applicable resources against controls that can be assessed automatically.

6. Compliance Controls

A compliance control is a logical grouping of security requirements within a standard.

Controls can contain one or more security assessments or recommendations.

Conceptually:

			
PCI DSS
   |
   +--- Network Security
   |       |
   |       +--- Assessment
   |       +--- Assessment
   |
   +--- Access Control
   |       |
   |       +--- Assessment
   |       +--- Assessment
   |
   +--- Data Protection
           |
           +--- Assessment
           +--- Assessment

		

This hierarchy makes it easier to determine where an organization is meeting requirements and where gaps exist.

7. Assessments

An assessment determines whether a resource satisfies a particular security requirement.

For example, an assessment might determine whether:

Storage data is encrypted
Administrative access is restricted
Network traffic is appropriately protected
A VM has disk encryption enabled
A resource has an insecure configuration
Logging is configured

If a resource fails an automated assessment, Defender for Cloud can generate a security recommendation explaining what needs to be changed.

The relationship can therefore be thought of as:

			
Standard
   ↓
Control
   ↓
Assessment
   ↓
Resource Evaluation
   ↓
Pass / Fail / Unavailable

		

8. Compliance Assessment States

Defender for Cloud uses compliance assessment states to communicate whether resources satisfy a control.

The Regulatory compliance experience uses three important states:

Compliant

Resources in scope satisfy the applicable assessment.

Noncompliant

One or more resources do not satisfy the applicable requirement.

Unavailable

Defender for Cloud cannot automatically determine compliance for that control.

This distinction is important.

Unavailable does not necessarily mean noncompliant.

It means Defender for Cloud cannot automatically determine the compliance state for that control.

9. Why Some Controls Are Unavailable

Not every compliance requirement can be evaluated automatically.

Some requirements require:

Human review
Organizational documentation
Policies
Procedures
Evidence
Interviews
Physical security verification
Business processes
External audit evidence

For example, a framework might require an organization to have a documented incident-response procedure.

Defender for Cloud cannot determine solely from Azure resource configuration whether that procedure exists and is being followed.

The control may therefore be unavailable for automatic assessment.

10. Automated vs. Manual Assessments

This distinction is particularly important for the SC-500 exam.

Automated assessment

Defender for Cloud can evaluate the requirement using available technical information.

Example:

Are storage accounts configured according to the required security configuration?

Defender for Cloud can inspect resource configuration and determine the result.

Manual assessment

The requirement requires customer input or evidence.

Example:

Does the organization maintain a documented security incident-response procedure?

A cloud platform cannot necessarily determine this automatically.

Manual assessments can require the organization to provide an attestation and evidence. Current Microsoft documentation explicitly supports manual attestation and evidence through the Regulatory compliance experience.

11. The Regulatory Compliance Dashboard

The Regulatory compliance dashboard is the central location for reviewing compliance posture.

Security teams can use it to:

View assigned standards
Review compliance scores/status
Examine controls
Identify failing assessments
Investigate resources
Review remediation actions
Track compliance over time
Generate reports
Access audit-related reports

The dashboard provides an interactive overview of the organization’s compliance state.

12. Understanding the Compliance Dashboard

A simplified view of the workflow is:

			
Regulatory Compliance
        |
        +--- Standards
        |
        +--- Controls
        |
        +--- Assessments
        |
        +--- Resources
        |
        +--- Recommendations
        |
        +--- Remediation
        |
        +--- Reports

		

A security administrator can start at the standard level and drill down toward individual resources.

For example:

			
PCI DSS
   ↓
Requirement / Control
   ↓
Failed Assessment
   ↓
Azure Resource
   ↓
Security Recommendation
   ↓
Remediation

		

13. Assigning a Compliance Standard

Organizations can assign supported regulatory compliance standards to applicable scopes.

The scope can include supported:

Azure subscriptions
AWS accounts
GCP projects

Defender for Cloud uses Azure Policy initiatives to represent regulatory compliance standards and evaluates the selected scope against those standards.

Example

Suppose a company has an Azure subscription supporting a payment-processing application.

The company may choose to apply:

PCI DSS

to the appropriate scope.

Defender for Cloud can then assess applicable resources against the controls represented by that standard.

14. Why Scope Matters

Compliance assessments are performed against a defined scope.

For example:

			
Tenant
   |
   +--- Subscription A
   |       |
   |       +--- Production
   |
   +--- Subscription B
           |
           +--- Development

		

The organization might apply a compliance standard to only the production subscription.

This is important because compliance requirements may differ between environments.

For example:

Production may contain regulated data.
Development may contain synthetic data.
A specific subscription may host payment-processing workloads.
Another subscription may host unrelated applications.

Therefore, applying the correct standard to the correct scope is an important part of compliance management.

15. Security Policies and Azure Policy Initiatives

Defender for Cloud regulatory standards are closely related to Azure Policy.

A useful conceptual model is:

			
Regulatory Standard
        ↓
Azure Policy Initiative
        ↓
Policies / Controls
        ↓
Resource Evaluation
        ↓
Assessment Results

		

Microsoft documentation states that regulatory compliance standards in Defender for Cloud use Azure Policy initiatives.

This is an important SC-500 relationship.

Exam Tip

If a question asks what mechanism is used to represent regulatory compliance standards for assessment, remember:

Azure Policy initiatives.

16. Compliance Gaps

A compliance gap exists when a resource or configuration does not satisfy an applicable compliance requirement.

For example:

			
ISO 27001
   |
   +--- Access Control
           |
           +--- PASS
           |
           +--- PASS
           |
           +--- FAIL
                  |
                  ↓
             VM01
                  |
                  ↓
        Security Recommendation

		

The failing assessment tells the security administrator where attention is required.

17. Investigating a Compliance Gap

A typical investigation might follow this sequence:

Step 1

Open Regulatory compliance.

Step 2

Select the relevant standard.

Step 3

Select the control with a failing assessment.

Step 4

Review the affected resources.

Step 5

Review the associated security recommendation.

Step 6

Review remediation instructions.

Step 7

Remediate the resource.

Step 8

Wait for the assessment to run again.

Step 9

Confirm that the compliance status has improved.

This creates a continuous improvement cycle.

18. Compliance Recommendations

A failed compliance assessment frequently maps to a security recommendation.

For example:

Control:

Protect data at rest.

Assessment:

Storage resource does not meet encryption requirement.

Recommendation:

Configure the required encryption settings.

Remediation:

Modify the resource configuration.

This creates a practical relationship between compliance and security operations.

Compliance does not merely tell an organization:

“You failed.”

It can help explain:

“Here is the resource causing the problem and what you can do about it.”

19. Compliance Scores and Posture

The Regulatory compliance dashboard provides a way to monitor compliance posture.

For example:

			
PCI DSS
Passed Controls:       82%
Failed Controls:       18%

An organization can use this information to:

Identify weak areas
Prioritize remediation
Communicate progress
Track improvements
Prepare for audits

However, a compliance percentage should not automatically be interpreted as a legal certification.

20. Defender for Cloud Does Not Make an Organization “Certified”

This is a critical concept.

Suppose Defender for Cloud shows:

ISO 27001 — 95% compliant

That does not automatically mean:

“The company is ISO 27001 certified.”

Similarly:

PCI DSS — 100% of automatically assessed controls passed

does not necessarily mean the organization has satisfied every PCI DSS obligation or received a formal certification/attestation from the appropriate authority.

Defender for Cloud provides assessment and posture-management capabilities.

Organizations may still need:

Policies
Procedures
Evidence
Manual attestations
Independent audits
External certification
Other organizational controls

Exam Principle

Compliance tooling supports compliance; it does not automatically confer legal or regulatory certification.

21. Shared Responsibility

Cloud compliance must also be understood in the context of the shared responsibility model.

Microsoft is responsible for security aspects of the cloud platform that are under Microsoft’s control.

The customer remains responsible for many aspects of its own:

Data
Identities
Configurations
Applications
Access
Policies
Processes

Therefore, passing a technical cloud assessment does not necessarily mean every organizational compliance requirement has been satisfied.

22. Microsoft Actions vs. Your Actions

The Regulatory compliance experience can help distinguish responsibilities associated with compliance.

For a selected control, the dashboard can provide information about:

Your Actions

Actions the customer needs to take to improve compliance.

Microsoft Actions

Actions Microsoft has taken to support compliance with the applicable standard.

This is particularly useful when communicating compliance responsibilities to auditors and stakeholders.

23. Manual Attestation

Manual assessments require customer participation.

A security administrator can provide:

An attestation
Supporting information
Evidence

This allows the organization to document compliance for requirements that Defender for Cloud cannot technically evaluate on its own.

Conceptually:

			
Manual Control
      |
      ↓
Customer Review
      |
      ↓
Attestation
      |
      ↓
Evidence
      |
      ↓
Compliance Record

		

Example

A framework requires:

Security incidents must be reviewed according to a documented organizational process.

Defender for Cloud may not be able to prove that the organization follows the process.

The organization may therefore provide an attestation and supporting evidence.

24. Compliance Reporting

Organizations often need to communicate compliance posture to:

Security leadership
IT leadership
Auditors
Compliance officers
Risk management teams
Regulators
Business stakeholders

Defender for Cloud supports reporting capabilities that can help communicate compliance status.

The Regulatory compliance dashboard can generate reports for a selected standard, including a summary of compliance status based on Defender for Cloud assessment data.

25. Compliance Over Time

Compliance is not a one-time activity.

A company might be compliant today and become noncompliant tomorrow because:

A new resource is deployed.
A configuration changes.
A firewall rule is modified.
A new identity receives excessive permissions.
Encryption is disabled.
A security policy changes.
A new vulnerability is discovered.

Therefore:

Compliance must be continuously monitored.

Defender for Cloud’s compliance capabilities allow organizations to track their compliance posture over time.

26. Compliance Workbooks

Compliance information can also be presented through workbooks.

Workbooks can help security teams visualize and communicate information such as:

Compliance trends
Standard performance
Control status
Remediation progress
Compliance changes over time

This can be particularly useful for executive reporting.

27. Microsoft Purview Compliance Manager Integration

Defender for Cloud compliance information can integrate with Microsoft Purview Compliance Manager.

This provides an opportunity to bring compliance information into a broader compliance-management experience.

Current Microsoft documentation states that compliance data from Defender for Cloud can be surfaced in Compliance Manager for the same standards, including standards monitoring supported AWS and GCP environments.

Think of the distinction this way:

Defender for Cloud

Cloud security posture and technical compliance assessment

Microsoft Purview Compliance Manager

Broader compliance-management experience across the organization’s digital estate

28. Compliance Reporting vs. Audit Reports

These concepts should not be confused.

Compliance status report

Communicates the organization’s current compliance posture based on Defender for Cloud assessment data.

Audit report

Provides Microsoft audit/certification documentation for applicable Microsoft services and standards.

An organization’s own compliance posture is not the same thing as Microsoft’s certification of its cloud services.

This distinction can matter when preparing evidence for auditors.

29. Compliance Assessment Refresh

After correcting a compliance issue, the dashboard may not immediately show the new result.

Defender for Cloud assessments run periodically.

Current Microsoft documentation states that compliance assessments run approximately every 12 hours for the applicable assessments.

Therefore, if an administrator fixes a resource and immediately checks the compliance dashboard, the old result may still be displayed.

Exam Scenario

A security engineer fixes a failed recommendation but the compliance dashboard still shows the resource as noncompliant.

What should the engineer consider?

The assessment may not have run again yet.

30. Automating Compliance Responses

Defender for Cloud supports workflow automation.

For example, an organization could configure an automation workflow that responds when a regulatory compliance assessment changes.

A Logic App can be used to perform actions such as:

Sending notifications
Triggering workflows
Initiating downstream processes
Alerting compliance personnel

Current Microsoft documentation specifically describes triggering Logic Apps when regulatory compliance assessments change state.

31. Compliance Across Multiple Clouds

Modern organizations often use:

Azure
AWS
Google Cloud

Defender for Cloud can provide regulatory compliance visibility across supported multicloud environments.

This allows organizations to use a centralized security posture experience rather than maintaining completely separate compliance-management processes for each cloud.

Supported standards vary by cloud provider.

For example:

			
Microsoft Defender for Cloud
          |
   +------+------+
   |      |      |
 Azure   AWS    GCP
   |      |      |
Standards / Compliance Assessments

		

The specific standards available depend on the cloud provider and the current Defender for Cloud capabilities.

32. Custom Standards

Organizations may have security requirements that aren’t fully represented by a built-in regulatory standard.

Defender for Cloud supports custom standards and custom recommendations.

Custom recommendations can be created with organization-specific logic, including KQL-based evaluation, and can then be associated with custom standards.

Example

An organization might require:

All production storage resources must use a specific approved configuration.

If a built-in framework does not provide the exact requirement, the organization can create a custom recommendation and incorporate it into a custom standard.

33. Built-In Standards vs. Custom Standards

Capability	Built-In Standard	Custom Standard
Based on recognized framework	Yes	Not necessarily
Microsoft-provided	Yes	Organization-defined
Standard controls included	Yes	Organization selects/defines
Custom organizational requirements	Limited	Strong
Useful for regulatory frameworks	Yes	Can supplement them
Can use custom recommendations	Not the primary purpose	Yes

Custom standards are particularly useful when organizations need to enforce internal security requirements that aren’t adequately represented by an existing framework.

34. Example: PCI DSS Assessment

Consider a company processing credit-card transactions.

The organization assigns PCI DSS to the appropriate environment.

The resulting workflow might be:

			
PCI DSS
   |
   ↓
Compliance Controls
   |
   ↓
Azure Resources
   |
   ↓
Assessments
   |
   +---- PASS
   |
   +---- FAIL
          |
          ↓
    Recommendation
          |
          ↓
      Remediation
          |
          ↓
    Reassessment

		

The security team can then identify which controls are failing and which resources are responsible.

35. Example: ISO 27001 Assessment

Suppose an organization wants to evaluate its Azure environment against ISO 27001.

The organization can:

Assign the appropriate standard.
Review the Regulatory compliance dashboard.
Examine the applicable controls.
Identify failed assessments.
Investigate affected resources.
Remediate applicable technical issues.
Provide manual evidence where required.
Generate compliance reports.
Track progress over time.

The process helps the organization identify technical gaps, but formal ISO certification involves additional organizational and audit requirements.

36. Example: NIST Assessment

Suppose an organization uses NIST as its security framework.

Defender for Cloud can help map technical cloud configurations and recommendations to the applicable supported NIST standard.

The security team can then determine:

Which controls are passing
Which controls are failing
Which resources are affected
Which recommendations need remediation
Which controls require manual assessment

This provides a technical starting point for broader compliance activities.

37. Compliance vs. Security Posture

These concepts overlap but are not identical.

Security posture

Answers:

How secure is our environment?

Regulatory compliance

Answers:

How closely does our environment align with the requirements of a particular standard or framework?

For example, an organization could have:

Strong security posture
But not satisfy a particular regulatory requirement

Conversely, an organization could satisfy many technical controls in a framework while still having broader security risks that aren’t fully captured by that framework.

Therefore, organizations should manage both.

38. Compliance vs. Secure Score

Secure Score and Regulatory Compliance serve different purposes.

Secure Score	Regulatory Compliance
Measures security posture	Measures alignment with a selected standard
Broad security recommendations	Framework-specific controls
Helps improve security posture	Helps evaluate compliance requirements
Not a certification	Not automatically a certification
Security-focused	Compliance/framework-focused

Exam Tip

If the question mentions:

“Improve overall security posture”

think Secure Score.

If it mentions:

“Evaluate against PCI DSS, ISO, NIST, CIS, or another framework”

think Regulatory compliance.

39. Compliance vs. Defender for Cloud Recommendations

Security recommendations are often the technical mechanism through which compliance issues are addressed.

For example:

			
Compliance Requirement
        ↓
Control
        ↓
Failed Assessment
        ↓
Security Recommendation
        ↓
Remediation

		

This makes recommendations extremely important to compliance operations.

40. Common Mistakes

Mistake 1: Assuming a passing compliance score equals certification

A Defender for Cloud compliance result does not automatically constitute formal certification.

Mistake 2: Treating “Unavailable” as “Noncompliant”

Unavailable means Defender for Cloud cannot automatically determine the result.

Mistake 3: Assuming every control can be automated

Some controls require manual evidence or attestation.

Mistake 4: Forgetting the scope

Standards are assigned to specific scopes.

Always determine which subscription, account, project, or other supported scope is being assessed.

Mistake 5: Expecting remediation results immediately

Compliance assessments run periodically. Changes may not appear immediately.

Mistake 6: Confusing MCSB with a regulatory certification

MCSB is Microsoft’s cloud security benchmark. It is not itself a regulatory certification.

Mistake 7: Confusing compliance standards with individual policies

A standard represents a framework or benchmark containing multiple controls. Azure Policy initiatives are used to implement regulatory compliance standards for assessment.

Mistake 8: Assuming Microsoft is responsible for every compliance requirement

Cloud compliance follows a shared-responsibility model.

41. SC-500 Exam-Focused Comparison

If the question asks about…	Think about…
Overall cloud security posture	Secure Score
A specific security weakness	Security recommendation
Evaluating against ISO, PCI DSS, NIST, CIS, etc.	Regulatory compliance
Default Azure security benchmark	MCSB
Logical grouping of related requirements	Compliance control
Technical evaluation of a control	Assessment
Cannot automatically determine compliance	Unavailable/manual assessment
Customer-provided evidence	Manual attestation
Applying a standard to a subscription	Assign compliance standard
Framework implementation mechanism	Azure Policy initiative
Fixing a failed technical assessment	Security recommendation/remediation
Communicating compliance posture	Compliance report/workbook
Broader compliance management	Microsoft Purview Compliance Manager
Automatic response to assessment changes	Workflow automation / Logic Apps
Organization-specific requirements	Custom standards/recommendations

42. A Complete Compliance Management Workflow

The entire process can be summarized as:

                   SELECT STANDARD
                         |
                         v
                DEFINE THE SCOPE
                         |
                         v
                 ASSESS RESOURCES
                         |
              +----------+----------+
              |                     |
             PASS                  FAIL
              |                     |
              |                     v
              |              INVESTIGATE GAP
              |                     |
              |                     v
              |              REVIEW RECOMMENDATION
              |                     |
              |                     v
              |                 REMEDIATE
              |                     |
              |                     v
              |                REASSESS
              |                     |
              +----------+----------+
                         |
                         v
                 MONITOR OVER TIME
                         |
                         v
                REPORT COMPLIANCE

For controls that cannot be automatically evaluated:

			
Manual Control
     |
     v
Customer Review
     |
     v
Attestation + Evidence
     |
     v
Compliance Record

		

43. Key Takeaways

For the SC-500 exam, remember the following:

Defender for Cloud provides a Regulatory compliance experience for evaluating cloud environments against supported standards and frameworks.
A security standard represents a framework, benchmark, or regulatory requirement.
Standards are divided into compliance controls.
Controls are evaluated through assessments.
Failed assessments can produce security recommendations.
Security recommendations provide remediation guidance.
MCSB is the default security benchmark for Azure when Defender for Cloud is enabled.
Regulatory compliance standards use Azure Policy initiatives.
Standards can be assigned to appropriate scopes such as Azure subscriptions and supported multicloud scopes.
Some controls can be assessed automatically.
Other controls require manual attestation and evidence.
Unavailable does not mean noncompliant; it means Defender for Cloud cannot automatically determine the status.
Compliance status can be investigated through the Regulatory compliance dashboard.
Compliance reports can communicate assessment results to stakeholders.
Compliance can be monitored over time rather than evaluated only once.
Compliance assessment results may take time to update after remediation because assessments run periodically.
Defender for Cloud compliance information can integrate with Microsoft Purview Compliance Manager.
Workflow automation can trigger Logic Apps when compliance assessments change.
Custom standards and recommendations can address organization-specific requirements.
Passing Defender for Cloud assessments does not by itself constitute legal or regulatory certification.

Practice Exam Questions

Question 1

A security administrator wants to evaluate an Azure subscription against the requirements of a recognized security framework such as ISO 27001.

Which Microsoft Defender for Cloud capability should the administrator use?

A. Secure Score only

B. Cloud Security Explorer

C. Microsoft Defender Vulnerability Management

D. Regulatory compliance

Answer: D

Explanation

The Regulatory compliance experience is designed to evaluate cloud environments against supported security standards, regulatory standards, and benchmarks.

Secure Score is useful for evaluating overall security posture, but it does not replace framework-specific compliance assessment.

Question 2

An organization enables Microsoft Defender for Cloud on an Azure subscription. The security team wants to begin evaluating the environment against Microsoft’s default cloud security benchmark.

Which benchmark should the team expect?

A. PCI DSS

B. Microsoft Cloud Security Benchmark

C. ISO 27001

D. NIST SP 800-53

Answer: B

Explanation

The Microsoft Cloud Security Benchmark (MCSB) is the default security benchmark used for Azure when Defender for Cloud is enabled.

Other regulatory and industry standards can be added as appropriate.

Question 3

A compliance administrator selects a regulatory standard and wants to understand why several resources are reported as failing a particular requirement.

What should the administrator investigate first?

A. Microsoft Security Copilot

B. Secure Score history

C. The compliance control and its failing assessments

D. Azure Activity Log only

Answer: C

Explanation

The Regulatory compliance dashboard organizes standards into controls, which contain assessments.

The administrator can expand the applicable control, investigate failing assessments, identify affected resources, and review associated remediation guidance.

Question 4

A regulatory framework contains a requirement that an organization maintain a documented incident-response procedure. Defender for Cloud cannot determine automatically whether the organization has such a procedure.

How should this type of requirement be handled?

A. Mark the resource as vulnerable

B. Automatically pass the control

C. Disable the entire compliance standard

D. Use a manual assessment and provide appropriate attestation or evidence

Answer: D

Explanation

Not every compliance requirement can be evaluated from cloud resource configuration.

For requirements that cannot be automatically assessed, Defender for Cloud can use manual assessments, where the customer provides an attestation and supporting evidence.

An unavailable assessment should not automatically be interpreted as a failed assessment.

Question 5

An administrator fixes a resource that previously failed a compliance assessment. Immediately afterward, the Regulatory compliance dashboard still shows the resource as noncompliant.

What is the most likely explanation?

A. The compliance standard must always be deleted and reassigned

B. The assessment has not yet run again

C. Secure Score must reach 100 percent first

D. The resource must be moved to another subscription

Answer: B

Explanation

Defender for Cloud compliance assessments run periodically. Current Microsoft documentation indicates that applicable assessments run approximately every 12 hours.

Therefore, a remediation change may not be reflected immediately in the compliance dashboard.

Question 6

A company wants to apply a PCI DSS standard only to the Azure subscription hosting its payment-processing workloads.

What should the security administrator configure?

A. Assign the PCI DSS standard to the appropriate scope

B. Enable Microsoft Sentinel on every subscription

C. Increase the Secure Score target

D. Create a Microsoft Purview eDiscovery case

Answer: A

Explanation

Regulatory compliance standards can be assigned to appropriate scopes.

If only one subscription contains the applicable workload, the organization can apply the standard to that subscription rather than unnecessarily applying it to unrelated environments.

Question 7

Which technology mechanism is used to represent regulatory compliance standards for assessment in Microsoft Defender for Cloud?

A. Microsoft Sentinel analytics rules

B. Azure Monitor alerts

C. Azure Policy initiatives

D. Microsoft Entra Conditional Access policies

Answer: C

Explanation

Defender for Cloud regulatory compliance standards use Azure Policy initiatives.

These provide the policy structure used to evaluate applicable resources against the controls represented by the standard.

This is an important SC-500 distinction: Conditional Access is primarily an identity access-control mechanism, while Azure Policy initiatives are used for resource governance and compliance evaluation.

Question 8

A security administrator sees that a compliance control is displayed as unavailable rather than compliant or noncompliant.

What does this generally indicate?

A. The subscription has been compromised

B. The standard has been permanently disabled

C. The resource has failed the control

D. Defender for Cloud cannot automatically determine compliance for that control

Answer: D

Explanation

An unavailable control indicates that Defender for Cloud cannot automatically assess the requirement.

This is different from a noncompliant result.

Some controls require manual assessment, organizational evidence, or other information that cannot be determined from cloud resource configuration alone.

Question 9

An organization wants to provide executives with a summary of its current compliance posture against a selected security standard.

Which Defender for Cloud capability is most appropriate?

A. Compliance status reporting

B. Just-in-time VM access

C. Cloud Security Explorer

D. Network Security Groups

Answer: A

Explanation

The Regulatory compliance experience supports compliance reporting, including reports summarizing the organization’s current compliance status for a selected standard.

These reports can help communicate compliance posture to stakeholders and support audit activities.

The other options address unrelated security functions.

Question 10

A company wants Defender for Cloud to notify its compliance team when a regulatory compliance assessment changes state.

Which solution should the company use?

A. Azure Bastion

B. Logic Apps with Defender for Cloud workflow automation

C. Azure Firewall

D. Microsoft Entra PIM

Answer: B

Explanation

Defender for Cloud supports workflow automation that can respond to changes in regulatory compliance assessments.

A Logic App can be configured to perform downstream actions such as notifications or other workflow processing when the relevant Defender for Cloud event occurs.

Final SC-500 Exam Reminder

The most important mental model for this topic is:

Standard → Control → Assessment → Finding → Recommendation → Remediation → Reassessment

And remember these four distinctions:

MCSB
→ Microsoft’s cloud security benchmark

Regulatory Compliance
→ Evaluate your environment against a selected framework or standard

Security Recommendation
→ Identifies a technical security issue and provides remediation guidance

Manual Attestation
→ Used when Defender for Cloud cannot automatically determine whether a compliance requirement is satisfied

Finally, remember:
Defender for Cloud can help an organization measure, improve, and document its compliance posture, but a passing Defender for Cloud assessment does not by itself constitute formal regulatory certification.

Defender for Cloud can help an organization measure, improve, and document its compliance posture, but a passing Defender for Cloud assessment does not by itself constitute formal regulatory certification.

Go to the SC-500 Exam Prep Hub main page

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

Assign roles in Microsoft Sentinel (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:
Manage and monitor security posture (20–25%)
   --> Implement activity and event collection in Microsoft Sentinel
      --> Assign roles in Microsoft Sentinel

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

Microsoft Sentinel uses role-based access control (RBAC) to control what users and services can do within a Sentinel environment.

For a security operations team, assigning the correct roles is critical. Security analysts may need to investigate and manage incidents, security engineers may need to create analytics rules and other Sentinel content, while other users may only need read access to security information.

Microsoft Sentinel provides several built-in Azure roles specifically designed for these scenarios, including:

Microsoft Sentinel Reader
Microsoft Sentinel Responder
Microsoft Sentinel Contributor
Microsoft Sentinel Playbook Operator
Microsoft Sentinel Automation Contributor

Microsoft Sentinel also works with broader Azure roles such as Owner, Contributor, and Reader, as well as Log Analytics roles. Because these broader roles can provide access beyond Sentinel itself, Microsoft recommends using the least-privileged Sentinel-specific role that satisfies the user’s requirements.

For the SC-500 exam, you should understand what each role allows, when to assign each role, where to assign it, how permissions are inherited, and how to avoid granting excessive privileges.

1. What Is RBAC?

Role-Based Access Control (RBAC) is an authorization model in which permissions are assigned to roles and those roles are assigned to users, groups, service principals, or managed identities.

Instead of granting individual permissions directly to every user, an organization can define roles based on job responsibilities.

For example:

                    Microsoft Sentinel
                           |
              +------------+------------+
              |            |            |
              v            v            v
          Analyst       Engineer     Automation
              |            |            |
              v            v            v
          Responder     Contributor   Automation
                                        Contributor

This makes security administration easier and supports the principle of least privilege.

Microsoft Sentinel uses Azure RBAC for its SIEM capabilities. Microsoft Sentinel also has a separate role model for its data lake capabilities that uses Microsoft Entra ID RBAC.

For SC-500, the primary focus is the Azure RBAC roles used to control access to Microsoft Sentinel.

2. Why Role Assignment Matters in Microsoft Sentinel

A Microsoft Sentinel environment can contain highly sensitive information, including:

Security alerts
Incidents
User activity
Authentication events
Network activity
Endpoint information
Threat intelligence
Investigation data
Security analytics
Incident comments
Security automation

Giving every user administrative access would create unnecessary security risk.

For example, a junior SOC analyst may only need to investigate and update incidents. Giving that analyst the ability to modify analytics rules or install Sentinel solutions could violate least-privilege principles.

Therefore, organizations should map job responsibilities to appropriate Sentinel roles.

3. The Core Microsoft Sentinel Roles

The five Sentinel-specific Azure roles you should know for the SC-500 exam are:

Role	Primary purpose
Microsoft Sentinel Reader	View Sentinel information
Microsoft Sentinel Responder	View information and manage incidents
Microsoft Sentinel Contributor	Manage Sentinel content, resources, and incidents
Microsoft Sentinel Playbook Operator	View and manually run playbooks
Microsoft Sentinel Automation Contributor	Allows Sentinel automation to add/playbook actions to automation rules

Microsoft’s current role documentation identifies these as built-in roles for Microsoft Sentinel SIEM.

The key progression to remember is:

			
Reader
   |
   v
Responder
   |
   v
Contributor

		

Each step generally provides broader Sentinel capabilities.

Playbook Operator is a specialized role rather than simply another level in that hierarchy.

Automation Contributor is primarily intended for Sentinel automation rather than normal human users.

4. Microsoft Sentinel Reader

The Microsoft Sentinel Reader role provides read access to Sentinel information.

A user with this role can generally:

View Sentinel data
View incidents
View workbooks
View recommendations
View Sentinel resources
Query supported workspace data

The Reader role does not provide the ability to manage incidents or modify Sentinel configuration.

Microsoft’s current role documentation identifies Sentinel Reader as providing view access to Sentinel data, incidents, workbooks, recommendations, and other resources.

Example

A compliance auditor needs to review Sentinel information but should not be able to modify incidents or Sentinel configuration.

Microsoft Sentinel Reader is a strong fit.

5. Microsoft Sentinel Responder

The Microsoft Sentinel Responder role includes the Reader capabilities and adds incident-management capabilities.

Conceptually:

			
Microsoft Sentinel Reader
          +
Incident management
          =
Microsoft Sentinel Responder

		

A Responder can generally:

View Sentinel information
View incidents
Manage incidents
Perform supported incident-response actions
Work with incident-related information
Use certain response capabilities

Microsoft’s current documentation describes the Responder role as including all Reader permissions plus the ability to manage incidents.

Example

A SOC analyst needs to:

Investigate incidents
Update incidents
Add comments
Change incident status
Perform incident-response activities

The Microsoft Sentinel Responder role is generally more appropriate than Reader.

6. Microsoft Sentinel Contributor

The Microsoft Sentinel Contributor role provides broader administrative capabilities.

It includes the capabilities of Responder and adds the ability to manage Sentinel content and resources.

A Contributor can generally:

Manage incidents
Create and edit analytics rules
Manage Sentinel resources
Install and update solutions
Manage security content
Configure Sentinel functionality

Microsoft describes the Contributor role as including Responder permissions plus capabilities such as installing/updating solutions and creating/editing resources.

Example

A Sentinel engineer is responsible for:

Creating analytics rules
Maintaining workbooks
Installing Sentinel solutions
Managing Sentinel configuration
Managing incidents

Microsoft Sentinel Contributor is appropriate.

7. Microsoft Sentinel Playbook Operator

The Microsoft Sentinel Playbook Operator is a specialized role.

Its purpose is to allow a user to view and manually run playbooks.

This role does not give the user the broad permissions of Sentinel Contributor.

Microsoft currently describes Playbook Operator as allowing users to list, view, and manually run playbooks.

Important distinction

Do not confuse:

Running a playbook

with:

Creating or editing a playbook.

These are different permissions.

A user who only needs to run an existing playbook may need Microsoft Sentinel Playbook Operator, while creating or modifying the underlying Logic App requires additional Logic Apps permissions.

8. Microsoft Sentinel Automation Contributor

The Microsoft Sentinel Automation Contributor role is primarily associated with Sentinel automation.

It allows Microsoft Sentinel to add playbooks to automation rules.

This is an important distinction:

Automation Contributor is not intended to be a general-purpose role for human analysts.

Microsoft explicitly describes this role as allowing automation rules to run playbooks and notes that it is not used for other purposes.

This role becomes particularly important when Sentinel needs to execute playbooks automatically.

9. Role Comparison

A simplified comparison is useful for exam preparation:

Capability	Reader	Responder	Contributor	Playbook Operator
View Sentinel data	Yes	Yes	Yes	Limited
View incidents	Yes	Yes	Yes	No general incident access
Manage incidents	No	Yes	Yes	No
Create/edit Sentinel resources	No	No	Yes	No
Manage Sentinel content	No	No	Yes	No
Install/update solutions	No	No	Yes	No
Manually run playbooks	No	Not by this role alone	Not by this role alone	Yes

The important distinction is that Responder is primarily an incident-management role, while Contributor is an administrative/content-management role.

10. Reader vs. Responder

This is one of the most likely distinctions to appear in a certification question.

Reader

Use Reader when someone needs to:

View information
Review incidents
Query available data
Review workbooks

but does not need to modify incidents.

Responder

Use Responder when someone needs to:

View information
Investigate incidents
Manage incidents
Perform incident-response activities

Exam shortcut

Think:

Reader = See

Responder = See + Respond

11. Responder vs. Contributor

Another important distinction is between Responder and Contributor.

Responder

Primarily focused on incident response.

Contributor

Focused on broader Sentinel administration and content management.

For example:

Task	Appropriate role
View an incident	Reader
Investigate/manage an incident	Responder
Create an analytics rule	Contributor
Install a Sentinel solution	Contributor
Manage Sentinel content	Contributor
Manually run a playbook	Playbook Operator

This distinction is important because organizations should avoid giving Contributors to analysts who only need incident-management capabilities.

12. Azure RBAC Scope

Azure RBAC assignments can be applied at different scopes.

The major scopes are:

			
Management Group
       |
     Subscription
       |
   Resource Group
       |
     Resource

		

Permissions assigned at a higher scope can be inherited by resources beneath that scope.

For example:

			
Subscription
     |
     +-- Resource Group
            |
            +-- Sentinel Workspace
            |
            +-- Playbooks
            |
            +-- Workbooks

		

A role assigned at the resource-group level can therefore apply to the resources within that resource group.

13. Why Microsoft Recommends Resource-Group-Level Assignments

Microsoft currently recommends assigning Sentinel-specific roles at the resource-group level in many Sentinel deployments.

The reason is that Sentinel commonly depends on several related resources, including:

Log Analytics workspace
Logic Apps
Playbooks
Workbooks
Other Sentinel-related resources

Putting those resources into a dedicated security resource group allows a role assignment to cover the relevant Sentinel environment more consistently.

Example

			
Security Resource Group
       |
       +-- Log Analytics Workspace
       |
       +-- Microsoft Sentinel
       |
       +-- Workbooks
       |
       +-- Logic Apps
       |
       +-- Playbooks

		

Assigning a Sentinel role at this resource-group level can simplify administration.

14. Resource-Level Assignments

A role can also be assigned more narrowly at the resource level.

For example, an organization could assign a Sentinel Reader role directly to a particular workspace.

This provides more limited scope than assigning the role at the subscription level.

General principle

When designing RBAC:

Assign permissions at the lowest practical scope that satisfies the requirement.

This supports least privilege.

15. Subscription-Level Assignments

A role can also be assigned at the subscription level.

However, subscription-level assignments can provide access to a much broader set of resources.

For example:

			
Subscription
   |
   +-- Security RG
   +-- Application RG
   +-- Database RG
   +-- Networking RG

		

A role assignment at the subscription level may affect resources across all of these resource groups.

Therefore, if a user only needs access to Sentinel, assigning a broad subscription-level role may be excessive.

16. Management-Group-Level Assignments

The highest Azure RBAC scope is the management group.

Permissions assigned here can flow down to subscriptions and their resources.

Management-group-level RBAC can be useful in large enterprises, but it must be used carefully because the scope is extremely broad.

For SC-500, remember the hierarchy:

			
Management Group
        ↓
Subscription
        ↓
Resource Group
        ↓
Resource

		

17. Role Assignments Are Cumulative

This is an important exam concept.

Suppose a user receives:

Microsoft Sentinel Reader
Microsoft Sentinel Contributor

The user’s effective permissions are cumulative.

The Contributor assignment effectively provides broader permissions than Reader alone.

Microsoft explicitly warns that role assignments are cumulative and that assigning both Reader and Contributor can result in more permissions than intended.

Example

			
User
 |
 +-- Sentinel Reader
 |
 +-- Sentinel Contributor
          |
          v
   Effective permissions
   include Contributor

		

Therefore, don’t assume that assigning a lower-level role somehow removes permissions granted by a higher-level role.

18. Avoiding Excessive Permissions

Consider a security analyst who needs only to investigate and manage incidents.

Giving the analyst:

Microsoft Sentinel Contributor

would provide more capabilities than necessary.

A better choice would generally be:

Microsoft Sentinel Responder

because the analyst needs incident-management capabilities but does not necessarily need to create or modify Sentinel content.

Microsoft recommends using the fewest permissions necessary to perform the user’s job.

19. Recommended Roles for Common Users

Microsoft’s current guidance provides useful role patterns for common Sentinel users.

User	Typical role
Security analyst who only needs to view	Sentinel Reader
Security analyst who investigates/manages incidents	Sentinel Responder
Security engineer	Sentinel Contributor
User who needs to manually run playbooks	Sentinel Playbook Operator
Sentinel automation	Sentinel Automation Contributor
Logic App/playbook developer	Appropriate Logic Apps role

The exact permissions should always be determined by the tasks the user actually needs to perform.

20. Playbook Permissions Are More Complicated

Playbooks deserve special attention because they involve both Microsoft Sentinel and Azure Logic Apps.

A playbook is implemented using Logic Apps.

Therefore, permissions associated with Sentinel do not automatically grant every Logic Apps capability.

For example:

Sentinel Responder can access an incident and may initiate certain response actions.
Sentinel Playbook Operator can manually run a playbook.
Logic App Contributor provides permissions to edit/manage Logic Apps.
Owner may be required for certain permission-granting operations.
Sentinel Automation Contributor allows Sentinel automation to run applicable playbooks.

Microsoft’s current documentation explicitly distinguishes these permissions.

21. A Critical Playbook Exam Scenario

Suppose an analyst needs to manually execute an existing playbook.

The question asks:

Which Sentinel-specific role should be assigned?

The answer is:

Microsoft Sentinel Playbook Operator.

However, if the question asks:

Which role allows the user to edit the Logic App implementing the playbook?

The answer changes.

The user needs an appropriate Logic Apps role, such as Logic App Contributor for a Consumption Logic App, depending on the deployment model and required task.

Remember

Run a playbook ≠ Edit a playbook.

22. Automation Contributor and Playbooks

There is another subtle distinction.

Suppose Sentinel has an automation rule that needs to execute a playbook automatically.

The automation process needs the appropriate Sentinel automation permissions.

Microsoft provides the Microsoft Sentinel Automation Contributor role for this purpose. Microsoft states that this role allows automation rules to run playbooks and isn’t intended for other purposes.

Therefore:

Scenario	Role
Manually run existing playbook	Sentinel Playbook Operator
Attach playbook to an analytics/automation rule	Sentinel Contributor, where applicable
Allow Sentinel automation to run playbooks	Sentinel Automation Contributor
Modify Logic App	Appropriate Logic Apps role

23. Resource-Context RBAC

Sometimes a user doesn’t need access to the entire Sentinel workspace.

For example:

A Windows administrator should be able to view logs generated by the servers that the administrator manages, but should not have access to the entire security operations environment.

This is where resource-context RBAC can be useful.

Instead of granting the administrator access to the entire Sentinel workspace, access can be based on the resources that the user is authorized to manage.

Microsoft recommends resource-context RBAC when users need access only to specific data associated with resources rather than the entire Sentinel environment.

24. Example of Resource-Context RBAC

Consider:

			
Microsoft Sentinel Workspace
          |
     +----+----+
     |         |
     v         v
 Server A   Server B
     |         |
     v         v
 Windows    Windows
   Admin      Admin

		

The administrator responsible for Server A may need access to logs associated with Server A but should not automatically receive access to all Sentinel data.

Resource-context RBAC can help establish that more granular access model.

25. Table-Level RBAC

There are also scenarios where organizations need access to particular categories of data rather than entire resources.

For example:

A Windows administration team needs access to Windows Security events but should not have access to unrelated security tables.

Microsoft Sentinel supports more granular approaches such as table-level RBAC for certain scenarios.

This is another example of applying least privilege.

26. Sentinel Roles vs. Broad Azure Roles

Be careful when a question gives you several role choices.

Azure includes broad roles such as:

Owner
Contributor
Reader

These roles apply across Azure resources and are not specific to Microsoft Sentinel.

Microsoft Sentinel also provides specialized roles:

Sentinel Reader
Sentinel Responder
Sentinel Contributor
Sentinel Playbook Operator
Sentinel Automation Contributor

For Sentinel administration, the Sentinel-specific roles are generally preferable when they satisfy the requirement because they provide more targeted permissions.

Example

If the requirement is:

“Allow an analyst to manage Sentinel incidents but not modify Sentinel analytics rules.”

The best answer is not Azure Contributor.

It is:

Microsoft Sentinel Responder.

27. Microsoft Sentinel Reader vs. Azure Reader

These roles sound similar but are not identical.

Azure Reader

Provides read access across Azure resources within its assigned scope.

Microsoft Sentinel Reader

Provides Sentinel-specific read capabilities.

Therefore, if a question asks for the least-privileged role specifically for viewing Microsoft Sentinel, the Sentinel-specific Reader role is generally the stronger choice.

Microsoft’s current unified security operations guidance identifies Sentinel Reader as the minimum required Azure RBAC role for an analyst to view Microsoft Sentinel data.

28. Microsoft Sentinel Contributor vs. Azure Contributor

Similarly, these roles should not be treated as interchangeable.

Azure Contributor is a broad Azure resource-management role.

Microsoft Sentinel Contributor is focused on Sentinel capabilities.

For least privilege, a Sentinel administrator should generally receive the Sentinel-specific role if it provides the required functionality.

29. Connecting Sentinel to the Defender Portal

Current Microsoft Sentinel deployments increasingly use the Microsoft Defender portal as the unified security operations experience.

Permissions still matter when Sentinel is accessed through the Defender portal.

Microsoft’s current documentation specifies that viewing Microsoft Sentinel in the Defender portal requires appropriate Sentinel permissions, with Microsoft Sentinel Reader being sufficient for viewing Sentinel data.

This is important because simply giving someone access to the Microsoft Defender portal does not necessarily mean they automatically have the required Sentinel permissions.

30. Current Portal Transition

Microsoft is transitioning Microsoft Sentinel toward the Microsoft Defender portal.

Microsoft currently states that after March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in the Microsoft Defender portal.

This is useful current-state knowledge for SC-500 preparation.

However, the RBAC concepts remain fundamentally the same:

Access to Sentinel capabilities is controlled through appropriate roles and scopes.

31. Service Principals and Automation

Not all role assignments are for human users.

Automation and applications may use:

Service principals
Managed identities
Other workload identities

These identities may require Sentinel permissions to perform automated tasks.

For example, a service principal managing Sentinel content may require an appropriate Sentinel Contributor assignment.

The same principle applies:

Give the workload identity only the permissions it actually needs.

Do not automatically grant Owner.

32. Managed Identity and Playbooks

Playbooks can also use managed identities to authenticate when interacting with Microsoft Sentinel and other Azure services.

This can reduce reliance on stored credentials.

Microsoft’s current playbook guidance documents assigning Sentinel Reader or Responder permissions to a Logic App managed identity depending on what the playbook needs to do. For example, a playbook that only receives incidents can use Reader, while one that updates incidents requires Responder-level access.

This provides another practical application of least privilege.

33. A Practical Role-Assignment Process

A security administrator can use the following process when assigning Sentinel roles.

Step 1 — Identify the user’s job

Ask:

Is this user an auditor?
SOC analyst?
Incident responder?
Security engineer?
Automation account?
Playbook operator?

Step 2 — Identify required actions

Determine whether the user needs to:

View data
Manage incidents
Create analytics rules
Install solutions
Run playbooks
Edit playbooks
Configure automation

Step 3 — Select the narrowest appropriate role

For example:

			
View only
   ↓
Reader
Manage incidents
   ↓
Responder
Manage Sentinel content
   ↓
Contributor
Run existing playbooks
   ↓
Playbook Operator

		

Step 4 — Select the appropriate scope

Prefer the narrowest practical scope:

			
Resource
   ↑
Resource Group
   ↑
Subscription
   ↑
Management Group

		

Step 5 — Review inherited permissions

Determine whether the user already has another role that provides broader permissions.

Remember that role assignments are cumulative.

Step 6 — Test the access

Confirm that the user can perform the required task without receiving unnecessary permissions.

34. Example: Building a SOC Role Model

Suppose an organization has the following personnel:

Tier 1 analysts

Responsibilities:

Monitor incidents
View security data
Perform initial investigation

Potential role:

Microsoft Sentinel Responder

Security engineers

Responsibilities:

Create analytics rules
Maintain Sentinel content
Configure solutions

Potential role:

Microsoft Sentinel Contributor

Auditors

Responsibilities:

Review security information
Validate compliance

Potential role:

Microsoft Sentinel Reader

Automation operator

Responsibilities:

Manually execute approved playbooks

Potential role:

Microsoft Sentinel Playbook Operator

This creates a much more defensible security model than assigning everyone Contributor.

35. Common Mistakes

Mistake 1: Giving every analyst Contributor

Most analysts do not need to modify Sentinel configuration.

Use Responder when incident management is sufficient.

Mistake 2: Assuming Reader can manage incidents

Reader provides visibility but not the incident-management permissions provided by Responder.

Mistake 3: Assuming Responder can edit Sentinel content

Responder is primarily an incident-response role.

Contributor provides broader content and resource-management capabilities.

Mistake 4: Assuming Playbook Operator can edit playbooks

Playbook Operator allows playbooks to be viewed and manually run.

Editing the underlying Logic App requires appropriate Logic Apps permissions.

Mistake 5: Giving Owner because it is easier

Owner is a broad Azure role and allows access management.

It is usually excessive for a Sentinel analyst.

Mistake 6: Forgetting that permissions are cumulative

A user assigned Reader and Contributor does not become “Reader only.”

The broader Contributor permissions still apply.

Mistake 7: Ignoring scope

A role assigned at subscription level can affect substantially more resources than the same role assigned at resource-group level.

Mistake 8: Assuming Defender portal access automatically grants Sentinel access

Users still require appropriate Sentinel permissions to view and use Sentinel capabilities in the Defender portal.

36. Exam-Focused Role Selection Matrix

Requirement	Best-fit role
View Sentinel data	Microsoft Sentinel Reader
View and manage incidents	Microsoft Sentinel Responder
Manage Sentinel resources/content	Microsoft Sentinel Contributor
Manually run an existing playbook	Microsoft Sentinel Playbook Operator
Allow Sentinel automation to run playbooks	Microsoft Sentinel Automation Contributor
Edit Logic Apps used as playbooks	Appropriate Logic Apps role
Broad Azure resource administration	Azure Contributor/Owner, only when actually required
Access only logs associated with particular resources	Resource-context RBAC

37. Quick Memory Model

For exam preparation, memorize this progression:

                    MICROSOFT SENTINEL ROLES

                          CONTRIBUTOR
                              |
                    Manage Sentinel
                    content/resources
                              |
                          RESPONDER
                              |
                       Manage incidents
                              |
                            READER
                              |
                          View data

Then remember the specialized roles:

			
PLAYBOOK OPERATOR
       |
       +--> Manually run playbooks
AUTOMATION CONTRIBUTOR
       |
       +--> Sentinel automation / playbook execution

		

And finally:

			
LOGIC APPS ROLES
       |
       +--> Create/edit/manage the underlying playbooks

This mental model is useful when working through scenario-based SC-500 questions.

38. Key Takeaways

The most important concepts for Assign roles in Microsoft Sentinel are:

Microsoft Sentinel uses Azure RBAC for its SIEM capabilities.
Microsoft Sentinel Reader provides read access.
Microsoft Sentinel Responder adds incident-management capabilities.
Microsoft Sentinel Contributor adds broader Sentinel content and resource-management capabilities.
Microsoft Sentinel Playbook Operator allows users to view and manually run playbooks.
Microsoft Sentinel Automation Contributor is intended for Sentinel automation involving playbooks.
Editing the underlying Logic App requires appropriate Logic Apps permissions.
Use the least-privileged role that satisfies the user’s responsibilities.
Sentinel-specific roles are generally preferable to broad Azure roles when they provide the required permissions.
Azure RBAC assignments can be made at management-group, subscription, resource-group, or resource scope.
Assigning roles at the resource-group level is often a useful approach for Sentinel environments because related Sentinel resources can be grouped together.
RBAC permissions are cumulative.
Resource-context RBAC can provide more granular access to data associated with specific resources.
Table-level RBAC can be used for certain scenarios requiring access to specific categories of data.
Access to the Microsoft Defender portal does not by itself mean that a user has all the permissions required to use Microsoft Sentinel.
The principle of least privilege should apply to both human users and automation identities.

Practice Exam Questions

Question 1

A SOC analyst needs to view Microsoft Sentinel data and investigate security information. The analyst must also be able to update and manage incidents but does not need to create analytics rules or modify Sentinel solutions.

Which role should you assign?

A. Microsoft Sentinel Reader

B. Microsoft Sentinel Responder

C. Microsoft Sentinel Contributor

D. Azure Owner

Answer: B

Explanation

Microsoft Sentinel Responder includes the Reader capabilities and adds the ability to manage incidents.

Contributor would provide broader Sentinel administration capabilities than the analyst requires, while Reader would not provide sufficient incident-management permissions. Azure Owner would be substantially more privileged than necessary.

Question 2

A security auditor needs to view Microsoft Sentinel incidents, workbooks, and security data. The auditor must not be able to modify incidents or Sentinel configuration.

Which role provides the most appropriate least-privilege access?

A. Microsoft Sentinel Contributor

B. Microsoft Sentinel Responder

C. Microsoft Sentinel Reader

D. Microsoft Sentinel Playbook Operator

Answer: C

Explanation

Microsoft Sentinel Reader is designed for read-only access to Sentinel information, including data and incidents.

Responder would provide incident-management capabilities that the auditor does not require. Contributor provides even broader administrative capabilities. Playbook Operator is specifically related to playbook access and execution.

Question 3

A security engineer is responsible for creating and editing Microsoft Sentinel analytics rules, managing Sentinel resources, and installing Sentinel solutions.

Which role is most appropriate?

A. Microsoft Sentinel Contributor

B. Microsoft Sentinel Reader

C. Microsoft Sentinel Playbook Operator

D. Microsoft Sentinel Responder

Answer: A

Explanation

Microsoft Sentinel Contributor provides broader management capabilities, including creating and editing Sentinel resources and managing Sentinel content. It includes the capabilities provided by Responder and adds administrative functionality.

Question 4

A SOC analyst needs to manually run an existing Microsoft Sentinel playbook. The analyst does not need to edit the underlying Logic App.

Which role is most appropriate?

A. Microsoft Sentinel Contributor

B. Microsoft Sentinel Automation Contributor

C. Microsoft Sentinel Responder

D. Microsoft Sentinel Playbook Operator

Answer: D

Explanation

Microsoft Sentinel Playbook Operator is specifically designed to allow users to list, view, and manually run playbooks.

Editing the Logic App behind a playbook requires appropriate Logic Apps permissions and is a separate requirement.

Question 5

A company wants to assign Sentinel permissions to its security team. The team needs access to the Sentinel workspace, workbooks, playbooks, and other Sentinel-related resources located in a dedicated security resource group.

Where should the organization generally consider assigning the Sentinel-specific role?

A. At the resource-group level

B. At the management-group level

C. At the tenant level

D. At the Microsoft Entra application level

Answer: A

Explanation

Microsoft recommends assigning Sentinel roles at the resource-group level in appropriate deployments. This can allow the role assignment to cover the Sentinel workspace and related resources contained in the security resource group.

This also avoids unnecessarily broad permissions at the subscription or management-group level.

Question 6

A user has both the Microsoft Sentinel Reader role and the Microsoft Sentinel Contributor role assigned at overlapping scopes.

What happens to the user’s effective permissions?

A. The Reader role overrides Contributor

B. The Contributor role is ignored because Reader was assigned first

C. The user receives the cumulative permissions of the assignments

D. The user loses access until one role is removed

Answer: C

Explanation

Azure RBAC role assignments are cumulative. A user with both Reader and Contributor permissions receives the broader effective permissions granted by the assignments.

Microsoft specifically warns that assigning multiple roles can result in more permissions than intended.

Question 7

A company has a Windows administration team that needs to view logs generated by the Windows servers it manages. The administrators should not receive access to the entire Microsoft Sentinel workspace or all security data.

Which approach should the security architect consider?

A. Assign Azure Owner at the subscription level

B. Assign Microsoft Sentinel Contributor at the workspace level

C. Give the administrators Microsoft Sentinel Responder at the management-group level

D. Use resource-context RBAC to provide access based on the resources they manage

Answer: D

Explanation

Resource-context RBAC is designed for scenarios where users need access to data associated with specific resources rather than the entire Sentinel environment.

This allows organizations to provide more granular access while maintaining least privilege.

Question 8

A Microsoft Sentinel automation rule needs to execute a playbook automatically when an incident is created.

Which Sentinel-specific role is associated with allowing Sentinel automation to run playbooks?

A. Microsoft Sentinel Reader

B. Microsoft Sentinel Automation Contributor

C. Microsoft Sentinel Playbook Operator

D. Microsoft Sentinel Responder

Answer: B

Explanation

Microsoft Sentinel Automation Contributor allows Microsoft Sentinel automation to run applicable playbooks.

Do not confuse this role with Playbook Operator, which is intended for a user who needs to manually run an existing playbook. Microsoft identifies Automation Contributor as a role for Sentinel automation rather than a general-purpose user role.

Question 9

A security engineer needs to modify the Logic App that implements a Microsoft Sentinel playbook.

Which statement is most accurate?

A. Microsoft Sentinel Reader automatically provides Logic App editing permissions

B. Microsoft Sentinel Responder automatically provides Logic App editing permissions

C. Microsoft Sentinel Playbook Operator automatically provides Logic App editing permissions

D. An appropriate Azure Logic Apps role is required to edit the underlying Logic App

Answer: D

Explanation

A Sentinel role and an Azure Logic Apps role serve different purposes.

Playbook Operator allows a user to manually run playbooks, but editing the underlying Logic App requires an appropriate Logic Apps role. For example, Microsoft documents Logic App Contributor for editing and managing Consumption Logic Apps.

Question 10

An organization wants to follow least-privilege principles for a Sentinel environment. A user only needs to view Microsoft Sentinel data and incidents and does not need to modify them.

Which assignment is most appropriate?

A. Microsoft Sentinel Reader

B. Microsoft Sentinel Responder

C. Microsoft Sentinel Contributor

D. Azure Owner

Answer: A

Explanation

Microsoft Sentinel Reader is the appropriate Sentinel-specific role when the user only needs read access.

Responder adds incident-management capabilities, Contributor provides broader administration, and Azure Owner provides extremely broad Azure permissions. Microsoft identifies Sentinel Reader as the minimum Sentinel-specific Azure RBAC role for an analyst who only needs to view Sentinel data.

Go to the SC-500 Exam Prep Hub main page

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

Create custom log tables in the workspace to store ingested data (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:
Manage and monitor security posture (20–25%)
   --> Implement activity and event collection in Microsoft Sentinel
      --> Create custom log tables in the workspace to store ingested data

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 Sentinel is built on Azure Monitor Logs, with a Log Analytics workspace serving as the underlying data store. While Microsoft Sentinel provides many predefined tables for common security data sources, organizations frequently need to ingest data that doesn’t fit an existing schema.

For these situations, you can create custom log tables in the Log Analytics workspace and use Data Collection Rules (DCRs) to control how the incoming data is collected, transformed, and routed into those tables.

This topic is part of the Manage and monitor security posture (20–25%) skill area of the SC-500 exam, specifically the Implement activity and event collection in Microsoft Sentinel area.

The key concepts to understand are:

Custom Log Analytics tables
The _CL naming convention
Table schemas and column data types
TimeGenerated
Data Collection Rules (DCRs)
Data Collection Endpoints (DCEs)
Logs Ingestion API
Ingestion-time transformations
Table plans
Analytics, Basic, and Auxiliary/Lake tables
Custom columns
Schema changes
KQL querying of custom tables
Cost and performance considerations

1. Why Create Custom Log Tables?

Microsoft Sentinel can ingest data from many Microsoft and third-party sources. Standard connectors typically send information into predefined tables such as:

SecurityEvent
CommonSecurityLog
Syslog
SigninLogs
AzureActivity

However, an organization may have a proprietary application, security product, network device, or custom process that produces information in a format that doesn’t correspond to an existing table.

For example, a company might have an internally developed security application that produces records like:

			
Timestamp
ApplicationName
UserName
RiskScore
SourceIP
Action
ThreatCategory

		

Rather than attempting to force this information into an unrelated standard table, the organization can create a custom table such as:

ContosoSecurityEvents_CL

The custom table defines the schema needed to store the incoming data.

Custom tables are particularly useful for:

Custom applications
Proprietary security solutions
Third-party security products
Custom scripts
Application telemetry
Specialized audit data
Logs received through the Logs Ingestion API
Data that requires a specialized schema

Azure Monitor provides custom tables specifically for situations where the predefined Azure table schemas don’t meet the requirements of the incoming data.

2. Microsoft Sentinel and the Log Analytics Workspace

One of the most important SC-500 concepts is understanding the relationship between Microsoft Sentinel and Azure Monitor Logs.

Conceptually:

                Data Sources
                     |
                     v
          Data Collection / Ingestion
                     |
                     v
          Data Collection Rules
              (DCRs)
                     |
                     v
          Azure Monitor Logs
                     |
                     v
           Log Analytics Workspace
                     |
          +----------+----------+
          |                     |
    Standard Tables       Custom Tables
          |                     |
          +----------+----------+
                     |
                     v
             Microsoft Sentinel
                     |
          +----------+----------+
          |          |          |
       Queries    Analytics   Incidents

Microsoft Sentinel does not maintain a completely separate log database. Sentinel uses Azure Monitor Logs, and the logs are stored in the associated Log Analytics workspace.

Therefore, when an SC-500 question asks you to create a custom table “in the workspace,” think:

Log Analytics workspace → custom table → DCR/ingestion → Microsoft Sentinel queries and analytics

3. What Is a Custom Log Table?

A custom table is a Log Analytics table whose schema is defined by the organization rather than being a predefined Azure service schema.

A typical custom table might be:

ContosoSecurityEvents_CL

The _CL suffix identifies a custom log table.

For example:

			
Table: ContosoSecurityEvents_CL
Columns:
    TimeGenerated       datetime
    ApplicationName     string
    UserName            string
    SourceIP            string
    RiskScore            int
    Action              string
    ThreatCategory      string

		

The table schema determines the structure of the data that can be stored and queried.

The Azure portal automatically adds _CL when you create a custom table through the portal. When creating a custom table through other methods, such as APIs or CLI, the _CL suffix needs to be specified.

SC-500 Exam Tip

If a question asks:

“Which table naming convention should be used for a custom Log Analytics table?”

The expected answer is generally:

_CL

For example:

			
NetworkThreats_CL
ApplicationAudit_CL
CustomSecurityEvents_CL

4. Custom Table Schema

The schema defines the columns and data types available in the table.

Common data types include:

Data Type	Typical Use
`string`	Usernames, IP addresses, application names
`int`	Integer values
`long`	Large integer values
`real`	Decimal/numeric values
`boolean`	True/false values
`datetime`	Timestamps
`dynamic`	JSON or complex structured data

For example:

			
ContosoSecurityEvents_CL
TimeGenerated       datetime
ApplicationName     string
UserName            string
SourceIP            string
RiskScore            int
IsMalicious         boolean
EventData            dynamic

		

The choice of data type matters because it affects how the information can be queried and analyzed.

For example, if RiskScore is stored as an integer, queries can perform numerical comparisons:

			
ContosoSecurityEvents_CL
| where RiskScore >= 80
| order by RiskScore desc

If the same value were stored as a string, numerical analysis would be more cumbersome.

5. The Importance of TimeGenerated

A particularly important requirement is the TimeGenerated column.

Log Analytics tables use TimeGenerated to represent the time associated with the log record. Custom tables must have a TimeGenerated column.

If the incoming sample data doesn’t contain an appropriate TimeGenerated value when creating a custom table, Azure Monitor can create a transformation to add one.

For example:

			
TimeGenerated       datetime
EventType           string
SourceIP            string
UserName            string
Action              string

		

This allows queries such as:

			
ContosoSecurityEvents_CL
| where TimeGenerated > ago(24h)
| summarize Count=count() by Action

Exam Tip

Remember:

Every Log Analytics table needs TimeGenerated.

It is one of the easiest details for an SC-500 question to test.

6. Data Collection Rules (DCRs)

Creating the table is only part of the process.

You also need a mechanism to control how the incoming data reaches the table.

That is where Data Collection Rules (DCRs) come into play.

A DCR defines how data is:

Collected
Filtered
Transformed
Routed
Sent to a destination

Conceptually:

			
Source Data
    |
    v
+----------------------+
| Data Collection Rule |
|                      |
| Collect              |
| Filter               |
| Transform            |
| Route                |
+----------------------+
    |
    v
Custom Table
    |
    v
Log Analytics Workspace

		

DCRs can therefore provide an ingestion-time processing layer between the source and the destination table.

7. DCR Data Flows

A DCR can define the relationship between an incoming data stream and the destination table.

For example:

			
CustomSecurityStream
        |
        v
       DCR
        |
        +---- Transformation
        |
        v
ContosoSecurityEvents_CL

		

The destination table name in the DCR must correspond to the custom table.

For example:

ContosoSecurityEvents_CL

The DCR data flow must target:

ContosoSecurityEvents_CL

A mismatch between the table definition and the DCR is a common configuration problem.

8. Ingestion-Time Transformations

One of the most powerful capabilities associated with custom ingestion is ingestion-time transformation.

A DCR can use a KQL transformation to manipulate incoming records before they are stored.

For example, suppose incoming records contain:

			
UserName
SourceIP
RiskScore
Action

A transformation could:

Remove unwanted records
Rename or derive values
Normalize information
Add calculated information
Mask sensitive information
Convert values
Enrich records
Reduce unnecessary data

Conceptually:

			
Raw Data
   |
   v
DCR
   |
   v
KQL Transformation
   |
   +---- Filter unwanted records
   |
   +---- Transform fields
   |
   +---- Enrich/normalize data
   |
   v
Custom Table

		

Microsoft Sentinel supports DCR-based transformations for custom data ingestion, and transformations can filter, enrich, or mask incoming data before it is stored.

9. Example Transformation

Suppose incoming data contains a numeric risk score:

RiskScore

You might want to classify the event during ingestion.

Conceptually, a transformation could produce:

RiskLevel

based on the score.

For example:

			
source
| extend RiskLevel =
    case(
        RiskScore >= 90, "Critical",
        RiskScore >= 70, "High",
        RiskScore >= 40, "Medium",
        "Low"
    )

		

The resulting record can then be stored in the destination custom table.

This approach is useful because the data is normalized before analysts and Sentinel analytics rules consume it.

10. Logs Ingestion API

The Logs Ingestion API provides another important method for sending custom-format data into Azure Monitor Logs.

It is particularly useful when an application or external system needs to send data programmatically.

Conceptually:

			
Custom Application
       |
       | HTTPS
       v
Logs Ingestion API
       |
       v
DCR
       |
       v
Transformation
       |
       v
Custom Table

		

The Logs Ingestion API can send custom-format logs into Log Analytics tables, including custom tables, while DCRs define the data flow and transformations.

Example Scenario

A company has an internally developed fraud-detection application.

The application generates:

			
{
    "user": "jsmith",
    "sourceIP": "10.10.20.15",
    "riskScore": 94,
    "action": "Blocked"
}

		

The application could send these records through the Logs Ingestion API.

The DCR could transform the data and route it to:

FraudDetection_CL

Microsoft Sentinel could then query that table for detections.

11. Data Collection Endpoints (DCEs)

A Data Collection Endpoint (DCE) can provide an ingestion endpoint for Azure Monitor data collection scenarios.

A common architecture is:

			
Application
     |
     v
Data Collection Endpoint
     |
     v
Data Collection Rule
     |
     v
Log Analytics Workspace
     |
     v
Custom Table

		

Not every DCR scenario requires a separately created DCE. For example, current Azure Monitor documentation describes a DCR with kind set to Direct that can create its own Logs Ingestion endpoint.

Exam Tip

Do not automatically assume:

“Every custom table requires a DCE.”

Instead, determine what ingestion mechanism the scenario specifies.

12. Creating a Custom Table in the Azure Portal

A typical portal workflow is:

Step 1 — Open the Log Analytics workspace

Navigate to the appropriate:

Log Analytics workspace

Step 2 — Open Tables

Select:

Tables

Step 3 — Create a table

Select:

Create

Step 4 — Specify the table name

For example:

ContosoSecurityEvents

The portal creates the custom table as:

ContosoSecurityEvents_CL

Step 5 — Select the table plan

Choose the appropriate table plan.

Step 6 — Associate a DCR

Select an existing DCR or create a new one.

Step 7 — Select the DCE if required

Depending on the ingestion scenario, select an appropriate Data Collection Endpoint.

Step 8 — Provide sample data

A JSON sample can be used to help define the schema.

For example:

			
{
    "TimeGenerated": "2026-09-13T14:30:00Z",
    "ApplicationName": "FraudDetection",
    "UserName": "jsmith",
    "SourceIP": "10.10.20.15",
    "RiskScore": 94,
    "Action": "Blocked"
}

		

Step 9 — Configure transformations

If required, use the transformation editor.

Step 10 — Review the schema

Verify:

Column names
Data types
TimeGenerated
Destination table
Transformation
Table plan

Step 11 — Create the table

After validation, create the custom table.

This workflow is supported directly through the Log Analytics workspace Tables experience.

13. Custom Table Naming Rules

There are several schema rules worth remembering.

A custom table uses:

<TableName>_CL

For example:

FirewallEvents_CL

Custom column names have their own restrictions. They must:

Start with a letter
Use letters, digits, and underscores
Avoid spaces
Avoid dots
Avoid dashes
Avoid other punctuation
Follow the applicable length restrictions

Custom column names added to Azure tables use the _CF suffix.

Good examples

			
SourceIP
UserName
RiskScore
ThreatCategory
DeviceName

		

Poor examples

			
Source-IP
Source IP
Source.IP
123SourceIP

14. Updating a Custom Table Schema

Custom tables aren’t necessarily static.

For example, you might initially have:

			
TimeGenerated
UserName
SourceIP
Action

Later, the application begins producing:

ThreatCategory

You may add a custom column to accommodate the new information.

However, there is an important consideration:

When the table schema changes, the DCR that sends data to the table must also be updated as appropriate.

Azure Monitor does not automatically update your DCR simply because you modified the destination table schema.

This is a very useful SC-500 exam distinction.

Think of it this way:

			
Table Schema
     ^
     |
Must remain compatible with
     |
     v
DCR Schema / Data Flow
     ^
     |
Incoming Data

		

If these components don’t agree, ingestion can fail or produce unexpected results.

15. Table Plans

A custom table can use different table plans depending on the organization’s requirements.

Current Azure Monitor Logs supports:

Table Plan	Typical Purpose
Analytics	Frequent querying, monitoring, detections, and complex analysis
Basic	Cost-effective storage for data that is queried less frequently
Auxiliary / Lake	High-volume or verbose data where inexpensive long-term storage is important

Analytics is the default plan when creating a custom table through the standard workflow. DCR-based custom tables support the available table plans, subject to the capabilities and limitations of each plan.

Choosing a plan

Consider:

How frequently the data will be queried
Whether the data supports active security detections
Query capabilities required
Data volume
Retention requirements
Cost

For example:

High-value security events

			
Authentication failures
Critical threat alerts
Security detections

These are likely candidates for an Analytics plan when frequent investigation and detection are required.

Large-volume historical data

			
Verbose application telemetry
Long-term diagnostic information
High-volume historical records

A lower-cost storage-oriented plan may be more appropriate, depending on the required capabilities.

16. Custom Tables Versus Standard Tables

Understanding the difference is important for the SC-500 exam.

Characteristic	Standard Table	Custom Table
Schema	Predefined	Organization-defined
Naming	Microsoft-defined	`_CL` suffix
Typical source	Microsoft service/connector	Custom or specialized source
Schema flexibility	More constrained	More flexible
DCR support	Depends on connector	Commonly used
Transformation	Depends on ingestion method	Strongly supported through DCR
Example	`SecurityEvent`	`SecurityAlerts_CL`

The general principle is:

Use a standard table when the data naturally belongs to an existing Microsoft schema; use a custom table when the data requires its own schema.

17. Querying a Custom Table with KQL

Once data is successfully ingested, it can be queried using Kusto Query Language (KQL).

Suppose the table is:

ContosoSecurityEvents_CL

A simple query is:

			
ContosoSecurityEvents_CL
| take 100

To retrieve recent events:

			
ContosoSecurityEvents_CL
| where TimeGenerated > ago(24h)
| order by TimeGenerated desc

To identify high-risk events:

			
ContosoSecurityEvents_CL
| where RiskScore >= 80
| project TimeGenerated, UserName, SourceIP, RiskScore, Action
| order by RiskScore desc

To summarize events by action:

			
ContosoSecurityEvents_CL
| summarize EventCount=count() by Action
| order by EventCount desc

18. Custom Tables and Microsoft Sentinel Analytics Rules

Once data exists in a custom table, Microsoft Sentinel can use that data for security monitoring.

For example:

			
Custom Application
       |
       v
SecurityEvents_CL
       |
       v
Microsoft Sentinel
       |
       +---- Analytics Rule
       |
       +---- Hunting Query
       |
       +---- Workbook
       |
       +---- Investigation
       |
       +---- Automation

		

Suppose an organization wants to detect:

A user generating three or more high-risk fraud events within 10 minutes.

A Sentinel analytics rule could query:

			
FraudDetection_CL
| where TimeGenerated > ago(10m)
| where RiskScore >= 90
| summarize EventCount=count() by UserName
| where EventCount >= 3

		

This illustrates an important concept:

Creating the custom table does not itself create a security detection.

The table stores the data. Sentinel analytics rules, hunting queries, workbooks, and other capabilities consume the data.

19. Permissions

Managing tables requires appropriate permissions on the Log Analytics workspace.

For example, permissions such as:

Microsoft.OperationalInsights/workspaces/*

at the appropriate workspace scope can allow table management. The Log Analytics Contributor role is an example of a built-in role that can provide the necessary permissions.

This should not be confused with permission to simply query the data.

There is an important distinction between:

Managing the table

and:

Reading/querying the data

An SC-500 scenario may therefore provide a user who can query logs but cannot create or modify a table.

20. Security and Privacy Considerations

Custom tables can contain sensitive information.

Avoid placing sensitive information in:

Table names
Column names unnecessarily
Diagnostic metadata
Uncontrolled raw log fields

For example, don’t name a table:

CustomerSocialSecurityNumbers_CL

even if the table happens to contain that information.

Instead, use a neutral operational name such as:

CustomerSecurityEvents_CL

Azure documentation specifically cautions against including sensitive information in custom table names because table names are used for billing.

DCR transformations can also be used to reduce unnecessary data, mask information, or remove irrelevant records before they are stored.

21. Controlling Ingestion Volume

One of the biggest operational concerns with custom logging is simply collecting too much data.

Suppose an application produces:

10 million events/day

but only:

100,000 events/day

are relevant to security monitoring.

Sending everything to Sentinel may increase:

Ingestion costs
Storage requirements
Query time
Noise
Investigation complexity

A DCR transformation can help filter irrelevant information before storage.

Conceptually:

			
10,000,000 Events
        |
        v
       DCR
        |
   Filter/Transform
        |
        v
  100,000 Useful Events
        |
        v
   Custom Table

		

This is one of the strongest reasons to understand DCRs rather than thinking of them simply as “connectors.”

22. Example: Custom Security Application

Consider an organization with an internal security application called ThreatWatch.

ThreatWatch produces:

			
Timestamp
DeviceName
UserName
SourceIP
ThreatType
Severity
Action

		

The security team wants the data available in Microsoft Sentinel.

Step 1 — Create the table

ThreatWatchEvents_CL

Step 2 — Define the schema

			
TimeGenerated       datetime
DeviceName          string
UserName            string
SourceIP            string
ThreatType          string
Severity            int
Action              string

		

Step 3 — Configure ingestion

The application sends records through an appropriate Azure Monitor ingestion mechanism.

Step 4 — Configure the DCR

The DCR:

Defines the incoming stream
Maps the fields
Applies transformations
Routes the records to ThreatWatchEvents_CL

Step 5 — Validate ingestion

Run:

			
ThreatWatchEvents_CL
| take 20

Step 6 — Create detections

For example:

			
ThreatWatchEvents_CL
| where Severity >= 8
| summarize HighSeverityEvents=count() by DeviceName
| where HighSeverityEvents >= 5

The resulting data can then participate in Sentinel investigations and detections.

23. Troubleshooting Custom Table Ingestion

When data isn’t appearing in a custom table, troubleshoot from the source toward the destination.

Step 1 — Verify the source

Is the application actually generating the expected data?

Step 2 — Verify the ingestion mechanism

Is the application correctly sending records?

Step 3 — Verify the DCE, if applicable

Is the ingestion endpoint correctly configured and reachable?

Step 4 — Verify the DCR

Check:

Data source
Stream
Transformation
Destination
Table name
Schema

Step 5 — Verify the table

Confirm:

TableName_CL

exists in the intended workspace.

Step 6 — Verify the schema

Make sure the incoming data matches the expected column types.

Step 7 — Query the table

For example:

			
ThreatWatchEvents_CL
| take 10

Step 8 — Check the time range

Don’t forget that the portal’s default query time range may exclude newly arriving data.

24. Common SC-500 Exam Traps

Trap 1: Confusing a custom table with a DCR

A DCR controls data collection and processing.

A custom table stores the resulting data.

They are related but are not the same thing.

Trap 2: Forgetting `_CL`

Custom tables use the _CL suffix.

MySecurityData_CL

Trap 3: Forgetting `TimeGenerated`

Custom Log Analytics tables require a TimeGenerated column.

Trap 4: Assuming the table automatically changes the DCR

It doesn’t.

If the table schema changes, review and update the DCR as necessary.

Trap 5: Assuming all data belongs in standard tables

If a data source has a unique schema that doesn’t fit an existing table, a custom table may be appropriate.

Trap 6: Confusing ingestion with detection

A custom table stores data.

A Sentinel analytics rule detects conditions in that data.

Creating the table doesn’t automatically create an incident.

Trap 7: Assuming all custom data must use the same table plan

Table-plan selection should be based on how the data will be used, queried, and retained.

Trap 8: Assuming a DCE is mandatory in every scenario

The required ingestion architecture depends on the ingestion mechanism and DCR configuration.

25. Best Practices

1. Design the schema before collecting data

Determine:

What fields are actually required
Appropriate data types
Which fields analysts will query
Which fields support detections

2. Use meaningful table names

For example:

			
FirewallThreats_CL
IdentityRiskEvents_CL
ApplicationSecurity_CL

3. Keep schemas consistent

Avoid frequently changing schemas unless there is a genuine requirement.

4. Use appropriate data types

Don’t store numeric values as strings unless there is a reason to do so.

5. Use DCR transformations

Filter unnecessary records and normalize data before ingestion when appropriate.

6. Minimize sensitive information

Don’t collect or retain sensitive information unnecessarily.

7. Select the table plan based on actual usage

Consider query frequency, detection requirements, retention, and cost.

8. Validate ingestion before creating detections

First confirm:

			
Data source
   ↓
DCR
   ↓
Custom table
   ↓
KQL query

		

Then build analytics rules.

9. Monitor ingestion volume

Unexpected increases in custom log volume can have both financial and operational consequences.

10. Treat the DCR and table schema as a coordinated design

A healthy ingestion architecture requires the source, DCR, transformation, and destination schema to agree.

26. SC-500 Exam-Focused Summary

For this topic, remember the following relationships:

Concept	What You Should Remember
Log Analytics workspace	Stores the logs used by Microsoft Sentinel
Custom table	Stores data using an organization-defined schema
`_CL`	Custom log table naming suffix
`TimeGenerated`	Required time column for Log Analytics tables
DCR	Controls collection, transformation, and routing
DCE	Provides an ingestion endpoint for applicable ingestion scenarios
Logs Ingestion API	Programmatic ingestion of custom-format data
Transformation	Processes incoming data before storage
Analytics plan	Best suited to active querying/analytics
Basic plan	Cost-oriented storage for less-frequent access
Auxiliary/Lake	High-volume/inexpensive storage scenarios
KQL	Used to query the resulting table
Sentinel analytics rule	Uses the data to identify security conditions

The most important architectural model is:

                DATA SOURCE
                     |
                     v
          +---------------------+
          | Ingestion Mechanism |
          +---------------------+
                     |
                     v
          +---------------------+
          |        DCR          |
          |                     |
          | Collect             |
          | Transform           |
          | Filter              |
          | Route               |
          +---------------------+
                     |
                     v
          +---------------------+
          | Custom Log Table    |
          |     *_CL            |
          +---------------------+
                     |
                     v
          Log Analytics Workspace
                     |
                     v
            Microsoft Sentinel
                     |
          +----------+----------+
          |          |          |
       Hunting   Analytics   Workbooks
                     |
                     v
                Incidents

27. Key Takeaways

Before taking the SC-500 exam, make sure you can explain:

Why an organization would create a custom Log Analytics table.
How a custom table differs from a standard Azure Monitor table.
Why custom tables use the _CL suffix.
Why TimeGenerated is important.
How a DCR controls data collection and routing.
How ingestion-time transformations work.
When the Logs Ingestion API can be used.
The purpose of a DCE in applicable ingestion architectures.
How table schemas and DCR schemas must remain consistent.
How to choose between Analytics, Basic, and Auxiliary/Lake table plans.
How to query a custom table using KQL.
Why controlling ingestion volume is important for both cost and security operations.
The difference between storing security data and creating a Sentinel detection.
How to troubleshoot a custom ingestion pipeline from source to destination.

Practice Exam Questions

Question 1

A security team has developed an internal application that generates security events in a proprietary JSON format. No existing Microsoft Sentinel table has an appropriate schema for the data.

The team wants to store the events in the Log Analytics workspace.

What should you create?

A. A Microsoft Sentinel workbook
B. A custom Log Analytics table
C. An automation rule
D. A resource lock

Answer: B

Explanation

A custom Log Analytics table is appropriate when incoming data has a schema that doesn’t fit an existing standard table. The table allows the organization to define the columns and data types required for the proprietary data.

A workbook visualizes data, an automation rule responds to conditions, and a resource lock protects Azure resources; none provides the required storage schema.

Question 2

A security engineer creates a custom Log Analytics table named:

NetworkThreats

The table is created through an Azure management interface that requires the complete table name.

Which name should be used?

A. NetworkThreats_LOG
B. NetworkThreats_CUSTOM
C. NetworkThreats_SENTINEL
D. NetworkThreats_CL

Answer: D

Explanation

Custom Log Analytics tables use the _CL suffix.

Therefore, the table should be:

NetworkThreats_CL

The Azure portal can add the suffix automatically when creating the table through the portal, but when using other creation mechanisms, the _CL suffix must be specified as required.

Question 3

A company creates a custom table for application security events. The application sends records containing:

			
UserName
SourceIP
RiskScore
Action

The records don’t contain a timestamp.

Which column must be available in the custom table to satisfy the Log Analytics table requirement?

A. TimeGenerated
B. EventID
C. SourceComputer
D. Severity

Answer: A

Explanation

Log Analytics tables require a TimeGenerated column. If the incoming sample does not provide an appropriate TimeGenerated value, Azure Monitor can create a transformation to add one during the custom-table creation process.

The other columns aren’t universally required for custom tables.

Question 4

A company sends custom application logs to Microsoft Sentinel. Before the logs are stored, the security team wants to remove irrelevant records and calculate a new field called RiskLevel.

Which capability is most appropriate?

A. Microsoft Sentinel workbook
B. Azure resource lock
C. DCR-based ingestion-time transformation
D. Microsoft Entra Conditional Access

Answer: C

Explanation

A DCR-based ingestion-time transformation can process incoming records before they are stored. KQL can be used to filter records, calculate values, normalize data, enrich records, or mask information.

A workbook operates on data after ingestion, a resource lock protects Azure resources, and Conditional Access controls identity access.

Question 5

A developer needs to send proprietary application logs programmatically to a custom table in a Log Analytics workspace.

Which Azure capability is specifically designed for programmatic ingestion of custom-format logs?

A. Logs Ingestion API
B. Azure Resource Graph
C. Microsoft Sentinel workbook API
D. Azure Policy

Answer: A

Explanation

The Logs Ingestion API allows applications and other data sources to send custom-format log data into Azure Monitor Logs. DCRs can define the data flow and transformations, and the data can be stored in a custom table.

Azure Resource Graph is primarily used to query Azure resource metadata, while Azure Policy governs resource configuration.

Question 6

An administrator adds a new column to an existing custom table. The DCR that sends data to the table has not been modified.

What should the administrator do?

A. Delete the Microsoft Sentinel workspace
B. Review and update the DCR so its schema/data flow remains compatible with the table
C. Recreate every Sentinel analytics rule
D. Disable Microsoft Sentinel and enable it again

Answer: B

Explanation

When the schema of a custom table changes, the associated DCRs should also be reviewed and updated as necessary. Azure Monitor doesn’t automatically update DCRs when the destination table schema changes.

This is an important exam concept:

Table schema changes and DCR schema/data-flow definitions must remain synchronized.

Question 7

A security operations team needs to store a very high volume of verbose application telemetry. The data is primarily intended for inexpensive long-term storage and aggregated trend analysis rather than frequent interactive security investigations.

Which table plan is most appropriate to investigate first?

A. Analytics
B. Premium
C. Basic
D. Auxiliary/Lake

Answer: D

Explanation

The Auxiliary/Lake plan is designed for high-volume, verbose data scenarios where inexpensive long-term storage and aggregated analysis are important.

Analytics is generally better suited to frequently queried operational and security analytics workloads. Basic can provide cost-effective storage for less frequently accessed data, but the scenario specifically emphasizes high-volume verbose data and inexpensive long-term storage.

Question 8

A security team wants a custom table containing security events that analysts will query frequently and that will be used for continuous monitoring and threat detection.

Which table plan is generally the best starting point?

A. Analytics
B. Auxiliary/Lake
C. Basic
D. Archive-only

Answer: A

Explanation

The Analytics plan is designed for active querying, continuous monitoring, real-time detection, and more comprehensive analytics capabilities.

Because the scenario emphasizes frequent querying and security detections, Analytics is the most appropriate choice.

Question 9

A security engineer successfully creates:

ThreatEvents_CL

in a Log Analytics workspace.

However, when running:

			
ThreatEvents_CL
| take 10

no records are returned.

The engineer verifies that the table exists.

What should be investigated next?

A. The ingestion source, DCR, transformation, destination mapping, and schema
B. Whether the workspace has a resource lock
C. Whether a Sentinel workbook has been created
D. Whether Conditional Access requires MFA

Answer: A

Explanation

Creating a table does not automatically populate it.

The administrator should trace the ingestion pipeline:

			
Source
  ↓
Ingestion mechanism
  ↓
DCR
  ↓
Transformation
  ↓
Destination table

		

The DCR configuration, stream, transformation, destination table name, and schema should all be validated.

Question 10

A company wants to use custom security data in Microsoft Sentinel to generate incidents when suspicious activity is detected.

Which statement correctly describes the relationship between the custom table and the Sentinel analytics rule?

A. Creating the custom table automatically creates an analytics rule
B. The analytics rule replaces the custom table after the first detection
C. The custom table stores the data, while the analytics rule evaluates the data for detection conditions
D. The custom table can only be queried by workbooks

Answer: C

Explanation

The custom table stores the ingested data.

A Microsoft Sentinel analytics rule can query that data and determine whether a specified security condition has occurred. If configured appropriately, the analytics rule can generate an alert or incident.

The two components therefore serve different purposes:

			
Custom Table
     ↓
Stores security data
Analytics Rule
     ↓
Evaluates security data
     ↓
Generates detection/alert/incident

		

This distinction is fundamental to understanding Microsoft Sentinel’s architecture.

Go to the SC-500 Exam Prep Hub main page

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

Enable and configure Microsoft agents and Security Store agents (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:
Manage and monitor security posture (20–25%)
   --> Implement Microsoft Security Copilot
      --> Enable and configure Microsoft agents and Security Store agents

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 Security Copilot extends beyond interactive prompting through security agents.

Agents are specialized AI-driven components designed to perform particular security or operational tasks. They can gather information, analyze security data, provide recommendations, and in some scenarios perform actions based on configured triggers, permissions, identities, plugins, and other parameters.

For the SC-500 exam, you should understand two important categories of agents:

Microsoft-built agents
Partner-built agents obtained through Microsoft Security Store

Microsoft Security Copilot provides an agent library where Microsoft and partner-built agents can be discovered and configured. Security Store provides an integrated storefront for discovering and acquiring Microsoft and partner security agents and solutions.

The current Microsoft training module specifically identifies the following objectives for this topic:

Discover and set up Microsoft-built agents using the Security Copilot agent library.
Acquire and configure partner-built agents through Security Store.
Understand the Global Administrator approval workflow.
Manage agent run state.
Edit agent configuration.
Manage agent memory.

1. What Is a Security Copilot Agent?

A Security Copilot agent is a specialized AI component designed to perform a particular security task or workflow.

An agent can combine:

An identity
Permissions
Plugins
Microsoft security products
Triggers
Input parameters
Security Copilot capabilities
Specialized instructions or logic

A useful mental model is:

                    Security Copilot Agent
                            |
          +-----------------+-----------------+
          |                 |                 |
          v                 v                 v
       Identity         Permissions        Plugins
          |                 |                 |
          v                 v                 v
     Who is the        What can the       What can the
       agent?            agent access?       agent use?
          |                 |                 |
          +-----------------+-----------------+
                            |
                            v
                         Trigger
                            |
                            v
                     Agent execution
                            |
                            v
                    Security result/action

Microsoft describes an agent’s identity as the credentials it uses when it runs, while permissions determine what information or tasks the agent is authorized to access or perform. Plugins extend what the agent can do by connecting it to capabilities in Microsoft and non-Microsoft services and public websites.

2. Microsoft-Built Agents

Microsoft-built agents are agents created and published by Microsoft.

They are designed for particular security scenarios and can be discovered through the Security Copilot agent library.

Microsoft provides agents across areas such as:

Microsoft Entra
Microsoft Defender
Microsoft Intune
Microsoft Purview
Microsoft Sentinel
Security Copilot

Agents may also be available through embedded experiences within Microsoft security products.

Example

Microsoft provides a Threat Intelligence Briefing Agent that can generate threat-intelligence reports using Microsoft threat data and related security information.

The agent has defined requirements for:

Identity
Licensing
Permissions
Products
Plugins
Role-based access
Triggering

This illustrates an important exam concept:

An agent is more than an AI prompt. It is a configured security workload with an identity, permissions, dependencies, and execution behavior.

3. Discovering Microsoft-Built Agents

To discover Microsoft-built agents in the standalone Security Copilot experience:

Sign in to Microsoft Security Copilot.
Select Agents from the navigation pane.
The agent library appears.
Browse or select the agent you want to use.
Select Set up.

Microsoft indicates that the agent must be set up before it can be used.

Conceptually:

			
Security Copilot
      |
      v
    Agents
      |
      v
 Agent Library
      |
      v
 Select Agent
      |
      v
    Set up
      |
      v
 Configure Agent
      |
      v
     Run

		

4. Agent Setup

When setting up a Microsoft-built agent, you may need to configure several components.

Microsoft identifies the following concepts as possible agent parameters:

Component	Purpose
Trigger	Determines what event or condition initiates the agent
Permissions	Determines what information or actions the agent is authorized to access
Identity	Provides credentials used when the agent runs
Plugins	Extend the agent’s capabilities
Products	Microsoft products required by the agent
Role-based access	Roles or permissions required to turn on or run the agent

Not every agent necessarily requires configuration of every parameter. The exact setup requirements vary by agent.

5. Agent Identity

Agent identity is one of the most important security concepts in the exam.

An agent needs an identity so that it can authenticate and securely access resources when it runs.

During setup, Microsoft-built agents can provide two identity options:

Create an agent identity
Use an existing user account

Microsoft recommends creating an agent identity where that option is available.

6. Dedicated Agent Identity

A dedicated agent identity gives the agent its own identity rather than making the agent dependent on an individual user’s account.

Conceptually:

              Agent
                |
                v
        Dedicated identity
                |
                v
        Assigned permissions
                |
                v
       Required resources

This can make access easier to control because the agent’s access can be managed independently of a specific employee.

Microsoft describes Microsoft Entra Agent ID as providing identities specifically for AI agents. The setup process allows permissions to be granted to the agent identity so that the agent can perform its required functions.

7. Using an Existing User Account

An alternative is to connect an existing user account.

In this model:

			
User account
     |
     v
Agent execution
     |
     v
User's permissions

		

The agent inherits the access and permissions associated with that account while it is active.

This can be appropriate in scenarios where the agent specifically needs to operate in the context of a user.

However, from a security-design perspective, you should understand the difference between:

Agent identity

and

User identity

because they produce different authorization and lifecycle considerations.

Exam clue

If a question asks:

“Which identity should be used to give the agent its own dedicated access?”

Think:

Agent identity.

If the question says:

“The agent should operate using the user’s existing permissions.”

Think:

Existing user account.

8. Agent Permissions

An agent’s identity determines who or what the agent is, while permissions determine what the agent can do.

For example:

			
Identity
   |
   +--> Authentication
             |
             v
         Permissions
             |
             +--> Read security data
             +--> Investigate alerts
             +--> Query threat intelligence
             +--> Perform authorized actions

		

An agent should receive only the permissions required for its intended workload.

This follows the principle of least privilege.

Microsoft specifically recommends using roles with the fewest permissions when configuring partner-built agents.

9. Plugins Used by Agents

Agents can use plugins to extend their capabilities.

A plugin can provide access to:

Microsoft services
Non-Microsoft services
Public websites
APIs
Threat-intelligence systems
Other security capabilities

Therefore:

			
Agent
  |
  +---- Plugin 1 --> Microsoft service
  |
  +---- Plugin 2 --> External API
  |
  +---- Plugin 3 --> Threat intelligence

		

An agent’s required plugins are part of its configuration.

Microsoft identifies plugins as components that extend an agent’s capabilities by providing access to Microsoft and non-Microsoft services and public websites through APIs.

10. Required Plugins

Some agents have dependent or required plugins.

When an agent requires a plugin, that plugin can be enabled for the agent.

However, there is an important distinction:

Enabled for the agent does not necessarily mean the plugin has been fully configured.

For an agent obtained through Security Store, Microsoft states that if the agent has a dependent plugin, the plugin is enabled for the agent but may still require configuration.

The administrator must go to:

Manage sources → Find the plugin → Configure the plugin

and complete the required configuration.

Exam scenario

An administrator obtains a Security Store agent.

The agent appears to be installed, but it does not run successfully.

The agent has a dependent plugin.

What should the administrator check?

The plugin’s configuration.

Do not assume that because the plugin is enabled for the agent, the plugin is completely configured.

11. Triggers

A trigger determines when an agent starts.

An agent may be configured to:

Run automatically based on a trigger
Run manually
Run according to a schedule
Be paused

Microsoft defines a trigger as an event or condition that tells an agentic system to initiate an action or series of actions.

Conceptually:

			
Event / Condition
       |
       v
    Trigger
       |
       v
    Agent
       |
       v
  Investigation
       |
       v
 Result / Action

		

12. Automatic Versus Manual Execution

Security Copilot allows an agent to operate automatically or manually.

Automatic

The agent runs when its configured trigger occurs.

Manual

An administrator or user can initiate a one-time execution.

Microsoft also allows an agent to be paused when it is not required to operate.

Example

An organization configures an agent to run every seven days.

If the organization wants to stop automatic executions temporarily, it can pause the agent.

The agent can later be resumed.

13. Pausing an Agent

Pausing an agent temporarily stops its operation.

This is useful when:

The underlying service is undergoing maintenance.
The agent is being investigated.
A security issue has been identified.
The agent is temporarily unnecessary.
The organization wants to stop automated execution without deleting the agent.

Pausing is therefore different from removing or deleting an agent.

			
RUNNING
   |
   v
 PAUSED
   |
   v
 RESUMED

		

14. Editing an Agent

Owners and Contributors can edit agents.

Editing can include modifying:

Identity
Trigger configuration
Other available parameters
Agent settings

Microsoft states that Owners and Contributors can edit an agent to modify its configuration.

Important distinction

Being able to run an agent does not necessarily mean being able to perform every administrative operation associated with the agent.

Always distinguish:

Discover
Set up
Run
Pause
Edit
Manage permissions
Manage identity

when analyzing an exam scenario.

15. Agent Memory

Security Copilot agents can maintain memory associated with feedback and configuration.

Owners and Contributors can provide feedback to an agent.

That feedback can become part of the agent’s memory and influence subsequent operation.

An administrator can review the agent’s memory and reject feedback that should no longer be retained.

Process

			
Agent output
     |
     v
Provide feedback
     |
     v
Feedback stored in memory
     |
     v
Agent considers memory
     |
     v
Future operation

		

To manage memory:

Open the agent.
Select the … menu.
Select Manage memory.
Review stored feedback.
Select feedback.
Use Reject feedback when appropriate.

16. Microsoft Security Store

Microsoft Security Store is a security-focused storefront for discovering, evaluating, acquiring, and deploying Microsoft and partner-built security solutions and agents.

It integrates with Microsoft security products including:

Microsoft Defender
Microsoft Sentinel
Microsoft Entra
Microsoft Purview
Microsoft Intune
Microsoft Security Copilot

Security Store is integrated into the standalone Security Copilot experience.

17. Microsoft Agents Versus Partner Agents

This distinction is important for SC-500.

Characteristic	Microsoft-built agent	Partner-built agent
Publisher	Microsoft	Microsoft partner
Discovery	Security Copilot agent library / Security Store	Security Store
Setup	Security Copilot	Security Copilot after acquisition
May require Microsoft permissions	Yes	Yes
Global Administrator consent	Not necessarily the same partner-agent workflow	Required when the partner agent needs certain Microsoft product permissions
Identity configuration	Yes	Yes
Plugins	May be required	May be required
Commercial terms	Depend on agent/prerequisites	May require separate purchase/subscription

Microsoft’s current documentation distinguishes Microsoft-built and partner-built agent setup, including a specific consent workflow for partner-built agents that require access to Microsoft tools and data.

18. Discovering Agents Through Security Store

From Security Copilot, users can navigate to:

Home → Security Store

They can then:

Search for an agent.
Filter by publisher, product, or pricing.
Select the desired agent.
Select Get agent.

Microsoft-built agents are routed to the Active agents experience.

Non-Microsoft agents are routed through Security Store for purchase or subscription where required.

19. Purchasing Versus Operating an Agent

This is an important exam distinction.

Security Store handles acquisition and billing.

Security Copilot handles agent configuration and operation.

Conceptually:

             Security Store
                   |
                   v
          Find / Purchase / Subscribe
                   |
                   v
              Get Agent
                   |
                   v
          Microsoft Security Copilot
                   |
                   v
          Configure / Run / Pause
                   |
                   v
              Manage Agent

Microsoft explicitly separates purchasing/subscription management from operational management in Security Copilot.

20. Removing an Agent Versus Ending a Subscription

A particularly important Security Store concept:

Removing an agent from Security Copilot and managing its commercial subscription are separate considerations.

Microsoft’s Security Store documentation states that purchases and subscriptions are handled separately from the Security Copilot platform.

For partner agents, billing and entitlement information may need to be managed through Security Store.

Exam clue

If the question says:

“Remove the agent from Security Copilot.”

Think:

Operational removal.

If the question says:

“Cancel the partner subscription.”

Think:

Security Store / subscription management.

Do not automatically treat the two as the same operation.

21. Security Compute Units

Using agents within Security Copilot consumes Security Compute Units (SCUs).

SCU consumption is distinct from any separate subscription or licensing fees associated with a partner agent.

This creates two potentially separate considerations:

			
Partner Agent
     |
     +---- Partner subscription / license
     |
     +---- Security Copilot usage
              |
              +---- SCUs

		

For exam purposes, remember:

Partner-agent acquisition costs and Security Copilot compute usage are not necessarily the same charge.

22. Partner Agent Global Administrator Consent

This is one of the most important exam scenarios.

Suppose an organization wants to deploy a partner-built Security Copilot agent.

The agent needs to access:

Microsoft Entra
Microsoft Intune
Microsoft Sentinel
Microsoft Defender
Defender Threat Intelligence

and therefore requires permissions to Microsoft services.

A Global Administrator must approve the required permissions for the partner-built agent.

The workflow is:

			
Security Copilot Owner/Contributor
             |
             v
       Begin agent setup
             |
             v
   Consent required banner
             |
             v
       Copy approval link
             |
             v
      Global Administrator
             |
             v
      Review permissions
             |
             v
        Approve access
             |
             v
 Owner/Contributor completes setup

		

23. What the Global Administrator Does

The Global Administrator should review the agent’s requested permissions before approving the agent.

The approval interface can provide information such as:

Agent details
Description
Trigger
Required permissions
Other configuration information

The administrator starts the approval process and grants the necessary permissions.

Security principle

Microsoft explicitly recommends using the fewest permissions possible.

Global Administrator is a highly privileged role and should not be used unnecessarily.

24. What Happens After Consent?

Once Global Administrator approval is complete:

Security Copilot Owners and Contributors can finish the agent setup.

They can configure items such as:

Identity
Trigger
Input parameters
Other agent-specific settings

They do not necessarily need to remain Global Administrators simply because the initial consent required Global Administrator approval.

This distinction is highly relevant to least-privilege exam questions.

25. When Global Administrator Approval Isn’t Required

Global Administrator approval is required in the documented partner-agent scenario when the agent needs access to Microsoft tools and Microsoft product data.

However:

If the partner-built agent does not require Microsoft product permissions, the documented Global Administrator approval isn’t required.

Example

A partner-built agent only processes information through its own external service and does not request access to Microsoft product data.

The special Microsoft-product consent workflow does not apply.

26. Security Store Agent With a Dependent Plugin

This is an especially useful scenario to remember.

Suppose:

You obtain a partner agent through Security Store.
The agent has a dependent plugin.
The agent appears in Security Copilot.
The agent still doesn’t operate successfully.

The likely next step is to configure the dependent plugin.

Microsoft’s documented process is:

Manage sources → Find the plugin → Configure the plugin

The plugin may already be enabled for the agent but not configured.

27. Agent Lifecycle

For exam purposes, understand the lifecycle:

             DISCOVER
                 |
                 v
              ACQUIRE
                 |
                 v
                SET UP
                 |
                 v
             CONFIGURE
                 |
                 v
               ENABLE
                 |
                 v
                RUN
              /     \
             v       v
        Automatic   Manual
             |
             v
            PAUSE
             |
             v
            EDIT
             |
             v
        Manage Memory
             |
             v
          REMOVE

Not every agent goes through exactly the same sequence, but this model is useful for scenario questions.

28. Agent States You Should Know

Microsoft’s Security Copilot agent experience distinguishes agents that are ready for configuration from agents that are already in use.

The custom-agent documentation describes:

Ready for setup

The agent has been made available but has not yet been configured.

Agents in use

The agent has been configured and is ready to run.

Conceptually:

             Agent available
                   |
                   v
             Ready for setup
                   |
                   v
                  Setup
                   |
                   v
             Agents in use
                   |
                   v
              Run / Pause

29. Security Copilot Owner and Contributor Roles

The Security Copilot Owner and Contributor roles are important when managing agents.

Microsoft states that Owners and Contributors can:

Set up agents
Edit agents
Provide feedback
Manage agent memory
Run or pause agents

Specific capabilities can still depend on the agent and its required permissions.

Do not confuse these roles with Microsoft Entra roles.

For example:

Security Copilot Contributor ≠ Global Administrator

and

Security Copilot Owner ≠ Azure Owner

They are different authorization systems.

30. Agent Identity, Role-Based Access, and Permissions

When configuring an agent, three concepts can appear very similar but should be distinguished.

Concept	Question it answers
Identity	Who/what is the agent when it runs?
Permissions	What information or actions can the agent access?
Role-based access	Which roles are required to turn on or run the agent?

For example:

			
Agent
 |
 +--> Identity
 |       "Who am I?"
 |
 +--> Permissions
 |       "What can I access?"
 |
 +--> RBAC
         "Who is allowed to enable/run me?"

		

This distinction is valuable for scenario-based questions.

31. Embedded Versus Standalone Agents

Security Copilot agents can appear in both:

Standalone experience

The user accesses Security Copilot directly.

Embedded experience

Security Copilot capabilities and agents are integrated into other Microsoft security products.

Microsoft identifies integrated experiences across products including:

Microsoft Defender
Microsoft Sentinel
Microsoft Intune
Microsoft Entra
Microsoft Purview

This matters because an agent’s availability can depend on how administrators configure access and which products and permissions are involved.

32. Common SC-500 Exam Traps

Trap 1: Assuming every agent is immediately usable

An agent generally needs to be set up and configured before it can be used.

Trap 2: Confusing an agent with a plugin

A plugin extends an agent’s capabilities.

An agent is the higher-level component that can use plugins, permissions, identities, triggers, and other configuration.

Think:

Agent → uses Plugin

not necessarily:

Plugin → is the Agent

Trap 3: Assuming the agent’s identity is the same as the administrator’s identity

An agent can have its own dedicated identity.

Microsoft recommends creating an agent identity where supported.

Trap 4: Assuming every partner agent requires Global Administrator approval

The special approval workflow applies when the partner-built agent needs access to Microsoft tools and Microsoft product data.

Partner agents that don’t require Microsoft product permissions don’t require that documented approval workflow.

Trap 5: Assuming Global Administrator must configure everything

Global Administrator approval may be required for the partner agent’s requested Microsoft permissions.

After approval, Security Copilot Owners and Contributors can complete the agent setup.

Trap 6: Assuming enabled dependent plugins are fully configured

A dependent plugin can be enabled for an agent but still require configuration.

Use:

Manage sources → Plugin → Configure

when required.

Trap 7: Confusing Security Store with Security Copilot

Security Store is used for discovering and acquiring partner agents and solutions.

Security Copilot is where agents are configured and operated.

Trap 8: Assuming removing an agent automatically cancels the subscription

Operational removal and subscription/billing management are separate considerations.

Trap 9: Giving the agent more permissions than necessary

Use least privilege.

Microsoft explicitly recommends using roles with the fewest permissions when setting up partner-built agents.

Trap 10: Confusing Run, Pause, and Remove

These are different lifecycle operations:

Run → execute the agent
Pause → temporarily stop operation
Remove → remove the agent from the Security Copilot environment

33. Practical Configuration Example

Imagine an organization wants an agent that automatically generates a weekly threat-intelligence briefing.

The process might look like this:

Step 1 — Discover the agent

The security administrator opens:

Security Copilot → Agents

Step 2 — Select the agent

The administrator selects the Threat Intelligence Briefing Agent.

Step 3 — Review requirements

The administrator reviews:

Identity
Permissions
Required products
Plugins
Trigger
RBAC requirements

Step 4 — Configure identity

Where supported, create a dedicated agent identity.

Step 5 — Configure permissions

Grant only the permissions required by the agent.

Step 6 — Configure required plugins

Make sure required plugins are enabled and properly configured.

Step 7 — Configure the trigger

The agent can run according to its configured trigger.

Step 8 — Run/test

Run the agent and review the output.

Step 9 — Monitor

Allow the agent to operate according to the configured schedule.

This illustrates the broader pattern:

Discover → Review → Identity → Permissions → Plugins → Trigger → Run → Monitor

34. Practical Security Store Example

Suppose a company wants to deploy a partner-developed incident investigation agent.

The process could look like:

			
Security Copilot
      |
      v
Security Store
      |
      v
Find partner agent
      |
      v
Get / Purchase / Subscribe
      |
      v
Agent available in Security Copilot
      |
      v
Does it require Microsoft permissions?
      |
    +---+---+
    |       |
   Yes      No
    |       |
    v       v
GA consent  Setup
    |       |
    +---+---+
        |
        v
   Configure identity
        |
        v
 Configure parameters/plugins
        |
        v
       Run

		

The exact commercial and consent requirements depend on the agent.

35. Exam-Focused Decision Tree

When you see an agent question, use this decision process:

Question 1: Who published it?

Microsoft → Microsoft-built agent

Partner → Partner-built agent

Question 2: Where did you find it?

Agents library → Security Copilot

Security Store → Security Store acquisition/discovery

Question 3: Does it require Microsoft product permissions?

Yes → Check the Global Administrator consent requirement for partner-built agents

No → That specific consent workflow isn’t required

Question 4: Does it have a dependent plugin?

Yes → Make sure the plugin is configured

No → Continue with normal setup

Question 5: What identity should it use?

Prefer a dedicated agent identity where supported and appropriate.

Question 6: How should it execute?

Choose the appropriate:

Triggered execution
Manual execution
Pause/resume

Question 7: What permissions should it receive?

Apply least privilege.

36. High-Value Exam Comparison

Scenario	Think
Find Microsoft-built agents	Security Copilot Agents library
Acquire partner-built agents	Security Store
Configure an agent	Security Copilot
Agent needs Microsoft product permissions	Global Administrator consent may be required for partner-built agents
Agent does not need Microsoft product permissions	No special Global Administrator approval workflow
Give agent its own identity	Create agent identity
Agent should use a user’s permissions	Existing user account
Agent requires additional capability	Plugin
Agent has dependent plugin but fails setup	Configure the plugin
Stop an agent temporarily	Pause
Change agent settings	Edit
Review stored agent feedback	Manage memory
Cancel partner subscription	Security Store
Control agent execution	Trigger / Run / Pause
Reduce security exposure	Least privilege

37. Key Takeaways

For the SC-500 exam, remember these points:

Security Copilot agents automate specialized security tasks and workflows.
Microsoft-built agents can be discovered in the Security Copilot agent library.
Partner-built agents can be discovered and acquired through Microsoft Security Store.
An agent must generally be set up before it can be used.
Agent setup can involve identity, permissions, plugins, products, triggers, and RBAC requirements.
Where supported, Microsoft recommends using a dedicated agent identity.
An existing user account can also be used, in which case the agent operates with that account’s permissions.
Identity and permissions are different concepts.
Plugins extend an agent’s capabilities.
A dependent plugin can be enabled for an agent without being fully configured.
Security Store handles acquisition and billing for partner offerings; Security Copilot handles agent configuration and operation.
A partner-built agent that requires access to Microsoft tools and Microsoft product data requires the documented Global Administrator consent workflow.
After consent, Security Copilot Owners and Contributors can complete the agent setup.
Partner agents that don’t require Microsoft product permissions don’t require that specific Global Administrator approval workflow.
Microsoft recommends using the fewest permissions necessary.
Agents can be configured to run automatically or manually.
Agents can be paused when they shouldn’t operate.
Owners and Contributors can edit agents and manage agent memory.
Removing an agent and managing a partner subscription are separate considerations.
Always distinguish Microsoft-built agents, partner-built agents, plugins, Security Store, identities, permissions, triggers, and agent lifecycle states.

Practice Exam Questions

Question 1

A security administrator wants to use a Microsoft-built Security Copilot agent for the first time. The agent appears in the Security Copilot Agents library but has not been configured.

What should the administrator do first?

A. Select the agent and choose Set up.

B. Purchase the agent through Microsoft Security Store.

C. Assign the Global Administrator role to the agent.

D. Create a custom plugin for the agent.

Answer: A

Explanation: Microsoft-built agents must be set up before they can be used. The administrator can select the agent from the Security Copilot Agents library and select Set up. Microsoft agents do not require the partner-agent acquisition workflow simply because they are Microsoft-built.

Question 2

An organization wants a Security Copilot agent to have its own identity and permissions rather than using an employee’s account.

Which option should the administrator select when configuring the agent?

A. Create an agent identity

B. Security Copilot Contributor

C. Microsoft Entra Global Administrator

D. Security Store subscription identity

Answer: A

Explanation: Microsoft-built agents can be configured with a dedicated agent identity. Microsoft recommends creating an agent identity where that option is available.

Question 3

A company acquires a partner-built Security Copilot agent. During setup, the agent requests access to Microsoft Sentinel and Microsoft Defender data.

What is required before the Security Copilot Owner can complete the setup?

A. The agent must first be converted into a Microsoft-built agent.

B. A Security Copilot Contributor must approve the permissions.

C. The agent must be published to Security Store again.

D. A Global Administrator must approve the required Microsoft permissions.

Answer: D

Explanation: When a partner-built agent requires access to Microsoft tools and Microsoft product data, a Global Administrator in the tenant must approve the required permissions. After approval, the Security Copilot Owner or Contributor can complete setup.

Question 4

A partner-built agent does not access Microsoft product data or require Microsoft product permissions.

Is the documented Global Administrator approval workflow required?

A. Yes, all partner agents require Global Administrator approval.

B. Yes, but only when the agent uses a trigger.

C. Yes, but only when the agent uses a plugin.

D. No, that specific approval workflow isn’t required when Microsoft product permissions aren’t needed.

Answer: D

Explanation: Microsoft specifically states that partner-built agents that don’t require Microsoft product permissions do not require the documented Global Administrator approval workflow.

Question 5

A Security Copilot Owner has received Global Administrator approval for a partner-built agent. What can the Owner do next?

A. Nothing; the Global Administrator must perform the remainder of the configuration.

B. Delete the agent and reinstall it.

C. Complete the agent setup, including configuring identity, trigger, and other required values.

D. Convert the agent into a custom plugin.

Answer: C

Explanation: After Global Administrator approval, Security Copilot Owners and Contributors can finish setting up the partner-built agent, including identity, trigger, and other configuration values.

Question 6

An agent obtained through Security Store has a dependent plugin. The agent appears in Security Copilot, but it cannot operate successfully.

What should the administrator check?

A. Whether the dependent plugin has been configured.

B. Whether the agent has been converted to a Microsoft-built agent.

C. Whether the Security Copilot workspace has been deleted.

D. Whether the user has been assigned Global Administrator permanently.

Answer: A

Explanation: A dependent plugin can be enabled for an agent but still require configuration. Microsoft directs administrators to Manage sources, find the plugin, and configure it before using the agent successfully.

Question 7

A security team wants to temporarily stop an automated Security Copilot agent while investigating an issue with its behavior. They don’t want to remove the agent.

What should they do?

A. Delete the agent.

B. Pause the agent.

C. Remove its Security Copilot license.

D. Delete all of its plugins.

Answer: B

Explanation: Security Copilot allows an agent to be paused so that it temporarily stops operating. The agent can later be resumed. This is different from deleting or removing the agent.

Question 8

An organization wants to obtain a partner-built security agent and manage its acquisition and subscription.

Where should the organization perform the purchasing or subscription activity?

A. Azure Policy

B. Microsoft Entra admin center only

C. Security Copilot agent configuration

D. Microsoft Security Store

Answer: D

Explanation: Security Store is the security-focused storefront for discovering and acquiring Microsoft and partner-built security solutions and agents. Purchasing and subscription management are handled separately from the operational configuration of agents in Security Copilot.

Question 9

A Security Copilot administrator wants to give an agent only the access required to perform its assigned security task.

Which security principle should guide the configuration?

A. Least privilege

B. Full administrative access

C. Global Administrator inheritance

D. Shared credentials

Answer: A

Explanation: Microsoft recommends using roles with the fewest permissions when configuring partner-built agents. Least privilege reduces unnecessary access and limits the potential impact of a compromised or misconfigured agent.

Question 10

An administrator wants a Security Copilot agent to operate automatically when its configured condition occurs, rather than requiring a user to start it each time.

Which agent configuration should the administrator use?

A. User identity

B. Security Store subscription

C. Trigger

D. Agent memory

Answer: C

Explanation: A trigger is an event or condition that causes an agentic system to initiate an action or series of actions. Security Copilot supports automatic execution based on configured triggers as well as manual one-time execution.

Final Exam Mental Model

When an SC-500 question asks you to enable or configure a Microsoft or Security Store agent, use this sequence:

1. Identify the agent source

→ Microsoft-built
→ Partner-built

2. Find/acquire it

→ Security Copilot Agents library
→ Security Store

3. Determine whether consent is required

→ Does a partner agent need Microsoft product permissions?

4. Configure identity

→ Prefer a dedicated agent identity when supported
→ Or use an existing user account when appropriate

5. Configure permissions

→ Apply least privilege

6. Configure dependencies

→ Required products
→ Plugins
→ Input parameters

7. Configure execution

→ Trigger
→ Manual run
→ Pause/resume

8. Manage afterward

→ Edit
→ Review memory
→ Monitor
→ Remove when no longer required

The most important distinctions to remember are:

Microsoft agent vs. partner agent
Security Copilot vs. Security Store
Identity vs. permissions
Plugin enabled vs. plugin configured
Global Administrator consent vs. ongoing agent administration
Purchase/subscription vs. operational management
Run vs. pause vs. remove

Go to the SC-500 Exam Prep Hub main page

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

Query Microsoft Purview Audit in Defender XDR (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:
Manage and monitor security posture (20–25%)
   --> Implement activity and event collection in Microsoft Sentinel
      --> Query Microsoft Purview Audit in Defender XDR

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

Security investigations often require more than security alerts and endpoint telemetry. Investigators also need to know what users and administrators actually did across Microsoft 365 and Microsoft security services.

For example:

Who changed a Microsoft Defender security setting?
Who created or modified a custom detection rule?
Who isolated a device?
Who changed a data-retention setting?
Who modified security roles?
Who assigned a user to an incident?
What actions were performed by an administrator before or during a security incident?

Microsoft Purview Audit provides the auditing infrastructure used to record supported user and administrator activities across Microsoft 365. Microsoft Defender XDR uses this auditing capability, and the audit records can be searched from the Microsoft Defender portal.

For the SC-500 exam, the important skill is understanding how to query the Microsoft Purview unified audit log from Microsoft Defender XDR, what information can be searched, what permissions are required, and how audit-log retention affects an investigation.

1. What Is Microsoft Purview Audit?

Microsoft Purview Audit records supported user and administrator activities throughout the Microsoft 365 environment.

The resulting audit records can be used for:

Security investigations
Forensic investigations
Compliance investigations
IT investigations
Legal investigations
Insider-risk investigations
Tracking administrative changes

Microsoft describes Audit (Standard) as a solution for logging and searching audited activities across Microsoft services. It includes thousands of searchable audit events.

A useful conceptual model is:

			
Users / Administrators
        |
        v
Audited activities
        |
        v
Microsoft Purview Unified Audit Log
        |
        +-----------------------+
        |                       |
        v                       v
Microsoft Defender XDR     Microsoft Purview
        |                       |
        +-----------+-----------+
                    |
                    v
             Investigation

		

The important point is that the audit information is not simply a Defender-specific log.

Microsoft Defender XDR uses Microsoft Purview auditing.

2. Why Query the Audit Log During a Security Investigation?

Security telemetry can tell you that something happened.

The audit log can help answer:

Who performed the action, what action occurred, and when did it occur?

Consider an investigation into a compromised security administrator account.

An investigator might discover that:

The account signed in.
A Defender security configuration was changed.
A device was isolated.
A security role was modified.
A custom detection rule was created.

Security alerts alone might not provide the complete administrative activity trail.

The audit log can provide evidence of supported administrative and user activities.

Microsoft specifically identifies Defender activities such as changes to data-retention settings, changes to advanced features, creation of indicators of compromise, device isolation, security-role changes, custom detection-rule changes, and incident assignments as audited activities.

3. Microsoft Defender XDR and the Unified Audit Log

Microsoft Defender XDR activities are integrated with the Microsoft Purview auditing solution.

This means that an investigator can use the Audit page in the Microsoft Defender portal to search for supported activities.

Microsoft states that the Defender portal audit search is identical to the audit-log search experience available through Microsoft Purview.

Conceptually:

			
Microsoft Defender XDR
        |
        | audited activity
        v
Microsoft Purview auditing
        |
        v
Unified Audit Log
        |
        v
Defender portal → Audit

		

This is particularly useful because security personnel can investigate Defender activity without having to switch to an entirely separate audit system.

4. What Can You Search For?

The audit search allows investigators to filter activities using several criteria.

Important search criteria include:

Date and time range
Activities
Users

The available activities depend on the services and workloads being audited.

Microsoft Defender XDR audit records can include activities associated with Microsoft Defender XDR and Microsoft Defender for Endpoint.

Examples include:

Activity type	Example investigation question
Data-retention changes	Who changed a retention setting?
Advanced-feature changes	Who changed a Defender configuration?
Indicator changes	Who created an indicator of compromise?
Device isolation	Who isolated a device?
Security-role changes	Who added, edited, or removed a security role?
Custom detections	Who created or modified a custom detection rule?
Incident assignment	Who assigned a user to an incident?

These examples illustrate an important distinction:

The audit log records administrative and user actions, not simply security alerts.

5. Accessing Audit Search in Microsoft Defender

The current Microsoft Defender portal provides an Audit page for searching audit records.

The general process is:

Sign in to the Microsoft Defender portal.
Open Audit.
Configure the search criteria.
Select Search.
Review the returned audit records.
Export results if required.

Microsoft documents the Defender portal Audit page as the starting point for audit-log searches.

The same audit-search capability can also be accessed from Microsoft Purview.

6. Search Criteria

A typical audit search begins by narrowing the investigation.

Date and Time

Specify the period in which the activity occurred.

For example:

			
Start: September 20, 2026 00:00 UTC
End:   September 25, 2026 23:59 UTC

Be careful with time zones.

Microsoft’s audit search uses a date/time range, and audit activities are represented using UTC-based timing.

Exam Tip

If an exam question asks you to investigate activity during a specific period, date/time is one of the primary search filters.

Activities

The Activities filter lets you search for specific audited operations.

For example, an investigator could search for a Defender activity involving:

Device isolation
Security-role changes
Custom detection rules
Indicators
Retention settings

The exact activity names available depend on the workload and audit records being searched.

Users

The Users filter allows an investigator to narrow results to activities performed by particular users.

For example:

“Determine whether the compromised administrator account changed any Defender settings during the incident.”

The investigator can specify that account in the Users filter.

Leaving the Users field empty allows the search to include activities from all users within the search scope.

7. Example Investigation

Suppose a security team discovers that a critical endpoint was isolated unexpectedly.

The team wants to determine:

Who initiated the isolation and when?

A reasonable audit investigation would be:

			
Audit
  |
  +-- Date/time
  |     |
  |     +-- Incident timeframe
  |
  +-- Activity
  |     |
  |     +-- Device isolation-related activity
  |
  +-- User
        |
        +-- Leave blank initially

		

The investigator reviews the resulting audit records to determine which account performed the action.

If a particular account is identified, a second search can narrow the investigation to that user and the surrounding time period.

This illustrates an important investigation technique:

Start broad enough to discover the activity, then narrow the search as evidence identifies relevant users, activities, or time periods.

8. Audit Records vs. Microsoft Sentinel Logs

This distinction is important for SC-500.

Microsoft Purview Audit is not simply another Microsoft Sentinel table.

The audit log is a Microsoft 365 auditing system.

Microsoft Sentinel can collect and analyze many different data sources, while Microsoft Purview Audit provides auditing of supported Microsoft 365 activities.

Therefore:

Microsoft Purview Audit	Microsoft Sentinel
Focuses on audited user/admin activities	Security information and event management
Unified Microsoft 365 audit log	Centralized security data platform
Search through Audit	Query using KQL and Sentinel capabilities
Used heavily for compliance and administrative investigations	Used for detection, investigation, hunting, and response
Records supported audited activities	Collects many security and operational data sources

The two systems can complement one another.

For example:

			
Defender alert
      |
      v
Sentinel investigation
      |
      +---- Endpoint telemetry
      |
      +---- Identity logs
      |
      +---- Microsoft 365 activity
      |
      v
Purview Audit
      |
      v
Administrative action

		

An investigator may use both security telemetry and audit records to reconstruct an incident.

9. Microsoft Defender XDR Audit vs. Defender Alerts

Another important distinction is:

Alert

An alert generally indicates that a security-related condition or detection occurred.

Audit record

An audit record documents a supported user or administrator activity.

For example:

Alert:

Suspicious activity detected on a device.

Audit record:

Administrator isolated the device.

These are different types of information.

During an investigation, both can be valuable.

10. Required Permissions

Access to the audit log is controlled through permissions.

Microsoft currently documents that users need the Audit Logs or View-Only Audit Logs permissions/roles to search audit records. In the Defender/XDR context, these permissions are associated with Exchange Online role groups such as Compliance Management and Organization Management by default.

Microsoft also emphasizes least privilege.

A Global Administrator can have the necessary access, but Microsoft recommends using lower-privilege roles when they are sufficient.

Exam Tip

If a question asks:

“What permissions are required to search the audit log?”

Think:

Audit Logs or View-Only Audit Logs.

Do not automatically choose Global Administrator simply because that role can perform the task.

11. Audit Logs vs. View-Only Audit Logs

These permissions provide access to audit information.

The principle is:

Give investigators the minimum permissions required to perform their responsibilities.

For an investigator who only needs to search and review audit records, a read-oriented audit role is preferable to granting broad administrative permissions.

This aligns with the principle of least privilege emphasized throughout Microsoft security solutions.

12. Audit Must Be Available

Before investigating audit activity, auditing must be available for the organization.

Microsoft Defender XDR uses Microsoft Purview auditing, and Microsoft states that auditing needs to be turned on in Microsoft Purview before audit data can be viewed in the Defender portal.

This creates an important troubleshooting sequence:

			
Can't find audit records?
        |
        +--> Is auditing enabled?
        |
        +--> Does the user have audit permissions?
        |
        +--> Is the activity actually audited?
        |
        +--> Is the activity within the retention period?
        |
        +--> Are the search filters correct?

		

A missing audit record does not automatically mean the activity never occurred.

The activity may:

Not be audited
Fall outside the retention period
Require different search criteria
Belong to a different workload
Have been performed outside the period being searched

13. Audit Retention

Retention is especially important when investigating historical incidents.

The default Audit (Standard) retention period is currently 180 days for audit logs generated on or after October 17, 2023. Older Audit (Standard) records generated before that date followed the previous 90-day default.

Therefore, an investigator should not assume that an audit record from several years ago is automatically available.

Audit retention depends on the organization’s Microsoft Purview audit configuration and licensing.

14. Audit (Premium) and Longer Retention

Microsoft Purview Audit (Premium) provides additional audit capabilities, including configurable audit-log retention policies.

Audit retention policies can retain audit records for:

More than the standard retention period
Up to one year for appropriately licensed users
Up to 10 years when the required licensing and 10-year audit retention add-on are in place

Microsoft currently documents support for audit-log retention policies of up to 10 years.

Important Licensing Concept

Longer retention is not simply a matter of changing a setting.

Microsoft documents licensing requirements for longer retention. For example, retaining audit logs beyond 180 days and up to one year requires appropriate E5-level licensing for the users whose activities generate the audit records; 10-year retention requires an additional 10-year audit-log retention license.

Exam Tip

When a question combines:

Long-term audit retention
Compliance
Microsoft Purview Audit

look for Audit retention policies and the appropriate licensing, rather than assuming Microsoft Sentinel table retention controls the audit records.

15. Audit Retention Policies

Microsoft Purview Audit (Premium) supports audit log retention policies.

Policies can specify how long audit records should be retained.

They can be configured according to criteria such as the audited workload, record type, and other supported conditions.

An organization can have up to 50 audit-log retention policies.

The important exam concept is:

Microsoft Purview Audit retention is managed through Purview audit-retention capabilities, not through Microsoft Sentinel table-retention settings.

16. Searching With PowerShell

The audit log can also be queried programmatically.

Microsoft provides the Search-UnifiedAuditLog PowerShell cmdlet for searching audit events.

This can be useful when:

Searches need to be automated
Investigators need repeatable queries
Results need to be processed programmatically
An investigation involves many searches
Security teams want to integrate audit searching into operational workflows

The portal and PowerShell access the same underlying audit-log capability.

17. Microsoft Graph Audit Search API

Microsoft also provides the Audit Search Graph API.

This allows applications to programmatically access audit-search data through Microsoft Graph.

This is useful for organizations building:

Automated investigations
Compliance workflows
Security dashboards
Custom reporting
Integration with security operations tooling

For the SC-500 exam, recognize the relationship:

			
Audit Search
     |
     +---- Defender portal
     |
     +---- Purview portal
     |
     +---- PowerShell
     |
     +---- Microsoft Graph Audit Search API

		

18. Exporting Audit Results

Audit-search results can be exported.

The Microsoft Purview audit search experience supports exporting results to a CSV file.

The exported data includes an AuditData column containing additional event information formatted as JSON.

That JSON can be transformed in tools such as Excel’s Power Query Editor to make individual properties easier to analyze.

This can be useful for:

Compliance reports
Investigation evidence
Sorting and filtering
Offline analysis
Sharing investigation results with authorized personnel

19. Understanding the AuditData Property

An audit record contains multiple properties describing the event.

When audit results are exported, the AuditData field contains additional event information as JSON.

For example, an exported record can conceptually look like:

			
CreationTime
UserId
Operation
Workload
RecordType
AuditData

		

The AuditData field may contain additional properties that provide more context about the operation.

This is particularly useful when the standard columns do not provide all the information required for an investigation.

20. Investigating Microsoft Defender XDR Activities

Microsoft Defender XDR provides a specific collection of audited activities.

Examples include:

Data-retention changes

An investigator can determine whether an administrator changed a security data-retention setting.

Device isolation

An investigator can investigate which user or administrator performed an isolation action.

Security-role changes

An investigator can determine whether security permissions or roles were changed.

Custom detection changes

An investigator can determine who created or modified custom detection rules.

Incident assignments

An investigator can determine who assigned a user to an incident.

These activities can provide important evidence during an investigation into unauthorized administrative behavior.

21. Example: Investigating an Unauthorized Defender Change

Suppose a security team discovers that an organization’s Defender configuration changed unexpectedly.

The investigation could proceed as follows:

Step 1 — Identify the approximate timeframe

Determine when the configuration change was discovered.

Step 2 — Search the Audit page

Open the Audit page in Microsoft Defender.

Step 3 — Filter by activity

Select the relevant Defender activity.

Step 4 — Review users

Identify which account performed the activity.

Step 5 — Correlate with other telemetry

Compare the audit event with:

Sign-in activity
Device activity
Security alerts
Incident timelines
Other administrative changes

Step 6 — Export if required

Export the results for additional investigation or reporting.

This provides a more complete picture than examining a security alert alone.

22. Audit Log Search Is Not the Same as KQL

A common SC-500 exam trap is assuming that every Microsoft security data source is queried with KQL.

Microsoft Purview Audit provides its own search experience.

The standard Audit search uses filters such as:

Date/time
Activities
Users

It can also be accessed programmatically through PowerShell and Microsoft Graph.

By contrast, Microsoft Sentinel uses KQL extensively for querying data stored in its Log Analytics environment.

Therefore:

Task	Primary mechanism
Search Microsoft Purview audit activities	Audit search
Search Defender audit activity	Defender Audit
Programmatically search unified audit log	Search-UnifiedAuditLog / Graph API
Query Sentinel log tables	KQL
Build Sentinel analytics rules	KQL-based queries

23. Common Troubleshooting Scenario

Suppose an administrator says:

“I know a user changed a Defender setting yesterday, but I cannot find the event.”

Work through the following checklist.

1. Check permissions

Does the investigator have:

Audit Logs
View-Only Audit Logs

or equivalent access?

2. Check auditing

Is Microsoft Purview auditing enabled?

3. Check the date/time

Is the correct UTC range being searched?

4. Check the activity

Is the specific operation actually audited?

5. Check the user

Was the correct account selected?

6. Check retention

Is the event still within the organization’s audit-log retention period?

7. Check the workload

Could the activity have been generated by another Microsoft workload?

This systematic approach is more reliable than simply expanding the search indefinitely.

24. Audit Data and Incident Reconstruction

One of the most valuable uses of audit information is reconstructing a timeline.

For example:

			
09:12  User signs in
   |
09:17  Defender configuration changed
   |
09:19  Indicator created
   |
09:23  Device isolated
   |
09:31  Incident assigned
   |
09:45  SOC begins investigation

		

The audit log can provide evidence for supported administrative actions within this timeline.

Other security data sources can then provide additional context.

This is particularly useful for determining:

What happened?
When did it happen?
Who performed the action?
Which security controls were changed?
What happened immediately before or after the change?

25. Best Practices

Use least privilege

Do not give investigators Global Administrator privileges merely because that role can search audit logs.

Use the appropriate Audit Logs or View-Only Audit Logs permissions.

Search narrowly before expanding

Start with:

Known timeframe
Known user
Known activity

Then expand the search when necessary.

Correlate audit records with security telemetry

Audit records provide administrative context. Combine them with Defender, Microsoft Entra, endpoint, and Sentinel data for a more complete investigation.

Understand retention before an incident occurs

Organizations should establish audit retention policies before they need historical evidence.

Consider licensing requirements

Longer audit retention may require specific Microsoft licensing and the appropriate retention policy configuration.

Export important results

Export relevant audit results when investigation or compliance procedures require a durable copy for analysis or reporting.

26. Common Exam Mistakes

Mistake 1: Confusing Purview Audit with Sentinel data retention

Purview audit records are governed by Microsoft Purview audit retention, not Microsoft Sentinel table-retention settings.

Mistake 2: Assuming Defender audit data is separate from Purview

Microsoft Defender XDR uses Microsoft Purview auditing.

Mistake 3: Choosing Global Administrator unnecessarily

Audit Logs or View-Only Audit Logs permissions are the more relevant concept for audit searches.

Mistake 4: Assuming every Defender action is audited

Only supported activities generate audit records.

Mistake 5: Forgetting retention

If an event is older than the organization’s applicable audit retention period, it may no longer be available.

Mistake 6: Confusing alerts with audit records

An alert identifies a security condition; an audit record documents a supported user or administrator action.

Mistake 7: Assuming audit search requires KQL

The Microsoft Purview/Defender Audit search experience is not the same as querying Sentinel tables with KQL.

27. SC-500 Exam-Focused Summary

Concept	What to remember
Microsoft Purview Audit	Records supported user/admin activities
Unified Audit Log	Central audit repository for supported Microsoft 365 activities
Defender XDR auditing	Uses Microsoft Purview auditing
Defender Audit page	Used to search audit activity
Main search filters	Date/time, activities, users
Audit Logs role	Provides audit-log access
View-Only Audit Logs	Read-oriented audit access
Global Administrator	Should not be selected unnecessarily
Audit (Standard)	Default retention is currently 180 days for newer audit records
Audit (Premium)	Provides enhanced audit capabilities and retention policies
Long-term retention	Requires appropriate licensing/configuration
Maximum documented retention	Up to 10 years with required licensing
PowerShell	`Search-UnifiedAuditLog`
Microsoft Graph	Audit Search Graph API
Export	CSV
AuditData	JSON containing additional event properties
Sentinel KQL	Different from Purview Audit search
Retention settings	Purview audit retention, not Sentinel table retention

28. Key Takeaways

The most important points for the SC-500 exam are:

Microsoft Defender XDR uses Microsoft Purview auditing.
The Audit page in Microsoft Defender can be used to search supported audit activities.
Searches can be narrowed by date/time, activities, and users.
Defender audit activities include operations such as device isolation, security-role changes, custom detection changes, indicator creation, and data-retention changes.
Audit searches require appropriate Audit Logs or View-Only Audit Logs permissions.
Microsoft recommends least privilege rather than automatically assigning Global Administrator.
Audit retention is controlled by Microsoft Purview audit-retention capabilities.
The current default Audit (Standard) retention period is 180 days for applicable newer audit records.
Audit (Premium) supports retention policies and can provide retention of up to 10 years when the required licensing is in place.
Audit searches can be performed through the portal and programmatically through PowerShell or Microsoft Graph.
Audit results can be exported to CSV, with additional event information available in the AuditData JSON property.
Purview Audit searches are different from KQL queries against Microsoft Sentinel data.
A missing audit event may be caused by permissions, incorrect filters, unsupported activity, or retention expiration.

Practice Exam Questions

Question 1

A security analyst needs to determine who isolated a device in Microsoft Defender XDR yesterday.

Where should the analyst begin the investigation?

A. Microsoft Defender portal Audit

B. Azure Policy

C. Microsoft Sentinel Data Lake

D. Azure Resource Graph

Answer: A

Explanation: Microsoft Defender XDR activities are audited through Microsoft Purview, and the Defender portal provides an Audit page where supported Defender activities can be searched.

Question 2

An investigator needs to search the Microsoft Purview audit log for activity performed by a specific administrator during a particular time period.

Which combination of search criteria is most appropriate?

A. KQL table, workspace, and analytic rule

B. Subscription, resource group, and Azure region

C. Date/time range, activities, and user

D. Device group, vulnerability, and exposure score

Answer: C

Explanation: Audit searches can be filtered using criteria such as the date/time range, activities, and users. These are the core filters an investigator uses to narrow audit activity.

Question 3

A security analyst needs to search Microsoft Defender XDR audit records but should not receive broad administrative privileges.

Which permission is most directly relevant?

A. Contributor

B. View-Only Audit Logs

C. Security Administrator

D. Global Administrator

Answer: B

Explanation: View-Only Audit Logs provides read-oriented access to audit information. The important SC-500 principle is to use the minimum permissions required rather than assigning Global Administrator unnecessarily.

Question 4

An organization needs to determine whether an administrator changed a Microsoft Defender data-retention setting.

Which Microsoft Defender/Purview capability should be used?

A. Microsoft Defender Vulnerability Management

B. Microsoft Sentinel analytics rules

C. Microsoft Purview Audit

D. Azure Resource Locks

Answer: C

Explanation: Changes to data-retention settings are among the types of Microsoft Defender activities that can be audited. The audit record can be searched through the Defender Audit experience.

Question 5

An investigator wants to search the unified audit log programmatically rather than through the Microsoft Defender portal.

Which PowerShell cmdlet is specifically designed for this purpose?

A. Get-MgUser

B. Get-AzActivityLog

C. Get-MgAuditLogDirectoryAudit

D. Search-UnifiedAuditLog

Answer: D

Explanation: Search-UnifiedAuditLog is the Exchange Online PowerShell cmdlet used to search Microsoft Purview unified audit-log events.

Question 6

A security team discovers that an administrative action occurred 14 months ago. The organization has not configured extended audit retention and is using the standard audit-retention period.

What should the investigator consider first?

A. The audit record may no longer be available because it is outside the applicable retention period.

B. Microsoft Sentinel automatically retrieves the missing audit event.

C. Defender XDR automatically converts the event into an alert.

D. The event must be available indefinitely because it is an administrative action.

Answer: A

Explanation: The current default Audit (Standard) retention period for applicable newer audit records is 180 days. Historical availability depends on the organization’s retention configuration and licensing.

Question 7

An organization has a compliance requirement to retain applicable audit records for several years.

Which capability should the organization investigate?

A. Azure resource locks

B. Microsoft Purview audit-log retention policies with appropriate licensing

C. Microsoft Sentinel automation rules

D. Microsoft Defender Vulnerability Management

Answer: B

Explanation: Microsoft Purview Audit (Premium) supports audit-log retention policies, including long-term retention. Longer retention periods require appropriate licensing.

Question 8

A security analyst searches Microsoft Defender XDR Audit and cannot find an expected event.

Which of the following is a valid reason the event might not appear?

A. Microsoft Defender audit records are never retained.

B. Audit records can only be queried with KQL.

C. The activity may not be a supported audited activity.

D. Audit records are stored only in Azure Resource Manager.

Answer: C

Explanation: Not every action performed in a Microsoft service is necessarily an audited activity. Investigators should verify that the activity is supported, as well as checking permissions, time range, user filters, and retention.

Question 9

A security engineer exports Microsoft Purview audit search results to CSV and wants to examine additional event properties contained within each record.

Which exported field contains additional event information formatted as JSON?

A. AuditData

B. ResourceGroup

C. IncidentData

D. SecurityData

Answer: A

Explanation: The exported audit results include an AuditData column containing additional event information in JSON format. The JSON can be transformed for easier analysis.

Question 10

An investigator is trying to determine whether a user changed a Defender security role immediately before a security incident.

Which approach provides the most appropriate combination of evidence?

A. Search Azure Policy compliance results only.

B. Review the Azure Activity Log only.

C. Search Microsoft Purview Audit for the relevant Defender activity and correlate the result with other security telemetry.

D. Query Azure Resource Graph for the user’s mailbox activity.

Answer: C

Explanation: Defender administrative actions are audited through Microsoft Purview. Searching the relevant audit activity can identify the administrative action and user, while correlating it with Defender, identity, endpoint, or Sentinel telemetry can help reconstruct the incident timeline.

Final Exam Reminder

When an SC-500 question asks you to investigate who performed an administrative or user action in Microsoft Defender XDR or Microsoft 365, think:

			
Microsoft Defender XDR activity
             |
             v
    Microsoft Purview Audit
             |
             v
       Audit search
             |
      +------+------+
      |      |      |
    Time  Activity  User
             |
             v
       Audit record
             |
             v
      Correlate with
     security telemetry

		

The central concept to remember is:

Microsoft Defender XDR uses Microsoft Purview auditing to record supported user and administrator activities, and those activities can be searched from the Defender portal’s Audit experience.

For the exam, keep the following distinctions especially clear:

Purview Audit → audited activities

Microsoft Sentinel → security data and KQL-based analysis

Defender XDR Audit → Defender activities recorded through Purview auditing

Audit retention → governed by Microsoft Purview audit-retention capabilities

Long-term audit retention → requires the appropriate Purview licensing and retention configuration

Go to the SC-500 Exam Prep Hub main page

azure, Cloud computing, Cybersecurity, Microsoft Certification, SC-500, security 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

azure, Cloud computing, Microsoft Certification, SC-500, security 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

azure, Cloud computing, Microsoft Certification, SC-500, security 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