Study guide
Technical reference and lesson notes
Purpose of This Lesson
Microsoft Sentinel playbooks are Azure Logic Apps, so their native automation is primarily designed to work with cloud services and connectors. To execute actions on on-premises servers or other local resources, a playbook must use an Azure Automation runbook together with a Hybrid Runbook Worker.
This pattern gives a SOC team a controlled bridge between cloud-based incident response and local operational actions such as running PowerShell, collecting a file, restarting a server, or performing an approved on-premises identity action.
Key Concepts
Sentinel playbooks and Azure Automation runbooks
A Sentinel playbook is a Logic App that can be triggered by an incident, alert, or other supported event. When the playbook needs to perform work in an environment that is not directly reachable through a cloud connector, it can invoke an Azure Automation runbook.
The runbook defines the automation procedure. The Hybrid Runbook Worker executes that procedure on a designated Windows or Linux machine rather than in Azure itself.
Hybrid Runbook Worker
A Hybrid Runbook Worker is an extension installed on a supported Windows or Linux server. It allows an Azure Automation account to execute runbooks on that machine or within its local environment.
The worker can run on different types of infrastructure, including:
- On-premises Windows or Linux servers
- Azure Arc-enabled servers
- Arc-enabled physical servers
- Arc-enabled VMware virtual machines
- Azure virtual machines configured as workers
Worker groups
Workers are organized into Hybrid Runbook Worker groups. The Azure Automation account targets the group, not a manually selected individual worker.
A group may contain one worker or multiple workers. Multiple workers support:
- High availability
- Load distribution
- Redundancy if a worker fails
- Separation of operational functions, such as production, testing, Windows administration, or Linux automation
Polling and availability behavior
Workers use a polling model. They periodically check Azure Automation for work rather than Azure pushing a job directly to a particular worker. The lecture identifies a polling interval of approximately 30 seconds.
If no worker in a group checks in for about 30 minutes, Azure considers the group inactive. Jobs can eventually become suspended after retry attempts, so worker connectivity and health must be monitored.
Network connectivity
The worker communicates with Azure Automation over HTTPS using port 443. This outbound connectivity model is important for environments that do not permit unsolicited inbound connections from Azure into the local network.
Microsoft Security Operations Context
A common response workflow is:
- An alert or incident is created in Microsoft Sentinel.
- A Sentinel playbook is triggered.
- The playbook calls an Azure Automation runbook.
- The runbook is assigned to a Hybrid Runbook Worker group.
- An available worker polls Azure Automation, retrieves the job, and executes it locally.
- The result is returned to the automation workflow for logging, notification, or additional response actions.
Examples of suitable local actions include:
- Running an approved PowerShell script on a server
- Collecting a file or other evidence from a local system
- Restarting a virtual machine as part of a controlled response
- Performing a local administrative task that cannot be completed through a cloud connector
This architecture separates the cloud orchestration layer from the execution environment. Sentinel and the playbook coordinate the response, while the worker performs the action where the required local access exists.
Exam-Relevant Takeaways
- A Sentinel playbook is an Azure Logic App.
- A playbook cannot automatically execute arbitrary on-premises commands merely because it was triggered by Sentinel.
- Use an Azure Automation account and a Hybrid Runbook Worker when a playbook must perform work on local infrastructure.
- The worker extension can be installed on Windows or Linux systems.
- Workers are placed in a Hybrid Runbook Worker group.
- The Automation account targets the worker group; the analyst does not normally select the individual machine for each job.
- Multiple workers in one group provide redundancy and load balancing.
- Workers poll Azure Automation rather than receiving pushed jobs.
- The relevant connectivity is HTTPS over port
443. - A group that stops checking in for approximately 30 minutes is treated as inactive, and queued jobs may eventually be suspended after retries.
Tool / Feature Decision Guide
| Requirement | Appropriate component | Reason |
|---|---|---|
| Orchestrate a response to a Sentinel incident | Sentinel playbook | Playbooks are Logic Apps designed to coordinate response workflows. |
| Define a script or procedure to run | Azure Automation runbook | The runbook contains the executable automation logic. |
| Execute that runbook on an on-premises Windows or Linux host | Hybrid Runbook Worker | The worker provides the local execution point. |
| Provide redundancy for local automation | Multiple workers in one worker group | Jobs can be handled by available workers in the group. |
| Organize workers by function or environment | Separate worker groups | Groups can be used for production, testing, operating system, or workload separation. |
| Permit the worker to communicate with Azure Automation | Outbound HTTPS over port 443 | Workers poll Azure Automation through the HTTPS connection. |
Common Exam Traps
- Confusing a playbook with a worker: The playbook orchestrates the response; the Hybrid Runbook Worker executes the runbook locally.
- Assuming a playbook runs directly on a local server: The required chain is playbook → Azure Automation runbook → Hybrid Runbook Worker.
- Selecting an individual worker manually: Automation is directed to a worker group, and the group handles worker availability.
- Choosing inbound firewall access: The described worker communication uses HTTPS on port
443and a polling model, not an Azure push connection. - Ignoring worker health: A configured group is not necessarily operational. If workers stop checking in, jobs can become suspended.
- Treating one worker as highly available: A one-worker group has no worker-level redundancy. Multiple workers are needed for fault tolerance.
Real-World SOC Analyst Notes
On-premises automation can have significant blast radius. A playbook that disables accounts, restarts servers, or runs scripts should use strict scoping, approvals where appropriate, and clear failure handling.
Before enabling automated response, validate:
- The runbook performs only the intended action.
- The worker has the minimum permissions required.
- The selected worker group contains the correct production or test systems.
- Credentials, secrets, and script inputs are protected.
- Actions and outputs are logged for investigation and audit purposes.
- The response does not destroy evidence needed for forensic analysis.
- Change control and server-owner coordination requirements are satisfied.
Use separate worker groups for testing and production when practical. Monitor worker check-ins and job failures, and document whether a failed job should be retried, escalated, or handled manually.
Quick Reference Summary
Sentinel incident or alert
|
v
Sentinel playbook (Azure Logic App)
|
v
Azure Automation runbook
|
v
Hybrid Runbook Worker group
|
v
Windows or Linux worker executes the local action
Remember the core mapping: playbook = orchestration, runbook = automation procedure, and Hybrid Runbook Worker = local execution point. Workers communicate with Azure Automation by polling over HTTPS port 443.
Flashcards
Q: A Sentinel playbook must run a PowerShell script on an on-premises server. Which components are required?
A: Use an Azure Automation runbook and a Hybrid Runbook Worker associated with an Automation account. The playbook orchestrates the call, while the worker executes the runbook locally.
Q: What is the decisive difference between a Sentinel playbook and a Hybrid Runbook Worker?
A: The playbook is the Azure Logic App that coordinates the response. The Hybrid Runbook Worker is the Windows or Linux execution host for the runbook.
Q: When should a Sentinel response use an Azure Automation runbook instead of only cloud connectors?
A: Use a runbook when the response must perform an action inside an on-premises or otherwise locally managed environment, such as running a script or collecting a local file.
Q: What does the Azure Automation account connect to when using Hybrid Runbook Workers?
A: It connects to a Hybrid Runbook Worker group. The group provides the pool of workers that can execute assigned jobs.
Q: Why would a SOC deploy multiple workers in one Hybrid Runbook Worker group?
A: Multiple workers provide load distribution and redundancy. If one worker fails, another worker in the group can handle work, subject to availability and configuration.
Q: Can an Automation job normally be assigned to a specific individual worker in the group for each execution?
A: The group is the target, not a manually selected individual worker. Available workers in the group poll for and process jobs.
Q: Do Hybrid Runbook Workers receive pushed jobs from Azure Automation?
A: No. They use a polling model, checking Azure Automation for work at approximately 30-second intervals.
Q: Which network port is associated with the worker’s communication with Azure Automation in this lesson?
A: HTTPS over port 443. The worker uses this connection to poll Azure Automation.
Q: What does it indicate if no worker in a group checks in for about 30 minutes?
A: Azure considers the group inactive. Jobs may eventually be suspended after retry attempts, so worker connectivity must be investigated.
Q: A group contains only one worker. What availability limitation does this create?
A: The group has no worker-level redundancy. If that worker fails or becomes unreachable, jobs may not execute until the issue is resolved.
Q: How can worker groups help separate operational risk?
A: Organizations can create distinct groups for environments or functions such as production, testing, Windows operations, or Linux automation. This helps target automation to the intended execution pool.
Q: Which part of the architecture actually performs a local server action?
A: The Hybrid Runbook Worker executes the Azure Automation runbook on the local or Arc-enabled machine.
Practice Questions
Question 1
A Sentinel incident playbook must collect a file from an on-premises server. The action is not available through a suitable cloud connector. What should the analyst implement?
A. Add another Sentinel analytics rule
B. Use an Azure Automation runbook with a Hybrid Runbook Worker
C. Create a workbook and map the server as an entity
D. Add the server to a Sentinel watchlist
Correct answer: B
The playbook needs a local execution point. An Azure Automation runbook executed by a Hybrid Runbook Worker can perform the file-collection action on the on-premises server.
Question 2
A company wants its local response automation to continue operating if one worker server fails. Which design best meets the requirement?
A. Create multiple playbooks with the same trigger
B. Install multiple workers in the same Hybrid Runbook Worker group
C. Use multiple Azure Automation accounts without workers
D. Configure the playbook to select a different server manually for every job
Correct answer: B
Multiple workers in one group provide redundancy and allow work to be handled by another available worker. The Automation account targets the group rather than requiring per-job manual server selection.
Question 3
A firewall team asks whether Azure must initiate inbound connections to the on-premises worker to deliver runbook jobs. What is the best response based on this architecture?
A. Yes, inbound TCP access is required from Azure to every worker
B. No, workers poll Azure Automation over HTTPS port 443
C. No network connection is required after the worker extension is installed
D. Yes, but only port 3389 is required
Correct answer: B
Workers use a polling model and check Azure Automation for jobs over HTTPS on port 443; the described design does not rely on Azure pushing jobs directly to the worker.
Question 4
A runbook remains queued, and monitoring shows that no worker in its assigned group has checked in for 35 minutes. What is the most likely explanation?
A. The Sentinel incident lacks entity mapping
B. The worker group is considered inactive
C. The playbook has become an analytics rule
D. The runbook can execute only on a Windows worker
Correct answer: B
A group with no worker check-in for approximately 30 minutes is treated as inactive. Jobs can eventually be suspended after retry attempts, so worker health and connectivity should be checked.
Question 5
An analyst needs to run a local administrative script but mistakenly tries to place the script directly in the Sentinel playbook without configuring local execution. What is the primary design issue?
A. Sentinel playbooks are Logic Apps and do not, by themselves, provide arbitrary on-premises execution
B. Sentinel cannot trigger automation from an incident
C. Azure Automation runbooks can execute only KQL queries
D. Hybrid workers are used only for workbooks
Correct answer: A
The playbook provides cloud-based orchestration. To execute the script in the local environment, the workflow must call an Azure Automation runbook assigned to a Hybrid Runbook Worker group.