SC-100: Protecting Data Across Clouds and Apps

A healthcare analytics company moves patient-related information from a private data center into cloud storage, a managed database, and a reporting service used by external partners. The migration team focuses on encrypting each destination. Six months later, security discovers that a development environment holds a full copy of production data and an overly broad service identity can export it. Every platform may have used encryption, yet the overall data protection design failed to control where information traveled and who could use it.

The SC-100 exam expects the cybersecurity architect to design security for applications and organizational data across Microsoft 365, Azure, and hybrid environments. Microsoft’s July 2026 objectives include discovery and classification, encryption, cloud data services, AI workloads, Defender protections, and data security through Microsoft Purview. These are interconnected responsibilities. Data security cannot be reduced to one storage setting or one compliance label.

Start with the data’s purpose and movement

Architecture begins by understanding which information exists, why the business uses it, and where it goes. A health service may retain clinical records, invoices, appointment metadata, aggregated performance reports, and operational logs. The information has different sensitivities and retention needs. Before selecting controls, identify the owner of each major dataset, the systems that store it, the processing performed on it, and the recipients permitted to access the results.

Data flows reveal gaps that a static inventory may miss. An application could read protected records from an approved database and write a debug file to an unprotected storage account. A reporting pipeline could create an extract that is copied to an analyst’s desktop. A test environment could import a production backup containing direct identifiers. If the architecture considers only the primary database, all these secondary paths remain exposed. A useful data-flow model follows the information through ingestion, transformation, analysis, export, and deletion.

The model should describe trust boundaries, not just arrows. Moving data into a managed Azure service changes operational responsibility but does not settle who can query it, what identity the service trusts, or how the output is shared. For regulated workloads, establish which transfers are legitimate and which should trigger a prevention control or investigation. The intended business purpose should justify each significant movement.

Classification must lead to enforceable handling rules

Labels are valuable only when they change behavior appropriately. A dataset containing personal records might require limited access, stronger monitoring, defined retention, and special review before external sharing. General operational information may allow wider internal collaboration. Organizations should design a classification vocabulary that employees can use consistently and map it to concrete controls rather than create dozens of categories nobody understands.

Automated discovery can help locate sensitive data in unexpected places, but it will not always recognize context. A list of names may be ordinary staff directory information or part of a highly confidential case record. Classification and privacy review should consider purpose, legal obligations, and likely harm, not rely solely on pattern matching. The architect needs a process for correcting misclassification and deciding what happens when detection confidence is low.

Microsoft Purview brings capabilities for information protection and compliance, but product deployment follows policy design. Teams need to know who may label or relabel content, which external-sharing rules apply, and how exceptions are approved. The practical operation of these data protection controls is closely associated with SC-401; SC-100 examines whether the design fits the organization’s broader data and application architecture.

Encryption protects a particular risk, not every risk

Encryption at rest can reduce exposure if storage media or underlying data stores are accessed improperly. Encryption in transit can help protect information as it moves between systems. Neither prevents a legitimate but overprivileged application identity from reading sensitive content and sending it to an unauthorized destination. Nor does encryption guarantee that a developer will not write decrypted information into logs. Threat modeling should identify what each control protects and where it stops being effective.

Key management is a critical design choice. Applications need access to keys or key operations, but administrators of the workload should not automatically control every aspect of the key lifecycle. Azure Key Vault and related technologies can centralize management of secrets and cryptographic material, yet the architecture must still define authorization, rotation, recovery, audit events, and separation of duties. If a key becomes unavailable during an incident, dependent systems may become inaccessible even when their data remains intact.

The distinction between different encryption approaches helps explain why system designs use different mechanisms for bulk data and identity or key exchange. The architect does not need to reinvent cryptography. The responsibility is to choose appropriate supported protections, keep key use controlled, and verify that cryptographic boundaries correspond to the actual flow of sensitive data.

Apply consistent controls across cloud data services

Storage accounts, managed relational databases, and globally distributed databases expose different access paths and security features. Azure SQL, Azure Synapse Analytics, Azure Cosmos DB, and Azure Storage should not be configured by copying one generic checklist. The design must account for resource authentication, networking, encryption, auditing, operational access, backup, and the way each service presents data to applications.

Consider a reporting application that reads from a production database and writes aggregated files into storage. A narrow workload identity may be able to query only the required dataset and write only to the intended destination. A network restriction reduces where the service can be reached; an authorization policy controls what the authenticated identity may do. Monitoring helps detect queries or exports outside expected patterns. Each control addresses a different weakness, and none should be assumed to make another unnecessary.

Data security should also survive replication and restore. A protected production database can lose its intended boundary when its backup is restored into an environment with weaker access policies. Recovery procedures need to preserve classification, access, audit, and deletion requirements where applicable. The same principle applies to snapshots, archived exports, and temporary processing systems used during migration.

Applications and APIs can defeat a strong storage design

Even when the data store is well protected, an application may expose excessive information through an endpoint or authorization flaw. The security architect should examine user-to-application authentication, workload identity, API permissions, input validation, egress controls, and development practices. Sensitive information displayed in a user interface may be copied into browser caches or support logs; data protection must follow the application path as well as the database.

Threat modeling is valuable because it asks who could misuse a capability, not only whether a product is configured according to a standard. A multi-tenant application may correctly authenticate every user and still fail to constrain each user to the right tenant’s records. An API can require a token but accept a token with broader permissions than the calling workflow needs. Testing authorization boundaries is therefore as important as testing successful access.

Controls should be positioned at several levels. Application policies limit business actions; identity governs service-to-service permissions; network rules reduce exposure; data classification and protection help shape handling; monitoring identifies abnormal patterns. Together these layers create opportunities to prevent or detect misuse that would bypass any single mechanism. The goal is not maximum control count but coverage of the actual business data paths.

Protect AI workloads without assuming they are ordinary search

AI systems introduce additional patterns of information use. A user may submit confidential data in a prompt, a retrieval system may bring internal documents into the model’s context, and the generated answer may summarize protected material for a different audience. The architecture must evaluate who can submit queries, which sources can be retrieved, and what information may be disclosed in responses. Existing file permissions matter, but they do not eliminate the need to review prompt content, retrieved context, and sharing behavior.

An AI assistant can also be targeted through untrusted documents containing instructions that try to redirect its behavior. The data security design should separate retrieved content from trusted operating instructions and apply appropriate monitoring and approval to consequential actions. It should also consider retention and handling requirements for prompts and generated artifacts. An assistant that helps employees find relevant internal information is still a new route through which that information is processed.

The healthcare company’s developer copy provides a useful test. If employees ask an AI assistant to analyze it, the system may generate a sensitive summary even when the underlying data was not supposed to leave the controlled development environment. The immediate fix is not simply to tell the AI to keep secrets; it is to remove the inappropriate copy, constrain access and data flows, and ensure that similar copies are detected in future.

Measure whether the boundary actually holds

Dashboards can confirm that encryption or logging is enabled, but business leaders need evidence that sensitive data remains under appropriate control. Useful measures include the share of high-risk datasets with verified owners, the time needed to identify unauthorized copies, results of access reviews, and whether critical exports are observable. These measures are meaningful only when the underlying inventory and definitions are credible.

A good architecture exercise traces one sensitive record from intake through processing, reporting, retention, and deletion. At each stage, ask which identity can act, what prevents unauthorized copying, how misuse would be detected, and who owns the exception process. Then test what happens when the data is restored from backup or referenced by an AI assistant. This exposes weaknesses that isolated product configuration questions miss.

SC-100 data protection design is successful when the organization can explain why information is held, who may use it, where it may travel, and what happens when a control fails. Encryption is essential in many cases. A defensible data boundary requires much more: classification, least privilege, careful application design, governance, and evidence that those protections survive the full information lifecycle.