Security and Compliance Concepts

Ask one question of any cloud security task and most of this topic falls into place: do you configure it, or does Microsoft run it for you? That single dividing line is the shared responsibility model, and it moves depending on how much of the stack you rent. In an on-premises datacenter you own the whole stack; as you move to the cloud, some duties transfer to Microsoft, and the more managed the service, the more it absorbs (Shared responsibility in the cloud^[1]).

Microsoft splits cloud services into three models, and the responsibility boundary sits at a different height in each. With infrastructure as a service (IaaS), such as an Azure virtual machine, Microsoft secures the physical hosts, physical network, and datacenter, and you still own the operating system, applications, and network controls on top. With platform as a service (PaaS), such as Azure App Service, Microsoft additionally runs the operating system, so your job narrows to the application and its data. With software as a service (SaaS), such as Microsoft 365, you consume a finished application and hand almost everything to Microsoft (SC-900 shared responsibility^[2]).

What never transfers

Three responsibilities stay with you no matter the model, and this is the single most tested fact in the topic: your information and data, your devices (the phones, laptops, and PCs that reach your services), and your accounts and identities. Because you always own identity, you also always own access management: the role assignments, multifactor authentication, and conditional access that decide who may do what. A band in the middle of the matrix is genuinely shared, most notably the identity and directory infrastructure, applications, network controls, and operating system, where the split depends on whether the service is IaaS, PaaS, or SaaS. The grid below reads left (you own the most, on-premises) to right (Microsoft owns the most, SaaS).

No single wall stops every attacker, so defense in depth stacks several independent walls: if one layer is breached, the next still stands between the attacker and your data (SC-900 defense in depth^[3]). Microsoft describes seven layers, drawn from the outside in.

• Physical security limits who can touch the hardware, through locked facilities, badge readers, guards, and cameras.
• Identity and access authenticates and authorizes users before granting access, using multifactor authentication (MFA), role-based access control (RBAC), and conditional access; even a stolen password can be stopped here.
• Perimeter protects the network boundary from bulk external attacks, including distributed denial-of-service (DDoS) protection and perimeter firewalls.
• Network controls traffic between resources through segmentation and network security groups (NSGs), so a compromise in one zone does not automatically reach every other.
• Compute hardens virtual machines and containers by patching, closing unused ports, and restricting administrative access.
• Application ensures software ships without exploitable flaws, through secure development and input validation against attacks such as SQL injection.
• Data is the innermost and most critical layer: access controls, encryption, and data classification protect the information every other layer exists to defend.

The CIA triad

Every layer works toward the same three goals, the CIA triad. Confidentiality keeps data readable only to authorized parties, and a breach of it is what we call a data breach. Integrity keeps data accurate and unaltered except through authorized changes, which is why verifying the hash of a downloaded file is an integrity check. Availability keeps systems reachable for legitimate users, which is exactly what a DDoS attack or ransomware takes away. The three can pull against each other: encrypting everything strengthens confidentiality, but losing the keys destroys availability, so good security balances the three rather than maximizing any one.

The traditional security model trusted anything inside the corporate network and guarded only the perimeter. That fails against modern attacks built on stolen identities, phishing, and session hijacking, which do not depend on network location (Zero Trust as a security foundation^[4]). Zero Trust replaces perimeter trust with one rule, never trust, always verify, treating every request as if it came from an open network.

Three guiding principles govern every access decision (SC-900 Zero Trust^[5]):

• Verify explicitly. Authenticate and authorize from all available signals: the user identity, sign-in location, the device and its compliance state, the application and data involved, and anomalies such as an unusual sign-in time, rather than from a single factor like a password.
• Use least privilege access. Grant only the access a task needs, for only as long as it is needed. This is implemented with just-in-time (JIT) access and just-enough-access (JEA), plus risk-based adaptive policies that tighten automatically when activity looks risky.
• Assume breach. Design as though an attacker is already inside: segment access so a compromised account cannot roam freely, encrypt data end to end, and monitor so a breach is detected and contained quickly.

The pillars

Microsoft enforces these principles across a set of interconnected pillars. Six are the resources and signal sources to defend, identities, devices, applications, data, infrastructure, and networks, and a seventh, visibility, automation, and orchestration, collects the signals from the other six and coordinates the response, typically through security information and event management (SIEM) and security orchestration, automated response (SOAR) tooling. Identity is called out as the primary control plane, because almost every successful attack eventually relies on abusing an identity.

Encryption and hashing both turn readable data into something unreadable, but they answer different questions, and telling them apart is the classic trap in this topic. Encryption is reversible: it scrambles data so that only a holder of the correct key can turn it back into plaintext, which is what protects data you must read again later (SC-900 encryption and hashing^[6]). Hashing is one-way: it has no key and cannot be reversed.

Two kinds of encryption

Symmetric encryption uses the same secret key to encrypt and decrypt. It is fast and well suited to bulk data such as files or database records, but it raises the key distribution problem, because both sides need the same key and sharing it securely is hard. Asymmetric encryption uses a mathematically related key pair, a public key and a private key, where you cannot derive the private key from the public one. Data encrypted with the public key can be decrypted only with the private key, which solves key distribution because the public key can be shared freely; the reverse direction, signing with the private key and verifying with the public key, produces digital signatures. Asymmetric encryption underpins HTTPS, where Transport Layer Security (TLS) secures the connection between browser and server.

Encryption is also described by the state of the data: at rest (stored on a disk, database, or storage account), in transit (moving across a network, protected by TLS or a VPN), and in use (being processed in memory, protected by confidential computing). Because encryption is only as strong as its keys, key management matters as much as the algorithm: store keys apart from the data, use hardware security modules (HSMs), and rotate keys regularly. Azure Key Vault is Microsoft's managed service for storing keys, secrets, and certificates (Azure Key Vault^[7]).

Hashing

Hashing runs any input through an algorithm to a fixed-length value called a hash, or digest. The same input always produces the same hash, and the value cannot be reversed to recover the input, which makes a hash a reliable fingerprint for verifying data without ever storing the original. That is why a system stores the hash of a password rather than the password itself: a stolen database yields only hashes. Because hashing is deterministic, attackers can precompute the hashes of common passwords into rainbow tables, so passwords are salted first. A salt is a unique random value added to each password before hashing, so two identical passwords produce different stored hashes and precomputed tables no longer match.

Organizations operate under a growing web of laws about how data is protected, where it may be stored, and who is accountable when something goes wrong. Governance, risk, and compliance (GRC) is the framework of policies, processes, and technology that keeps an organization on the right side of those obligations (SC-900 GRC concepts^[8]). Its three parts play distinct roles.

• Governance is the system of rules, practices, and processes that directs and controls an organization: who may access which resources, who holds administrative rights and for how long, and how data is classified, handled, and retained. Governance creates the structure on which the other two operate.
• Risk management identifies, assesses, and responds to threats. The goal is not to eliminate all risk but to understand it well enough to make informed decisions. Risk comes from outside (cyberattacks, disasters, suppliers) and inside (accidental exposure, insider threats). The process runs as a loop: identify risks, assess each by impact and likelihood to produce a risk score, respond by choosing to accept, mitigate, transfer (for example through insurance), or avoid the risk, and monitor continuously as the environment changes.
• Compliance is adherence to the laws, regulations, standards, and policies that apply, which depend on industry, geography, and data type. Familiar examples are HIPAA (US health data), ISO 27001 (an information security management standard), and SOC (an auditing standard for service providers).

Compliance is a floor, not security

A point the exam presses: compliance is not the same as security. Compliance is the minimum a law or regulation demands, while security is the broader set of practices that actually protect data and systems. An organization can be fully compliant and still carry serious vulnerabilities.

Data residency, sovereignty, and privacy

Three data-location terms sit inside compliance and are easy to confuse. Data residency is about where data may be physically stored, and how or when it may be transferred or accessed across borders; the rules differ by jurisdiction. Data sovereignty is the principle that data is subject to the laws of the country or region where it is physically collected, held, or processed, so a single dataset can fall under several jurisdictions as it moves between them. Data privacy is the appropriate handling of personal data, meaning any information that identifies a person, and it requires transparency about what is collected, obtaining consent, and honoring individual rights to access, correct, or delete their data.

These concepts appear as short "which term fits" or "who is responsible" questions. Anchor on the sharpest distinction in each.

Shared responsibility, who owns it. If the stem names your data, your accounts and identities, or the devices that access your services, the answer is you, in every model including SaaS. If it names the physical datacenter, physical hosts, or physical network, the answer is always Microsoft. The operating system flips with the model: yours on IaaS, Microsoft's on PaaS and SaaS. A classic distractor claims Microsoft owns your identities or your data because the service is managed; it never does.

Encryption vs hashing. If the task must recover the original value later, the answer is encryption, which is reversible and uses a key. If it stores passwords or checks that data was not altered, the answer is hashing, which is one-way and keyless. Within encryption, the same key both ways is symmetric, while a public and private key pair is asymmetric; encrypting with a public key and decrypting with the private key is the asymmetric giveaway. Calling hashing a form of encryption, or claiming a hash can be decrypted, is the trap.

Zero Trust principles. Match the phrase to the principle: evaluating many signals before granting access is verify explicitly; JIT or JEA access is use least privilege; segmenting and encrypting because an attacker may already be inside is assume breach.

Residency vs sovereignty vs compliance. Where data may be stored is residency; whose laws apply to it is sovereignty; meeting a named regulation such as HIPAA or ISO 27001 is compliance. And remember that being compliant is a minimum bar, not proof of being secure.