Microsoft Security, Compliance and Identity Fundamentals

Table of Contents

• Module 1: Cloud Computing — Who Secures What?
  • Types of Cloud Computing Services
  • The Pizza-as-a-Service Analogy
  • The Shared Responsibility Model
• Module 2: Security Concepts and Methodologies in the Microsoft Cloud
  • Common Security Threats
  • The Zero Trust Methodology
  • Defense in Depth
  • Encryption
  • Hashing
  • Digital Signatures
• Module 3: Identity Concepts in the Microsoft Cloud
  • Authentication and Authorization
  • Modern Authentication, Identity Providers, SSO, and Federation
  • Identity as the Primary Security Perimeter
  • Directory Services and Microsoft Active Directory
• Module 4: Compliance Concepts in the Microsoft Cloud
  • Introduction to Regulatory Compliance
  • Governance, Risk, and Compliance (GRC)
• Summary

This document is a technical study reference covering the foundational security, compliance, and identity concepts behind the Microsoft Cloud ecosystem (Microsoft 365, Azure, Microsoft Entra ID, and Microsoft Purview). It is written as exam-prep material aligned with the SC-900: Microsoft Security, Compliance, and Identity Fundamentals certification, focusing on the conceptual foundations that later map onto specific Microsoft security, compliance, and identity products.

Module 1: Cloud Computing — Who Secures What?

Types of Cloud Computing Services

Before discussing who is responsible for securing cloud workloads, it’s essential to understand the three main cloud service delivery models. What differs between these models is how much you manage versus how much the cloud vendor manages.

• On-premises: The customer manages everything — the data center, networking, virtualization, operating systems, and applications.
• Infrastructure as a Service (IaaS): The cloud vendor delivers infrastructure — servers, network, storage, and virtualization technology. The customer still manages the operating system, applications, and data on top of that infrastructure.
• Platform as a Service (PaaS): The cloud vendor provides a framework/platform that developers build custom applications on top of. Servers, storage, and networking are managed by the provider, while developers maintain and manage their applications.
• Software as a Service (SaaS): The customer simply consumes a finished service (often through a web browser) for a fee. The vendor manages everything — there is nothing to install or configure at the infrastructure level.

flowchart TB
    subgraph OnPrem["On-Premises"]
        direction TB
        O1[Applications]
        O2[Data]
        O3[Runtime]
        O4[Middleware]
        O5[O/S]
        O6[Virtualization]
        O7[Servers]
        O8[Storage]
        O9[Networking]
    end
    subgraph IaaS["Infrastructure as a Service"]
        direction TB
        I1["Applications (You)"]
        I2["Data (You)"]
        I3["O/S (You)"]
        I4["Virtualization (Provider)"]
        I5["Servers / Storage / Networking (Provider)"]
    end
    subgraph PaaS["Platform as a Service"]
        direction TB
        P1["Applications (You)"]
        P2["Data (You)"]
        P3["Runtime / O/S / Virtualization / Servers / Storage / Networking (Provider)"]
    end
    subgraph SaaS["Software as a Service"]
        direction TB
        S1["Everything (Provider)"]
        S2["Configuration & Data Governance (You)"]
    end

Even though workloads are conceptually separated into service types, most organizations use a mix of all three. For example, in the Microsoft Cloud:

The Pizza-as-a-Service Analogy

A well-known way to make the differences intuitive is comparing the cloud service models to ordering pizza:

mindmap
  root((Cloud Service Models))
    On-Premises
      Make pizza from scratch
      You manage everything
    IaaS
      Frozen pizza, cook at home
      Provider: servers/storage/network/virtualization
      You: OS, apps, data
    PaaS
      Pizza delivery
      Provider: servers through OS/runtime
      You: applications and data
    SaaS
      Dining out
      Provider manages everything
      You: configuration and governance

The Shared Responsibility Model

Security in the cloud is always a partnership between the cloud provider and the customer. At a high level, the cloud provider operates and secures the base infrastructure (and, in many cases, the host operating layers), while the customer always controls and secures identities and related application settings (for example, enabling multi-factor authentication).

This is not a fixed list — responsibilities shift depending on the cloud service type selected. In IaaS, the customer manages more (and therefore is responsible for more) than in SaaS.

flowchart LR
    A[On-Premises: Customer secures everything] --> B[IaaS: Provider secures physical data center, network, hosts]
    B --> C[PaaS: Provider also secures the O/S; app code security is shared]
    C --> D[SaaS: Provider secures nearly everything except identity, devices, and data governance]

Key rules that never change regardless of the service model:

• Information and data, devices, and accounts and identities are always the customer’s responsibility.
• In PaaS, application security is a split responsibility: if the customer’s own code contains a vulnerability, that is the customer’s responsibility; the cloud provider is responsible for making sure the underlying platform isn’t compromised from the outside.
• In SaaS, even though the provider hosts everything, identity is still shared: the provider secures the directory infrastructure against being hacked, but the customer is responsible for configuring protections like multi-factor authentication (MFA).

Two illustrative real-world examples of customer-owned responsibility that persist even in SaaS:

1. An employee’s device is stolen and has no password or PIN — whoever finds it gets direct access to company data. This is the customer’s responsibility, not the cloud provider’s.
2. A user clicks a phishing/ransomware link and gives away their password, and MFA was not enabled. The resulting compromise is the customer’s responsibility, not the provider’s.

Exam takeaway: The shared responsibility model is your guide to who secures what in the cloud. It is your duty to understand and know your security responsibilities for each type of product and workload you use — and some responsibilities (data, devices, identities) will always belong to the customer.

Module 2: Security Concepts and Methodologies in the Microsoft Cloud

Common Security Threats

Modern organizations face many categories of threats. Some aim to steal data, some aim to extort money, and others aim to disrupt normal operations.

Data breaches: A data breach occurs when data is stolen — either proprietary data/trade secrets, or personal data (any information related to an individual that can be used to identify them directly or indirectly). Stolen personal data frequently leads to identity attacks such as phishing or spear phishing.

Phishing vs. spear phishing:

• Phishing is a cybercrime in which targets are contacted by email, phone, or text message by someone posing as a legitimate institution, luring individuals into providing sensitive data (PII, banking/credit card details, passwords). The malicious link often leads to a fake website nearly identical to the real one (sometimes differing by only a few characters in the URL). A generic phishing attack is a mass distribution — casting a wide net with the same message, with no specific victim in mind.
• Spear phishing is a highly targeted phishing attack aimed at a specific individual. The attacker performs significant reconnaissance on the target (their role, their manager, their colleagues, what they’re authorized to do) before crafting a message that appears to come from someone the victim regularly works with.

Real-world example: A sales manager who regularly validated reseller pricing quotes with PDF attachments received a spear-phishing email spoofed as a familiar reseller requesting a “proposal review.” The link led to a fake Office 365 login page. The attack succeeded because the request matched the employee’s normal daily routine — a request to wire $50,000 directly to a salesperson would raise suspicion, but a routine document-review request sent to someone used to receiving exactly that kind of request does not.

Dictionary attacks (brute-force attacks): A common identity attack where an attacker attempts to steal an identity by systematically trying a large number of known passwords against a known username.

Password spray attacks: Instead of trying many passwords against one account (brute force), a password spray attack submits a small number of the most common weak passwords against many accounts across an enterprise. This lets the attacker search for an easily compromised account while avoiding account-lockout detection thresholds (which typically trigger after a handful of failed attempts per account).

Ransomware: A form of malware that encrypts files and folders, denying access to important data, and then extorts money (typically cryptocurrency) from the victim in exchange for the decryption key. Organizations without a regular backup schedule are hit the hardest by ransomware.

Disruptive attacks (DDoS): A Distributed Denial of Service attack attempts to exhaust an application’s resources, making it unavailable to legitimate users. DDoS attacks can target any publicly reachable endpoint. While most DDoS attacks don’t steal data directly, some are used as a smokescreen to mask another breach happening simultaneously.

Worms: Malware that can copy itself and spread through a network by exploiting security vulnerabilities — via email attachments, text messages, file-sharing programs, social networking sites, network shares, and removable drives (e.g., a lost USB key plugged in by a curious finder).

Coin miners / cryptojacking: Malware that installs software, or runs directly in a browser, to hijack the infected computer’s resources/power to mine cryptocurrency. Victims typically only notice a performance slowdown, so infections can go unnoticed for a long time.

mindmap
  root((Common Security Threats))
    Data Breaches
      Proprietary data / trade secrets
      Personal data (PII)
    Identity Attacks
      Phishing (mass, untargeted)
      Spear Phishing (targeted, researched)
      Dictionary / brute-force attacks
      Password spray attacks
    Malware
      Ransomware (encrypt + extort)
      Worms (self-replicating, spreads via network)
      Coin miners / Cryptojacking
    Disruptive Attacks
      DDoS (exhausts resources)
      Can mask a simultaneous breach

The Zero Trust Methodology

Zero trust is a cybersecurity model built on a simple premise: eliminate the concept of trust from your network.

In a traditional network design, resources are split into corporate (internal), internet (external/untrusted), and a DMZ with granular access rules. By default, anything inside the corporate perimeter was implicitly trusted and free to move laterally. This worked when corporate boundaries were well-defined, but the modern workforce has changed that: cloud technology is accessed from anywhere in the world, from any device (desktops, tablets, laptops, smartphones), and threat actors have evolved. The old “trusted internal network” assumption no longer holds.

The National Institute of Standards and Technology (NIST) defines zero trust as follows: zero trust assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location (on the corporate network vs. the internet) or based on asset ownership (a corporate-owned laptop is not automatically more trusted than a personal device — both should be treated with the same skepticism as a bring-your-own-device scenario).

flowchart LR
    subgraph Traditional["Traditional Perimeter-Based Model"]
        direction LR
        Internet1[Internet — Untrusted] --> DMZ1[DMZ — Rules Apply]
        DMZ1 --> Corp1[Corporate Network — Implicitly Trusted, Free Lateral Movement]
    end
    subgraph ZeroTrust["Zero Trust Model"]
        direction LR
        Internet2[Internet] -.Verify Explicitly.-> Resource2[Every Resource Access Request]
        Corp2[Corporate Network] -.Verify Explicitly.-> Resource2
        Resource2 --> Decision{"Least-Privileged, Just-in-Time Access Granted?"}
    end

Three guiding principles of zero trust:

1. Verify explicitly — Always authenticate and authorize based on all available data points, including user identity, location, device, service/workload, data classification, and anomalies. For example, a user who logs in from Canada and then, an hour later, logs in from Germany should trigger an anomaly that forces a re-evaluation of trust.
2. Use least-privileged access — Limit user access with just-in-time (JIT) and just-enough-access (JEA). Users should not have standing administrator permissions on everything; elevated permissions should be requested, approved via risk-based adaptive policies, and time-bound.
3. Assume breach — Reduce the attack surface and prevent lateral movement by segmenting networks, users, and devices. Ensure all data and sessions are encrypted, and use analytics for visibility and improved threat detection. Continue monitoring authenticated users and take corrective action the moment a threat is detected.

Six foundational pillars of zero trust:

mindmap
  root((Zero Trust))
    Guiding Principles
      Verify Explicitly
      Least Privileged Access - JIT/JEA
      Assume Breach
    Foundational Pillars
      Identities
      Devices
      Applications
      Data
      Infrastructure
      Networks

Defense in Depth

Defense in depth is an information security approach (as described by the Center for Internet Security) in which a series of security mechanisms and controls are thoughtfully layered throughout a computer network to protect the confidentiality, integrity, and availability of the network and its data.

Key characteristics:

• Uses a layered approach to security instead of relying on a single perimeter.
• Each layer slows down an attack so that even if one layer is breached, a subsequent layer prevents unauthorized access to the data.

Layers of defense in depth (outer to inner):

flowchart TB
    L1["Physical Security — limit data center access to authorized personnel"]
    L2["Identity and Access Security — control access to infrastructure and change control"]
    L3["Perimeter Security — DDoS protection filters large-scale attacks"]
    L4["Network Security — segmentation and access controls limit communication between resources"]
    L5["Compute Layer Security — secure access to VMs, e.g. by closing unneeded ports"]
    L6["Application Layer Security — ensure applications are secure and free of vulnerabilities"]
    L7["Data Layer Security — control access to business/consumer data; encourage encryption"]
    L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7

Encryption

Encryption is the process of making data unreadable and unusable to unauthorized viewers. To use or read encrypted data, it must be decrypted, which requires a secret key.

sequenceDiagram
    participant P as Plaintext ("Hello World")
    participant E as Encryption Algorithm + Secret Key
    participant C as Ciphertext (unreadable)
    participant D as Decryption Algorithm + Secret Key
    P->>E: Encrypt
    E->>C: Produces ciphertext
    C->>D: Decrypt (same secret key)
    D->>P: Restores original plaintext

Key terminology:

• Plaintext: content in its readable format.
• Ciphertext: content while encrypted.
• Secret key: the key used to encrypt or decrypt information.

Two types of encryption:

When data is encrypted:

• Data at rest: data stored on a physical device (server, internal/external hard drive, database, storage account). Encryption at rest ensures the data is unreadable without the necessary keys/secrets — so even a stolen physical drive remains safe.
• Data in transit: data moving from one location to another (e.g., across the internet or a private network). Encrypting data in transit protects it from network observers. HTTPS is the everyday example of encryption in transit.

Hashing

Hashing uses an algorithm to convert original content into a unique, fixed-length hash value, which acts as a unique identifier for its associated data. Hashing is deterministic: the same input always produces the same output, and changing anything in the input changes the hash.

Encryption vs. hashing:

Hashing is commonly used to store passwords — the actual password is never stored in plaintext. Instead, only the hash of the password is stored. When the user later logs in, the same algorithm hashes the entered password, and if the newly computed hash matches the stored hash, the password is correct.

Because hashing is deterministic, attackers can precompute hashes for common passwords (brute force) and match them against a stolen hash database. Salting mitigates this: a value known only to the system (the “salt”) is appended to the input before hashing.

sequenceDiagram
    participant U as User Password ("Plur@ls!ght")
    participant S as Salt (e.g. "SALT")
    participant H as Hash Algorithm
    participant DB as Database

    Note over U,S: Registration
    U->>H: Password + Salt
    H->>DB: Store resulting hash

    Note over U,S: Sign-in
    U->>H: Entered password + Salt
    H->>DB: Compare newly computed hash to stored hash
    DB-->>U: Match = authenticated

Best practice: each user (or each password instance) should have a unique salt in the database, so even identical passwords produce different stored hashes.

Digital Signatures

The goal of a digital signature is to prove that a document or digital message was not modified — intentionally or unintentionally — since it was signed. Digital signatures use both encryption keys and hashing, but they do not necessarily encrypt the content of the message itself (they are complementary to encryption). They rely on asymmetric cryptography (public/private key pairs).

Signing and verification workflow:

sequenceDiagram
    participant Sender
    participant HashAlgo as Hash Algorithm
    participant Verifier

    Sender->>HashAlgo: Run data through hash algorithm
    HashAlgo-->>Sender: Produces hash of the data
    Sender->>Sender: Encrypt hash with sender's PRIVATE key
    Sender->>Verifier: Send data + encrypted hash (digitally signed document)

    Verifier->>HashAlgo: Recompute hash of received data
    Verifier->>Verifier: Decrypt received encrypted hash with sender's PUBLIC key
    Verifier->>Verifier: Compare recomputed hash vs. decrypted hash
    Note over Verifier: Match = signature valid (data unmodified)

If the two hashes match, the signature is valid, proving that the document was not modified between signing and verification.

Module 3: Identity Concepts in the Microsoft Cloud

Authentication and Authorization

Although often used interchangeably by non-technical users, authentication and authorization are distinct security processes in identity and access management:

• Authentication is the act of validating that users are who they claim to be.
• Authorization is the process of granting a user permission to access a specific resource or function.

Authentication typically begins with a request for identification — most commonly a username and password. When only a username and password are required, this is called single-factor authentication (one factor needed to authenticate). Single-factor authentication is increasingly considered insecure, which is why multi-factor authentication (MFA) is recommended: in addition to a username/password, the user must confirm their identity via another factor (e.g., an authenticator app code or a text message code).

Authentication always happens before authorization. Once a user is authenticated (the system confirms “this is really Vlad”), the system moves to authorization, which determines what the authenticated user is permitted to do — e.g., can they only view documents, or can they also edit or delete them?

flowchart LR
    A[User provides credentials] --> B{Authentication:\nAre you who you say you are?}
    B -- Valid --> C{Authorization:\nWhat are you allowed to do?}
    B -- Invalid --> D[Access Denied]
    C -- Permitted --> E[Access Granted to Resource/Action]
    C -- Not Permitted --> D

Exam takeaway: Authentication (AuthN) confirms identity; authorization (AuthZ) confirms permissions. Authentication always comes first.

Modern Authentication, Identity Providers, SSO, and Federation

Modern authentication is a Microsoft umbrella term (not a general industry term, unlike zero trust) describing authentication and authorization methods between a client and a server.

Before modern authentication: a client needed to provide its username/password directly to each server it accessed (file server, web server, etc.). Multiple servers meant multiple credentials to manage, credentials traveling across the network repeatedly, and — if any one server was breached — potential compromise of stored credentials across the whole environment. This was both poor user experience and a larger attack surface.

With modern authentication, an identity provider (IdP) is introduced into the flow:

sequenceDiagram
    participant Client
    participant IdP as Identity Provider
    participant Server as Resource / Server

    Client->>IdP: Authenticate (username/password, smart card, MFA, etc.)
    IdP-->>Client: Issue token
    Client->>Server: Present token
    Note over Server,IdP: Server trusts the IdP
    Server-->>Client: Access granted based on trusted token

Because the server has a trust relationship with the identity provider, it trusts the token as proof of authentication without needing to see the user’s raw credentials. This also enables single sign-on (SSO): once a user authenticates to the identity provider, they can access any other resource that trusts that same identity provider without re-entering credentials.

A modern identity provider delivers:

• Authentication
• Authorization
• Auditing services
• Single sign-on (SSO)

Federation extends this concept further: it enables single sign-on between multiple identity providers. A familiar example is a website login page offering “sign in with Google/Facebook/Apple/X” (or “sign in with your organization or school account”) instead of forcing you to create a new username/password. The app trusts another identity system — this is a trust relationship between two identity systems.

flowchart LR
    App[Application / Website] -- trusts --> IdP1[Your Organization's Identity Provider]
    App -- trusts --> IdP2[Social IdP: Google / Facebook / Apple / X]
    User((User)) --> IdP1
    User --> IdP2
    IdP1 -- SSO token --> App
    IdP2 -- SSO token --> App

Federation enables access to services across organizational or domain boundaries by establishing trust relationships between the respective domains’ identity providers — eliminating the need for separate credentials per domain, which increases both security and productivity.

Identity as the Primary Security Perimeter

Modern authentication and identity providers lead to the concept of identity as the primary security perimeter — a concept that works alongside zero trust, asserting that the traditional network-perimeter-based security model is no longer sufficient.

An identity is how someone or something can be verified and authenticated — this includes not only users, but also applications, devices, and IoT devices. Since cloud services are accessed from anywhere, in any network, on any device, the network/device context can no longer be the primary basis of trust — identity becomes that basis.

Four pillars of an identity and access management solution:

mindmap
  root((Identity & Access Management))
    Administration
      Creation and lifecycle of identities
    Authentication
      Assurance level / proof of identity
    Authorization
      Access level determination
    Auditing
      Reporting, alerts, governance

Directory Services and Microsoft Active Directory

A directory service is a customizable information store that acts as a single point from which users can locate resources and services distributed across a network — including users, groups, devices, printers, and more. It also serves as a single administrative point for managing those objects.

Active Directory Domain Services (AD DS) is the set of directory services developed by Microsoft, originally released as part of Windows 2000, and remains a central component of on-premises IT infrastructure today. AD DS stores information about domain members (devices and users), verifies their credentials, and defines their access rights. However, since it is over two decades old, AD DS by default does not support the latest identity innovations natively.

For cloud environments, Microsoft created Microsoft Entra ID — the next evolution of Microsoft’s identity solutions and a cloud-only service. Organizations with on-premises infrastructure will typically still run Active Directory on-premises, while everything cloud-related uses Microsoft Entra ID.

Naming note: Microsoft Entra ID was previously named Azure Active Directory (Azure AD). It was rebranded in 2023. Most online resources referencing “Azure AD” remain valid — only the name changed, though some additional cloud-native features have been added since the rebrand.

flowchart LR
    subgraph OnPrem["On-Premises Identity"]
        AD["Active Directory Domain Services (AD DS)\nSince Windows 2000"]
    end
    subgraph Cloud["Cloud Identity"]
        Entra["Microsoft Entra ID\n(formerly Azure Active Directory, renamed 2023)"]
    end
    AD -. can sync with .-> Entra

Module 4: Compliance Concepts in the Microsoft Cloud

Introduction to Regulatory Compliance

In IT, compliance is a set of digital security requirements and practices. Following compliance requirements helps ensure that a company’s business processes are secure and that sensitive data (including customer data) is not accessed by unauthorized parties.

Compliance is similar to security in that both drive a business toward being more secure, but the motive differs: compliance is generally driven by the requirements of a third party — a government, a security framework, or a client’s contractual terms. For example, working with a healthcare or finance company may require satisfying compliance requirements specific to that industry.

Popular compliance standards:

Typical requirements found across compliance standards:

• Granting individuals the right to access their own data at any time.
• Granting individuals the right to correct or delete data about them.
• Defining retention periods — a minimum or maximum amount of time data must be stored (e.g., decision-related data retained for 7 years, audit logs retained for 5 years).
• Enabling governments/regulatory agencies the right to access and examine data when necessary.
• Defining rules for what data can be processed and how.

Just as security in the cloud is a shared responsibility, compliance is also a partnership. Many regulatory standards include requirements about the security of the data center — which, in the Microsoft Cloud, Microsoft manages and documents/proves compliance for. However, many requirements remain the customer’s responsibility. For example, a 7-year retention requirement: Microsoft provides the tool (Microsoft Purview retention policies), but it is up to the customer to configure it correctly.

flowchart LR
    A[Regulatory Standard Requirement] --> B{Who Fulfills It?}
    B -- Data center security, physical infrastructure --> C[Microsoft / Cloud Provider]
    B -- Configuring retention, access controls, data classification --> D[Customer]
    C & D --> E[Combined Compliance Achieved]

Governance, Risk, and Compliance (GRC)

GRC (Governance, Risk, and Compliance) is an industry-standard framework, not a Microsoft-specific term. As defined by AWS: “Governance, risk, and compliance is a structured way to align IT with business goals while managing risks and meeting all industry and government regulations. It includes the tools and processes to unify an organization’s governance and risk management with its technological innovation and adoption.” Companies use GRC to achieve organizational goals reliably, remove uncertainty, and meet compliance requirements.

flowchart TB
    G[Governance:\nPolicies, procedures, rules, frameworks]
    R[Risk Management:\nIdentify, assess, control risks]
    C[Compliance:\nLaws and regulations to follow]
    G --> Align[Aligned Business Objectives]
    R --> Align
    C --> Align
    Align --> Stakeholders[Executives, Legal, HR, Finance, IT]

While governance, risk management, and compliance are often handled by different departments, a GRC framework helps align everyone — from senior executives, to legal teams, to HR and finance, to the IT staff responsible for implementation — around shared business objectives. Microsoft provides many tools that support an organization’s GRC posture (e.g., Microsoft Purview for data governance and compliance capabilities).

Summary

This course established the conceptual foundation for understanding security, compliance, and identity in the Microsoft Cloud, which underpins the SC-900 certification path.

Key Exam-Relevant Principles

• Cloud service models (IaaS, PaaS, SaaS) differ in how much infrastructure the customer vs. the provider manages — but information/data, devices, and accounts/identities are always the customer’s responsibility, regardless of model.
• The shared responsibility model applies to security; a similar partnership model applies to compliance.
• Common threats include data breaches, phishing/spear phishing, dictionary and password spray attacks, ransomware, DDoS, worms, and cryptojacking.
• Zero trust replaces implicit network/perimeter-based trust with continuous verification, guided by three principles (verify explicitly, least-privileged access, assume breach) applied across six pillars (identities, devices, applications, data, infrastructure, networks).
• Defense in depth layers security controls (physical, identity, perimeter, network, compute, application, data) so a breach in one layer doesn’t compromise the whole system.
• Encryption (symmetric and asymmetric) protects data confidentiality at rest and in transit; hashing (with salting) verifies data/password integrity without needing to store or reverse the original value; digital signatures combine both techniques to prove data hasn’t been tampered with.
• Authentication confirms identity; authorization determines permitted access — authentication always occurs first.
• Modern authentication introduces the identity provider, enabling single sign-on and federation across trusted identity systems, making identity the primary security perimeter.
• Active Directory Domain Services is Microsoft’s on-premises directory service; Microsoft Entra ID (formerly Azure Active Directory, renamed in 2023) is Microsoft’s cloud-native identity provider.
• Regulatory compliance (e.g., GDPR, HIPAA, NIST, PCI-DSS) is driven by third-party requirements (governments, industry bodies, contracts) and typically involves rules on data subject rights, retention periods, and regulator access.
• GRC (Governance, Risk, and Compliance) is an industry framework that aligns governance policies, risk management, and compliance obligations across an entire organization.

Quick-Reference Table

Study Checklist

• Can you list what the customer is always responsible for securing, regardless of IaaS/PaaS/SaaS?
• Can you explain the difference between phishing and spear phishing, and between dictionary attacks and password spray attacks?
• Can you name the three guiding principles of zero trust and its six foundational pillars?
• Can you list the seven layers of defense in depth in order?
• Can you explain the difference between symmetric and asymmetric encryption, and between encryption and hashing?
• Can you describe how salting protects hashed passwords, and how a digital signature is created and verified?
• Can you explain the difference between authentication and authorization, and why authentication always comes first?
• Can you describe the role of an identity provider, and the difference between SSO and federation?
• Can you distinguish Active Directory Domain Services (on-premises) from Microsoft Entra ID (cloud)?
• Can you name at least four major compliance standards and what industry/region each applies to?
• Can you define governance, risk management, and compliance individually, and how GRC unifies them?

Search Terms

microsoft · security · compliance · identity · fundamentals · governance · risk · networking · systems · cloud · concepts · authentication · computing · services