Hands-on Lab — SC-200 Microsoft Security Operations Analyst

Overview

Prerequisites

Steps

1. 1.Provider, Resource Group, naming

   Standard Azure opener.

   Copy

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
     }
   }
   
   provider "azurerm" {
     features {}
   }
   
   locals {
     tags = {
       Project   = "certlabpro-sc-200"
       ManagedBy = "terraform"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-sc-200-rg"
     location = "eastus"
     tags     = local.tags
   }

2. 2.Stand up the Log Analytics workspace + onboard Sentinel

   Provisions:

   • Azure Monitor
   • Microsoft Sentinel

   Microsoft Sentinel is a layer on top of a Log Analytics workspace — it doesn't have its own data plane. SC-200's Manage a Microsoft Sentinel environment domain hammers on this dependency: every Sentinel feature reads/writes from the workspace, every data connector lands data into it, every analytic rule runs KQL against it.

   We provision the workspace at PerGB2018 SKU + the azurerm_sentinel_log_analytics_workspace_onboarding resource to attach Sentinel. After this, you'd connect data sources (Azure Activity, Microsoft Entra ID sign-ins, Defender XDR connectors) via the portal — they're surface-area-heavy and easier through the GUI than Terraform.

   Copy

   resource "azurerm_log_analytics_workspace" "main" {
     name                = "log-sc200"
     resource_group_name = azurerm_resource_group.main.name
     location            = azurerm_resource_group.main.location
     sku                 = "PerGB2018"
     retention_in_days   = 30
   
     tags = local.tags
   }
   
   resource "azurerm_sentinel_log_analytics_workspace_onboarding" "main" {
     workspace_id = azurerm_log_analytics_workspace.main.id
   }

3. 3.Create a scheduled analytic rule that triggers on a KQL pattern

   Provisions:

   • Microsoft Sentinel

   Analytic rules are how Sentinel turns raw log events into incidents. SC-200 tests rule-type recognition: Scheduled (KQL-based, the most common), Microsoft incident (forwards Defender XDR alerts), Anomaly (ML-based), Threat intelligence (TI matching).

   We create a scheduled rule with a stub KQL query (every 5 minutes, looking back 5 minutes — the SC-200 near-real-time shape). The query here is a placeholder (SecurityEvent | take 1); in production the KQL is the rule's actual logic — testing for impossible-travel logins, password-spray patterns, unusual privilege escalations, etc.

   The tactics field maps the rule to the MITRE ATT&CK framework — required for Defender XDR integration and for hunting workflows that pivot by tactic.

   Copy

   resource "azurerm_sentinel_alert_rule_scheduled" "stub" {
     name                       = "certlabpro-sc-200-stub-rule"
     log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
     display_name               = "Stub rule — lab demonstration"
     description                = "Sample scheduled analytic rule for the SC-200 lab. Replace KQL with a real hunting pattern."
     severity                   = "Medium"
     enabled                    = true
   
     query                      = "SecurityEvent | take 1"
     query_frequency            = "PT5M" # run every 5 minutes
     query_period               = "PT5M" # look back 5 minutes
   
     trigger_operator           = "GreaterThan"
     trigger_threshold          = 0
   
     tactics    = ["InitialAccess"]
     techniques = ["T1078"] # Valid Accounts (MITRE ATT&CK)
   
     incident {
       create_incident_enabled = true
   
       grouping {
         enabled = true
       }
     }
   
     depends_on = [azurerm_sentinel_log_analytics_workspace_onboarding.main]
   }

4. 4.Wire an automation rule for incident response

   Provisions:

   • Microsoft Sentinel

   Automation rules are SC-200's Configure your Microsoft Sentinel environment for incident management primitive — they trigger when an incident is created, updated, or closed, and run a set of actions: assign the incident to a user, change its severity, add tags, or invoke a Logic App playbook.

   We create a rule that runs every time any incident is created. The example action just changes severity to High and tags the incident — in production you'd invoke a Logic App playbook here that posts to Teams, creates a Jira ticket, enriches with threat-intel, or triggers a remediation runbook. SC-200 tests this triggered automation shape as the standard L1 SOC pattern.

   Copy

   resource "azurerm_sentinel_automation_rule" "tag_and_escalate" {
     name                       = "0e84e57b-8b8a-4c8b-a0a8-1d3f3e6f9a01" # GUID required
     log_analytics_workspace_id = azurerm_log_analytics_workspace.main.id
     display_name               = "Tag-and-escalate every new incident"
     order                      = 1
     enabled                    = true
   
     triggers_on  = "Incidents"
     triggers_when = "Created"
   
     action_incident {
       order    = 1
       severity = "High"
     }
   
     action_incident {
       order  = 2
       labels = ["lab-auto-tagged"]
     }
   
     depends_on = [azurerm_sentinel_log_analytics_workspace_onboarding.main]
   }

Cleanup