Hands-on Lab — SC-100 Microsoft Cybersecurity Architect

Overview

Prerequisites

Steps

1. 1.Provider, Resource Group, naming

   Standard Azure opener + the azuread provider for Conditional Access.

   Copy

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
       azuread = { source = "hashicorp/azuread", version = "~> 3.0" }
     }
   }
   
   provider "azurerm" {
     features {
       key_vault {
         purge_soft_delete_on_destroy = true
       }
     }
   }
   
   provider "azuread" {}
   
   data "azurerm_client_config" "current" {}
   data "azurerm_subscription" "current" {}
   
   locals {
     tags = {
       Project   = "certlabpro-sc-100"
       ManagedBy = "terraform"
     }
   }
   
   resource "azurerm_resource_group" "main" {
     name     = "certlabpro-sc-100-rg"
     location = "eastus"
     tags     = local.tags
   }

2. 2.Author a Conditional Access policy stub (Zero Trust identity gate)

   Provisions:

   • Microsoft Entra ID

   Conditional Access is the SC-100 Zero Trust identity primitive: verify explicitly — every access request gets evaluated against context (user, device, location, app, risk) before being granted. We create a policy in report-only mode that says "for all users accessing all cloud apps, require MFA". Report-only means the policy logs what would happen if enforced — the SC-100-recommended path before flipping a CA policy to enabled.

   Real Zero Trust architectures stack many CA policies — risk-based, location-based, device-compliance-based, session-control. This stub is the shape; SC-100's Design a strategy for securing privileged access domain tests the layered-policy composition.

   Copy

   resource "azuread_conditional_access_policy" "require_mfa_report" {
     display_name = "certlabpro-sc-100-require-mfa-report-only"
     state        = "enabledForReportingButNotEnforced"
   
     conditions {
       client_app_types = ["all"]
   
       users {
         included_users = ["All"]
       }
   
       applications {
         included_applications = ["All"]
       }
     }
   
     grant_controls {
       operator          = "OR"
       built_in_controls = ["mfa"]
     }
   }

3. 3.Onboard Defender for Cloud Foundational CSPM + Microsoft Sentinel

   Provisions:

   • Microsoft Defender for Cloud
   • Microsoft Sentinel

   SC-100 Evaluate Governance, Risk, and Compliance (GRC) technical strategies tests the dual-purpose of these two services: Defender for Cloud is the posture layer (continuous compliance assessment, security recommendations); Sentinel is the detection layer (KQL hunting, incident response). Together they're the Microsoft answer for "how do I architect security observability for a Zero Trust environment?".

   We onboard both onto a single Log Analytics workspace — the SC-100 reference architecture for cost efficiency (data lands once, both services read from the same store).

   Copy

   resource "azurerm_log_analytics_workspace" "main" {
     name                = "log-sc100"
     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_security_center_subscription_pricing" "cspm" {
     tier          = "Free" # Foundational CSPM
     resource_type = "CloudPosture"
   }
   
   resource "azurerm_sentinel_log_analytics_workspace_onboarding" "main" {
     workspace_id = azurerm_log_analytics_workspace.main.id
   }

4. 4.Assign an Azure Policy enforcing 'storage requires HTTPS' at subscription scope

   Provisions:

   • Azure Policy

   Azure Policy is the SC-100 Design a strategy for governance and compliance primitive — it enforces rules across every resource in a scope. We assign the built-in policy Secure transfer to storage accounts should be enabled at subscription scope with effect = Deny, which prevents creation of any new storage account that allows HTTP. The exam tests this DenyAssignment vs Audit distinction: Deny prevents the bad config from happening; Audit only flags it after the fact.

   The Zero Trust principle this enforces is encrypt in transit by default — one of the recurring SC-100 exam themes. Real Zero Trust deployments use Policy initiatives (groups of policies) to enforce dozens of controls at once; this is the smallest demonstrable shape.

   Copy

   # Look up the built-in policy definition by name.
   data "azurerm_policy_definition" "storage_https" {
     display_name = "Secure transfer to storage accounts should be enabled"
   }
   
   resource "azurerm_subscription_policy_assignment" "storage_https" {
     name                 = "certlabpro-sc-100-storage-https"
     display_name         = "Storage accounts must require HTTPS"
     description          = "Enforces secure transfer (HTTPS-only) on all storage accounts in the subscription."
     policy_definition_id = data.azurerm_policy_definition.storage_https.id
     subscription_id      = data.azurerm_subscription.current.id
   
     # The built-in policy defaults to Audit; force Deny for Zero Trust enforcement.
     parameters = jsonencode({
       effect = {
         value = "Deny"
       }
     })
   }

5. 5.Provision a Key Vault as the architecture's secrets layer

   Provisions:

   • Azure Key Vault

   Zero Trust architectures centralize secrets in a hardened vault — RBAC-only, no admin-key shortcuts, soft-delete + purge protection on. We provision the vault with purge protection off for lab cleanup convenience; in production every SC-100-recommended vault has purge_protection_enabled = true to meet the standard 'unrecoverable deletion required' compliance requirements.

   With the five blocks in place (Conditional Access for identity, Defender + Sentinel for posture and detection, Azure Policy for guardrails, Key Vault for secrets), the SC-100 Zero Trust scaffolding is shaped. Every additional SC-100 architectural pattern (Privileged Identity Management for just-in-time elevation, Microsoft Purview for data classification, Defender XDR for unified threat protection) layers onto this base.

   Copy

   resource "azurerm_key_vault" "main" {
     name                       = "kv-sc100-${substr(replace(uuid(), "-", ""), 0, 6)}"
     resource_group_name        = azurerm_resource_group.main.name
     location                   = azurerm_resource_group.main.location
     tenant_id                  = data.azurerm_client_config.current.tenant_id
     sku_name                   = "standard"
     enable_rbac_authorization  = true
     soft_delete_retention_days = 7
     purge_protection_enabled   = false # set true in production for compliance
   
     tags = local.tags
   
     lifecycle {
       ignore_changes = [name]
     }
   }
   
   resource "azurerm_role_assignment" "kv_admin_self" {
     scope                = azurerm_key_vault.main.id
     role_definition_name = "Key Vault Administrator"
     principal_id         = data.azurerm_client_config.current.object_id
   }

Cleanup