Security automation and orchestration (SOAR) takes the repetitive, error-prone manual work of responding to cyber threats and makes it fast, consistent, and machine-driven. For the SC-100 exam, you need to understand how Microsoft tools like Microsoft Sentinel and Microsoft Defender for Cloud can automatically contain a breach while simultaneously orchestrating a coordinated response across your entire IT environment, reducing a potential multi-hour crisis to seconds.
Jump to a section
A simple way to picture Security Automation and Orchestration with Microsoft Tools
30 minutes before the morning rush, the head baker at 'The Daily Loaf' must hand off the bakery to the afternoon manager. Manually, this takes 45 minutes: the head baker writes down which doughs are proofed, which ovens are preheated, which deliveries are late, and who called in sick. The afternoon manager then re-types the list, checks the walk-in cooler herself, and adjusts the oven timers by hand. One missed note means burnt croissants.
Then the bakery installs a 'Bakery Orchestrator' system. Now, the head baker presses a tablet button labelled 'End Shift'. The system automatically logs that the sourdough starter is at 78% activity, the deck oven is at 220°C, and the delivery truck is 12 minutes out. It emails the allergens report to the afternoon manager, resets the timer on the proofing cabinet for the next batch, and locks the retail till. The handover takes 3 minutes. If the cooler temperature rises above 4°C, the system automatically texts the manager and turns on the backup compressor, without anyone lifting a finger.
This is security automation and orchestration. Automation does the single, repetitive jobs – like sending that alert text. Orchestration ties all the separate jobs together into one smooth, repeatable process – like the shift handover flow. Microsoft's security tools do the same for your company's digital bakery: they detect a security problem, automatically quarantine the infected computer, and then orchestrate a full incident response playbook that notifies your team, blocks the attacker's IP, and saves forensic logs – all without a human typing a single command.
Security automation and orchestration (often shortened to SOAR, which stands for Security Orchestration, Automation, and Response) is a set of technologies that helps security teams respond to threats without having to click through dozens of screens or type complex commands every time an alarm goes off. Think of it as a recipe for handling a security incident. The recipe lists the ingredients (the data from different tools), the steps (what to do – quarantine a file, block an IP address, notify the team), and the order in which to perform them.
First, let's define the two key parts separately.
Automation means making a single, repetitive task happen automatically. For example, if Microsoft Defender for Endpoint detects a suspicious file on a computer, an automation rule could instantly isolate that computer from the rest of the network. No human needs to sit and watch the alert queue. The machine does the one job on its own.
Orchestration goes a step further. It connects multiple automated tasks together into a complete workflow, or 'playbook'. A playbook is like a step-by-step instruction manual that a computer can follow. In Microsoft Sentinel, a playbook might do this:
Step 1: Receive an alert from Microsoft Entra ID (the identity service that manages user logins) that a user account is signing in from an unusual location.
Step 2: Check the user's risk score using Microsoft Entra ID Protection.
Step 3: If the risk score is high, automatically disable the user's account.
Step 4: Open a ticket in ServiceNow (a helpdesk system) to notify the IT team.
Step 5: Send a push notification to the user's phone asking them to verify their identity.
Each step is an automation. But the playbook that connects them all in the right order is orchestration.
Why does this exist? Because security teams are overwhelmed. A typical company might get thousands of security alerts per day. No human can read all of them. Before automation, analysts would manually sort through alerts, investigate each one, and decide what to do. This took hours or days. Attackers move in minutes. Automation and orchestration close that gap by letting computers handle the initial triage – deciding which alerts are genuine threats and which are false alarms.
What does this replace? It replaces the manual, human-driven 'swivel chair' approach, where an analyst would look at one screen, then physically turn to another screen (the 'swivel chair' motion), copy data, and type commands. Orchestration tools like Microsoft Sentinel's Logic Apps connector allow all those systems to talk to each other automatically.
On the SC-100 exam, you will encounter scenarios where you must design a solution that uses automation to reduce the 'mean time to respond' (MTTR) – the average time it takes to stop an attack. You will also need to know that orchestration enforces consistency: a playbook always follows the same steps, which satisfies compliance requirements and prevents human error.
A key term here is 'playbook'. Microsoft Sentinel uses Azure Logic Apps to run playbooks. Azure Logic Apps is a 'low-code' or 'no-code' platform, meaning you can build these workflows by dragging and dropping boxes on a visual canvas, rather than writing extensive code. This makes it accessible to security analysts who are not professional programmers.
Another crucial point: automation and orchestration must be 'context-aware'. A playbook that blocks every IP address from a high-risk country might accidentally block a legitimate customer. So Microsoft tools integrate with threat intelligence feeds (lists of known malicious IPs and domains) to make smarter decisions. They also integrate with identity systems (Microsoft Entra ID) and endpoint protection (Microsoft Defender for Endpoint) to gather full context before acting.
In summary, security automation and orchestration turns chaotic, manual incident response into a predictable, machine-driven process. It saves time, reduces errors, and allows a small security team to protect a large organisation effectively. For your exam, remember: automation does the individual tasks, orchestration ties them together into a playbook, and the goal is speed and consistency.
Identify the Trigger
Every automated security response starts with a trigger. In Microsoft Sentinel, a trigger can be an alert (a single suspicious event) or an incident (a group of related alerts). You must decide what event should start the playbook. For example, an alert for a successful sign-in from an impossible travel location. This step matters because choosing the wrong trigger will either flood your team with false positives or miss critical events.
Enrich the Alert with Context Data
Before taking any action, the playbook gathers more information. It queries Microsoft Entra ID for the user's role, recent sign-in history, and risk score. It also queries threat intelligence feeds to see if the attacker's IP is known to be malicious. This step is critical because acting without context can cause legitimate users to be blocked accidentally.
Apply Conditional Logic to Decide Action
The playbook uses 'if-then-else' logic to decide what to do based on the enriched data. For example: 'If the user's risk score is high AND the user is in the finance department, then disable the account and isolate the device. Else, if the risk score is medium, just notify the user to reset their password.' This step ensures that the response is proportional to the threat, avoiding over-reaction.
Execute Automated Containment Actions
Based on the decision, the playbook performs the chosen actions. This could include disabling the user account via the Microsoft Graph API, isolating the endpoint using Microsoft Defender for Endpoint, or blocking the attacker's IP on the firewall via a connector. These actions happen in parallel or sequentially, orchestrated by the playbook design. This is where the actual threat is stopped.
Notify and Document the Incident
After containment, the playbook sends notifications: a Microsoft Teams message to the security team, an SMS to the incident manager, and an email to the affected user. It also creates a ticket in the IT service management tool (like ServiceNow) containing all the enrichment data and actions taken. This step ensures the human team is aware and can follow up, and it creates an audit trail for compliance.
Monitor and Adjust the Playbook
This is not a one-time step but an ongoing process. The IT professional reviews the playbook's execution logs to see if any steps failed, if the playbook caused false positives (like blocking a legitimate user), or if the conditions need tuning. Playbooks must be updated as the organisation's environment or threat landscape changes. This step ensures the automation remains effective over time.
Consider 'GlobalTech Retail', a company with 5,000 employees spread across three continents. They sell electronics online and have a security team of just four people. Every night, the team used to take turns manually reviewing logs from their firewalls, email gateways, and cloud servers. One night, a phishing email tricks an accountant in the London office into entering their password on a fake link. The attacker now has that accountant's credentials.
Manually, the process would look like this:
An alert pops up on Microsoft 365 Defender saying 'A user reported a suspicious link in a recent email.'
The on-call analyst opens the alert but is distracted by a second alert. They investigate the first one 20 minutes later.
They find the accountant's account is logging in from an unknown IP in Nigeria. They must manually log into Microsoft Entra ID to disable the account.
Then they must go to Microsoft Defender for Endpoint to isolate that accountant's computer.
Then they must write an email to the IT director explaining the incident. This whole process takes 55 minutes.
With Microsoft Sentinel orchestration, the same event triggers a playbook. Here is exactly what happens, step by step:
Detection: Microsoft 365 Defender detects the compromised credentials and sends a high-severity alert to Microsoft Sentinel. This is the automation of detection.
Enrichment (first automation): The Sentinel playbook automatically queries Microsoft Entra ID to get the user's role, recent sign-in locations, and the device ID of the computer they last used.
Decision (orchestration logic): The playbook checks a condition: 'Is the user's role 'Finance' or 'Executive'? Yes. Is the sign-in location outside the company's home countries? Yes.' The condition is met, so the playbook proceeds to containment.
Containment (multiple automations tied together):
The playbook runs a command to disable the user account in Microsoft Entra ID.
It runs a second command to force the user's device to be isolated in Microsoft Defender for Endpoint.
It creates a high-priority ticket in the company's IT service management tool (like ServiceNow) with all the evidence.
Notification (final automation): The playbook sends a Microsoft Teams message to the security team channel and an SMS text to the IT director's phone. It also sends an email to the affected user telling them their account has been temporarily blocked and to contact IT.
Total time elapsed: approximately 45 seconds. The attack is contained before the attacker can exfiltrate any customer data or initiate a ransomware attack.
What the IT professional does here is not type commands. They design, test, and maintain these playbooks. They use the 'Azure Logic Apps' designer in Sentinel to create the workflow. They also set up connectors to other tools – for example, a connector to Microsoft Graph API (the unified API for Microsoft services) to disable user accounts, a connector to Microsoft Entra ID to read sign-in logs, and a connector to an external threat intelligence platform to check if the attacker's IP is known as malicious.
Furthermore, the IT professional must test the playbook regularly. They might simulate a phishing attack to ensure the playbook fires correctly. They also monitor the playbook's execution logs to see if any steps failed. Optimising the playbook's logic is a continuous task, because real-world attackers adapt their methods.
Finally, the IT professional must document the playbook for compliance auditors. Regulators like to see that security responses are 'repeatable and consistent', not dependent on which human analyst happened to be on duty. The playbook provides that proof.
The SC-100 exam tests your ability to design, not just recall. You will be asked to select the correct combination of Microsoft tools to automate a security process or orchestrate a response. The exam objective 'Design solutions for security automation and orchestration' specifically wants you to know when to use Microsoft Sentinel, Microsoft Defender for Cloud, and Azure Logic Apps together.
Here are the exact concepts and trap patterns you must master:
Core exam topics:
Playbooks: You must know that Microsoft Sentinel playbooks are built on Azure Logic Apps. A common exam question asks: 'Which Azure service should you use to automatically respond to a Sentinel incident?' The answer is Azure Logic Apps (or Logic Apps connector). Trap: some candidates choose Azure Functions (which is for custom code), but Logic Apps is the correct low-code orchestration engine for Sentinel.
Automation rules: These are simpler than playbooks. Automation rules in Sentinel trigger on alert or incident creation and can perform basic actions like assign severity or assign an owner. They are for simple, linear responses without complex branching logic. The exam may ask you to differentiate between when to use an automation rule (simple) versus a playbook (complex branching).
Connectors: Microsoft security tools connect to hundreds of third-party products via 'data connectors'. For orchestration to work, the connector must exist. The exam expects you to know that if a connector is not available, you might need to use a webhook or an API call. A trap question might describe a desired integration and ask 'Which component is missing?' and the answer will be a specific connector.
Microsoft Defender for Cloud automation: This is separate from Sentinel. Defender for Cloud automates responses to cloud security misconfigurations (like an open storage container or an unpatched VM). It uses 'Workflow automation' triggers, which also integrate with Logic Apps. The exam may ask you to choose between using Sentinel playbooks for incident response versus Defender for Cloud automation for compliance and posture management.
Conditional logic in playbooks: You will be tested on the ability to design a playbook that checks conditions (e.g., 'if the user is in the HR department, skip blocking and just notify'). The exam presents a scenario with many variables, and you must select the design that correctly uses conditions and parallel actions.
Common traps:
Trap 1: Confusing automation with orchestration. A question might describe a scenario where a single action (e.g., restarting a server) happens automatically. The correct answer is 'automation'. But if the scenario involves multiple coordinated actions (restart server, notify team, log to database), the answer is 'orchestration'.
Trap 2: Overcomplicating the solution. Sometimes the simplest answer is 'an automation rule', not a full playbook. The exam loves to test whether you can identify when a simple rule suffices versus when a complex playbook is needed.
Trap 3: Forgetting about licensing. Some automation capabilities require specific licenses (e.g., Microsoft Sentinel costs extra, Logic Apps has consumption costs). The exam may include a scenario with budget limitations, forcing you to choose a cheaper automation method (like Defender for Cloud's built-in automation) over Sentinel.
Trap 4: Assuming all actions happen instantly. The exam may test your understanding that playbook actions can be asynchronous or require manual approval steps. A well-designed playbook might pause and wait for a human to approve before continuing, especially for destructive actions like deleting a user account.
Key definitions to memorise for SC-100: - 'Mean Time to Respond' (MTTR): The average time from detection to containment. Automation and orchestration directly reduce MTTR. - 'Playbook': A collection of automated steps (run on Logic Apps) that respond to a Sentinel incident. - 'Automation Rule': A simple, single-trigger rule in Sentinel that performs basic actions (changing status, assigning owner, running a playbook). - 'Workflow automation' (in Defender for Cloud): Automated responses to cloud security findings. - 'Incident' (in Sentinel): A group of related alerts that a security team investigates. Playbooks run on incidents, not individual alerts (though they can run on alerts too). - 'Connector': The bridge between a data source (like a firewall) and Microsoft Sentinel or Defender for Cloud.
When you see a question asking 'which Microsoft tool should be used to design a multi-step response that includes user approval, IP blocking, and ticket creation?', your answer is a Sentinel playbook using Azure Logic Apps. Never choose a single action tool for a multi-step scenario.
Automation handles a single repetitive task; orchestration coordinates multiple automated tasks into a unified playbook workflow.
Microsoft Sentinel playbooks are built on Azure Logic Apps, not on custom code or Azure Functions, by default.
Automation rules in Sentinel are for simple actions like changing severity, while playbooks are for complex, multi-step incident response.
The primary goal of security automation and orchestration is to reduce the Mean Time to Respond (MTTR) from hours to seconds.
Playbooks can include conditional logic, human approval steps, and integrations with hundreds of third-party tools via connectors.
Microsoft Defender for Cloud's 'Workflow automation' is for automating responses to cloud security misconfigurations, separate from Sentinel incident playbooks.
Orchestration enforces consistency and compliance by ensuring every incident is handled with the same, approved playbook.
A well-designed playbook must be context-aware, using threat intelligence and identity risk scores before taking destructive actions.
These come up on the exam all the time. Here's how to tell them apart.
Automation
Handles a single, repetitive task (e.g., blocking an IP address).
Does not connect different tools together; works in isolation.
Can be implemented using a simple automation rule or a single action in a playbook.
Orchestration
Coordinates multiple automated tasks into a complete workflow (e.g., block IP, disable user, notify team).
Ties together different tools and systems (Sentinel, Entra ID, Defender, ServiceNow).
Requires a playbook (Logic Apps) with conditional logic and sequential/parallel steps.
Automation Rule (Sentinel)
Triggers on alert or incident creation with simple conditions (e.g., severity = High).
Can only perform basic actions: change status, assign owner, or run a single playbook.
No branching logic or approval steps; linear execution.
Playbook (Sentinel/Logic Apps)
Triggers via an automation rule, not directly from an alert.
Can perform unlimited actions: query databases, call APIs, send emails, wait for approval.
Supports if-then-else branching, loops, parallel tasks, and error handling.
Microsoft Sentinel Playbooks
Used for incident response to security threats (e.g., malware, phishing).
Triggers on Sentinel incidents and alerts.
Integrated with hundreds of connectors for external tools.
Microsoft Defender for Cloud Workflow Automation
Used for automating responses to cloud security misconfigurations (e.g., open network ports).
Triggers on Defender for Cloud security recommendations and findings.
Primarily focused on Azure resource remediation (e.g., apply resource locks, enable encryption).
Automated Response (No Human Input)
Actions are executed immediately upon triggering without any pause.
Best for low-risk, time-critical actions like blocking a known malicious IP.
Risk of false positive causing disruption if criteria are too broad.
Automated Response with Human Approval
Playbook pauses at an approval step and waits for a human to approve or reject the action.
Best for high-risk, irreversible actions like deleting a user account or shutting down a server.
Reduces risk of accidental damage but increases MTTR.
Mistake
Automation and orchestration are the same thing; you can use the words interchangeably.
Correct
Automation handles a single repetitive task (like blocking an IP), while orchestration coordinates multiple automated tasks into a cohesive workflow (like a playbook). They are distinct but related concepts.
Sales and marketing material often use them together as a single buzzword ('SOAR'), leading beginners to believe they are synonyms. In the exam, the distinction matters.
Mistake
Azure Logic Apps is only for IT system integration, not security. I should use custom code in Azure Functions for security playbooks.
Correct
Azure Logic Apps is the officially recommended and designed method for building security playbooks in Microsoft Sentinel. It is low-code, has native connectors to security tools, and is easier to audit. Azure Functions is for custom, complex logic but is not the default choice.
Many beginners with a software background assume 'real' automation must involve writing code. They overlook the powerful, security-specific capabilities of Logic Apps.
Mistake
Once I set up a playbook in Sentinel, it automatically runs on all alerts forever without any maintenance.
Correct
Playbooks require ongoing maintenance: testing after updates to integrated systems, tuning thresholds to reduce false positives, and monitoring execution logs for failures. They are not 'set and forget'.
Vendors market automation as a 'solution' to understaffed teams, creating the false impression that it is maintenance-free. Real-world IT professionals know any automated process degrades without care.
Mistake
Automation and orchestration in Microsoft tools can replace the need for human security analysts entirely.
Correct
Automation and orchestration handle repetitive, high-volume tasks (triage, containment, notification), but complex incidents (novel attacks, policy decisions, legal holds) still require human judgment. The goal is to augment humans, not replace them.
Beginners fear that automation means job loss, or they overestimate AI's capability. The exam reinforces that the human analyst remains in the loop for decision-making.
Mistake
If I have automation rules in Microsoft Sentinel, I do not need playbooks.
Correct
Automation rules are for simple, linear responses (e.g., assign severity). Playbooks are for complex, multi-step workflows with branching logic, integrations, and approvals. Both are needed, depending on the scenario.
The names 'automation rule' and 'playbook' sound similar, and beginners think one is a replacement for the other. The exam tests knowing which to use when.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Microsoft Sentinel is a Security Information and Event Management (SIEM) tool that handles incident response and uses playbooks (Logic Apps) for orchestration. Microsoft Defender for Cloud is a Cloud Security Posture Management (CSPM) tool that automates responses to cloud misconfigurations (like open storage) using 'Workflow automation'. They serve different purposes: Sentinel for threats, Defender for Cloud for posture.
No. Sentinel playbooks are built using Azure Logic Apps, which is a low-code/no-code platform. You design the playbook by dragging and dropping actions onto a visual designer. You do not need to write code for most connectors, although custom code is possible via Azure Functions if needed.
You create an 'automation rule' in Sentinel that listens for a specific alert or incident condition (e.g., alert name contains 'ransomware' or severity is 'high'). The automation rule then runs your playbook. The playbook itself does not directly listen for triggers; the automation rule acts as the bridge.
Yes. Azure Logic Apps supports 'approval' steps. For example, the playbook can send an approval request email to a security manager and pause. Only when the manager clicks 'Approve' does the playbook proceed to actions like deleting a user account or shutting down a server.
Logic Apps provides detailed execution logs showing which step failed and why. You can configure the playbook with error-handling steps, such as sending a notification to the team if a failure occurs. No automated action is taken if the playbook fails partway through, so the incident remains open in Sentinel for manual review.
Yes. Microsoft Sentinel has its own cost (based on data ingestion), and Azure Logic Apps has a consumption cost per execution. Microsoft Defender for Cloud's basic automation capabilities are included with the licence, but advanced workflow automation may require additional Azure credits. Always check the latest pricing on the Microsoft pricing page.
You've finished Security Automation and Orchestration with Microsoft Tools. Continue through the SC-100 study guide to build a complete picture of the exam.
Done with this chapter?