Foundations of Security, Compliance, and Cloud Responsibility
Shared responsibility, defense in depth, the CIA triad, Zero Trust, cryptography, hashing, GRC, and data residency, sovereignty, and privacy
Suggested study time: 48 minutes • Beginner level • Aligned with the first domain of the SC-900 exam
By João Ricardo Dutra••Full material
1. Introduction
The history of information security follows the very evolution of computing. In the first data processing centers, protection was concentrated on physical access to the machines, on controlled rooms, and on simple permissions. With the expansion of corporate networks and the Internet, firewalls, antivirus, detection systems, and access policies emerged. Cloud computing added a decisive change: the infrastructure came to be operated by a provider, but the data, the identities, and much of the configuration remained the customer's responsibility.
Understanding this division helps professionals and organizations avoid a dangerous mistake: imagining that hiring a cloud service fully transfers security to the provider. In practice, the cloud can offer highly protected infrastructure, automation, monitoring, and certifications, but a compromised identity, an excessive permission, or a misconfigured storage account can still expose information. This understanding benefits the reader, companies, and society because it reduces incidents, preserves essential services, and strengthens trust in the responsible use of technology.
In this chapter, you will follow a logical line: who protects each layer, how several defenses complement one another, which properties of the information need to be preserved, why trust must be continuously verified, and how cryptography, governance, and compliance turn principles into concrete controls. By the end, the terms stop looking like an isolated list and come to form a single mental architecture for interpreting SC-900 scenarios and real security decisions.
Central idea
Cloud security is not a ready-made deliverable. It is a system of responsibilities, controls, and decisions that must work end to end.
2. From physical security to identity-driven security
For decades, the predominant security architecture was compared to a castle surrounded by a moat: the network perimeter was strongly protected and, once inside it, users and equipment received a high degree of trust. This approach made sense when people, applications, and data were concentrated in the same building or datacenter. Physical security, entry controls, and firewalls formed the main line of defense.
Mobility, remote work, SaaS services, APIs, personal devices, and hybrid architectures dissolved that boundary. Today, a user can be in the office, at home, or on a public network; an application can combine on-premises resources and services from different clouds; and data can circulate through several systems. In this context, being “inside the network” does not prove that a request is legitimate.
This transformation produced four consequences that appear throughout the chapter:
Security must be distributed in layers, and not concentrated in a single perimeter.
Identity has become an essential control plane for deciding who can access what.
Risk must be assessed continuously, because the context changes with each access.
The organization must demonstrate that its controls meet policies, laws, standards, and contractual commitments.
The modern strategy combines shared responsibility, defense in depth, Zero Trust, cryptography, and GRC. Each concept solves a different part of the problem; none of them replaces the others.
3. Shared responsibility model
The shared responsibility model defines how security and operation obligations are distributed between the cloud service provider and the customer. The division depends on the service model consumed. In an on-premises environment, the organization manages the entire stack. As you move to IaaS, PaaS, and SaaS, more technical layers come to be managed by the provider. However, the customer remains responsible for their data, their identities, access, devices, and the configurations they control.
Figure 1 — A didactic view of the shared responsibility model. Conceptual source: Microsoft Learn.
3.1 On-premises environment
In the on-premises model, the organization owns or operates the datacenter and assumes full responsibility: building security, power, climate control, servers, storage, cabling, switches, hypervisors, operating systems, applications, identities, permissions, data, backups, and recovery. Control is maximal, but so is the operational load. If patches stop being applied, a UPS fails, or the server room lacks adequate protection, the responsibility belongs to the organization itself.
The on-premises environment is not necessarily less secure; it simply requires the organization to have the people, processes, budget, and technology to protect every layer. In many companies, the difficulty lies in coverage: controls are strong in some systems and fragile in others, especially in legacy assets.
3.2 Infrastructure as a Service (IaaS)
In IaaS, the provider operates datacenters, physical network, physical servers, and virtualization. The customer receives resources such as virtual machines, disks, and virtual networks, but remains responsible for the guest operating system, virtual machine patches, port configuration, firewall rules or security groups, installed applications, credentials, identities, data, and backups according to the adopted design.
A virtual machine in Azure illustrates the model well. Microsoft protects the physical host and the hypervisor; the company needs to protect the VM. If the administrator exposes an administrative port to the Internet, uses a weak password, or leaves the operating system unpatched, the physical infrastructure may be secure and, even so, the workload can be compromised.
3.3 Platform as a Service (PaaS)
In PaaS, the provider also manages the operating system, the runtime, and much of the middleware. The customer focuses on the code, the business logic, the service configuration, the identities, the permissions, and the data. Azure App Service, Azure Functions, and Azure SQL Database are common examples of services in which the organization does not need to directly maintain the underlying virtual machines.
Reducing operational responsibility does not eliminate configuration flaws or application vulnerabilities. An API developed without input validation, a managed identity with excessive permissions, or an improperly exposed connection remain the customer's problems. In PaaS, the central question changes from “how to patch the server?” to “how to configure and use the platform securely?”.
3.4 Software as a Service (SaaS)
In SaaS, the provider operates the application and all the underlying infrastructure. The customer consumes a ready-made solution, such as Microsoft 365 or Dynamics 365. Even so, the organization must manage users, groups, authentication methods, permissions, sharing, retention policies, data classification, tenant settings, and the devices that access the service.
A file shared publicly by mistake in a SaaS solution does not represent a datacenter failure; it represents an inadequate decision or configuration within the customer's scope. This distinction is recurrent in the SC-900: the provider protects the platform, while the customer protects the use they make of it.
3.5 Responsibilities that remain with the customer
Data: deciding which data to collect, classifying its sensitivity, defining retention, controlling access, and meeting legal requirements.
Identities and access: creating and removing accounts, requiring strong authentication, applying least privilege, and reviewing permissions.
Endpoints: protecting laptops, phones, workstations, and other devices that access cloud services.
Use of the service: establishing processes, training, monitoring, and incident response.
Exam trap
“Microsoft protects the service” does not mean “Microsoft decides who should access your data”. Data and identities remain the customer's responsibility in every model.
3.6 Shared responsibility in AI services
Microsoft Learn has extended the model to artificial intelligence services. The provider usually protects the model hosting infrastructure and the controls available in the platform. The customer remains responsible for the data provided to the system, the authorized identities, the enabled connectors, the configurations, the retention, the usage policies, and the oversight of responses.
Risks such as exposure of confidential data, excessive permissions on connected sources, inappropriate use of results, and prompt injection need to be handled by the organization. For the SC-900, the conclusion is the same: choosing a higher-level service transfers technical tasks but does not transfer responsibility for data, access, and secure use.
4. Defense in depth
Defense in depth is a strategy that uses overlapping controls. Instead of relying on a single barrier, the organization creates several layers to prevent, detect, limit, and respond to attacks. If one control fails, another should reduce the possibility of unauthorized access or lessen the impact of the incident.
The logic is similar to protecting a vault: building security, surveillance, entry control, internal doors, authentication, alarms, and the vault itself. No barrier is considered infallible. The value lies in the combination of independent and complementary controls.
Figure 2 — Typical layers of defense in depth.
4.1 Physical security
Protects facilities, servers, network equipment, and media against physical access, theft, sabotage, fire, flood, and environmental failures. It includes guards, cameras, badge readers, barriers, sensors, redundant power, and temperature control. In cloud services, this layer is usually the provider's responsibility.
4.2 Identity and access
Confirms who or what requests access and limits the permissions granted. Typical controls include multifactor authentication, Conditional Access policies, RBAC, access reviews, and temporary privileges. This layer is decisive because valid credentials can cross firewalls without exploiting technical vulnerabilities.
4.3 Perimeter
Filters traffic at the boundary between environments. Firewalls, DDoS protection, gateways, proxies, and edge services reduce large-scale external attacks. Although the perimeter remains important, it is not sufficient to protect hybrid and distributed environments.
4.4 Network
Controls communication between segments, subnets, and resources. Segmentation, microsegmentation, security groups, routes, inspection, and traffic encryption hinder lateral movement. If a resource is compromised, the network should limit which other resources can be reached.
4.5 Compute
Protects virtual machines, containers, hosts, and runtimes. It involves patch management, reduction of ports and services, secure configurations, antimalware protection, monitoring, and controlled administrative access. Outdated or insecurely configured assets frequently become entry points.
4.6 Applications
Seeks to avoid vulnerabilities in the software. It includes secure development, code review, testing, input validation, correct authentication and authorization, dependency management, API protection, and safe error handling. Fixing flaws during development is usually less expensive and risky than fixing them in production.
4.7 Data
It is the layer closest to the asset that truly matters. Classification, labeling, access control, encryption, data loss prevention, backup, and auditing protect the information even when other controls fail. Well-classified and encrypted data keeps its own protection as it circulates through different environments.
4.8 Preventive, detective, and corrective controls
Types of security control.
Type
Objective
Examples
Preventive
Avoid or reduce the chance of an event.
MFA, least privilege, firewall, encryption, hardening.
A mature architecture combines these categories. Only preventing is insufficient, because controls can fail. Only detecting is also insufficient, because the damage may occur before the response. Defense in depth seeks a balance between prevention, visibility, containment, and recovery.
5. The CIA triad: confidentiality, integrity, and availability
The CIA triad represents three fundamental properties that information security seeks to preserve. It works as a lens for assessing threats, controls, and impacts. A single incident can affect one, two, or all three properties.
5.1 Confidentiality
Confidentiality means preventing information from being seen or disclosed to unauthorized people, systems, or processes. Personal data, trade secrets, financial records, credentials, and internal communications require different levels of protection.
Confidentiality controls include authentication, authorization, least privilege, encryption, classification, segmentation, and data loss prevention. A breach occurs when someone accesses content they should not, even if they do not modify it.
5.2 Integrity
Integrity means keeping information correct, complete, and altered only by authorized processes. It also involves the ability to detect modifications. A fraud that changes the value of a transaction, malware that alters a file, and a software bug that corrupts records all affect integrity.
Hashes, digital signatures, transaction controls, versioning, audit logs, and write permissions help protect this property. Integrity is not a synonym for confidentiality: a file can be public and still need a guarantee that it has not been tampered with.
5.3 Availability
Availability means ensuring that systems and data are accessible to authorized users when needed. DDoS attacks, ransomware, hardware failures, deployment errors, and disasters can interrupt services.
Redundancy, load balancing, availability zones, failover, backups, disaster recovery, monitoring, and adequate capacity contribute to this property. A backup only protects availability when it can be restored within the time required by the business.
5.4 Balance and risk-based decisions
The three properties can create tensions. Very strict access controls can hinder work; high availability may require copies of data in several regions; strong encryption requires careful key management so as not to make the content inaccessible. For this reason, security does not mean maximizing a single objective, but balancing confidentiality, integrity, and availability according to the risk and criticality of the service.
Impact of incidents on the CIA triad.
Situation
Most affected property
Associated control
Exposure of a customer registry
Confidentiality
Access control, classification, and encryption.
Improper alteration of a transaction
Integrity
Signature, hash, auditing, and separation of duties.
Portal unavailable after a DDoS attack
Availability
DDoS protection, scalability, and redundancy.
Ransomware encrypts files and backups
Availability and integrity
Isolated backups, endpoint protection, and tested recovery.
An encryption key is lost
Availability
Management, backup, and secure key rotation.
6. Zero Trust
Zero Trust is a security strategy based on the idea that no request should be automatically trusted for being inside a network, coming from a known device, or using a valid credential. Access must be authenticated, authorized, and re-evaluated based on context and risk. It is not a specific product, but a model that guides policies and architecture.
The model gained importance as the traditional perimeter lost effectiveness. In 2020, NIST published the Zero Trust Architecture SP 800-207, consolidating principles and deployment models. Microsoft's approach translates these fundamentals into three guiding principles and seven interconnected pillars.
Figure 3 — Zero Trust principles and pillars presented in summarized form.
6.1 Verify explicitly
Each decision should use all available signals: identity, authentication method, location, device, compliance, sign-in risk, application, resource type, data sensitivity, and observed behavior. A correct password is just one signal; on its own, it does not prove that the request is legitimate.
In practice, an access attempt from an unusual country, on an unmanaged device, and for a financial application may require additional MFA, limit the session, or block access. The goal is not to distrust people, but to technically verify each context.
6.2 Use least privilege access
Users, applications, and services should receive only the necessary permissions, in the necessary scope, and for the necessary time. Just-in-Time access grants privileges temporarily; Just-Enough-Access limits which operations can be performed. Both reduce the surface available to an attacker who compromises an identity.
Least privilege also requires review. A permission that was necessary in the past may become excessive after a role change, project completion, or offboarding. Identity governance and periodic reviews keep the model up to date.
6.3 Assume breach
Assuming breach means designing the environment while recognizing that credentials can be stolen, devices can be compromised, and vulnerabilities can exist. For this reason, the organization segments networks, limits lateral movement, encrypts data, collects telemetry, prepares response, and tests recovery.
The principle does not express pessimism; it expresses resilience. If the environment is designed as if an external defense could fail, the failure of a component does not automatically turn into total compromise.
6.4 The seven pillars
The seven pillars of Zero Trust.
Pillar
Main question
Examples of controls
Identities
Who or which service requests access?
MFA, identity risk, least privilege, Conditional Access.
Devices
Is the equipment healthy and compliant?
Management, posture, updates, threat detection.
Applications
Is the application authorized and are its permissions adequate?
How will signals be correlated and turned into response?
SIEM, SOAR, central telemetry, playbooks, and automation.
Zero Trust does not mean blocking everything
It means making explicit, contextual, and continuously verified access decisions, offering enough access for work without creating permanent trust.
7. Cryptography, digital signatures, and hashing
Cryptography transforms readable data into a representation that cannot be understood without the appropriate key. It is used to protect confidentiality and, when combined with authentication and integrity mechanisms, can detect tampering. Security depends not only on the algorithm but also on the generation, protection, rotation, and revocation of the keys.
7.1 Symmetric encryption
In symmetric encryption, the same key is used to encrypt and decrypt. It is efficient and suitable for large volumes, such as disks, databases, backups, and communication sessions. The main challenge is sharing and protecting the key without exposing it.
AES is a widely used example. In the context of the SC-900, it is not necessary to compute algorithms; it is important to recognize that symmetric encryption is fast, uses a shared key, and depends on secure management of that key.
7.2 Asymmetric encryption
In asymmetric encryption, each entity has a pair of mathematically related keys: a public one, which can be distributed, and a private one, which must remain protected. Data encrypted with the corresponding public key is decrypted with the private key.
This model helps with the secure establishment of keys, with certificates, with protocols such as TLS, and with digital signatures. Because it is more computationally expensive, systems commonly combine asymmetry for authentication and secret exchange with symmetric encryption to protect the main volume of data.
7.3 Digital signatures
The digital signature uses asymmetric encryption to provide authenticity and integrity. In a simplified way, the sender signs with the private key and the recipient verifies with the public key. If the data is modified, verification fails. Signing is not the same as encrypting: signing does not necessarily make the content secret.
Authenticity: helps confirm the origin of the signature.
Integrity: helps detect alteration after the signature.
Non-repudiation: in certain legal and technical contexts, it reinforces the evidence of authorship, provided that keys and identities are properly managed.
7.4 Key management
An exposed key can nullify the protection of encrypted data. The lifecycle includes secure generation, separate storage, access control, backup where applicable, rotation, auditing, and destruction. HSMs protect cryptographic material in tamper-resistant hardware, while services such as Azure Key Vault centralize keys, secrets, and certificates.
Do not store keys together with the protected data.
Limit access by identity and least privilege.
Rotate keys and certificates before expiration or upon suspicion of compromise.
Log administrative and usage operations of the keys.
Plan recovery to avoid permanent loss of access to the data.
7.5 Hashing
Hashing applies a one-way function to an input and produces a fixed-size summary, also called a digest. The same input generates the same result with the same algorithm, while a minimal change produces a different summary. Unlike encryption, the hash was not designed to be reversed and does not depend on a key for its basic operation.
Hashes are used to verify file integrity, support digital signatures, index data, and store password verifiers. For passwords, the system should not simply apply a fast, generic function. It should use algorithms appropriate for password derivation, with a unique salt and adjusted computational cost, reducing brute-force attacks and precomputed tables.
7.6 Salt and password storage
Salt is a random value associated with each password before processing. Two users with the same password come to have different results. This prevents an attacker from reusing a single table of precomputed hashes for all records. The salt does not need to be secret, but it must be unique and unpredictable.
Essential distinction
Encryption is reversible with the appropriate key. Hashing is one-way and normally serves for verification, not for recovering the original value.
Comparison of cryptographic mechanisms.
Mechanism
Reversible?
Uses a key?
Typical purpose
Symmetric encryption
Yes
A shared key
Protect large volumes of data.
Asymmetric encryption
Yes, depending on the operation
Public/private pair
Secure exchange, authentication, and secret protection.
Digital signature
Does not recover a secret; it is verified
Public/private pair
Authenticity and integrity.
Hashing
No, in its basic form
No
Integrity, comparison, and verification.
HMAC
No
Secret key
Authenticity and integrity of messages between parties that share a secret.
Cryptography checklist
Choose the mechanism according to the objective: secrecy, integrity, or authenticity.
Protect and rotate keys, secrets, and certificates.
Use current algorithms and protocols, avoiding your own implementations.
Combine cryptography with access control, monitoring, and governance.
8. Data at rest, in transit, and in use
Protection must follow the state of the data. A file can be stored, be transmitted through an API, and then be loaded into memory for processing. Each phase presents different risks and controls.
Figure 4 — Data states and associated protection controls.
8.1 Data at rest
This is data stored on disks, databases, backups, snapshots, persistent queues, and storage accounts. Encryption at rest reduces the impact of media loss, improper access to storage, or unauthorized copying. It is necessary to consider who controls the keys, how rotation occurs, and which identities can decrypt.
8.2 Data in transit
This is data moving between browser and server, application and API, cloud services, local networks, and external environments. TLS, HTTPS, VPNs, and authenticated channels protect against interception and tampering. Digital certificates help establish trust in the identity of the accessed service.
A frequent mistake is to protect only Internet traffic and ignore internal communication. In Zero Trust, internal networks are also considered untrusted by default, and end-to-end encryption reduces the risk of eavesdropping and lateral movement.
8.3 Data in use
This is data loaded into memory or processed by the CPU. Traditionally, it needs to be decrypted for processing, creating a window of exposure. Confidential computing and trusted execution environments use hardware-backed isolation to protect data during processing, including against privileged system components in certain scenarios.
8.4 Encryption does not replace access control
If an authorized user is granted permission to decrypt data, encryption has fulfilled its technical function, even if the permission was granted improperly. For this reason, encryption must be combined with strong identities, least privilege, classification, monitoring, and governance. Effective security depends on the combination, not on an isolated mechanism.
9. Governance, risk, and compliance (GRC)
GRC brings together practices to direct the organization, understand uncertainties, and demonstrate that obligations are being met. The integration prevents policies, audits, risks, and controls from being treated as disconnected activities. Governance defines direction and responsibility; risk guides priorities; compliance demonstrates adherence to requirements.
9.1 Governance
Governance is the system of rules, processes, decision-making structures, and responsibilities used to direct and control the organization. In security, it defines who approves access, how data is classified, which standards should be adopted, who owns each control, and how exceptions are handled.
Policies: high-level statements about what should be done.
Standards: mandatory, measurable requirements, such as minimum versions or permitted algorithms.
Procedures: operational steps to perform an activity.
Guidelines: recommendations that guide decisions when there is no rigid obligation.
Roles and responsibilities: definition of owners, approvers, operators, and auditors.
A policy without an owner and without a verification mechanism rarely produces a result. Effective governance connects decision, execution, evidence, and accountability.
9.2 Risk
Risk is the possibility of an event affecting objectives. In security, it is usually analyzed by the combination of likelihood and impact, considering threats, vulnerabilities, assets, and controls. The goal is not to eliminate all risk, which would be unfeasible, but to keep it within the appetite and tolerance defined by the organization.
Identify assets, processes, threats, vulnerabilities, and dependencies.
Assess likelihood, impact, and the effectiveness of existing controls.
Prioritize risks according to criticality and business context.
Respond through mitigation, acceptance, transfer, or prevention.
Monitor changes and continuously review the assessment.
Forms of risk response.
Risk response
Meaning
Example
Mitigate
Reduce likelihood or impact with controls.
Require MFA and restrict administrative privileges.
Accept
Acknowledge and keep the risk within tolerance.
Accept a brief unavailability of a non-critical system.
Transfer
Share part of the impact with a third party.
Cyber insurance or contractual clauses.
Avoid
Remove the activity that generates the risk.
Do not store unnecessary data or disable an insecure service.
Inherent risk is the risk before controls; residual risk is what remains after them. The fact that a control exists does not mean the risk has disappeared. The organization needs to know whether the residual risk is acceptable and to monitor it.
9.3 Compliance
Compliance is adherence to applicable laws, regulations, contracts, standards, and policies. Requirements vary by country, sector, type of data, and service. Examples include privacy laws, information security standards, and customers' contractual requirements.
Compliance is not a synonym for security. An organization can present evidence that it meets a minimum set of requirements and still maintain important risks not covered by the standard. Security is broader and adaptive; compliance defines obligations that need to be demonstrated.
A phrase to memorize
Compliance helps prove that requirements were met. Security seeks to reduce real risks, including those that have not yet been turned into a formal obligation.
9.4 Controls, evidence, and auditing
A control is an administrative, technical, or physical safeguard. To demonstrate compliance, it is necessary to produce evidence: approved policies, access logs, configuration reports, test results, review minutes, and audit trails. Auditing assesses whether controls were adequately designed and whether they operated as expected during a period.
In the cloud, the shared model affects auditing. The provider presents evidence relating to the infrastructure under its responsibility; the customer needs to demonstrate configurations, identities, data, and processes under their control. Provider certifications do not automatically make the customer's workload compliant.
10. Data residency, sovereignty, and privacy
These terms are related, but they answer different questions. Confusing them can lead to mistaken technical and legal decisions. The SC-900 expects the candidate to recognize the conceptual distinction.
10.1 Data residency
Data residency concerns the physical or geographical location where information is stored and, depending on the requirement, processed or transferred. An organization may require that certain records remain in a region, country, or set of datacenters. When choosing cloud services, it is necessary to verify which components are regional, which are global, and which contractual commitments apply.
Selecting a region does not by itself resolve all requirements. Logs, backups, metadata, support, replication, and dependent services may have their own rules. The analysis must consider the complete architecture and the specific documentation of the service.
10.2 Data sovereignty
Data sovereignty refers to the subjection of data to the laws and authority of the jurisdiction related to the location of collection, storage, or processing. It involves not only “where the data is”, but who can exercise legal authority, who operates the infrastructure, how administrative access is controlled, and which mechanisms exist to maintain autonomy and continuity.
In global operations, a single set of data may involve several jurisdictions. The organization needs to understand conflicts of laws, international transfers, and contractual responsibilities. Digital sovereignty is a broader topic and can include operational control and technological independence.
10.3 Data privacy
Privacy concerns the appropriate use of personal data: which information is collected, for what purpose, on what legal basis, for how long, with whom it is shared, and which rights the data subject can exercise. Personal data includes direct identifiers, such as name and document, and information that can identify someone indirectly, such as location, behavior, and combinations of attributes.
Common privacy principles include transparency, purpose, minimization, quality, security, limited retention, and respect for the data subject's rights. In Brazil, the LGPD establishes specific obligations; in other contexts, laws such as the GDPR may apply. The technical team must turn legal requirements into controls for identity, classification, retention, auditing, and protection.
10.4 Direct comparison
Residency, sovereignty, privacy, and security.
Concept
Question it answers
Example
Residency
Where is the data stored or processed?
Records must remain in a certain geography.
Sovereignty
Which laws, authorities, and jurisdictional controls apply?
Data hosted in a country is subject to its rules and legal mechanisms.
Privacy
How can personal data be collected, used, shared, and kept?
Collect only what is necessary, inform the purpose, and allow the exercise of rights.
Security
How to protect against access, alteration, loss, and unavailability?
MFA, encryption, segmentation, backup, and monitoring.
A service can meet a residency requirement and still require analysis of sovereignty and privacy. Likewise, data can be strongly encrypted and, even so, be used for a purpose incompatible with the law or with the consent obtained. Security and privacy complement each other, but they are not equivalent.
11. How the concepts connect
The concepts in this chapter form a decision chain:
Shared responsibility identifies who should operate each control.
Governance defines policies, owners, standards, and acceptance criteria.
Risk assessment prioritizes which threats and assets require more protection.
Defense in depth distributes physical, administrative, and technical controls.
The CIA triad establishes which properties must be preserved.
Zero Trust decides access based on context, least privilege, and assumption of breach.
Cryptography and hashing protect confidentiality, integrity, and authenticity across different states of the data.
Compliance and privacy require evidence that controls and processes meet the obligations.
Consider a company that stores confidential documents in SaaS. The provider protects the datacenter, servers, and application. The company configures identities, MFA, Conditional Access, labels, sharing, and retention. Defense in depth protects the device, the session, the application, and the document. Zero Trust assesses the risk of the access. Cryptography protects transmission and storage. GRC defines policy, records risk, collects evidence, and demonstrates compliance. No isolated piece would solve the scenario.
12. Common traps in the SC-900
Incorrect statements and how to correct the reasoning.
Incorrect statement
How to correct the reasoning
“When migrating to the cloud, the customer stops being responsible for security.”
The responsibility changes in distribution, but data, identities, access, and configurations remain with the customer.
“SaaS means that the provider controls who can access the company's data.”
The provider operates the application; the customer manages users, permissions, and tenant policies.
“A hash is a form of encryption that can be decrypted.”
Hashing is one-way; encryption is reversible with the appropriate key.
“A digital signature is mainly used to hide the content.”
A signature provides authenticity and integrity; confidentiality requires encryption.
“Zero Trust is a Microsoft product.”
It is a strategy and an architectural model implemented by different technologies.
“Compliance guarantees complete security.”
Compliance demonstrates that requirements are met; additional risks can still exist.
“Residency and sovereignty are synonyms.”
Residency concerns location; sovereignty concerns jurisdiction, authority, and control.
“Encryption solves excessive permissions.”
Authorized users can access decrypted data; access control is still necessary.
13. Integrated scenario: a cloud service portal
An organization develops a portal for customers. The interface and the APIs are hosted in PaaS; documents are stored in a storage service; employees access the system through corporate devices; customers use a browser and external authentication.
13.1 Shared responsibility
Microsoft protects datacenters, hosts, virtualization, operating system, and runtime of the PaaS.
The organization protects code, configurations, identities, permissions, data, integrations, and devices.
The organization must confirm the regional options and residency commitments applicable to the chosen services.
13.2 Defense in depth
Identity: MFA for employees and risk-based policies.
Perimeter: WAF and DDoS protection.
Network: private connectivity and restrictions between services.
Application: input validation, API protection, and dependency management.
Data: classification, encryption, sharing controls, and backup.
Detection: centralized logs, alerts, and investigation.
13.3 Zero Trust
Administrative access is granted temporarily and requires a compliant device. A sign-in from an unusual location raises the risk and requires additional verification. Services use their own identities, without secrets embedded in the code. The network is segmented and each application has only the necessary permissions.
13.4 Cryptography and data states
Documents are encrypted at rest; connections use TLS; keys and secrets are stored in a dedicated service; logs do not record sensitive content. For high-sensitivity operations, the organization evaluates confidential computing capabilities. Hashes and signatures help verify the integrity of artifacts and messages.
13.5 GRC and privacy
Governance defines owners, retention policy, and approval process. Risk assessment considers leakage, unavailability, and fraud. Controls are mapped to legal and contractual obligations. The privacy notice informs purpose and retention; only necessary data is collected; data subject requests are handled through a documented process.
Scenario outcome
Security arises from the combination of architecture, identity, configuration, data protection, and governance. The provider delivers a secure base; the customer needs to turn it into a secure solution.
14. Quick review for the exam
Summary of the chapter's topics.
Topic
What to memorize
Shared responsibility
On-premises: the customer does everything. IaaS: the customer manages the OS and applications. PaaS: the customer manages code, configuration, and data. SaaS: the customer manages access, data, and configurations.
Defense in depth
Multiple overlapping layers; the failure of one layer should not result in total compromise.
CIA
Confidentiality = prevent disclosure; Integrity = prevent or detect alteration; Availability = maintain access when needed.
Zero Trust
Verify explicitly, use least privilege, and assume breach.
Cryptography
Symmetric uses the same key; asymmetric uses a public/private pair; a signature protects authenticity and integrity.
Hashing
One-way, without decryption; used for integrity and verification. Passwords require a salt and an appropriate function.
Data states
At rest, in transit, and in use require different controls.
Physical location; jurisdiction and control; handling of personal data.
15. Conclusion
The fundamentals of security and compliance begin with clarity. Before choosing tools, the organization needs to know which assets it protects, who is responsible for each layer, which risks are acceptable, and which obligations need to be demonstrated. The shared responsibility model prevents the cloud from being treated as a total outsourcing of security. Defense in depth acknowledges that controls fail. The CIA triad defines the objectives. Zero Trust turns context and risk into access decisions. Cryptography and hashing protect data and integrity. GRC connects technology to strategy, legislation, and accountability.
In my assessment, this chapter is the most important foundation of the SC-900 track. The Microsoft products studied in the following chapters make more sense when the reader understands which problem each one solves. Microsoft Entra strengthens identity and access; Defender and Sentinel support prevention, detection, and response; Purview contributes to protection, governance, and compliance. Without the fundamentals, these names look like a catalog. With the fundamentals, they become components of a coherent architecture.
The natural next step is to go deeper into identity as the new security perimeter. The question stops being only “did the connection come from inside the network?” and becomes “who is requesting access, in what context, with what risk, and for which resource?”. This change leads directly to the concepts of authentication, authorization, identity providers, directories, and federation that support the rest of the SC-900.
16. Review questions
Question 1
A company uses a virtual machine in Azure. Who is responsible for applying updates to the guest operating system?
A) Only Microsoft, because the host is in Azure.
B) The customer, because in IaaS they manage the guest operating system.
C) The manufacturer of the installed application.
D) The responsibility cannot be determined.
Commented answer key
Correct answer: B. In IaaS, the provider protects the physical infrastructure and virtualization; the customer manages the VM's operating system, its configurations, and applications.
Question 2
Which Zero Trust principle recommends granting only the necessary permissions and for the necessary time?
A) Verify explicitly.
B) Assume breach.
C) Use least privilege access.
D) Trust the corporate perimeter.
Commented answer key
Correct answer: C. Least privilege includes limiting scope, duration, and permitted operations, using approaches such as JIT and JEA.
Question 3
Which statement correctly differentiates hashing from encryption?
A) Hashing always uses a private key.
B) Hashing is designed to be reverted by the administrator.
C) Encryption cannot protect data in transit.
D) Hashing is one-way and serves for verification; encryption is reversible with the appropriate key.
Commented answer key
Correct answer: D. Hashing produces a summary for comparison and integrity; encryption transforms data and allows recovery with the appropriate key.
Question 4
Which option describes data sovereignty?
A) The time during which a file must be kept.
B) The laws, authorities, and jurisdictional controls that apply to the data.
C) The algorithm used to encrypt a disk.
D) The number of backup copies in different regions.
Commented answer key
Correct answer: B. Sovereignty involves jurisdiction, authority, and control; residency focuses on the physical or geographical location of the data.
SC-900 study plan provided by the user: Chapter 1 - Foundations of Security, Compliance, and Cloud Responsibility.
Note: service names, exam scopes, and documentation may be updated by Microsoft. Before the exam, consult the current official guide and the date of the localized version of the exam.
