SC-100 Microsoft Cybersecurity Architect

Architect vs Implementer distinction: SC-100 tests design decisions, not configuration steps. An architect answers: "Given these business requirements, which control architecture best achieves the risk posture?" Not: "Which portal do I click to enable MFA?" Exam cases present business scenarios, regulatory context, organizational constraints, and ask: which design recommendation is correct?

Microsoft Cybersecurity Reference Architecture (MCRA): Microsoft's reference architecture covering all pillars. Not a prescriptive blueprint — a set of recommended patterns that org can adopt selectively. Key sections: IdAM (Entra ID as identity control plane), Multi-cloud security, Endpoint management, Threat protection (Defender XDR), SIEM/SOAR (Sentinel), Information protection (Purview), Operational Technology (OT) security. An architect maps org requirements to MCRA patterns, identifies gaps, and recommends a target state.

Resilient architecture principles: Design to fail safely. Assume any single control can be compromised — architect layered defenses (Defense in Depth) so no single failure leads to full breach. Principle of least privilege applied at architecture level: minimize blast radius of any compromise. Explicit trust with continuous evaluation (CAE, Defender for Identity behavioral baselines) rather than static trust boundaries.

Resiliency patterns for identity: CAE (Continuous Access Evaluation) = near-real-time token revocation (instead of waiting for 1h token expiry, Entra revokes session within seconds if risk detected). Backup authentication: SSPR + FIDO2 as fallback. Federated identity resilience: if ADFS goes down, fail over to Password Hash Sync authentication (PHS as resilience option). Conditional Access "Break Glass" accounts: 2 emergency accounts per tenant, excluded from CA, stored credentials in physical safe — for scenarios where CA misconfiguration locks out all admins.

Azure Landing Zone (ALZ): pre-built architecture framework with Management Groups, subscriptions, policies, identity, and network topology already structured. ALZ provides security baselines out of the box: Azure Policy assignments (no public IP, require encryption, require Defender plans). ALZ Platform subscriptions: Identity (AD DS), Management (Log Analytics, Defender for Cloud), Connectivity (hub network, Firewall, VPN/ExpressRoute). ALZ Landing Zone subscriptions: Corp (connected to hub) and Online (internet-facing, no hub peering).

Hub-Spoke network design: Hub: central VNet containing shared services (Azure Firewall, VPN Gateway, DNS, Azure Bastion). Spokes: individual VNets for each workload, peered to hub only (not peer-to-peer). All inter-spoke traffic routes through hub Firewall (inspect and control east-west). Internet-bound traffic routes through hub Firewall (inspect north-south). Benefit: single place to manage network security policy, consistent logging at Firewall level.

Azure Defender for Cloud — multi-cloud CSPM: Cloud Security Posture Management across Azure, AWS, GCP. Connect AWS account → Defender for Cloud ingests AWS Config, Security Hub findings → unified Secure Score across clouds. Regulatory compliance dashboard: map to CIS, SOC 2, PCI-DSS, ISO 27001 — show compliance posture across all clouds in one view. Defender for DevOps: integrate with GitHub/Azure DevOps — scan IaC (Terraform, ARM) for misconfigurations before deploy.

Privileged access workstations (PAW): dedicated, hardened devices for privileged tasks only. No email, no web browsing, no productivity apps. Separate from daily-use devices. Managed by Intune with strict compliance policies. Admin tasks (PIM activation, Azure portal, Entra admin) done only from PAW. Reduces risk of credential theft via phishing on admin machines. Three-level model: PAW for Tier 0 (identity/infrastructure), Enterprise Access Workstation for Tier 1 (servers), Specialized Access Workstation for Tier 2 (application).

Shift-left security: move security earlier in the development lifecycle — find and fix issues at design and code time rather than post-deployment. Tools: pre-commit hooks (git hooks with secrets detection — detect API keys before push), SAST (Static Application Security Testing — code analysis without running), DAST (Dynamic Application Security Testing — run against running app), SCA (Software Composition Analysis — scan dependencies/libraries for known CVEs), IaC scanning (Terraform/Bicep misconfig before deploy).

Threat modeling — STRIDE: Spoofing (identity — attacker impersonates legitimate user/system). Tampering (integrity — modify data in transit or at rest). Repudiation (non-repudiation — deny performing action — solve with audit logs). Information Disclosure (confidentiality — expose sensitive data). Denial of Service (availability — overwhelm resource). Elevation of Privilege (authorization — gain higher access). For each STRIDE threat, identify mitigations in the architecture design.

Defender for DevOps: integrates with GitHub Actions and Azure DevOps pipelines. Capabilities: secrets scanning (detect hardcoded API keys, tokens in code), IaC scanning (Terraform, ARM, Bicep — flag Public Access: true, no encryption), dependency scanning (SCA — known vulnerable packages), code scanning (SAST via CodeQL integration). All findings surface in Defender for Cloud as Code Security recommendations. Developer sees security findings directly in pull request comments.

API security architecture: Azure API Management (APIM) as central API gateway — apply OAuth 2.0 token validation, rate limiting, IP filtering, TLS enforcement before traffic reaches backend. WAF on Application Gateway or Azure Front Door for web-facing APIs (OWASP Top 10 protection). Managed Identity for service-to-service API calls (no stored credentials in config files). Private Endpoint for backend APIs (no public exposure).

Regulatory compliance in cloud: Shared responsibility model for compliance — cloud provider (Microsoft) is responsible for physical, infrastructure compliance (SOC 2, ISO 27001, PCI-DSS for the cloud platform itself). Customer is responsible for how they configure and use cloud services (data classification, access control, encryption keys management, application security). Compliance is not inherited — customer must implement controls on top of compliant infrastructure.

Defender for Cloud Regulatory Compliance: assign compliance frameworks (ISO 27001, SOC 2, PCI-DSS, NIST SP 800-53, NIS2, GDPR) to subscriptions → automatic assessment of controls against current Azure config. Control A.9.4.2 (Secure log-on procedures): Defender checks if MFA is enabled, CA policies exist, sign-in risk detection on. Compliance score shows % of controls passed. Export to compliance report for auditors. Workflow: remediate findings in Defender for Cloud → score improves → auditor evidence generated automatically.

NIST Cybersecurity Framework (CSF): 5 functions — Identify (asset management, risk assessment, governance), Protect (IAM, awareness, data security, maintenance, protective technology), Detect (anomalies and events, security monitoring, detection process), Respond (response planning, communications, analysis, mitigation, improvements), Recover (recovery planning, improvements, communications). SC-100 maps Microsoft technologies to each NIST CSF function. Example: Detect function → Microsoft Sentinel + Defender XDR.

Azure Policy for governance: initiative = group of policies. Assign initiative at Management Group level → applies to all subscriptions. Policy effects: Deny (prevent non-compliant resource creation), Audit (flag existing non-compliant, don't block), DeployIfNotExists (auto-remediate — deploy Defender plan if not enabled), Modify (add tags). Policy-driven governance vs manual governance: at scale (1000+ resources), policies ensure consistent compliance without manual checks.