Design security solutions for applications and data practice questions

Configure the database to reject unencrypted connections.

Why wrong: Configuring the database to reject unencrypted connections, via the 'Encryption' connection string property or a server-side encryption requirement, forces all traffic to be transmitted over an encrypted channel. However, this measure does not control which TLS protocol version is negotiated during the handshake; a client could still connect using deprecated TLS 1.0 or 1.1, which are weak and have known vulnerabilities. Therefore, this approach fails to guarantee the specified minimum TLS version.

Set the connection policy to Proxy and force TCP.

Why wrong: The connection policy in Azure SQL Database—either Proxy or Redirect—controls how client connections are routed (through an intermediary gateway or directly to the database) and does not influence the TLS handshake or the protocol version used. Forcing TCP is likewise irrelevant because TCP is already the underlying transport protocol for SQL connections and has no bearing on encryption settings. This option changes nothing about TLS version enforcement, so it cannot meet the requirement.

Enable 'Force SSL' on the database.

Why wrong: Enabling 'Force SSL' on the database (equivalent to requiring an encrypted connection) ensures that clients establish an encrypted session before data is exchanged. While this protects data in transit, it does not dictate the specific TLS version; a client instructing the connection with TLS 1.0 or 1.1 would still be accepted by the server if no minimum version policy is set. Thus, this approach does not guarantee that the connection uses TLS 1.2 or higher.

Azure Policy

Why wrong: Azure Policy is an Azure-native governance service that evaluates and enforces compliance rules against resource properties, such as allowed locations, SKUs, or tags, during create/update and continuously over the resource hierarchy. It does not inspect the content of blobs nor apply data classification labels; it works at the control plane and resource configuration level, not the data plane. Therefore, it cannot automatically discover or classify sensitive customer data stored in Azure Blob Storage, making it unsuitable for this requirement.

Microsoft Purview Information Protection

Why wrong: Microsoft Purview Information Protection (formerly Azure Information Protection) focuses on applying sensitivity labels and protection policies to documents and emails either manually by users or via recommended/automatic labeling rules based on patterns or custom conditions. While it can classify and protect data, it requires the data to be already scanned or labeled, and its automatic labeling typically works on files at rest on endpoints or in Microsoft 365, not by scanning Azure Blob Storage assets directly. For a central, automated scan-and-classify of blobs without user intervention, Data Map's scanning capabilities are the appropriate mechanism, not Information Protection alone.

Microsoft Purview Data Loss Prevention

Why wrong: Microsoft Purview Data Loss Prevention (DLP) is designed to detect and prevent the unintentional sharing, transfer, or exfiltration of sensitive data across services such as Exchange Online, SharePoint, OneDrive, Teams, and endpoints. DLP policies match sensitive information types in transit or in use and enforce actions like blocking or alerting, but they do not perform background scanning and classification of all assets in Azure Blob Storage for cataloging. The requirement is to automatically scan and classify stored data, which is Data Map's role; DLP is a reactive control, not a discovery/classification engine.

Microsoft 365 E3

Why wrong: Microsoft 365 E3 does include Microsoft Entra ID P1 as part of its suite, so SSPR is technically available in that subscription. However, it is not the minimum licensing option because an organization can purchase Entra ID P1 as a standalone SKU for a lower per-user cost, without paying for Exchange Online, SharePoint Online, Teams, and the other workloads bundled into E3. Using E3 solely for SSPR would be overkill and more expensive than the required baseline.

Microsoft Entra ID P2

Why wrong: Microsoft Entra ID P2 is an advanced tier that bundles everything in P1, including SSPR, but additionally provides Identity Protection, Privileged Identity Management, and risk-based conditional access policies. These extra capabilities are valuable for identity security programs, yet they exceed the stated requirement for SSPR and add significant per-user licensing cost. Since P1 already meets the SSPR need, P2 is not the minimum license despite also supporting the feature.

Microsoft Entra ID Free

Why wrong: Microsoft Entra ID Free is the built-in directory tier offered with every Microsoft cloud subscription, but it provides only basic identity management capabilities such as user/group administration and single sign-on for Microsoft services. Self-Service Password Reset (SSPR) is a premium feature that requires Azure AD Premium licensing; the Free tier lacks not only SSPR but also password writeback and fine-grained access policies. Therefore, it cannot satisfy a requirement for SSPR.

It restricts access to the database to specific IP addresses.

Why wrong: Restricting access to specific IP addresses is a network access-control function implemented at the Azure SQL logical server firewall, virtual network rules, or private endpoint connections; it is not part of Microsoft Defender for Cloud's SQL security suite. While Defender for Cloud may recommend such rules and can monitor for risky network configurations, the actual enforcement of IP restrictions is performed by the database platform's networking layer, not by the security service itself. Therefore, saying the service restricts IPs conflates its advisory and monitoring role with the platform's native firewall mechanism.

It encrypts the database at rest using TDE.

Why wrong: Transparent Data Encryption (TDE) is a distinct database encryption capability that performs real-time I/O encryption and decryption of data and log files at rest; it is not part of the Advanced Data Security (ADS) suite. While TDE is automatically enabled for new Azure SQL databases, it does not provide vulnerability scanning or threat detection, which are the hallmark features of the Defender for Cloud SQL protections. Thus, claiming that Microsoft Defender for Cloud does this via ADS confuses a separate baseline control with the security monitoring suite.

It enables automatic backup encryption.

Why wrong: Automatic backup encryption in Azure is handled by storage-level encryption and the platform's managed key infrastructure, not by Advanced Data Security. For Azure SQL databases, backups are always encrypted when the database uses TDE, but that encryption is a transitive effect of TDE, not an independent feature that Defender for Cloud enables or administers. Consequently, attributing backup encryption to Defender for Cloud misrepresents the actual separation of duties between database security monitoring and Azure Storage encryption.

Enable Azure Disk Encryption on the VMs that mount the share.

Why wrong: Azure Disk Encryption (ADE) uses BitLocker on Windows or DM-Crypt on Linux to encrypt the operating system and data disks attached to a virtual machine. It protects the VM's local disk contents, but the Azure file share is a managed cloud service whose data resides in Azure Storage infrastructure, not on the VM's disks. Consequently, enabling ADE has no bearing on the confidentiality of data stored in the file share and cannot fulfill the encryption-at-rest requirement for that share.

Configure the storage account to use HTTPS only.

Why wrong: Configuring the storage account to 'HTTPS only' (i.e., requiring secure transfer for the REST API) ensures that requests made through the Blob, Queue, Table, and File REST endpoints are encrypted via TLS. However, clients connecting to an Azure file share over the Server Message Block (SMB) protocol do not use HTTPS; they use SMB dialects such as 3.0 or newer. Therefore, this setting fails to protect SMB traffic and also does not address encryption of data at rest within the share itself, making it an incomplete and incorrect answer.

Use Azure File Sync to sync files to on-premises servers.

Why wrong: Azure File Sync is a service that synchronizes an Azure file share with one or more on-premises Windows Servers, enabling caching and distributed access. While it reduces latency and centralizes management, it does not inherently encrypt the file share data at rest in Azure. Synchronization traffic may traverse HTTP/SMB channels that could themselves be encrypted, but the service does not add any additional encryption layer to the cloud copy of the files. Thus, deploying Azure File Sync does nothing to meet the specific requirement of encrypting the sensitive documents stored in the Azure file share, making it an incorrect remedy.

Use Azure Information Protection scanner to apply labels automatically.

Why wrong: The Azure Information Protection scanner can discover and automatically label sensitive files across on-premises stores, but labeling alone does not add a watermark. Watermarks are a content-marking action defined inside a sensitivity label's protection settings; the scanner simply applies the label and does not inject any visual markings unless the label itself specifies them. Therefore, using the scanner without a properly configured sensitivity label will not produce watermarks on your content.

Create a DLP policy that blocks sharing of highly confidential content.

Why wrong: A DLP policy in Microsoft Purview is designed to detect and block unauthorized sharing of sensitive data by controlling how information flows, such as preventing users from emailing or sharing highly confidential content. It operates at the policy enforcement layer, checking conditions and taking actions like blocking or alerting, but it never modifies the underlying file or email content. Watermarking is a visual alteration that requires the content-marking capabilities of sensitivity labels, not DLP actions.

Enable Microsoft 365 Message Encryption for all emails.

Why wrong: Microsoft 365 Message Encryption (OME) encrypts email messages in transit and restricts access to intended recipients, but it does not add any watermark to the email body, headers, or attachments. Its security model focuses on transport-level confidentiality and recipient-based decryption privileges, not on visually marking or identifying the sensitivity of content. Watermarking is exclusively handled by sensitivity label content-marking features, so enabling OME across all mailboxes does not meet the requirement to add watermarks.

Implicit grant

Why wrong: The implicit grant was originally designed for browser-based SPAs, but it places the access token directly in the URL fragment, making it vulnerable to token leakage through browser history, referrer headers, and malicious scripts. It also cannot issue refresh tokens, forcing token re-acquisition and increasing attack surface, which is why Microsoft has deprecated it for all customers. Therefore, this flow should not be used to secure access to backends exposed via Azure API Management.

Resource owner password credentials grant

Why wrong: The resource owner password credentials (ROPC) grant requires the application to directly collect and handle a user's username and password, which is an anti-pattern because it circumvents advanced Azure AD features like conditional access and multi-factor authentication. ROPC is also incompatible with federated identity providers and works only with organizational accounts, not personal Microsoft accounts or social identities. Because of these limitations, Microsoft explicitly recommends against ROPC, making it invalid for this SPA scenario.

Client credentials grant

Why wrong: The client credentials grant is intended for confidential clients, such as daemons or server-side services, that need to authenticate and obtain tokens without a user context. In this scenario, user authentication is required to access backend APIs, and client credentials cannot represent an individual user, so they cannot enforce user-level authorization or meet the requirements of a SPA. Therefore, this grant is unsuitable for API Management when the goal is user-based access.

Microsoft Monitoring Agent (MMA)

Why wrong: Microsoft Monitoring Agent (MMA) is the legacy agent that has been deprecated in favor of the Azure Monitor Agent. It was originally designed for on-premises and Azure VMs, but its architecture relies on the Log Analytics workspace gateways and custom performance counters that are now outdated. New Sentinel deployments should not use MMA because it will be retired and lacks the modern data collection rules and multi-homing capabilities of AMA.

Log Analytics agent

Why wrong: The Log Analytics agent is effectively the same legacy agent as MMA, just under a different name when deployed for Log Analytics workspaces. It is not a separate or modern solution for Sentinel; it shares the same retirement timeline and limitations as MMA. Unlike Azure Monitor Agent, it cannot use data collection rules for granular, per-data source filtering, nor does it support advanced features like Windows Event forwarding or Azure Arc over a single unified pipeline.

Microsoft Defender for Cloud agent

Why wrong: Microsoft Defender for Cloud agent is purpose-built to collect security-related telemetry for Defender for Cloud's posture and threat detection, not to ingest all Windows event logs and custom logs needed by Sentinel. While it may forward some security events, it does not provide the comprehensive data collection of the Azure Monitor Agent, which can gather Windows Event logs, Syslog, custom JSON, and performance counters under flexible data collection rules. Relying on this agent would leave Sentinel starved of the broad telemetry it needs for full visibility.

Certificate-based authentication using Azure Key Vault

Why wrong: Certificates stored in Azure Key Vault can authenticate, but they are static credentials, not a managed identity. The application must manage certificate acquisition, renewal, and distribution, and the JWT claims do not come from an Azure AD pod-level identity. This approach reintroduces secret-management and rotation overhead, and does not provide automatic pod-scoped Azure AD tokens.

System-assigned managed identity on the cluster

Why wrong: The system-assigned managed identity is tied to the entire AKS cluster resource and is used by the control plane for operations such as image pulls and resource provisioning. It cannot be scoped to individual pods, so all workloads would share the same high-privileged cluster identity, violating least-privilege principles. Pod-level authentication requires a separate identity per pod or per microservice, which AAD Pod Identity provides.

Service principal with client secret

Why wrong: Using a service principal with a client secret requires storing the secret in Kubernetes secrets, environment variables, or mounted files, creating a significant leak and rotation burden. Unlike a managed identity, the client secret must be renewed periodically and distributed securely to every pod replica. Managed identities eliminate this because Azure AD issues tokens automatically without any stored credentials.

Implement client-side encryption using the .NET SDK.

Why wrong: Client-side encryption using the .NET SDK encrypts data in the application before transmission, but it does not address at-rest encryption of Cosmos DB's persisted data. At-rest encryption is a storage-layer guarantee that operates on the data after it is written to disk, independent of client-side operations. Moreover, client-side encryption introduces key management complexity and can hinder querying since the database cannot natively parse encrypted fields.

Enable Azure Disk Encryption on the VMs that access Cosmos DB.

Why wrong: Azure Disk Encryption (ADE) encrypts the OS and data disks of virtual machines, protecting data held on VM-local storage. Cosmos DB, however, is a fully managed database platform where data resides in Microsoft's own storage infrastructure, not on your VM disks. Enabling ADE on the accessing VMs has no effect on the encryption of Cosmos DB data at rest, making this option irrelevant to the requirement.

Turn off automatic encryption and use a custom encryption algorithm.

Why wrong: Azure Cosmos DB always encrypts all data at rest automatically using server-side encryption; there is no option to disable this encryption or plug in a custom algorithm. The underlying storage is managed by Microsoft, and you cannot alter the encryption implementation—only the key management approach (Microsoft-managed vs. customer-managed) is configurable. Attempting to turn off automatic encryption is not supported and would violate the service's security guarantees.

Require device encryption on all devices.

Why wrong: Requiring device encryption protects data at rest by scrambling storage, but it does nothing to detect or remediate active threats such as malware, network attacks, or compromised devices. Encryption is a static compliance control; it cannot block a device that is already infected or exhibiting risky behavior. In this scenario, the goal is to stop risky devices from accessing corporate resources, which requires real-time threat assessment rather than a cryptographic safeguard.

Deploy a device compliance policy that requires a PIN.

Why wrong: A compliance policy that requires a PIN establishes a baseline for device authentication, but it does not evaluate the security posture of the device or detect threats such as malware, suspicious network activity, or tampering. Compliance policies are prerequisites for access, not dynamic risk-based controls. A PIN alone cannot block a device that is already compromised; it merely ensures the device has a simple lock screen. Therefore, it does not address the requirement to block risky devices.

Configure IP firewall rules to restrict access.

Why wrong: IP firewall rules operate at the network layer, filtering traffic based on the source IP address or virtual network of the client attempting to reach the storage account endpoint. They do not authenticate or authorize the caller; a user who connects from an allowed IP still requires an identity-based permission (RBAC, ACL, SAS, or account key) to read or write data. Thus, IP rules are a network security control, not a data-plane authorization mechanism.

Use managed identities for Azure resources.

Why wrong: Managed identities are Azure-issued service principals that provide an automatically rotated, secure identity for Azure resources like VMs, Logic Apps, and Function Apps to authenticate to services. They are a form of authentication, not an authorization method; authorization still requires assigning permissions to that identity (e.g., via RBAC or ACLs) before it can access storage data. Therefore, choosing managed identities alone does not grant any access — you must still explicitly assign a role such as Storage Blob Data Contributor, making this option incomplete for the authorization question.

Generate shared access signatures (SAS) for delegated access.

Why wrong: A shared access signature (SAS) is a cryptographically signed URI token that grants scoped, time-limited access to specific resources, but it is a delegation mechanism created from root credentials (account key, user delegation key, or stored access policy), not a permanent, identity-based authorization method. SAS tokens must be managed, rotated, and guarded like secrets, and they default to no integration with Microsoft Entra ID, so they aren't suitable for long-lived, identity-managed access. While user-delegation SAS can be backed by Microsoft Entra credentials, the design intent is short-lived client access, not the continuous authorization of security principals that RBAC/ACLs provide.

The policy must be assigned at the management group scope.

Why wrong: Policy assignment scope is flexible: it can be a management group, subscription, or resource group. Assigning at the management group is useful for broad, cross-subscription enforcement, but it is not a requirement for a policy that enables TDE. The policy will function identically at subscription or resource group scope as long as the relevant SQL servers/databases are in scope. Therefore, the statement is incorrect.

The database must be newly created.

Why wrong: Azure Policy evaluates both new and existing resources, so a TDE-enabling policy can remediate already-deployed databases, not only newly created ones. The Modify effect can trigger a remediation task that enables TDE on every matching SQL database in scope regardless of creation date. There is no policy logic that filters by resource age or creation time. Hence, the database need not be newly created for the policy to succeed.

The SQL database must be using the General Purpose service tier.

Why wrong: Transparent Data Encryption is available in every Azure SQL Database service tier, including Basic, Standard, Premium, General Purpose, Business Critical, and Hyperscale. The service tier controls performance and storage options, not the ability to enable TDE, which is a logical encryption operation at the database level. Consequently, using the General Purpose tier is not a prerequisite for the policy to work.

Accounts that have been locked out due to multiple failures.

Why wrong: The query aggregates Event ID 4625 (failed logon) records by account and computer, so it counts failure occurrences but contains no logic to evaluate the account's lockout state or to filter on lockout-specific events such as Event ID 4740. Lockout status is an Active Directory attribute or local security policy result, not something derivable from a series of 4625 events alone. Thus this query cannot report accounts that are currently locked out due to multiple failures.

Computers with more than 10 login attempts from the same IP address.

Why wrong: This query never references the source IP address field available in the 4625 event's network information; it only groups by account and computer name. To identify computers with repeated attempts from one IP, you would need to group by ComputerName and IpAddress and apply a threshold to that composite key. Simply filtering on login attempts from the same IP is impossible because the IP is not part of the query's grouping or output.

Accounts that successfully logged in more than 10 times.

Why wrong: Event ID 4625 is specific to failed logons; successful authentication is logged as Event ID 4624. Because the query filters on 4625, it only counts failures and has no mechanism to count successful sign-ins. Therefore it cannot return accounts that successfully logged in more than ten times, and any such interpretation misreads the event ID being queried.

Use a shared access signature (SAS) token stored in an environment variable

Why wrong: Storing a SAS token in an environment variable is insecure because SAS tokens are bearer credentials that grant access to anyone who obtains them, and environment variables can leak through process dumps, debugging logs, or CI/CD artifacts. Additionally, SAS tokens require manual rotation and governance, and they do not bind access to the application's Azure AD identity, which violates the principle of least privilege and creates a secret-management burden.

Enable public network access on Key Vault and restrict inbound IP addresses

Why wrong: Enabling public network access on the key vault expands the attack surface and relies on source IP filtering, a weak control because IP addresses can be spoofed or misconfigured and because it does not authenticate the calling application's identity. Moreover, this approach conflicts with the security best practice of keeping key vaults accessible only via private endpoints or trusted Azure services; the correct pattern uses managed identity with RBAC, which requires no network exposure at all.

Install a client certificate on the application server and use it to authenticate to Key Vault

Why wrong: Client certificate authentication requires you to generate, securely store, distribute, and periodically rotate certificates on every application server, which adds significant operational overhead and creates a risk of private-key compromise. While certificates offer mutual TLS, they are not natively integrated with Azure AD identity and do not replace the simpler, more secure system-assigned managed identity that Azure recommends for Azure resources; using certificates here is an outdated and more complex pattern.

Create a retention label and apply it automatically via a data loss prevention (DLP) policy

Why wrong: Retention labels are lifecycle controls that determine how long content must be kept and whether a disposition review is required; they do not encrypt data or restrict access. Additionally, a DLP policy is designed to use rules to detect and manage the transmission of sensitive data (e.g., block sharing), but it does not natively auto-apply retention labels — retention labels are auto-applied via retention label auto-apply policies that use KQL queries or sensitive info types. Neither component meets the stated need to automatically encrypt documents containing credit card numbers.

Use a trainable classifier to detect PII and apply a sensitivity label

Why wrong: Trainable classifiers are machine-learning models that must be trained on custom examples of the content you want to identify, making them suited for subjective document types (e.g., contracts or resumes) rather than predictable data patterns. Credit card numbers have a well-known structure and are detected by Microsoft 365's built-in sensitive information types (SITs) with predefined regular expressions and checksums. An auto-labeling policy for credit card data should reference the Credit Card Number SIT, not a trainable classifier, which would require extra training steps and does not provide deterministic accuracy for this entity.

Configure a manual sensitivity label policy for users to apply

Why wrong: Publishing a sensitivity label policy to users enables manual labeling through the Office apps, but the label will only be applied if each user remembers to select the label and chooses the correct one. In an automatic data classification strategy, relying on users introduces inconsistency and security gaps, especially for regulated data like credit card numbers. While manual labeling is useful for context-aware decisions, it fails the explicit requirement for automatic classification and encryption of all matching content.

Create a Conditional Access policy in Microsoft Entra ID to block the app

Why wrong: Conditional Access in Microsoft Entra ID operates at the authentication layer, so it can block sign-ins to apps that are integrated as enterprise applications. For discovered cloud apps that are not federated or registered, Conditional Access has no construct to directly block their network traffic, and it cannot prevent access that occurs outside the browser or via other authentication flows, leaving the app usable.

Use Microsoft Intune to set a compliance policy that blocks the app

Why wrong: Intune compliance policies evaluate security and configuration conditions such as device encryption, OS version, or jailbreak status, and they can trigger Conditional Access to restrict access to protected resources. They cannot identify or block a specific third-party SaaS application; even if a device is marked non-compliant, the app itself is not prevented from being launched, so this approach does not satisfy a requirement to block a discovered cloud app.

Add the app to the blocked list in Microsoft Defender for Cloud Apps

Why wrong: Adding the app to the blocked list in Defender for Cloud Apps is only a static categorization; it changes the app's status in the app catalog and affects the 'Unsanctioned' filter in reports. Without an accompanying access or session policy that references that status and specifies a 'Block' action, the list itself does not intercept or block any traffic, so enforcement never actually occurs.

Set up a Conditional Access policy in Microsoft Entra ID to block sign-ins from devices with USB activity

Why wrong: Conditional Access evaluates signals like user risk, device compliance, and location, but it has no sensor for USB activity. Even if you could query device events, Conditional Access only governs access to cloud apps at sign-in — it cannot audit or block a locally connected USB device after authentication. Therefore, it cannot fulfill the requirement to audit and block USB usage for high-risk users.

Use Microsoft Intune to create a device configuration profile that disables USB ports

Why wrong: Disabling USB via a device configuration profile is a blunt instrument: it blocks all removable storage for every user, preventing legitimate business use and introducing operational friction. It also produces no audit trail, so you cannot monitor which users attempted to use USB or enforce granular policies based on risk. Microsoft Defender for Endpoint's device control delivers targeted, audited enforcement instead of a global off switch.

Configure a Microsoft Purview DLP policy for endpoint devices

Why wrong: A Microsoft Purview endpoint DLP policy focuses on content inspection — detecting sensitive data like credit card numbers or PII and preventing those specific files from being copied to USB. While it can block certain copy operations, it does not provide comprehensive device-level control over all removable storage and does not natively differentiate actions based on user risk groups. MDE device control is the proper mechanism for blanket, risk-based USB auditing and blocking, independent of file content.

Configure Azure Policy to require image scanning before deployment

Why wrong: Azure Policy is an Azure Resource Manager governance service that can enforce tags, locations, or SKU constraints across cloud resources, but it does not execute code or inspect container image layers. Although custom policies can be written to call external APIs via Azure Functions or Logic Apps, there is no native Azure Policy capability to wait for or assess a container image vulnerability scan result during a DevOps build. Furthermore, Azure Policy evaluates resources in Azure, not artifacts in transit, so it cannot gate a GitHub Actions workflow step on scan findings. This makes the option ineffective for the stated requirement of blocking deployment based on scan outcome.

Deploy Azure Bastion to scan images during build

Why wrong: Azure Bastion is a Platform-as-a-Service (PaaS) jump server that provides secure RDP and SSH connectivity to virtual machines through the Azure portal, eliminating public IP exposure. It has no image scanning, container registry, or workload analysis capabilities — it operates at the network transport layer for interactive administrative access. Deploying Bastion would not integrate with a GitHub Actions pipeline, nor would it have any visibility into container image layers or known vulnerabilities. The option fundamentally misunderstands the service's purpose and would add no value to a container security gating workflow.

Use Azure Security Center (legacy) to scan images on push

Why wrong: Azure Security Center was the predecessor to Microsoft Defender for Cloud; the legacy name was retired in July 2022, and all capabilities, including container registry scanning, now reside under the Microsoft Defender for Cloud brand. Even if you attempted to use the old service, it no longer receives updates and its APIs have been migrated or deprecated, meaning a GitHub Actions step would likely fail to authenticate or return data. Relying on a deprecated product is a security risk because new vulnerability signatures are not backported, so images would be assessed against an outdated vulnerability database. The correct current implementation is to enable the Defender for Cloud container security plan, not to call a legacy endpoint.

Create a DLP policy with the action 'Audit only' for credit card numbers

Why wrong: The 'Audit only' action in a Microsoft Purview DLP policy simply logs the detection of credit card numbers without imposing any restriction. Users can still share, email, or transfer the data externally, so this approach fails to stop data loss; it only provides visibility after the fact.

Create a DLP policy that encrypts emails containing credit card numbers

Why wrong: Encrypting emails with credit card numbers (e.g., via Microsoft Purview Message Encryption) protects the content from being read by unauthorized parties, but it does not prevent the email from being sent to an external recipient. The sharing action itself is allowed, so the data leaves the organization's control, violating the requirement to block the sharing.

Create a DLP policy with the action 'Block' for credit card numbers

Why wrong: The 'Block' action in Purview DLP completely prevents the sharing of credit card numbers without any option for users to override the restriction. While this ensures data is not accidentally exposed, it is too rigid for legitimate business scenarios, causing productivity disruption and forcing data owners to find unmonitored workarounds.