Secure compute, storage, and databases practice questions

Configure a private endpoint for the SQL server to the Key Vault.

Why wrong: While a private endpoint could provide connectivity, it is not necessary because Azure SQL Database is a trusted service that can be granted an exception to the Key Vault firewall. Using a private endpoint would also require additional networking setup and is not the simplest solution.

Change the Key Vault firewall to allow all Azure services.

Why wrong: Allowing all Azure services is a broader setting than necessary and could expose the Key Vault to other services. The trusted service exception is the recommended and more secure option.

Create a VNet service endpoint for Microsoft.KeyVault on the SQL server's subnet.

Why wrong: Service endpoints enable a more secure connection from a VNet to Azure services, but they do not grant permission for a trusted managed service to bypass the Key Vault firewall. The trusted service exception is required.

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

Why wrong: Azure Files supports SMB 3.0 encryption, but it is not enforced by default. The 'Secure transfer required' setting must be enabled to require encryption.

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

Why wrong: NSGs do not inspect encryption; they filter traffic based on IP and port. They cannot enforce encryption requirements on the SMB protocol itself. That is a storage-level setting.

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

Why wrong: While CMK for Azure Files is only available on premium shares, SMB encryption enforcement is available on both standard and premium shares via the 'Secure transfer required' setting.

Configure a network security group (NSG) to allow only encrypted traffic.

Why wrong: Incorrect. NSGs filter based on IP addresses and ports; they cannot enforce SMB encryption. Encryption is a transport-layer feature.

Set the minimum SMB protocol version to 3.0 on the file share.

Why wrong: Incorrect. Azure Files does not support configuring a minimum SMB version at the share level. The 'Secure transfer required' setting is the correct method.

Create a service endpoint for the storage account.

Why wrong: Incorrect. Service endpoints provide network security by restricting access to the storage account from specific virtual networks, but they do not enforce encryption in transit.

Add a network rule in the Key Vault firewall allowing the public IP range of the Azure SQL Database server.

Why wrong: Azure SQL Database does not have a fixed public IP range that can be whitelisted. The correct approach is to allow trusted Microsoft services to bypass the firewall, not to add IP rules.

Create a private endpoint for the Key Vault and connect it to the same virtual network as the Azure SQL Database.

Why wrong: While a private endpoint is secure, it does not grant access to Azure SQL Database as it runs outside the virtual network. SQL Database is a platform service; it would need a private endpoint as well, or use the trusted services bypass.

Configure the Key Vault to use role-based access control (RBAC) and assign the 'Key Vault Crypto Service Encryption User' role to the SQL Database server's managed identity.

Why wrong: RBAC is used for authorization (who can access the key), but the networking firewall still blocks the traffic. The network bypass is required to allow the SQL Database service to reach the Key Vault over the internet.

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

Why wrong: The SQL server firewall controls access to the SQL server, not access to the Key Vault.

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

Why wrong: Both system and user-assigned identities work; the issue is not the identity type but the firewall.

Change the Key Vault firewall to allow all networks.

Why wrong: This would open the Key Vault to public access, which defeats the security requirement.

Configure Azure SQL Database auditing to log key usage.

Why wrong: Auditing logs access to the database but does not encrypt data or rotate keys.

Enable Azure Information Protection for the database.

Why wrong: Azure Information Protection is for classification and labeling, not for encryption at rest with CMK.

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

Why wrong: This setting is used for Azure Resource Manager template deployments, not for Azure Disk Encryption. It is not the correct fix.

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

Why wrong: 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 wrong: Storage Account Contributor has nothing to do with accessing Key Vault for disk encryption. The VMs need key permissions, not storage permissions.

Enable soft-delete and purge protection on the Key Vault.

Why wrong: Soft-delete and purge protection help recover deleted keys, but they do not enable automatic key rotation or re-wrapping of disks.

Create a new KEK every 90 days and modify the disk encryption set to point to the new key version.

Why wrong: This approach is manual and does not automatically re-wrap running VMs. It requires updating the disk encryption set and may require a VM restart or manual re-encryption.

Use Azure Policy to enforce automatic key rotation.

Why wrong: Azure Policy can audit or enforce that VMs use a specific key version, but it does not cause automatic re-wrapping after key rotation. The disk encryption set must be configured to use the latest key version.

User-assigned managed identity

Why wrong: A user-assigned identity is managed separately and must be explicitly deleted; it does not auto-delete with the resource.

Service principal

Why wrong: Service principals require credential management (secrets or certificates) and are not automatically tied to resource lifecycle.

Azure AD user account

Why wrong: User accounts are for human users, not for Azure resource authentication.

Create a private endpoint for the SQL server to access the Key Vault

Why wrong: A private endpoint would provide a private IP connection, but it is not required if the 'Allow trusted Microsoft services' setting is enabled. It adds complexity for this scenario.

Enable public network access on the Key Vault

Why wrong: Disabling the Key Vault firewall entirely would expose it to public internet, which violates the requirement to block public access.

Assign the SQL server's managed identity the 'Reader' role on the Key Vault

Why wrong: The managed identity already has the necessary cryptographic permissions ('Key Vault Crypto Service Encryption User'). The 'Reader' role does not provide key access. The issue is network connectivity, not permissions.

Always Encrypted with randomized encryption.

Why wrong: Randomized encryption does not support equality searches; it is used for pattern-hiding but prevents any comparison operations inside the database.

Always Encrypted with deterministic encryption.

Why wrong: Deterministic encryption supports equality searches but is less secure because the database engine can see patterns from repeated values. Secure enclaves provide stronger security while still allowing equality searches.

Transparent Data Encryption (TDE).

Why wrong: TDE encrypts the entire database at rest but does not protect data from database administrators who have access to the database engine. It does not provide column-level encryption or computation support.

Transparent Data Encryption (TDE) with a customer-managed key stored in Azure Key Vault.

Why wrong: TDE encrypts the entire database at rest, but DBAs can still query the data because SQL Server automatically decrypts the data when read. The encryption key is available to the service.

Dynamic Data Masking (DDM) for the credit card column.

Why wrong: DDM masks the column in query results based on user permissions, but the underlying data is still stored in plaintext. Users with permissions can unmask the data, and it does not protect against DBAs.

Row-Level Security (RLS) to restrict DBA access to the credit card column.

Why wrong: RLS restricts row-level access based on user context but does not provide column-level encryption. DBAs can still see the plaintext in the column if they have the appropriate permissions.

Configure a service endpoint for Microsoft.KeyVault on the SQL server's subnet

Why wrong: Service endpoints are for Azure services to access resources in a VNet, not for a service like SQL Database to access Key Vault. Also, SQL Database is not deployed in a VNet by default.

Assign the SQL server's server identity the 'Contributor' role on the Key Vault

Why wrong: The SQL server needs the 'Key Vault Crypto Service Encryption User' role to use the key for TDE. Contributor does not grant key permissions. Also, without the firewall exception, access is blocked anyway.

Create a private endpoint for the Key Vault in the SQL server's virtual network

Why wrong: A private endpoint would allow access from a specific VNet, but SQL Database is not deployed in a VNet by default; you would need to use Azure SQL Managed Instance or integrate with VNet. For a regular SQL Database, this is not straightforward and the trusted services exception is the standard solution.

Transparent Data Encryption (TDE)

Why wrong: TDE encrypts the entire database at rest, but the database engine has access to the encryption keys, so DBAs can see plaintext.

Always Encrypted with randomized encryption

Why wrong: Randomized encryption provides stronger security but does not support equality comparisons because the same plaintext encrypts to different ciphertexts each time.

Dynamic Data Masking

Why wrong: Dynamic Data Masking obfuscates data for non-privileged users but does not encrypt it; privileged users can still see plaintext.

Transparent Data Encryption (TDE)

Why wrong: TDE encrypts the entire database at rest, but the database engine can still access plaintext. DBAs can query encrypted data in plaintext.

Dynamic Data Masking

Why wrong: Dynamic Data Masking hides data from non-privileged users, but users with the 'db_owner' role can still see the unmasked plaintext data.

Row-Level Security

Why wrong: Row-Level Security restricts row access based on user, but it does not encrypt data. DBAs with 'db_owner' can bypass such policies.

Add the managed identity as an Azure AD admin for the SQL server.

Why wrong: Adding the managed identity as an Azure AD admin grants server-level admin privileges, which is not required and is overly permissive.

Enable Azure AD-only authentication on the SQL server.

Why wrong: Azure AD-only authentication is an optional setting that restricts SQL authentication, but it is not required for managed identity access.

AKS managed identity

Why wrong: Managed identity would give the cluster direct access to ACR, violating the policy of not using cluster identity.

ACR admin account

Why wrong: Admin account is a shared account with elevated access, not recommended for production.

Azure AD pod identity

Why wrong: Pod identity gives pods an Azure AD identity, which could be used to authenticate but still uses an identity; the requirement specifically wants a service principal secret.

Transparent Data Encryption (TDE)

Why wrong: TDE encrypts the entire database at rest but automatically decrypts data when read; privileged users can access plaintext data. It does not support queries on encrypted data.

Dynamic Data Masking

Why wrong: Dynamic Data Masking obfuscates data from non-privileged users but does not encrypt it; privileged users can see plaintext. It does not support encrypted queries.

Row-Level Security

Why wrong: Row-Level Security controls access to rows based on a function but does not encrypt any data; privileged users can still read all rows.

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

Why wrong: This is related but the 'Azure Disk Encryption' access policy specifically enables platform access; the statement is vague.

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

Why wrong: While a firewall could cause failure, the access policy omission is more common and specifically required.

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

Why wrong: ADE does not use the VM's managed identity; it uses the Azure platform identity.

Enable the Key Vault firewall and add the VM's public IP address to the allowed list.

Why wrong: This allows access but traffic goes over the public internet, violating the requirement to avoid the public internet.

Use a service endpoint for Key Vault on the VM's subnet, and assign a managed identity to the VM.

Why wrong: Service endpoints provide connectivity over the Azure backbone without public IP, but the traffic still uses public-facing endpoints. Private endpoints are explicitly required for private connectivity.

Assign a system-assigned managed identity to the VM and grant it access to the Key Vault.

Why wrong: Managed identity provides authentication but does not ensure that the network path is private.