Design security solutions for applications and data practice questions

Configure the database to reject unencrypted connections.

Why it fails: 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 it fails: 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 it fails: 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.

Microsoft 365 E3

Why it fails: 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 it fails: 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 it fails: 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 Microsoft Entra ID 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Implicit grant

Why it fails: 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 it fails: 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 Microsoft Entra ID 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 it fails: 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.

Certificate-based authentication using Azure Key Vault

Why it fails: 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 Microsoft Entra ID pod-level identity. This approach reintroduces secret-management and rotation overhead, and does not provide automatic pod-scoped Microsoft Entra ID tokens.

System-assigned managed identity on the cluster

Why it fails: 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 it fails: 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 Microsoft Entra ID issues tokens automatically without any stored credentials.

Implement client-side encryption using the .NET SDK.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

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

Why it fails: 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 it fails: 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 it fails: 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 client certificate authentication and map certificates to Microsoft Entra ID apps

Why it fails: Client certificates are not OAuth 2.0.

Enable API key authentication and restrict access using subscription keys

Why it fails: API keys are not OAuth 2.0.

Use OAuth 2.0 with Microsoft Entra ID and configure inbound policies to validate JWTs

Why it fails: This is part of the solution but does not include rate limiting or IP filtering explicitly.

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

Why it fails: 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 it fails: 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 it fails: 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.

Audits virtual machines that have a network interface

Why it fails: The policy does not audit anything; its effect is `Deny`, which blocks a deployment rather than auditing existing resources. Additionally, the condition evaluates whether a network interface is absent, not present, so the policy would never target a VM that has a NIC. An audit effect would simply log non-compliance after the fact, but this policy proactively prevents the resource from being created.

Deletes virtual machines that do not have a network interface

Why it fails: Deny is a pre-creation enforcement action, not a remediation or cleanup action. When a VM without a NIC is submitted for deployment, the `Deny` effect causes the API request to fail with a 403 status before any resource is written. This policy does not delete anything; a deletion would require a policy with `DeployIfNotExists` or `Modify` effect plus a remediation task, or an explicit automated cleanup process.

Denies creation of virtual machines that have a network interface

Why it fails: This option inverts the policy's condition logic. The policy's condition returns true only when no network interface is attached, so a VM with a NIC has a false condition and is permitted. In other words, the policy is designed to block NIC-less VMs, not to block NIC-bearing VMs. Choosing this option would mean you read the existence check backward.

The Key Vault access policy allows the user to list secrets

Why it fails: Listing secrets does not grant read access to the secret value.

The user has the 'Key Vault Secret Management' role in Azure RBAC

Why it fails: There is no built-in 'Secret Management' role; the correct role is 'Key Vault Secrets User'.

The command was executed using the Key Vault managed identity

Why it fails: No managed identity is shown; the command runs under the user's context.

Count the number of 'Suspicious process execution' alerts in the last hour

Why it fails: This query does not contain a `summarize` operator, so it cannot perform any aggregation. The `count()` function in KQL requires an aggregation context, such as `| summarize Count = count()`, to compute the number of alerts. Without that, the query simply filters and projects rows, and attempting to count would be syntactically invalid in the context shown.

Join the SecurityAlert table with another table to enrich the results

Why it fails: The query uses no `join` or `lookup` operator, so it cannot enrich results by combining data from another table. Enrichment in KQL requires a join on a common field (e.g., `AccountUPN` or `DeviceID`) or a `lookup` operator, but the exhibit shows a single-table query that only filters and projects columns from `SecurityAlert`, meaning no external data is merged.

Create an analytics rule to detect 'Suspicious process execution'

Why it fails: This query is not creating an analytics rule; it is reading from the `SecurityAlert` table, which contains alerts that already have been generated by existing detection logic. Analytics rules are defined by writing KQL against raw data sources (like `SecurityEvent` or `SigninLogs`) and configuring a schedule, or by using an ARM template. The query here simply retrieves historical alerts for investigation, not detection logic.

Enable Azure SQL Database auditing

Why it fails: Enabling Azure SQL Database auditing is fundamentally an accountability and forensics control: it records events such as logins, query executions, and schema changes into an audit log, but it performs no inspection of column-level data values. Auditing does not discover, classify, or tag sensitive data like credit card numbers; it only tells you who did what and when. Therefore, while it supports compliance and anomaly detection, it cannot satisfy a requirement to identify and label sensitive data types in the database.

Create a data loss prevention (DLP) policy in Purview

Why it fails: Creating a data loss prevention (DLP) policy in Microsoft Purview is a protective enforcement control that acts on already-labeled or already-classified data by blocking, restricting, or auditing risky sharing actions. DLP policies do not perform discovery or labeling; they rely on sensitivity labels or classifier results to trigger rules. Since the organization's data has not yet been scanned or labeled, deploying a DLP policy now would have nothing to act on, and therefore it cannot address the requirement to classify sensitive data types.

Configure Conditional Access policies in Microsoft Entra ID to block unsanctioned apps

Why it fails: Conditional Access in Microsoft Entra ID enforces sign-in conditions like MFA, device compliance, or location, but it does not analyze or restrict the usage of a discovered cloud app within a browser session. It has no built-in condition that recognizes the 'unsanctioned' tag from the Defender for Cloud Apps catalog, so it cannot directly block an unsanctioned app. You would need to combine Conditional Access with app control in Defender for Cloud Apps, but alone it only governs authentication, not ongoing app usage.

Create a DLP policy to prevent data upload to unsanctioned apps

Why it fails: Data loss prevention (DLP) policies in Microsoft Purview or Defender for Cloud Apps focus on inspecting the content of data flows—such as detecting credit card numbers or confidential files—and can block or quarantine those specific matches. They do not manage the availability or accessibility of an application itself; a DLP policy cannot prevent a user from launching or browsing an unsanctioned app or from using its core functionality. Blocking an unsanctioned app is an access control decision, whereas DLP is a content-control decision. Since the requirement is to block the app, not the data, DLP is the wrong tool.

Create a Conditional Access App Control session policy

Why it fails: Conditional Access App Control (CAAC) is the underlying reverse-proxy technology that enforces session policies, not a policy object you create directly. The actual artifact you configure is a session policy inside Defender for Cloud Apps, where you define conditions such as device tags and target actions like block download. Saying 'Create a Conditional Access App Control session policy' conflates the feature name with the policy type—you can't create a policy named that; you create a session policy that leverages CAAC for enforcement.

Create a Microsoft Purview Data Loss Prevention policy for SharePoint

Why it fails: A Microsoft Purview Data Loss Prevention (DLP) policy for SharePoint is designed to classify and protect data at rest and in transit—for example, by preventing sharing of sensitive documents or applying encryption—but it does not evaluate the device's management state or intercept a user's live session actions. It works at the data level, not the session level, so it cannot inspect device tags or block a download action in real time based on whether the device is compliant. Even if DLP could block downloads in some cases, it lacks the session-aware context (device tag) that the requirement demands, making it a misaligned control.

Create a Microsoft Intune compliance policy to block unmanaged devices

Why it fails: Intune compliance policies define whether a device meets organization standards (like OS version, threat level, encryption) and influence Conditional Access grant decisions at sign-in, but they do not govern granular actions within an already-established app session. Once a user is in SharePoint, a compliance policy cannot inspect the ongoing session and selectively block a download based on device tags—it is a device-level access gate, not a session-level action controller. Additionally, device tags used in Defender for Cloud Apps session policies are often sourced from Intune, but the compliance policy itself doesn't provide the real-time, per-action enforcement required here.

Enable RBAC authorization on the vault

Why it fails: Enabling RBAC authorization on the vault is a data-plane access management choice that determines how clients are authenticated and authorized for vault operations, typically via Azure RBAC roles or vault access policies. This is orthogonal to network connectivity: private endpoints operate at the network layer by assigning a private IP address to the vault, regardless of which authorization model is in use. Even with RBAC enabled, the vault still needs a private endpoint and DNS configuration to be reachable from your virtual network. Therefore, enabling RBAC is not a required step for private endpoint connectivity.

Assign a system-assigned managed identity to the vault

Why it fails: A system-assigned managed identity is an Microsoft Entra ID identity provisioned for the Key Vault itself, typically used when the vault needs to authenticate to another Azure resource (such as accessing a secret from a storage account). This identity is completely unrelated to network-level constructs like private endpoints, which do not require any identity on the vault resource. Private endpoint configuration simply creates a network interface with a private IP address and associates it with the vault; no managed identity is involved in that process. Therefore, assigning a system-assigned managed identity is unnecessary and does not help satisfy the requirement for private endpoint connectivity.

Set the defaultAction to Allow for the network ACLs

Why it fails: Setting `defaultAction` to `Allow` in the network ACLs would permit all public traffic to reach the Key Vault over the internet, effectively bypassing the isolation that a private endpoint is designed to provide. When you use a private endpoint, you must configure the vault's network firewall to deny public access (set `defaultAction` to `Deny`) so the only ingress path is through the private endpoint's private IP. Allowing public access (defaultAction = Allow) not only contradicts the security intent but also leaves the vault vulnerable to public exposure, and the private endpoint becomes redundant because public connectivity remains open. Therefore, this option is incorrect for establishing private-only access.

Azure Information Protection

Why it fails: Azure Information Protection (AIP) is a cloud-based classification and labeling service that enables organizations to identify, classify, and optionally protect documents and emails based on sensitivity, but it does not interact with Azure SQL Database storage architecture. AIP uses Azure Rights Management for encryption of files and emails, not database files, data pages, or backups. Therefore, AIP cannot provide native at-rest encryption for Azure SQL Database, making it unsuitable for this requirement.

Always Encrypted

Why it fails: Always Encrypted is a client-side encryption technology that protects sensitive data in transit and at rest by encrypting column values in the application layer before they are sent to the database, and the database engine never sees the plaintext values. While it does encrypt data at rest, it is designed to protect data from unauthorized access by DBAs and high-privilege users, not to replace server-level transparent encryption of the entire database. Additionally, Always Encrypted introduces limitations on querying encrypted columns (e.g., equality only) and requires client/application changes, whereas Transparent Data Encryption (TDE) is the primary, transparent, and simpler at-rest encryption solution for Azure SQL Database.

Dynamic Data Masking

Why it fails: Dynamic Data Masking (DDM) is a presentation-layer security feature that hides sensitive data from non-privileged users by obfuscating query results based on masking rules (e.g., showing 'XXX-XX-XXXX' for Social Security numbers). However, DDM does not encrypt the underlying data—it remains fully stored in plaintext and is only masked in the output for users who lack the UNMASK permission. This means DDM cannot protect data from unauthorized access at the file level or from privileged users, and it does not satisfy at-rest encryption requirements. DDM is useful as a complementary control to limit data exposure, but it is not a substitute for TDE.

Store the connection string in App Service application settings with the password encrypted by App Service

Why it fails: App Service application settings are encrypted at rest by the platform, which prevents casual inspection of configuration files, but the plaintext password is still loaded into the app's process memory at startup and from that moment is available to any code running in the sandbox. This approach does nothing to eliminate secret management, since the password still has to be created, rotated, and distributed, and it is also visible to anyone with access to the app's configuration through the Kudu console or environment variables. Even though encryption at rest is a basic control, it does not satisfy the principle of using identity instead of secrets.

Store the connection string with username and password in Key Vault and reference it in App Settings

Why it fails: Storing the username and password as a secret in Key Vault and referencing it from App Settings is a clear improvement over hard-coding, because it centralizes secret storage and enables access policies and audit logging. However, the connection string still contains a credential, meaning the application must read that secret at runtime, handle it in memory, and implement rotation workflows to change the password across the database and the vault. A managed identity would remove the credential entirely: the App Service authenticates to Azure SQL with its own identity, so there is no password to store, retrieve, or rotate.

Store the connection string as a secret in Azure Key Vault and use a Key Vault reference in App Settings

Why it fails: A Key Vault reference in an App Service app setting looks like @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/sqlconn/...) and is resolved at runtime, which means the App Service itself never stores the secret in its configuration. But this still leaves the actual username/password inside the Key Vault secret, so the connection string that reaches the application contains plaintext credentials at runtime. If an attacker who can execute code in the app reads the connection string, a Key Vault reference does not protect the credential—whereas a managed identity would give the app a token without any credential material in the connection string.