Secure compute, storage, and databases practice questions

No additional configuration is needed; Azure Files uses SMB encryption by default and cannot be disabled.

Why it fails: Azure Files does support SMB 3.0 encryption, but the protocol version and encryption are not mandatory by default; the storage account will accept unencrypted SMB traffic unless the 'Secure transfer required' setting is explicitly enabled. Furthermore, the claim that encryption cannot be disabled is incorrect because this setting is fully configurable, and its default value is disabled. Therefore, additional configuration is required to enforce encrypted connections.

Configure a network security group (NSG) rule to block SMB traffic on port 445 that does not use encryption.

Why it fails: An NSG filters traffic based on network-layer attributes such as source/destination IP address, port, and protocol; it has no visibility into the SMB session's encryption state because both encrypted and unencrypted SMB traffic use TCP port 445. A rule blocking port 445 would therefore block all SMB access, including legitimate encrypted connections, rather than selectively blocking only those that lack encryption. Encryption enforcement for Azure Files must be handled at the storage/application layer, not by network security groups.

Set the Azure Files share to use the 'Premium' performance tier; encryption is only available on premium shares.

Why it fails: The premium performance tier is related to storage throughput and latency, and it does enable customer-managed keys (CMK) for Azure Files encryption at rest, but it does not control encryption in transit. SMB encryption enforcement via the 'Secure transfer required' setting is available on both standard and premium file shares, so selecting premium is neither necessary nor sufficient to force SMB 3.0 encryption. The misconception arises from conflating at-rest encryption with in-transit SMB encryption.

Enable the Azure SQL Database server's firewall to allow Azure services to access the server.

Why it fails: Enabling the Azure SQL Database server's firewall with 'Allow Azure Services and resources to access this server' only governs inbound connections to the SQL database endpoint. It does nothing for outbound requests the SQL server makes to Azure Key Vault on behalf of Transparent Data Encryption (TDE). The failure occurs in the Key Vault's network layer, not at the SQL firewall, so this configuration change cannot resolve the access denied error.

Assign a user-assigned managed identity to the SQL server instead of a system-assigned identity.

Why it fails: Assigning a user-assigned managed identity instead of the system-assigned identity does not alter how the Key Vault firewall evaluates incoming requests. Both identity types originate from the same Azure platform and are subject to the vault's default deny-all network rule unless an explicit exemption exists. Switching identity types would only change the security principal used for authentication, not the network path, so the TDE key retrieval would still fail due to the firewall.

Change the Key Vault firewall to allow all networks.

Why it fails: Changing the Key Vault firewall to allow all networks would technically let the SQL server's managed identity reach the vault, but it would expose the entire vault to the public internet. Any entity with a valid Entra ID token and the correct access permissions could then retrieve or wrap keys, drastically increasing the risk of key exfiltration. This violates the security requirement for least-privilege access and ignores the more restrictive 'Allow trusted Microsoft services' exemption that solves the same problem safely.

Configure Azure SQL Database auditing to log key usage.

Why it fails: Enabling Azure SQL Database auditing does not encrypt the data or manage any cryptographic material; it only records login attempts, query activity, and related database events. Auditing can show that a key was used, but it cannot protect the database files at rest or enforce a 12-month rotation schedule. Key usage logs may be useful for reporting, but they do not fulfill the encryption requirement.

Enable Azure Information Protection for the database.

Why it fails: Azure Information Protection is a classification and labeling service for documents and emails, and it does not integrate with Azure SQL Database's storage engine or provide at-rest encryption. Even when labels are applied, the underlying database pages remain unencrypted by TDE, and there is no customer-managed key rotation. This makes it unrelated to both the encryption and rotation requirements.

Enable the key vault for deployment by setting the 'Enabled for deployment' access policy.

Why it fails: The 'Enabled for deployment' access policy is a Key Vault firewall/access policy toggle that allows Azure Resource Manager (ARM) templates to deploy resources by retrieving secrets during template operations. It does not grant any cryptographic key permissions like wrapping or unwrapping, so Azure Disk Encryption cannot use it to access a KEK. This setting is part of the legacy access policy model and is irrelevant to ADE's key operation requirements.

Enable the key vault for disk encryption by setting the 'Enabled for Azure Disk Encryption' access policy.

Why it fails: This setting is a legacy option used in older versions of ADE. While it might work, it is not the recommended approach and is not sufficient by itself without also granting the correct permissions. The modern approach uses RBAC roles.

Add the 'Storage Account Contributor' role for the VMs to access the key vault.

Why it fails: The 'Storage Account Contributor' role is a control-plane role that manages storage accounts, not a data-plane permission on keys or secrets in Key Vault. Azure Disk Encryption does not interact with storage accounts for key access; it needs the ability to perform crypto operations such as 'wrapKey' and 'unwrapKey' on the KEK. Assigning this role would neither grant those Key Vault permissions nor allow VMs to encrypt disks, making it an incorrect fix.

Always Encrypted with randomized encryption.

Why it fails: Always Encrypted with randomized encryption uses a new initialization vector for every encryption operation, so identical plaintext values produce different ciphertext each time. This hides data patterns from the database engine but completely precludes equality, range, join, and grouping operations, and even makes indexing on the column impossible. It is appropriate only for columns that are never filtered or sorted, such as free-text notes or individual identifiers that must remain opaque to the database server.

Always Encrypted with secure enclaves.

Why it fails: Always Encrypted with secure enclaves creates a protected memory region within the database engine where encrypted data is decrypted for computation, and the plaintext never leaves the enclave. It leverages Intel SGX or virtualization-based security (VBS) to attest the enclave to the client, allowing the database engine to perform equality, range, pattern matching, sorting, and even in-place operations on encrypted columns without exposing data to DBAs or OS administrators. This solution provides stronger security than deterministic encryption, which leaks frequency patterns, and more functionality than randomized encryption, which blocks all predicates.

Transparent Data Encryption (TDE).

Why it fails: Transparent Data Encryption (TDE) encrypts the entire database at rest, including data files, log files, and backups, using a database encryption key protected by a certificate or asymmetric key. It defends against offline theft of physical media, but it does nothing to restrict what database administrators or anyone with access to the database engine can read because data is transparently decrypted when loaded into memory and processed normally. TDE offers no column-level granularity, no client-side key control, and no ability to perform computations on ciphertext, making it fundamentally different from Always Encrypted features that protect data from privileged database users.

Add the managed identity as an Microsoft Entra ID admin for the SQL server.

Why it fails: Setting the managed identity as an Microsoft Entra ID admin for the SQL server is incorrect because it assigns the identity to the server-level `sysadmin` role, granting full administrative control over all databases on that server. This violates least privilege and is far broader than the intended read-only data access. Additionally, an Microsoft Entra ID admin is a server principal, not a contained database user, so it does not follow the scoped access model recommended for application identities.

Enable Microsoft Entra ID-only authentication on the SQL server.

Why it fails: Enabling Microsoft Entra ID-only authentication on the server disables SQL authentication, but it does not by itself grant any specific Microsoft Entra ID principal access to a database. Authentication and authorization are distinct: an identity must still have a contained database user and appropriate roles like `db_datareader` to read data. This server-level setting is optional and often used for compliance, not as a mechanism to allow managed identity access.

The Key Vault does not allow access from the Azure platform.

Why it fails: Key Vault does not have a monolithic 'Azure platform' access toggle; access is granted through Microsoft Entra ID identities and per-service-specific access policies. The Azure Disk Encryption feature specifically requires the 'Azure Disk Encryption for Azure VMs' access policy, not a generic network-level trust or a global bypass. Saying the vault 'does not allow access from the Azure platform' is imprecise because the platform's service principal is allowed only through that specific policy, so the missing policy is the precise underlying issue.

The Key Vault firewall is enabled and blocking access from Azure services.

Why it fails: While enabling the Key Vault firewall can block network calls, firewall rules are evaluated as an additional layer alongside access policies. When the 'Allow trusted Microsoft services' bypass is enabled (which is the default for back-end Azure services like Azure Disk Encryption), the ADE platform can traverse the firewall even if the firewall itself is turned on. Therefore, a firewall being enabled is not the direct cause here; the missing 'Azure Disk Encryption for Azure VMs' access policy is the actual blocker.

The Key Vault does not have the system-assigned managed identity of the VM enabled.

Why it fails: Azure Disk Encryption does not use the VM's system-assigned managed identity for Key Vault authentication; it relies on the Azure Disk Encryption service's own principal to access the vault. The VM's system-assigned identity is irrelevant to ADE's key retrieval process and does not participate in the encryption flow. Enabling that managed identity would not alter the Key Vault's access policy requirements, so it cannot be the source of the failure.

Disable public network access on the Key Vault.

Why it fails: Disabling public network access on the Key Vault would make the vault completely unreachable from any public endpoint, including the Azure SQL Database service, because Azure SQL runs in a shared Microsoft network and is not a private endpoint connection unless explicitly configured. This action would not only fail to fix the issue, it would guarantee that the SQL database cannot access the customer-managed key for TDE, causing the firewall to reject every attempt. The correct approach is to configure a selective bypass, not remove all public access.

Add the SQL Database server's system-assigned managed identity to the Key Vault access policy.

Why it fails: A system-assigned managed identity on the SQL Database server would handle authentication and authorization, typically granted via Key Vault access policies with get, wrapKey, and unwrapKey permissions, which are necessary for TDE with customer-managed keys. However, this does not address the network layer: the Key Vault's firewall evaluates the source IP or service tag before any authorization check, so even a properly permissioned identity cannot access the vault if the request is blocked by firewall rules. You need a network exception or private endpoint, not just an access policy.

Enable soft-delete on the Key Vault.

Why it fails: Enabling soft-delete on a Key Vault protects against accidental or malicious deletion by retaining deleted vaults and keys for a configurable retention period, which is a critical safeguard for TDE because losing the key would make the database inaccessible. However, soft-delete has absolutely no effect on the Key Vault's firewall configuration or the network path between Azure SQL Database and the vault. The firewall rejection is a connectivity issue, not a data retention issue, so this setting cannot resolve it.

BlockBlobStorage account with infrastructure encryption

Why it fails: BlockBlobStorage accounts are specifically designed for high-transaction, low-latency block blob workloads and do not offer access tiers such as Cool or Archive. Infrastructure encryption adds a second layer of encryption at the storage infrastructure level, which increases cost but does not reduce storage costs or address archival access patterns. For archival data that is accessed infrequently with minutes-level retrieval, this combination is both functionally incomplete and unnecessarily expensive.

BlobStorage account with Hot access tier and default encryption

Why it fails: A BlobStorage account with the Hot access tier is intended for data that is accessed or modified frequently, and it carries higher per-GB storage costs than Cool or Archive tiers. Archival data stored in the Hot tier will accrue significant storage fees over time, and the BlobStorage account type does not provide the same feature parity and account-level flexibility as general-purpose v2. Default encryption with Microsoft-managed keys is already included in all storage accounts, so the encryption choice does not compensate for the cost-inefficient tier.

General-purpose v1 account with Archive access tier and default encryption

Why it fails: General-purpose v1 accounts are legacy and do not support blob access tiers, so placing blobs in the Archive tier is not actually possible; the tier would need to be on a GPv2 or BlobStorage account. Furthermore, even if the Archive tier were available, rehydrating data from Archive can take up to 15 hours, which conflicts with a requirement for retrieval within minutes. Default encryption does apply to GPv1, but the unsupported tier and excessive retrieval latency make this option technically invalid.

The key vault is in a different Azure region than the VM.

Why it fails: The Azure Disk Encryption workflow uses the Key Vault's URI, which is a network endpoint that is accessible from any Azure region. A Key Vault residing in a different Azure region than the VM does not inherently block key recovery, as the VM contacts the vault over HTTPS rather than relying on regional affinity. As long as the vault's endpoint is reachable and the VM has the correct secrets, the encryption keys can be retrieved regardless of regional placement. Region mismatch alone is never a blocker for Azure Disk Encryption key retrieval.

The key was not created with soft-delete enabled.

Why it fails: Soft-delete is enabled at the vault level, and purge protection is also enabled. The key inherits these settings. If the key had soft-delete disabled, it would not be recoverable at all, but the question states they enabled both features on the vault.

The VM's managed identity does not have 'Key Vault Crypto Service Encryption User' permission.

Why it fails: While permissions are required for encryption operations, the recovery process (using the Azure portal or PowerShell) does not rely on the VM's managed identity; it uses the user's permissions. The issue is network connectivity, not permissions.

Use a virtual network service endpoint and disable public network access.

Why it fails: A virtual network service endpoint routes traffic from your VNet to Azure SQL over the Microsoft backbone, but it does not remove the underlying public endpoint of the managed instance—it merely adds a network-level restriction on the source VNet. Even if you disable public network access as a separate setting, the managed instance is still addressed via a public DNS name, and the configuration does not provide a dedicated private IP address in your VNet. This fails to give the true isolation and service-specific access that a private endpoint delivers, because service endpoints are not a replacement for Private Link and still leave the public endpoint architecture in place.

Configure firewall rules to allow only the IP ranges of Azure Data Factory and deny all other traffic.

Why it fails: Configuring firewall rules to allow only Azure Data Factory IP ranges on the public endpoint still leaves the managed instance publicly resolvable and listening on the internet. Such rules are IP-based, not service-based, so any client whose source IP falls within an allowed range—whether it is genuinely Data Factory or a different resource with a coincidentally matching IP—can connect. Azure Data Factory also does not have a fixed set of public IP ranges; it uses service tags that change over time, making this approach brittle and potentially over-permissive. This neither eliminates public exposure nor restricts access to specific Azure services, so it fails both requirements.

Apply a service tag for Azure SQL Managed Instance in the virtual network NSG.

Why it fails: Service tags in NSGs control outbound traffic to Azure services or inbound traffic from other Azure services, but they do not configure the managed instance itself to be non-public or restrict access to specific services.

Enable infrastructure encryption for the storage account

Why it fails: Infrastructure encryption provides a second layer of encryption at the infrastructure level, but it still uses the same key type as the base encryption. It does not provide the ability to revoke access via key disabling.

Enable soft delete for blobs

Why it fails: Soft delete retains deleted blobs for recovery; it does not configure customer-managed keys or permit key revocation. It is tempting because it protects against accidental deletion, but the scenario demands CMK encryption with fast access revocation, which soft delete cannot deliver.

Enable versioning for blobs

Why it fails: Blob versioning retains prior blob states for recovery; it neither applies a customer-managed key nor enables rapid cryptographic revocation. It is tempting because versioning supports data protection, but the requirement is encryption-at-rest key control, which versioning does not provide.

Soft-delete and resource locks

Why it fails: Incorrect. While soft-delete is necessary, resource locks on the Key Vault do not prevent purging of soft-deleted keys. Purging is an operation on the key resource, not on the vault itself.

Purge protection and access policies

Why it fails: Incorrect. Purge protection alone without soft-delete would not allow recovery; access policies control permissions, not deletion recovery or purge prevention.

Soft-delete and backup

Why it fails: Incorrect. Soft-delete alone allows recovery but does not prevent purging; backup does not prevent purging or provide the same recovery guarantee.

Store the key in a key vault in each region and use a managed identity to access the key vault.

Why it fails: Replicating keys into a Key Vault in every region adds unnecessary administrative overhead and does not satisfy the region-binding rule. Azure Storage customer-managed keys require a single key vault and key to reside in the exact same Azure region as the storage account; a managed identity only provides authenticated key retrieval, not regional alignment. If the key vault holding the active key is in a different region, encryption setup will fail regardless of how many vaults exist or which managed identity you use.

Use a key stored in an Azure Key Vault with the 'Soft Delete' enabled.

Why it fails: Soft Delete is a Key Vault recovery feature that retains a deleted vault or key for a configurable period (default 90 days), enabling restore after accidental deletion. It has no effect on the physical region of the vault; a key vault with Soft Delete enabled in a different region cannot be used as the encryption-key source for the storage account. Regional affinity is an architectural constraint, not a data-protection toggle.

Use an Azure Key Vault with 'Purge Protection' enabled.

Why it fails: Purge Protection is an optional retention safeguard that prevents a soft-deleted vault or key from being purged until the retention period has expired. It strengthens deletion control but does not influence the storage account's requirement that the key vault be in the same region. A vault with Purge Protection enabled but located outside the storage account's region would still violate the mandatory same-region placement rule for customer-managed keys.

Azure Defender for SQL

Why it fails: Azure Defender for SQL includes the Vulnerability Assessment feature, but the question asks for the specific feature that scans for vulnerabilities and generates reports, which is the Vulnerability Assessment itself. Azure Defender also includes threat detection and other capabilities not required here.

SQL Auditing

Why it fails: SQL Auditing is fundamentally a logging and tracking mechanism that records database events, such as SELECT, INSERT, UPDATE, and DELETE operations, along with schema changes and successful or failed login attempts, writing them to an Azure Storage account or Log Analytics workspace. Its purpose is compliance auditing, forensic investigation, and anomaly detection at the activity level—it never inspects configurations or permissions for weaknesses, so it is not a vulnerability scanner.

Azure SQL Insights

Why it fails: Azure SQL Insights is a monitoring and diagnostic solution that uses performance telemetry to visualize metrics like CPU, memory, I/O, query wait statistics, and index usage for Azure SQL databases. It is designed to help database administrators detect performance bottlenecks and tune workloads, not to assess security posture or identify vulnerabilities; a database can have excellent performance metrics while still containing critical security misconfigurations that Insights would never report.

Azure Storage Service Encryption with customer-managed keys (CMK)

Why it fails: Storage Service Encryption with customer-managed keys does encrypt every blob at rest with AES-256, but the encryption and decryption happen server-side inside the Azure Storage service. To perform those operations, the storage service uses a managed identity to access the customer's Key Vault key, so Azure—and Microsoft support with delegated access—retains the ability to decrypt the data. CMK gives the customer key lifecycle control such as rotation and disabling, but it does not create a zero-knowledge boundary where Azure cannot see plaintext.

Azure Disk Encryption

Why it fails: Azure Disk Encryption is scoped to IaaS virtual machines: it uses BitLocker on Windows and dm-crypt on Linux to encrypt the operating system and data disks attached to those VMs. Azure Blob Storage is a PaaS data-plane service with no disk, VM, or host-level mount, so ADE has no mechanism to encrypt containers or blobs. Deploying ADE would leave the blob data completely unprotected by that control and fails to address Azure's ability to access the data at the application layer.

Azure Information Protection

Why it fails: Azure Information Protection is a data classification and labeling solution that applies sensitivity labels, markings, and Azure Rights Management templates to files such as documents and emails. It is not a storage-level encryption control: it does not encrypt Blob Storage data at rest, and the underlying blob bytes remain accessible to the storage platform. AIP adds metadata and policy-based protection to rich content, but it cannot satisfy a requirement that Azure be unable to access sensitive data in a blob container.

Disabling all encryption

Why it fails: Disabling all encryption removes Azure Storage service-side encryption (SSE) at rest, leaving regulated data in plaintext if the underlying storage medium is compromised. It also forfeits the platform's default guarantee of encryption with Microsoft-managed keys, and it does nothing to prevent deletion, overwrite, or unauthorized access. This posture directly contradicts regulatory expectations for confidentiality and integrity, so it fails to meet the requirement.

Public container access

Why it fails: Public container access permits anonymous read requests to blobs without authentication, which would expose regulated records to anyone with the storage account URL. This is a security misconfiguration that destroys confidentiality and can violate compliance mandates; it also provides no data-loss protection. Because it increases rather than mitigates risk, it is not a suitable feature for securing regulated records.

Enable anonymous image pulls

Why it fails: Enabling anonymous image pulls removes authentication requirements for container registry access, allowing any user or workload to pull images without identity verification. This expands the attack surface because RBAC policies, audit logs, and access controls become ineffective, making it impossible to distinguish trusted images from untrusted third-party content. Instead of reducing risk from untrusted container images, it actively increases supply chain risk.

Store Kubernetes secrets in plain text ConfigMaps

Why it fails: Storing Kubernetes secrets in plaintext ConfigMaps is insecure because it exposes sensitive data such as image pull credentials, API keys, and connection strings to any principal who can read the ConfigMap. This does not address container image trust or image provenance at all, and introduces a separate vulnerability by keeping secrets unencrypted and easily retrievable. Use Kubernetes Secrets with encryption at rest or the Azure Key Vault Provider for Secrets Store CSI instead.

Transparent Data Encryption only

Why it fails: Transparent Data Encryption performs at-rest encryption of the entire database file, backup, and transaction log, but it does not prevent a database administrator or a user with database permissions from reading column values through normal T-SQL queries. Because TDE decrypts data automatically when it is read into memory and uses a server-held database encryption key, it provides no column-level protection against users who can execute SELECT statements. Therefore, TDE alone cannot satisfy the requirement to protect specific sensitive column values from authorized users.

Basic server firewall rule

Why it fails: A basic server firewall rule is a network access control that specifies which IP addresses can reach the SQL server endpoint, and it has no effect on how data is protected once a legitimate connection is established. It cannot encrypt column values or restrict what a connected principal can see, because authorized users can still retrieve the sensitive columns in plaintext. Thus, while a firewall is important for reducing the attack surface, it does not address the cryptographic protection requirement for sensitive column values.

Enable Azure Storage analytics logging with retention set to 90 days.

Why it fails: Storage Analytics logging records successful and failed requests to the storage account, and a 90-day retention gives you a forensic trail after an incident occurs. But logging is purely detective: it does not prevent unauthorized access or enforce any security policy. In fact, logs are only useful if you have already implemented access controls, encryption, and network rules; relying on logs as a security control is insufficient for a design question about securing storage.

Configure a shared access signature (SAS) token with full account-level permissions for each user.

Why it fails: Issuing a shared access signature with full account-level permissions to every user grants each user a token that can read, write, delete, and manage all blobs and queues within the entire account. This violates the principle of least privilege because there is no way to scope permissions to a specific resource or container, and no way to revoke a single user's token without regenerating the entire account key. The correct SAS approach is a user-delegation SAS scoped to a specific container or directory with short-lived expiry, which is why this option is incorrect.

Use Azure Traffic Manager to distribute storage requests across multiple regions.

Why it fails: Azure Traffic Manager is a DNS-based load balancing service that routes incoming HTTP/HTTPS traffic to multiple endpoints for improved scalability, performance, and failover across regions. It does not inspect or control authentication, authorization, encryption, or access policies — it simply forwards requests to the storage account. Because Traffic Manager has no influence over who can reach the account's data plane, it is not a security control and cannot be considered part of a secure storage strategy.