CCNA Secure Compute Storage Db Questions — Page 2 of 2

MCQeasy

You need to ensure that all data at rest in an Azure Storage account is encrypted using a customer-managed key. Which feature should you enable?

A.Azure Disk Encryption

B.Azure Storage Service Encryption (SSE) with platform-managed key

C.Azure Storage Service Encryption with customer-managed key

D.Azure Information Protection

AnswerC

Customer-managed keys wrap the storage account's data encryption key in Azure Key Vault, giving you control over rotation and revocation. This satisfies the requirement for encryption at rest governed by your own key rather than a Microsoft-managed one.

Why this answer

Azure Storage Service Encryption (SSE) automatically encrypts data at rest in Azure Storage accounts. By default, it uses Microsoft-managed keys, but you can configure it to use customer-managed keys (CMK) stored in Azure Key Vault. This ensures that you control the encryption keys and can manage their lifecycle, rotation, and access policies, meeting the requirement for customer-managed key encryption.

Exam trap

The trap here is that candidates often confuse Azure Disk Encryption (which encrypts VM disks) with Storage Service Encryption (which encrypts the storage account's blob, file, queue, and table data), leading them to select Option A instead of the correct SSE with CMK.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption (ADE) uses BitLocker (Windows) or DM-Crypt (Linux) to encrypt OS and data disks of virtual machines, not the data at rest in an Azure Storage account. Option B is wrong because SSE with platform-managed key uses Microsoft-managed keys, not customer-managed keys, so it does not satisfy the requirement for customer-managed key control. Option D is wrong because Azure Information Protection (AIP) is a classification and labeling service for documents and emails, not an encryption mechanism for data at rest in Azure Storage.

Practice this question →

MCQmedium

You are a security administrator for a company that stores sensitive data in Azure Blob Storage. The data must be encrypted at rest with a customer-managed key (CMK) stored in Azure Key Vault, and the key must be automatically rotated every 90 days. You need to configure the storage account to meet these requirements. What should you do?

A.Use a customer-provided key (CPK) on each blob upload and configure an Azure Automation runbook to rotate the key every 90 days.

B.Enable infrastructure encryption on the storage account and set the key rotation policy in Key Vault to 90 days.

C.Configure the storage account to use a customer-managed key from Key Vault and set the key rotation policy in Key Vault to 90 days.

D.Create a new customer-managed key in Key Vault every 90 days and manually update the storage account to use the new key.

AnswerC

Configuring the storage account to use a customer-managed key from Key Vault ensures that the data encryption key is wrapped by the CMK. Setting a rotation policy in Key Vault automatically rotates the key every 90 days. Because the storage account references the Key Vault key, it will use the new key version after rotation, meeting both encryption and rotation requirements.

Why this answer

To use a customer-managed key for Azure Storage encryption, you must configure the storage account to reference a key in Key Vault. Key Vault's rotation policy can automatically rotate the key on a schedule, and the storage account will use the latest version if configured to do so. This provides automatic key rotation without manual intervention, satisfying the 90-day requirement.

Exam trap

The trap here is confusing infrastructure encryption or customer-provided keys with customer-managed keys stored in Key Vault, which are distinct features with different configuration steps.

Practice this question →

MCQhard

A healthcare organization stores sensitive patient data in Azure SQL Database. They need to encrypt specific columns containing medical history so that even database administrators with the 'sysadmin' role cannot view the plaintext data. Additionally, they need to support equality comparisons (WHERE clauses) on the encrypted columns. Which encryption technology should they implement?

A.Transparent Data Encryption (TDE)

B.Always Encrypted with randomized encryption

C.Always Encrypted with deterministic encryption

D.Dynamic Data Masking

AnswerC

Always Encrypted with deterministic encryption derives a fixed initialization vector from the plaintext value, so identical plaintexts always yield identical ciphertexts, enabling the server to perform equality comparisons, joins, and exact-match lookups without ever seeing the plaintext. The column encryption key is stored and used only on the client side (for example, in Windows Certificate Store or Azure Key Vault), meaning SQL Server and DBAs see only opaque ciphertext and cannot decrypt the data. This achieves the dual goal of secure patient data protection while retaining the ability to query by known identifiers.

Why this answer

Always Encrypted with deterministic encryption is correct because it encrypts specific columns at the client side, ensuring that even database administrators with 'sysadmin' role cannot view plaintext data. Deterministic encryption generates the same ciphertext for identical plaintext values, which allows equality comparisons (WHERE clauses) on encrypted columns, meeting both requirements.

Exam trap

The trap here is that candidates confuse Dynamic Data Masking with encryption, thinking it prevents privileged users from seeing data, when in fact it only masks output and does not protect data at rest or from direct queries by sysadmins.

How to eliminate wrong answers

Option A is wrong because Transparent Data Encryption (TDE) encrypts the entire database at rest but does not protect data from database administrators who have access to the database engine; they can still query plaintext data. Option B is wrong because Always Encrypted with randomized encryption does not support equality comparisons (WHERE clauses) on encrypted columns, as it produces different ciphertext for the same plaintext each time. Option D is wrong because Dynamic Data Masking only obfuscates data at query result time but does not encrypt the underlying data, so administrators with 'sysadmin' role can still access plaintext by running queries without masking.

Practice this question →

MCQmedium

A company stores sensitive data in Azure Blob Storage. They want to encrypt the data at rest using customer-managed keys (CMK) stored in Azure Key Vault. Additionally, they want the key to be automatically rotated every 90 days without manual intervention. Which configuration should they implement?

A.Enable Azure Storage encryption with a CMK and configure a rotation policy on the storage account.

B.Enable Azure Storage encryption with a CMK and enable automatic key rotation in Azure Key Vault by creating a rotation policy.

C.Enable Azure Storage encryption with a CMK and manually rotate the key every 90 days.

D.Use Azure Storage service-side encryption with platform-managed keys and enforce rotation via Azure Policy.

AnswerB

This is correct because with a customer-managed key (CMK) in Azure Key Vault, you can define a key rotation policy that automatically generates new key versions on a schedule. The storage account must reference the key URI without a specific version so it automatically uses the latest key version. This provides the required automatic rotation of the encryption key, fully managed through Azure Key Vault, without manual intervention.

Why this answer

Azure Key Vault supports automatic key rotation through a rotation policy, which can be configured to rotate a customer-managed key (CMK) every 90 days without manual intervention. When Azure Storage encryption uses a CMK stored in Key Vault, the storage account references the key version, and enabling a rotation policy in Key Vault automatically creates new key versions, which Azure Storage then uses for encryption. This satisfies the requirement for automated 90-day rotation without manual steps.

Exam trap

The trap here is that candidates confuse where the rotation policy is configured—thinking it is on the storage account (Option A) rather than in Azure Key Vault, or they assume platform-managed keys can be scheduled for rotation (Option D), which is not supported.

How to eliminate wrong answers

Option A is wrong because a rotation policy cannot be configured on the storage account itself; key rotation is managed in Azure Key Vault, not on the storage account resource. Option C is wrong because it requires manual rotation every 90 days, which contradicts the requirement for automatic rotation without manual intervention. Option D is wrong because platform-managed keys (PMK) cannot be rotated on a custom schedule; they are managed entirely by Microsoft, and Azure Policy cannot enforce a specific rotation interval for PMKs.

Practice this question →

MCQmedium

Your company uses Azure Storage to store sensitive customer data. You need to ensure that only authorized applications running on Azure VMs can access the storage account without using shared keys or SAS tokens. What should you configure?

A.Use Azure AD authentication with storage account access keys.

B.Enable Azure Storage firewall, deny access from all networks, and add a private endpoint. Then assign a managed identity to the VMs and grant it the necessary RBAC role.

C.Configure a storage account key and distribute it to the applications.

D.Generate a SAS token with IP restrictions and embed it in the application code.

AnswerB

This is the correct keyless design. Enabling the storage firewall to deny all public network traffic ensures the account is unreachable from the internet, while adding a private endpoint places the storage account on a private IP within your VNet, so traffic never traverses the public endpoint. Assigning a managed identity to the VMs and granting the appropriate RBAC role (e.g., Storage Blob Data Reader) provides identity-based, least-privilege access without any account key or SAS token, and access is further verified against the virtual network rules.

Why this answer

Azure Storage firewall with service endpoints or private endpoints, combined with managed identity, allows secure access without shared keys or SAS tokens. Option A (storage account key) is a shared key. Option C (SAS token) is a shared access signature.

Option D (access keys) are shared keys.

Practice this question →

MCQeasy

You need to ensure that all new blobs uploaded to an Azure Storage account are automatically encrypted at rest. What is the simplest way to achieve this?

A.Use Azure Disk Encryption on any VMs writing to storage.

B.Implement client-side encryption in the application.

C.Enable Azure Storage Service Encryption (SSE) on the storage account.

D.Configure a customer-managed key in Azure Key Vault.

AnswerC

Azure Storage Service Encryption (SSE), now formally called Azure Storage encryption, is automatically enabled at the storage account level and transparently encrypts all data at rest—including blobs, files, queues, and tables—using AES-256 before it is written to disk. No extra configuration is needed for new blobs because encryption is applied by the platform on every write and decrypted on every read without any code changes. Ensuring that this setting is enabled (or simply confirming it is already on by default) directly guarantees that all new blob uploads are encrypted at rest.

Why this answer

Azure Storage Service Encryption (SSE) automatically encrypts data at rest for all storage accounts using 256-bit AES encryption, and it is enabled by default for new storage accounts. This ensures that any new blobs uploaded are encrypted without requiring any application changes or additional configuration, making it the simplest solution.

Exam trap

The trap here is that candidates often confuse Azure Disk Encryption (which encrypts VM disks) with Storage Service Encryption (which encrypts data at rest in Azure Storage), leading them to select option A incorrectly.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption encrypts the OS and data disks of VMs, not the blobs stored in Azure Storage; it protects data at the VM level, not the storage service level. Option B is wrong because client-side encryption requires modifying the application code to encrypt data before uploading, which adds complexity and is not the simplest approach. Option D is wrong because configuring a customer-managed key in Azure Key Vault is an additional step that can be used with SSE for more control, but SSE with Microsoft-managed keys already provides automatic encryption at rest without extra configuration.

Practice this question →

MCQmedium

You are deploying a new application on Azure VMs. The application must be encrypted at rest and during transmission. Which combination of features should you implement?

A.Azure Firewall and Azure Disk Encryption

B.Azure Disk Encryption and HTTPS

C.Azure Storage Service Encryption and SSL

D.Azure Disk Encryption and SSL

AnswerB

This combination fully satisfies both stated requirements. Azure Disk Encryption encrypts the VM's managed OS and data disks at rest using BitLocker for Windows and DM-Crypt for Linux, integrating with Azure Key Vault to protect the disk encryption keys. HTTPS, which relies on TLS, encrypts the application traffic in transit between the VM and its clients, preventing eavesdropping and tampering along the network path. Together, they provide the required at-rest and in-transit confidentiality for an Azure VM-hosted application.

Why this answer

Azure Disk Encryption (ADE) provides at-rest encryption for Azure VM disks using BitLocker (Windows) or DM-Crypt (Linux), while HTTPS ensures encryption in transit between the client and the application. Together, they satisfy the requirement for encryption both at rest and during transmission.

Exam trap

The trap here is that candidates often confuse Azure Storage Service Encryption (which applies to Azure Blob/File storage) with Azure Disk Encryption (which applies to VM disks), or they assume SSL/TLS alone covers all encryption needs, forgetting that at-rest encryption requires a separate mechanism like ADE.

How to eliminate wrong answers

Option A is wrong because Azure Firewall is a network security service that filters traffic, not an encryption mechanism; it does not encrypt data at rest or in transit. Option C is wrong because Azure Storage Service Encryption (SSE) encrypts data at rest in Azure Storage accounts, but it does not apply to VM disks, and SSL (the predecessor to TLS) is a transport encryption protocol, but the combination does not cover VM disk encryption. Option D is wrong because SSL (or TLS) provides in-transit encryption, but Azure Disk Encryption is needed for at-rest encryption; however, the question asks for the correct combination, and Option B explicitly pairs ADE with HTTPS (which is HTTP over TLS), making it the precise answer.

Practice this question →

MCQeasy

You are configuring security for an Azure App Service web app that connects to an Azure SQL Database. You need to ensure that the database connection string does not contain credentials in plaintext. What should you use?

A.Store the connection string in the web.config file with encryption.

B.Store the connection string in Azure Key Vault and use a Key Vault reference in the App Service application settings.

C.Store the connection string in Azure App Configuration with encryption.

D.Store the connection string in an App Service application setting without encryption.

AnswerB

Using an Azure Key Vault reference in an App Service application setting, written as `@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/...)`, removes the connection string from the App Service configuration entirely. App Service authenticates to Key Vault with the app's managed identity, retrieves the secret at runtime, and injects it as an environment variable, so the secret is never stored in plaintext on the platform. This enables central secret governance, granular access policies, full audit logging, and rotation without redeploying the application, making it the most secure and operationally efficient option.

Why this answer

Azure Key Vault provides a secure, centralized store for secrets like database connection strings. By using a Key Vault reference in the App Service application settings (e.g., @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)), the connection string is never exposed in plaintext in configuration files or environment variables, and access is controlled via managed identities or service principals.

Exam trap

The trap here is that candidates often confuse Azure App Configuration (which is for feature flags and configuration management, not secret storage) with Azure Key Vault, or they assume that encrypting a configuration file (web.config) is sufficient, not realizing that the decryption key is co-located and the plaintext is still exposed at runtime.

How to eliminate wrong answers

Option A is wrong because encrypting the web.config file (e.g., using aspnet_regiis.exe) only protects the file at rest on the server, but the decryption key is stored on the same machine, making it vulnerable to compromise; Azure App Service does not support this encryption natively, and the plaintext is still exposed during runtime. Option C is wrong because Azure App Configuration with encryption still stores the secret in a configuration store that requires additional access management, but it does not provide the same level of secret rotation, auditing, and access control as Key Vault; the connection string would still be retrievable in plaintext by anyone with access to the App Configuration store. Option D is wrong because storing the connection string in an App Service application setting without encryption leaves it as plaintext in the Azure portal and in the runtime environment, which can be exposed through logs, debugging, or compromised access.

Practice this question →

MCQeasy

You need to encrypt an Azure Storage account at rest using a customer-managed key stored in Azure Key Vault. Which feature should you enable?

A.Azure Information Protection

B.Azure Confidential Computing

C.Azure Disk Encryption

D.Azure Storage Service Encryption with customer-managed keys

AnswerD

Azure Storage Service Encryption (SSE) automatically encrypts all data at rest in an Azure storage account using AES-256 before it is persisted to disk. When configured with customer-managed keys, you supply a key from your Azure Key Vault or Managed HSM, giving you control over rotation, revocation, and audit logging of the encryption key. This is the correct service-level mechanism to encrypt a storage account at rest with a key you manage.

Why this answer

Azure Storage Service Encryption (SSE) encrypts data at rest automatically. By enabling customer-managed keys (CMK) in Azure Key Vault, you can control the encryption key used for SSE, meeting the requirement to encrypt the storage account with a key you manage.

Exam trap

The trap here is confusing Azure Disk Encryption (which encrypts VM disks) with Azure Storage Service Encryption (which encrypts the storage account's data at rest), leading candidates to pick Option C when the question explicitly targets storage account encryption.

How to eliminate wrong answers

Option A is wrong because Azure Information Protection is a data classification and labeling service, not an encryption mechanism for storage accounts. Option B is wrong because Azure Confidential Computing protects data in use via trusted execution environments (TEEs), not data at rest in storage. Option C is wrong because Azure Disk Encryption uses BitLocker or DM-Crypt to encrypt OS/data disks on VMs, not Azure Storage account blobs, files, or queues.

Practice this question →

MCQmedium

Refer to the exhibit. You are configuring network access for an Azure Storage account. After applying this configuration, users report that they cannot access the storage account from their on-premises network (public IP: 198.51.100.50). What is the most likely reason?

A.The storage account is configured with a private endpoint

B.The bypass for AzureServices is not configured correctly

C.The virtual network rules are missing

D.The user's public IP address is not in the allowed IP rules

AnswerD

The storage account's firewall has an IP allow rule only for 203.0.113.0/24. The user's public IP address is 198.51.100.50, which falls outside that CIDR range. Because the default action for the firewall is to deny all traffic that does not match an allow rule, the request is blocked. The IP must be added to the allowed range, or the user must use a permitted network path.

Why this answer

The correct answer is D: the user's public IP address is not in the allowed IP rules. When an Azure Storage account firewall is configured with selected networks, only traffic from explicitly listed public IP addresses (or ranges) and permitted virtual networks is allowed; since the on-premises public IP 198.51.100.50 is not included in the allowed IP rules, requests are denied. Option A is not the likely cause because a private endpoint would affect access over the private link rather than simply blocking an on-premises public IP, and the scenario points to firewall IP filtering.

Option B is incorrect because the AzureServices bypass applies to trusted Microsoft services, not to on-premises clients. Option C is incorrect because missing virtual network rules would not matter for an on-premises client connecting over the public internet.

Practice this question →

Multi-Selectmedium

You need to protect Azure SQL Database from SQL injection attacks. Which TWO measures should you implement? (Choose TWO.)

Select 2 answers

A.Use Always Encrypted for sensitive columns.

B.Deploy Azure Web Application Firewall (WAF) in front of the application.

C.Enable Transparent Data Encryption (TDE).

D.Enable SQL Server auditing.

E.Use parameterized queries in application code.

AnswersB, E

Azure Web Application Firewall, when attached to Application Gateway or Front Door, evaluates incoming HTTP requests against managed rule sets that specifically detect SQL injection patterns, allowing you to block malicious payloads at the network edge before they reach your application. It filters on query strings, request bodies, and header parameters using signature analysis and can scale to absorb attack traffic. This is a strong compensating control, but it operates outside the database engine and may require false-positive tuning.

Why this answer

Option B is correct because Azure Web Application Firewall (WAF), typically via Application Gateway or Front Door, inspects HTTP/HTTPS traffic and applies OWASP Core Rule Set rules that detect and block common SQL injection payloads before they reach the application or database. Option E is correct because parameterized queries (prepared statements) cause the database engine to treat user input strictly as data rather than executable SQL, which is the fundamental application-level defense against SQL injection. Option A is not correct here because Always Encrypted protects data confidentiality at rest and in memory by encrypting sensitive columns, but it does not detect or prevent SQL injection.

Option C is not correct because Transparent Data Encryption (TDE) only encrypts data and log files at rest and has no bearing on injection attacks. Option D is not correct because SQL Server auditing records activity for compliance and forensic review after the fact; it is a detective control, not a preventive measure against SQL injection.

Exam trap

The trap here is that candidates often confuse data-at-rest encryption (TDE or Always Encrypted) with input validation or application-layer defenses, mistakenly thinking encryption alone can prevent SQL injection attacks.

Practice this question →

MCQhard

A company uses Azure SQL Database with Transparent Data Encryption (TDE) protected by a customer-managed key (CMK) stored in Azure Key Vault. The Key Vault has a firewall enabled that denies all public network access. The SQL server is in the same region and has a system-assigned managed identity with the 'Key Vault Crypto Service Encryption User' role assigned at the key scope. However, TDE operations fail because the SQL server cannot access the Key Vault. What additional configuration is required to allow the SQL server to access the Key Vault for TDE operations?

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

B.Enable the 'Allow trusted Microsoft services to bypass the firewall' setting on the Key Vault.

C.Change the Key Vault firewall to allow all Azure services.

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

AnswerB

This setting allows trusted Azure services, including Azure SQL Database, to access the Key Vault even when the firewall is enabled. Since the SQL server's managed identity already has the cryptographic role, this is the missing piece to allow TDE operations.

Why this answer

When Azure Key Vault has a firewall that denies all public network access, the 'Allow trusted Microsoft services to bypass this firewall' setting is required for Azure SQL Database (a trusted Microsoft service) to authenticate using its system-assigned managed identity and access the customer-managed key for TDE. This setting allows the SQL server to reach the Key Vault over the Microsoft backbone network without requiring a private endpoint or VNet integration, as the service is explicitly trusted by Azure.

Exam trap

The trap here is that candidates often assume a private endpoint or VNet service endpoint is always required for Key Vault access when firewalls are enabled, but they overlook the 'Allow trusted Microsoft services' bypass which is specifically designed for Azure PaaS services like SQL Database to access Key Vault without additional network configuration.

How to eliminate wrong answers

Option A is wrong because configuring a private endpoint for the SQL server to the Key Vault would require the SQL server to be in a VNet with a private endpoint connection, but the SQL server is not VNet-injected by default and the question does not indicate VNet integration; additionally, the system-assigned managed identity and role assignment are already in place, so the issue is firewall bypass, not network connectivity. Option C is wrong because 'Allow all Azure services' is a legacy setting that is overly permissive and deprecated in favor of the more specific 'Allow trusted Microsoft services' option; it would also allow all Azure services, not just trusted ones, which violates least-privilege principles. Option D is wrong because a VNet service endpoint for Microsoft.KeyVault on the SQL server's subnet would only help if the SQL server were deployed in a VNet (which it is not by default for Azure SQL Database), and service endpoints do not bypass the Key Vault firewall's deny-all rule unless the firewall explicitly allows the specific VNet/subnet, which is not mentioned.

Practice this question →

MCQhard

A company plans to enable Azure Disk Encryption (ADE) on their Windows virtual machines. They will use a Key Encryption Key (KEK) stored in Azure Key Vault. What additional configuration must be made in the Key Vault to allow the Azure platform to access the KEK for encrypting the VM disks?

A.Grant the Azure Disk Encryption service principal 'Reader' role on the key vault.

B.Set the key vault's 'enabledForDiskEncryption' property to true.

C.Grant the virtual machine's managed identity 'Contributor' role on the key vault.

D.Configure soft-delete and purge protection on the key vault.

AnswerB

The 'enabledForDiskEncryption' boolean property on the key vault is a specific vault-level flag that tells Azure's compute platform that the vault is allowed to be used by the Azure Disk Encryption service. When set to true, it grants the ADE service (which runs as part of the Microsoft.Compute resource provider) the necessary access to read secrets and use keys wrapped in the vault during the encryption workflow. This is the standard prerequisite because neither a user-assigned identity nor a service principal with RBAC on the vault alone can suffice without this setting.

Why this answer

Azure Disk Encryption requires the key vault's 'enabledForDiskEncryption' property to be set to true. This property explicitly authorizes the Azure platform (specifically the Azure Disk Encryption service) to access the Key Encryption Key (KEK) stored in the vault for encrypting VM disks. Without this flag, the platform cannot retrieve the KEK, even if other permissions exist.

Exam trap

The trap here is that candidates often confuse the 'enabledForDiskEncryption' property with RBAC roles or managed identity permissions, assuming that granting a role to the VM or service principal is sufficient, when in fact the platform requires this specific vault-level flag to be enabled.

How to eliminate wrong answers

Option A is wrong because granting the Azure Disk Encryption service principal the 'Reader' role on the key vault is unnecessary; the platform uses the 'enabledForDiskEncryption' property, not an RBAC role, to authorize access. Option C is wrong because granting the VM's managed identity 'Contributor' role on the key vault is not required; ADE does not use the VM's identity to access the KEK—it uses the platform's identity authorized by the vault property. Option D is wrong because soft-delete and purge protection are important for recovery and compliance but are not required for the platform to access the KEK during encryption; they are separate prerequisites for some scenarios but not the specific configuration needed here.

Practice this question →

MCQmedium

A company has an Azure SQL Database that contains sensitive financial data. They want to audit all successful and failed login attempts for the database. What should they configure?

A.Azure SQL Database auditing

B.SQL Vulnerability Assessment

C.Microsoft Defender for Cloud alerts

D.Azure AD sign-in logs

AnswerA

Azure SQL Database auditing records both failed and successful login attempts to the SQL database, along with all database events such as INSERT, UPDATE, and DELETE operations. It writes the audit logs to an Azure Storage account, Log Analytics workspace, or Event Hub, giving a complete, queryable audit trail of who accessed the database and what actions they performed. This makes it the correct service for detecting and investigating sensitive-data access or brute-force login attempts.

Why this answer

Azure SQL Database auditing is the correct configuration because it captures both successful and failed login attempts (authentication events) at the database level. Auditing writes these events to an audit log destination (such as Azure Storage, Log Analytics, or Event Hubs), enabling detailed forensic analysis of access patterns. This directly meets the requirement to audit all login attempts for the sensitive financial database.

Exam trap

The trap here is that candidates often confuse Azure AD sign-in logs (which track Azure AD authentication) with SQL Database login auditing, failing to realize that SQL Database auditing is the only feature that captures all authentication attempts at the database engine level, including SQL authentication and contained database users.

How to eliminate wrong answers

Option B is wrong because SQL Vulnerability Assessment is a service that scans for potential security misconfigurations and vulnerabilities in the database, not a tool for capturing login audit events. Option C is wrong because Microsoft Defender for Cloud alerts provide security incident notifications based on threat detection, but they do not natively log every successful or failed login attempt for auditing purposes. Option D is wrong because Azure AD sign-in logs track authentication to Azure AD itself, not to the Azure SQL Database; SQL Database authentication events are not recorded in Azure AD sign-in logs unless Azure AD authentication is used and the logs are specifically configured to capture them, but even then, they do not cover all SQL-level login attempts (e.g., SQL authentication).

Practice this question →

MCQmedium

A company uses Azure SQL Database and wants to protect sensitive data (e.g., credit card numbers) from database administrators. They require that the data is encrypted at rest and in transit, and only a client application using a specific driver can decrypt it. Which technology should they implement?

A.Transparent Data Encryption (TDE)

B.Always Encrypted

C.Dynamic Data Masking (DDM)

D.Row-Level Security (RLS)

AnswerB

Always Encrypted encrypts sensitive columns at the client side, ensuring that the data is never exposed in plaintext to the server or DBAs. Only the client application with the column master key can decrypt the data.

Why this answer

Always Encrypted is the correct choice because it ensures that sensitive data (e.g., credit card numbers) is encrypted both at rest and in transit, and the encryption keys are never exposed to the database engine. Only a client application using the Always Encrypted-enabled driver (e.g., ADO.NET with Column Encryption Setting=enabled) can decrypt the data, protecting it from database administrators or any unauthorized access to the database server.

Exam trap

The trap here is that candidates often confuse Transparent Data Encryption (TDE) with Always Encrypted because both involve encryption, but TDE does not protect data from database administrators or encrypt data in transit, which is the core requirement in this scenario.

How to eliminate wrong answers

Option A is wrong because Transparent Data Encryption (TDE) encrypts data at rest but does not protect data in transit, and the database engine has access to the encryption keys, so DBAs can still see plaintext data. Option C is wrong because Dynamic Data Masking (DDM) only obfuscates data at query results for unauthorized users, but the underlying data remains unencrypted in storage and in transit, and DBAs can bypass masking. Option D is wrong because Row-Level Security (RLS) controls access to rows based on user context but does not encrypt data at rest or in transit, and DBAs with elevated permissions can still read all data.

Practice this question →

Multi-Selectmedium

Which two actions should you take to secure Azure Storage accounts against data exfiltration?

Select 2 answers

A.Use Azure Private Endpoints for storage accounts.

B.Enable shared access key authentication.

C.Configure firewall and virtual network service endpoints.

D.Enable soft delete for blobs.

E.Configure CORS rules to allow all origins.

AnswersA, C

A private endpoint grants the storage account a private IP address within your virtual network, so clients connect directly to that IP and all traffic is encapsulated within the Microsoft backbone, never traversing the public internet. This lets you block all public access to the storage account, eliminating the network path an attacker could use to exfiltrate data. It is therefore a core boundary control for preventing data exfiltration.

Why this answer

Correct: A and C. Firewall and virtual network service endpoints restrict network access, and private endpoints provide secure connectivity. Option B (shared access keys) does not prevent exfiltration.

Option D (soft delete) helps recovery but not prevention. Option E (CORS) controls cross-origin requests, not exfiltration.

Practice this question →

MCQeasy

You need to ensure that Azure SQL Database automatically detects and alerts on potential SQL injection attacks. Which Microsoft Defender for Cloud plan should you enable?

A.Microsoft Defender for SQL

B.Microsoft Defender for Storage

C.Microsoft Defender for Cloud (free tier)

D.Microsoft Defender for App Service

AnswerA

Microsoft Defender for SQL is the security plan that specifically protects Azure SQL Database, SQL Managed Instance, and Azure Synapse SQL. When enabled, it automatically monitors SQL audit logs for suspicious activities such as SQL injection, brute-force login attempts, and anomalous data exfiltration, generating security alerts in Microsoft Defender for Cloud. This is the direct service needed to satisfy the requirement for automatic threat detection on Azure SQL Database.

Why this answer

Microsoft Defender for SQL includes advanced SQL security features such as Vulnerability Assessment, Advanced Threat Protection, and Data Discovery & Classification. Specifically, its Advanced Threat Protection capability uses machine learning models to detect anomalous database activities, including SQL injection attempts, and can trigger alerts or automated responses. Enabling this plan on your Azure SQL Database ensures that potential SQL injection attacks are automatically detected and alerted.

Exam trap

The trap here is that candidates often confuse Microsoft Defender for Cloud's free tier with the paid plans, assuming basic threat detection is included, or they mistakenly think Defender for App Service covers database-level threats, when in fact only Defender for SQL provides the specific SQL injection detection for Azure SQL Database.

How to eliminate wrong answers

Option B is wrong because Microsoft Defender for Storage is designed to detect threats like malware uploads, anomalous access patterns, and data exfiltration in Azure Blob Storage, Azure Files, and Azure Data Lake Storage, not SQL injection attacks against Azure SQL Database. Option C is wrong because the free tier of Microsoft Defender for Cloud provides only basic security assessments and recommendations without the advanced threat detection capabilities, such as SQL injection alerting, which require a paid plan. Option D is wrong because Microsoft Defender for App Service protects web applications running on Azure App Service from threats like DDoS, brute force, and web application attacks, but it does not directly monitor or alert on SQL injection attacks targeting Azure SQL Database.

Practice this question →

MCQmedium

A company uses Azure SQL Database with Azure Active Directory authentication. To meet compliance requirements, they need to audit all failed login attempts and store the audit logs in a storage account located in a different Azure region for disaster recovery. What should they configure?

A.Enable SQL Auditing and set the destination to a Log Analytics workspace in a different region.

B.Enable SQL Auditing and set the destination to an Event Hub namespace in the same region.

C.Enable SQL Auditing and set the destination to an Azure Storage account in a different region.

D.Enable Advanced Threat Protection for Azure SQL Database and configure email notifications.

AnswerC

Azure SQL Auditing can write audit logs directly to an Azure Storage account, and placing that account in a different region provides geographic separation for disaster recovery. You can select a storage account configured with geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS), so audit .xel files are replicated to a paired region and remain accessible even if the primary SQL database region fails. This durable, long-term storage model satisfies compliance requirements for failed-login auditing and supports immutable retention policies to prevent tampering.

Why this answer

Azure SQL Database auditing can be configured to write audit logs directly to an Azure Storage account. Storing the logs in a storage account located in a different Azure region meets the disaster recovery requirement by ensuring logs survive a regional outage. The audit logs capture all database events, including failed login attempts, which satisfies the compliance need.

Exam trap

The trap here is that candidates often confuse auditing with threat detection or choose a Log Analytics workspace for centralized logging, overlooking the explicit requirement for durable, cross-region storage for compliance and disaster recovery.

How to eliminate wrong answers

Option A is wrong because a Log Analytics workspace does not provide geo-redundant storage for disaster recovery; it is primarily for log analytics and monitoring, not for long-term archival in a different region. Option B is wrong because an Event Hub namespace is a real-time streaming service, not a durable storage destination for audit logs, and it is specified to be in the same region, which fails the disaster recovery requirement. Option D is wrong because Advanced Threat Protection (ATP) detects suspicious activities and sends email notifications, but it does not audit or store failed login attempts in a storage account for compliance purposes.

Practice this question →

MCQhard

Your company uses Azure SQL Database with Microsoft Entra ID authentication. You need to restrict a user to only view data from the 'Sales' schema, without granting permissions to other schemas. What should you do?

A.Add the user to the db_datareader role in the database.

B.Use a DENY statement on all other schemas for the user.

C.Create a user mapped to the Entra ID user and grant SELECT on the Sales schema only.

D.Create a contained database user with password and assign to db_datareader.

AnswerC

This is the correct approach because Azure SQL Database supports creating a database user mapped directly to a Microsoft Entra ID user (CREATE USER [user@domain.com] FROM EXTERNAL PROVIDER). After creating that mapped user, you can issue a focused GRANT SELECT ON SCHEMA::Sales TO [user], which grants read access solely to objects in the Sales schema. This aligns with least privilege by allowing only the specific schema needed and works natively with Entra ID authentication.

Why this answer

It directly implements the principle of least privilege by creating a database user mapped to the Microsoft Entra ID user and granting SELECT only on the Sales schema. This ensures the user can view data exclusively within that schema, with no implicit permissions on other schemas. Azure SQL Database supports schema-level permissions, making this a precise and secure approach.

Exam trap

The trap here is that candidates often confuse database-level roles (like db_datareader) with schema-level permissions, mistakenly assuming that adding a user to a read-only role is sufficient, while ignoring that db_datareader grants access to all schemas, not a specific one.

How to eliminate wrong answers

Option A is wrong because adding the user to the db_datareader role grants read access to all user tables and views across all schemas in the database, which violates the requirement to restrict access to only the Sales schema. Option B is wrong because using a DENY statement on all other schemas is overly broad and can be overridden by explicit GRANT permissions; more importantly, it does not grant the necessary SELECT permission on the Sales schema, so the user would have no access at all. Option D is wrong because creating a contained database user with a password bypasses Microsoft Entra ID authentication entirely, and assigning db_datareader again grants access to all schemas, not just Sales.

Practice this question →

Multi-Selectmedium

You need to protect Azure SQL Database from SQL injection attacks. Which TWO measures should you implement?

Select 2 answers

A.Enable Transparent Data Encryption (TDE)

B.Implement Azure Web Application Firewall (WAF)

C.Configure Azure SQL Database firewall rules

D.Use parameterized queries in application code

E.Enable Always Encrypted for sensitive columns

AnswersB, D

Azure Web Application Firewall inspects inbound HTTP/S requests and blocks known SQL injection signatures before they reach the database, satisfying the requirement to filter malicious payloads at the application edge rather than relying solely on database-side controls.

Why this answer

Option B (Azure Web Application Firewall) is correct because WAF, especially when deployed with Azure Application Gateway or Front Door, includes managed rule sets that detect and block common SQL injection patterns in HTTP requests before they reach the database. Option D (parameterized queries) is correct because parameterization separates SQL code from user-supplied data, so injected input is treated as a literal value rather than executable SQL, which is the most fundamental defense against SQL injection at the application layer. Option A (TDE) is not correct because it only encrypts data at rest and does nothing to prevent injection attacks.

Option C (Azure SQL Database firewall rules) is not correct because it restricts access by IP address or Azure service, not by inspecting query content. Option E (Always Encrypted) is not correct because it protects sensitive column data from unauthorized viewing, not from SQL injection logic.

Exam trap

The trap here is that candidates often confuse network-level controls (firewall rules) or encryption features (TDE, Always Encrypted) with application-layer defenses against SQL injection, leading them to select options that protect data confidentiality or access but do not prevent the injection attack itself.

Practice this question →

MCQhard

You are a security administrator for a company that stores sensitive data in Azure Blob Storage. You need to ensure that data cannot be accessed from outside the corporate network, even if someone obtains a valid SAS token. The company uses a site-to-site VPN to connect to Azure. What should you configure?

A.Configure storage firewall to allow access only from selected virtual networks and IP ranges.

B.Enable soft delete for blobs.

C.Use customer-managed keys (CMK) for encryption at rest.

D.Enable Azure Defender for Storage.

AnswerA

The storage firewall restricts access to the storage account to specific virtual networks and IP addresses. By allowing only the corporate VPN's virtual network or public IP, you ensure that even with a valid SAS token, access from outside the corporate network is blocked.

Why this answer

To restrict blob access to the corporate network, you must configure the storage account firewall to allow only specific virtual networks or IP ranges. This ensures that requests from outside the allowed networks are denied, even if they present a valid SAS token.

Exam trap

The trap here is confusing data-at-rest encryption or threat detection with network access control, or assuming that SAS tokens alone provide sufficient security.

Practice this question →

MCQmedium

You are reviewing the ARM template for an Azure Disk Encryption Set. The template includes the JSON snippet shown. You notice that the key version is empty. What is the consequence?

A.The encryption set will use a platform-managed key.

B.The encryption set will automatically use the latest version of the key.

C.The encryption set will use the key name without any version, causing it to fail.

D.The deployment will fail because a key version is required.

AnswerB

When the keyUrl in the Disk Encryption Set ARM template omits the key version, Azure treats the reference as pointing to the latest version of the named key. This enables automatic key rotation because, whenever a new version of the key is created in Key Vault, the DES will pick it up without requiring a template update or redeployment. This is the intended behavior for customer-managed keys on managed disks, as long as the key vault has soft-delete and purge protection enabled.

Why this answer

When the key version is omitted in an Azure Disk Encryption Set ARM template, the encryption set automatically uses the latest version of the key from the specified Azure Key Vault. This behavior allows the encryption set to stay updated with key rotations without requiring manual template updates, as Azure Disk Encryption Sets support automatic key version updates when no version is specified.

Exam trap

The trap here is that candidates often assume a missing key version will cause a deployment failure or fallback to platform-managed keys, but Azure explicitly supports versionless key references to enable automatic key rotation, which is a key security and compliance feature.

How to eliminate wrong answers

Option A is wrong because omitting the key version does not fall back to a platform-managed key; the encryption set still uses a customer-managed key from Key Vault, just without a pinned version. Option C is wrong because the key name without a version does not cause a failure; Azure interprets the missing version as a directive to use the latest version of that key. Option D is wrong because a key version is not required for deployment; the ARM template will deploy successfully and the encryption set will dynamically resolve to the current version of the key.

Practice this question →

MCQmedium

Your company uses Azure SQL Database. You need to ensure that all queries are audited for compliance. Which feature should you enable?

A.Enable SQL Vulnerability Assessment.

B.Enable SQL Auditing on the server and configure the audit log destination.

C.Configure Dynamic Data Masking.

D.Enable Advanced Threat Protection.

AnswerB

SQL Auditing in Azure SQL Database tracks database events at the server or database level and writes them to a configurable destination such as Azure Storage, Log Analytics, or Event Hubs. By enabling it, you can capture exact T-SQL statements, the principal executing them, timestamps, and success/failure status, effectively logging queries for forensic and compliance purposes. The audit log can be customized via audit action groups to include SELECT, INSERT, UPDATE, DELETE, and other data operations, making this the only option that directly provides query-level logging.

Why this answer

To audit all queries against Azure SQL Database for compliance, you must enable SQL Auditing at the server level and configure an audit log destination (such as Azure Storage, Log Analytics, or Event Hubs). This captures database events, including all queries, and writes them to the chosen destination for review and retention. Option B directly fulfills the requirement to track and log query activity.

Exam trap

The trap here is that candidates often confuse security monitoring features (like Advanced Threat Protection or Vulnerability Assessment) with the specific auditing capability required to log all queries for compliance, leading them to select a feature that detects threats rather than records query history.

How to eliminate wrong answers

Option A is wrong because SQL Vulnerability Assessment is a service that scans for potential security misconfigurations and vulnerabilities, not a feature that logs or audits query execution. Option C is wrong because Dynamic Data Masking limits exposure of sensitive data by obfuscating it in query results, but it does not create an audit trail of who ran which queries. Option D is wrong because Advanced Threat Protection detects anomalous activities and potential threats (e.g., SQL injection), but it does not provide a comprehensive audit log of all queries for compliance purposes.

Practice this question →

MCQeasy

You run the above PowerShell script. What is the effect on the storage account?

A.Block blobs with the prefix 'logs' are deleted after 30 days

B.Block blobs with the prefix 'logs' are deleted after 90 days

C.All block blobs are deleted after 30 days

D.Block blobs with the prefix 'logs' are moved to cool tier after 30 days

AnswerA

The script creates an Azure Storage lifecycle management rule with a filter that matches only block blobs whose name has the prefix 'logs', and the rule's action is Delete on the base blob after a period defined by DaysAfterModificationGreaterThan is set to 30. Therefore, any existing or future block blob under that prefix will be permanently removed once it has been last modified more than 30 days ago, matching the policy intent.

Why this answer

The PowerShell script uses `Add-AzStorageAccountManagementPolicyAction` with `-Action Delete` and `-DaysAfterCreationGreaterThan 30` on a filter that targets block blobs with the prefix 'logs'. This creates a lifecycle management policy rule that automatically deletes those blobs 30 days after their creation. The correct answer is A because the rule specifically applies to block blobs (not all blobs) with the 'logs' prefix and sets a deletion action after 30 days.

Exam trap

The trap here is that candidates often confuse the action type (Delete vs. TierToCool) or misread the prefix filter, assuming the rule applies to all blobs instead of only those with the 'logs' prefix.

How to eliminate wrong answers

Option B is wrong because the script specifies `-DaysAfterCreationGreaterThan 30`, not 90, so blobs are deleted after 30 days, not 90. Option C is wrong because the filter uses `-BlobType 'BlockBlob'` and `-PrefixMatch 'logs'`, so the rule applies only to block blobs with the 'logs' prefix, not all block blobs. Option D is wrong because the action is `-Action Delete`, not `-Action TierToCool`; moving to cool tier would require a different action type.

Practice this question →

100

Multi-Selecthard

Which TWO of the following are valid ways to encrypt data at rest in Azure SQL Database? (Choose two.)

Select 2 answers

A.Dynamic Data Masking

B.Transparent Data Encryption (TDE)

C.Row-Level Security

D.Always Encrypted

E.Azure Disk Encryption (ADE)

AnswersB, D

Transparent Data Encryption performs real-time encryption and decryption of the database, backups, and transaction logs at rest using a symmetric database encryption key, with no application changes. It satisfies the at-rest encryption requirement natively at the storage layer.

Why this answer

Transparent Data Encryption (TDE) [B] is correct because it performs real-time encryption and decryption of the database, associated backups, and transaction log files at rest using a symmetric database encryption key (DEK) protected by a certificate stored in Azure Key Vault or the service-managed key store, directly satisfying the data-at-rest requirement. Always Encrypted [D] is also correct because it encrypts sensitive columns at rest and in memory, with keys held outside the database (in Windows Certificate Store or Azure Key Vault), so the data stored on disk is ciphertext and never exposed to the SQL Database engine. Dynamic Data Masking [A] is not encryption — it merely obfuscates column values in query results for non-privileged users while the underlying data remains plaintext.

Row-Level Security [C] restricts which rows a user can access via predicates but does not encrypt stored data. Azure Disk Encryption (ADE) [E] is not applicable to Azure SQL Database because it targets IaaS virtual machine OS and data disks (BitLocker/DM-Crypt), not the PaaS SQL Database service.

Exam trap

Candidates often confuse Dynamic Data Masking or Row-Level Security with encryption at rest. Another common trap is assuming Azure Disk Encryption applies to Azure SQL Database when it is actually for Azure VMs (IaaS).

Practice this question →

101

MCQhard

A company stores sensitive data in Azure Blob Storage. They want to enforce encryption at rest using a customer-managed key (CMK) stored in Azure Key Vault. Additionally, they require that the key vault be in a different region than the storage account to protect against regional disasters. Can this be achieved, and if so, what is the implication?

A.Yes, but the storage account must use a different key vault per region; no other implications.

B.Yes, but you must enable cross-region replication for the key vault and pay additional costs.

C.No, Azure does not support CMK from a different region than the storage account.

D.Yes, but you must use a managed identity from the storage account's region to access the key vault.

AnswerC

Correct. Azure Storage customer-managed keys require the key vault (or managed HSM) to be in the same Azure region as the storage account. Azure Key Vault is a regional service, and the key material cannot be used for encryption operations outside that region, so a CMK from a different region is simply not supported. This is a documented architectural constraint, and no configuration or feature—such as geo-replication or multi-region vaults—bypasses this requirement.

Why this answer

Azure Blob Storage encryption with customer-managed keys (CMK) requires the key vault to reside in the same Azure region as the storage account. This is a hard platform constraint because the storage account's encryption service must communicate with the key vault over the regional boundary to wrap/unwrap the data encryption key (DEK) using the customer-managed key (KEK). Cross-region CMK is not supported, making option C the correct answer.

Exam trap

The trap here is that candidates assume Azure's global infrastructure allows cross-region key vault access for CMK, but Azure explicitly restricts CMK to the same region to maintain low-latency encryption operations and avoid cross-region dependency for data at rest.

How to eliminate wrong answers

Option A is wrong because it incorrectly states that a different key vault per region is acceptable; Azure does not allow CMK from a different region at all, regardless of the number of key vaults. Option B is wrong because cross-region replication for the key vault does not enable cross-region CMK usage—the storage account's encryption service still requires the key vault to be in the same region, and Azure does not offer a feature to bypass this restriction. Option D is wrong because while a managed identity is required for the storage account to access the key vault, it does not override the regional constraint; the key vault must still be in the same region as the storage account.

Practice this question →

102

MCQeasy

Your organization is using Azure Database for MySQL. You need to ensure that only traffic from Azure services and specific client IP addresses can connect to the database. What should you configure?

A.Azure Active Directory authentication

B.Virtual Network service endpoints

C.Network Security Group (NSG) rules on the subnet

D.Firewall rules with 'Allow access to Azure services' enabled and specific IP rules

AnswerD

The correct network access control for Azure Database for MySQL is the server-level firewall, which accepts connections only from explicitly allowed IP ranges. Enabling 'Allow access to Azure services' adds the special Azure internal IP range, permitting connections from other Azure services without a specific public IP. Adding precise IP rules for client workstations or office ranges further restricts the database to known sources, making this the suitable mechanism for the described requirement.

Why this answer

Azure Database for MySQL uses firewall rules to control access at the server level. Enabling 'Allow access to Azure services' permits connections from Azure internal IP ranges, while adding specific client IP rules restricts access to only those addresses. This dual configuration meets the requirement to allow traffic from Azure services and specific client IPs while blocking all other traffic.

Exam trap

The trap here is that candidates often confuse network-level controls (NSGs, service endpoints) with the PaaS firewall, mistakenly thinking they can apply NSG rules to a PaaS database or that service endpoints alone can restrict access to specific IPs without additional firewall configuration.

How to eliminate wrong answers

Option A is wrong because Azure Active Directory authentication controls user identity, not network-level access; it does not restrict traffic by source IP or service. Option B is wrong because Virtual Network service endpoints integrate Azure Database for MySQL with a virtual network, but they do not provide a mechanism to allow all Azure services or specific client IPs; they require the database to be joined to a VNet, which changes the connectivity model. Option C is wrong because Network Security Group (NSG) rules operate at the subnet or NIC level and cannot be applied directly to Azure Database for MySQL, which is a PaaS service with its own firewall; NSGs are irrelevant for controlling traffic to the database endpoint.

Practice this question →

103

MCQmedium

Your organization uses Azure Files shares. You need to ensure that users authenticate using on-premises Active Directory credentials and that access is logged. What should you do?

A.Configure a firewall rule to allow on-premises IPs and enable diagnostic logs

B.Use shared access signatures (SAS) for access and enable diagnostic logs

C.Enable identity-based authentication for Azure Files and configure diagnostic logs

D.Configure Azure RBAC for the share and enable diagnostic logs

AnswerC

Enabling identity-based authentication for Azure Files lets SMB clients authenticate with Kerberos using either Azure AD Domain Services or an on-premises AD DS domain, so user access is tied to actual directory identities. After authentication, Azure Files enforces both RBAC share-level roles and Windows ACLs on directories and files. Configuring diagnostic logs then gives you audit trails of which identity performed which operation. This fully satisfies the requirement.

Why this answer

Azure Files supports identity-based authentication using on-premises Active Directory Domain Services (AD DS) via Kerberos. This allows users to authenticate with their on-premises AD credentials and access the file share seamlessly. Enabling diagnostic logs captures access events, meeting the logging requirement.

Exam trap

The trap here is that candidates often confuse Azure RBAC (which controls management-plane access) with identity-based authentication for data-plane access, or they mistakenly think SAS tokens or firewall rules can satisfy both authentication and logging requirements.

How to eliminate wrong answers

Option A is wrong because firewall rules control network access but do not authenticate users with on-premises AD credentials; they only restrict IP addresses. Option B is wrong because shared access signatures (SAS) provide token-based access without authenticating individual users via on-premises AD, and they do not log per-user access. Option D is wrong because Azure RBAC controls management-plane permissions (e.g., share-level roles) but does not authenticate users at the data-plane level with on-premises AD credentials; it also does not inherently log file-level access.

Practice this question →

104

MCQmedium

A Kubernetes workload in AKS needs to pull images from Azure Container Registry without using admin credentials. Which configuration should be used?

A.Grant the AKS kubelet identity AcrPull on the registry

B.Enable anonymous pull access on the registry

C.Store the ACR admin password in a ConfigMap

D.Expose the registry through a public load balancer

AnswerA

The AKS cluster's kubelet runs on each node and is responsible for pulling container images. Each cluster has a kubelet identity (a managed identity in Microsoft Entra ID) that can be granted the AcrPull role on the container registry, giving that identity permission to authenticate and pull images without any stored secrets. This is the recommended approach because it uses Azure's managed identity-based authentication, follows least privilege, and avoids managing or exposing long-lived credentials.

Why this answer

The AKS cluster uses a kubelet identity (managed identity) to authenticate with ACR. By granting the AcrPull role to this identity, the kubelet can pull container images without requiring admin credentials, as Azure RBAC handles the authentication via Azure AD tokens. This is the recommended secure method for image pull operations.

Exam trap

The trap here is that candidates may confuse anonymous pull access (Option B) as a valid alternative, but Azure explicitly recommends using managed identities with AcrPull for secure, credential-free image pulls in AKS.

How to eliminate wrong answers

Option B is wrong because enabling anonymous pull access on ACR allows unauthenticated pulls, which bypasses all security controls and is not recommended for production workloads. Option C is wrong because storing the ACR admin password in a ConfigMap exposes credentials in plaintext within the cluster, violating security best practices and the principle of least privilege. Option D is wrong because exposing the registry through a public load balancer does not solve authentication; it only changes network access and still requires credentials for image pulls.

Practice this question →

105

Multi-Selecthard

A Key Vault should be accessible only from selected private networks and approved Azure services. Which two settings are most relevant?

Select 2 answers

A.Configure Key Vault networking with private endpoint or selected networks

B.Disable soft delete permanently

C.Use firewall and virtual network restrictions

D.Store secrets as plain text tags

AnswersA, C

Private endpoint gives the vault a private IP inside your VNet, while selected networks plus service endpoints restrict public access to approved subnets; the service firewall's 'Allow trusted Microsoft services' toggle then admits approved Azure services, satisfying both constraints.

Why this answer

Option A is correct because configuring Key Vault networking with a private endpoint or selected networks restricts access to the vault from approved private IP ranges within your virtual networks, blocking public internet access. Option C is correct because Key Vault's firewall and virtual network restrictions let you allow traffic only from specified VNets/subnets and trusted Azure services, directly enforcing the 'selected private networks and approved Azure services' requirement. Option B is incorrect because soft delete is a data-protection feature that retains deleted vaults/objects for recovery; disabling it does not control network accessibility and would weaken security.

Option D is incorrect because storing secrets as plain text tags is insecure and unrelated to network access restrictions; tags are metadata and should never hold secret values.

Exam trap

The trap here is that candidates often confuse data protection features like soft delete (Option B) with network access controls, or mistakenly think that storing secrets in tags (Option D) is a valid configuration, when in fact tags are unencrypted metadata and never intended for secret storage.

Practice this question →

106

MCQhard

A company uses Azure SQL Database with Transparent Data Encryption (TDE) and wants to use a customer-managed key (CMK) stored in Azure Key Vault. The security policy requires that the Key Vault be protected by a firewall and virtual network service endpoints to restrict network access. The storage account for TDE logs is in the same Azure region. Which additional configuration is necessary in the Key Vault to allow Azure SQL Database to access the CMK for encryption operations?

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

B.Enable the 'Allow trusted Microsoft services to bypass this firewall' option in the Key Vault networking settings.

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

D.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.

AnswerB

Enabling 'Allow trusted Microsoft services to bypass this firewall' is the correct solution because Azure SQL Database is a trusted Microsoft service and its managed identity can authenticate to the Key Vault using Azure AD, then fetch the encryption key for TDE. With this setting, the Key Vault firewall remains enabled for public internet traffic, but Azure services like SQL Database are permitted to bypass the IP restrictions. This is the intended pattern for TDE with customer-managed keys, as SQL Database runs outside your virtual network and its outbound IPs cannot be reliably scoped.

Why this answer

Azure SQL Database uses TDE with CMK stored in Azure Key Vault, and when the Key Vault firewall is enabled with virtual network service endpoints, Azure SQL Database must be able to bypass the firewall to retrieve the key. The 'Allow trusted Microsoft services to bypass this firewall' setting permits Azure services like Azure SQL Database, which are considered trusted by Microsoft, to access the Key Vault even when network restrictions are in place. This is the only configuration that satisfies the security policy while enabling the necessary encryption operations.

Exam trap

The trap here is that candidates often confuse network-level access controls (firewall rules) with authorization (RBAC or access policies), leading them to select Option D, which addresses permissions but not the network restriction imposed by the Key Vault firewall.

How to eliminate wrong answers

Option A is wrong because Azure SQL Database does not have a static public IP range; its outbound IPs can change and are not predictable, so adding a public IP range would be unreliable and insecure. Option C is wrong because a private endpoint would require the Azure SQL Database to be in the same virtual network or have connectivity to it, but Azure SQL Database is a PaaS service that does not reside in a customer's virtual network by default, and creating a private endpoint for Key Vault does not grant the SQL Database access unless the SQL Database itself is network-integrated (e.g., via Azure SQL Managed Instance or a private endpoint for SQL). Option D is wrong because role-based access control (RBAC) is used for authorization, not network access; the 'Key Vault Crypto Service Encryption User' role grants permissions to use the key, but it does not bypass the Key Vault firewall, which is a network-level restriction.

Practice this question →

107

MCQhard

You have an Azure SQL Database that stores Personally Identifiable Information (PII). You need to mask the PII columns for support staff but allow full access to managers. What should you implement?

A.Dynamic Data Masking with a masking policy and grant UNMASK permission to managers

B.Always Encrypted with separate column encryption keys for managers

C.Azure Information Protection labels and encryption

D.Row-level security to restrict rows for support staff

AnswerA

Dynamic Data Masking (DDM) operates at query time, applying a masking function to the target column's values in the result set based on the executing user's permissions. By creating a masking policy on the PII column and granting the UNMASK permission only to managers, support staff automatically see obfuscated values (e.g., partial email or random digits) while managers see the plaintext. This directly satisfies the requirement to hide PII from certain roles without changing application queries or requiring client-side key management, making it a built-in, low-friction Azure SQL Database capability.

Why this answer

Dynamic Data Masking (DDM) obfuscates sensitive data in query results based on a masking policy, without altering the underlying data. Granting the UNMASK permission to managers allows them to see the original values, while support staff see masked data. This directly meets the requirement to mask PII columns for support staff but allow full access to managers.

Exam trap

The trap here is that candidates often confuse Dynamic Data Masking with Row-Level Security, thinking both restrict data access, but DDM masks columns while RLS filters rows, and only DDM with UNMASK permission provides the column-level obfuscation and selective full access described.

How to eliminate wrong answers

Option B is wrong because Always Encrypts encrypts data at rest and in transit, and while it can restrict access via column encryption keys, it does not provide granular per-user masking within the same query; managers would need separate keys, which is impractical for dynamic masking scenarios. Option C is wrong because Azure Information Protection (AIP) is a classification and labeling service for files and emails, not for masking columns in Azure SQL Database query results. Option D is wrong because Row-Level Security (RLS) restricts which rows a user can read, not which columns; it cannot mask specific columns like PII while leaving others visible.

Practice this question →

108

MCQhard

You are designing a security solution for Azure Cosmos DB that stores Personally Identifiable Information (PII). You need to encrypt data at rest and in transit. You also need to implement row-level security to restrict access based on user role. What should you configure?

A.Enable Azure Disk Encryption on the Cosmos DB account.

B.Enable Always Encrypted and configure column encryption.

C.Use Dynamic Data Masking to restrict sensitive data.

D.Encryption at rest is automatically enabled; enforce TLS for transit; implement row-level security via application code.

AnswerD

Azure Cosmos DB automatically encrypts all data at rest using Azure-managed keys, and this encryption cannot be disabled; transit security is enforced by requiring TLS for all client connections to the account. Row-level security is not natively provided by Cosmos DB, so you must implement it in the application layer — typically by filtering queries based on the authenticated user's token claims or by using partition keys to isolate tenant data. This aligns with the shared responsibility model: Cosmos DB secures the physical and network layers, while the application enforces fine-grained authorization over individual document access.

Why this answer

Azure Cosmos DB automatically encrypts data at rest using AES-256 encryption, and data in transit is secured by enforcing TLS (Transport Layer Security). Row-level security is not natively supported in Cosmos DB; instead, it must be implemented at the application layer by filtering queries based on user roles, typically using a partition key or a custom property in the document.

Exam trap

The trap here is that candidates often confuse Cosmos DB with SQL-based services and incorrectly assume features like Always Encrypted or Dynamic Data Masking apply, when in reality Cosmos DB relies on automatic encryption and application-layer row-level security.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption is for encrypting virtual machine disks, not Azure Cosmos DB, which is a PaaS service with its own built-in encryption. Option B is wrong because Always Encrypted is a SQL Server and Azure SQL Database feature for column-level encryption, not applicable to Cosmos DB's NoSQL document model. Option C is wrong because Dynamic Data Masking is a feature for Azure SQL Database and SQL Server to obfuscate data at query time, not for Cosmos DB, and it does not provide row-level security.

Practice this question →

109

MCQmedium

Your company has an Azure Cosmos DB account that stores customer profiles. You need to ensure that only authenticated and authorized users can access the data. Which access control method should you use?

A.Configure an IP firewall rule to allow only corporate IP ranges.

B.Use Azure RBAC with Microsoft Entra ID authentication.

C.Use primary read-write keys with connection strings.

D.Use resource tokens generated from a master key.

AnswerB

Azure RBAC with Microsoft Entra ID (formerly Azure AD) is the correct approach because Cosmos DB supports data-plane role assignments using Microsoft Entra identities. By assigning built-in roles like Cosmos DB Built-in Data Reader or Contributor to a user or group, you can grant fine-grained, identity-based access to specific databases/containers. This provides per-user authentication, follows the principle of least privilege, and integrates with conditional access and auditing, unlike shared secret keys.

Why this answer

Azure RBAC with Microsoft Entra ID authentication provides fine-grained, identity-based access control for Azure Cosmos DB. This method allows you to assign specific roles (e.g., Cosmos DB Built-in Data Reader) to users or service principals, ensuring that only authenticated and authorized identities can access the data plane operations, such as reading or writing documents. It eliminates the need to share or manage keys, aligning with the principle of least privilege.

Exam trap

The trap here is that candidates often confuse network-level controls (IP firewall) or key-based access (primary keys or resource tokens) with proper identity-based authentication, overlooking that only Azure RBAC with Microsoft Entra ID provides per-user authorization without exposing secrets.

How to eliminate wrong answers

Option A is wrong because an IP firewall rule only restricts network-level access based on source IP addresses; it does not authenticate or authorize individual users, so any user within the allowed IP range could still access the data without proper identity verification. Option C is wrong because primary read-write keys provide full administrative access to the Cosmos DB account; using them in connection strings exposes the key, which can be compromised, and does not enforce per-user authentication or authorization. Option D is wrong because resource tokens are generated from a master key and are typically used for scoped access to specific containers or items, but they still rely on the master key for generation and do not integrate with Microsoft Entra ID for user-level authentication and authorization.

Practice this question →

110

MCQhard

Your security team wants to automatically detect and remediate misconfigurations in Azure Storage accounts, such as enabling public access. The solution should use Azure Policy and be centrally managed for multiple subscriptions. What should you configure?

A.Azure Blueprints

B.Azure Resource Graph

C.Microsoft Defender for Cloud (formerly Azure Security Center)

D.Azure Policy with a custom initiative for storage security

AnswerD

Azure Policy with a custom initiative is the correct service because it allows you to author an initiative—a grouped set of policy definitions—that targets storage security controls such as secure transfer, encryption, public network access, and shared key auth. With the DeployIfNotExists or Modify effect, Azure Policy triggers remediation tasks to bring non-compliant storage accounts back into compliance, either automatically for new resources or via scheduled/on-demand remediation for existing ones. Scoping the initiative to the subscription or resource group and assigning it ensures continuous compliance evaluation and automatic corrective action, fulfilling the team's requirement.

Why this answer

Azure Policy with a custom initiative allows you to define a set of policies (e.g., 'Audit storage accounts with unrestricted public access') that can be assigned at a management group scope, covering multiple subscriptions. This enables automatic detection and remediation of misconfigurations like enabling public access, using built-in effects such as 'Deny' or 'DeployIfNotExists' to enforce compliance centrally.

Exam trap

The trap here is that candidates often confuse Azure Blueprints (a deployment orchestration tool) with Azure Policy (a continuous compliance enforcement service), or assume Microsoft Defender for Cloud alone can perform automatic remediation without an underlying policy assignment.

How to eliminate wrong answers

Option A is wrong because Azure Blueprints is used for orchestrating the deployment of resource templates, policies, and role assignments as a repeatable package, but it does not provide ongoing automatic detection and remediation of misconfigurations; it is a deployment artifact, not a continuous compliance engine. Option B is wrong because Azure Resource Graph is a query service for exploring and auditing resources across subscriptions, but it cannot enforce or remediate configurations; it only provides read-only data for analysis. Option C is wrong because Microsoft Defender for Cloud (formerly Azure Security Center) provides security recommendations and alerts for storage accounts, but it relies on Azure Policy to enforce remediation; Defender for Cloud itself does not natively perform automatic remediation via policy effects like 'DeployIfNotExists' without an underlying policy assignment.

Practice this question →

111

MCQmedium

Refer to the exhibit. You are deploying an Azure Storage account with the ARM template snippet shown. The deployment fails with an error about the encryption configuration. What is the most likely cause?

A.The key vault URI is incorrect

B.The storage account does not have the required permissions on the key vault

C.The key name or version is missing

D.The key vault is in a different region than the storage account

AnswerB

The most likely root cause is that the storage account's system-assigned managed identity has not been granted the required permissions on the key vault. When you use customer-managed keys (CMK) with Azure Storage, the storage service must wrap and unwrap the data encryption key using the key vault key. To do this, the managed identity needs at least Get, WrapKey, and UnwrapKey permissions on the key vault's access policy (or the equivalent RBAC role such as "Key Vault Crypto Service Encryption User"). Without these permissions, the storage account cannot perform the envelope encryption operation and the deployment fails.

Why this answer

The storage account must be granted explicit permissions on the Azure Key Vault to access the encryption key. Even if the key vault URI, key name, and version are correct, the deployment will fail if the storage account's managed identity (or the user-assigned identity) does not have 'Get', 'Wrap Key', and 'Unwrap Key' permissions on the key vault. This is a common oversight when configuring customer-managed keys for Azure Storage encryption.

Exam trap

The trap here is that candidates often assume the key vault URI or key identifier is the only configuration needed, overlooking the critical requirement that the storage account's identity must have explicit permissions on the key vault.

How to eliminate wrong answers

Option A is wrong because an incorrect key vault URI would cause a different error (e.g., 'KeyVaultNotFound' or 'InvalidKeyVaultUri'), not a generic encryption configuration error. Option C is wrong because missing key name or version would produce a specific error about the key identifier being incomplete, not a generic encryption configuration failure. Option D is wrong because Azure Key Vault and storage accounts can be in different regions when using customer-managed keys; cross-region access is supported as long as the key vault is in the same Azure Active Directory tenant.

Practice this question →

112

MCQmedium

You are the security administrator for a company that uses Azure Blob Storage to store sensitive documents. You need to ensure that all blob data is encrypted at rest using customer-managed keys (CMK) stored in Azure Key Vault. You have enabled encryption with CMK on the storage account. However, after a key rotation in Key Vault, you notice that newly uploaded blobs are encrypted with the new key, but existing blobs are still encrypted with the old key. You need to ensure that all blobs are re-encrypted with the new key. What should you do?

A.Update the storage account's encryption scope to use the new key version and then call the 'Rewrite' operation on each blob.

B.Set the storage account encryption to use a different key, then revert to the original key to force re-encryption.

C.No action is needed; Azure Storage automatically re-encrypts existing blobs with the new key after rotation.

D.Re-upload the existing blobs using the new key version by calling the Put Blob operation with the new encryption key.

AnswerD

To encrypt existing blobs with the new key version, you need to rewrite them. The recommended approach is to call the Put Blob operation (e.g., using the same blob name) with the new encryption key version, which overwrites the existing blob and encrypts it under the current key. This ensures the blob's encryption metadata is updated to reflect the new key version. You could also use Copy Blob or an Azure Storage SDK to read and re-upload the data, but Put Blob is the direct mechanism.

Why this answer

To ensure all blobs are re-encrypted with the new key, you must trigger a rewrite of the blob data. Re-uploading the existing blobs using the Put Blob operation with the new encryption key forces the storage account to re-encrypt the data using the latest key version from Key Vault. Option A is incorrect because the 'Rewrite' operation does not exist in Azure Blob Storage; you must overwrite the blob to trigger re-encryption.

Option B is incorrect because changing the encryption key setting does not retroactively re-encrypt existing blobs; it only applies to new blobs. Option C is incorrect because Azure Storage does not automatically re-encrypt existing blobs when the key is rotated; only new blobs use the new key version.

Practice this question →

113

MCQmedium

A company generates shared access signature (SAS) tokens to grant time-limited access to blobs in an Azure Storage container. A security administrator needs the ability to immediately revoke all active SAS tokens for that container if a token is compromised. What should they use?

A.Use a stored access policy on the container and reference it in the SAS token.

B.Use a user delegation key to create the SAS token.

C.Use an account-level SAS token.

D.Use a service-level SAS token with IP address restrictions.

AnswerA

By attaching the SAS to a stored access policy defined on the container, you gain a centralized revocation point: deleting or shortening the policy's expiry immediately invalidates every SAS token that references it, regardless of the token's own expiry time. Because the policy controls permissions, start time, and expiry, you can also modify access after issuance without redeploying new tokens. This is why a stored access policy is required for full revocation control in Azure Storage.

Why this answer

A stored access policy on the container provides a centralized way to manage permissions for shared access signatures (SAS). By associating the SAS token with the policy, you can immediately revoke all tokens that reference that policy by simply deleting or modifying the policy's permissions or expiry time. This is the only method that allows instant revocation of multiple SAS tokens without waiting for their individual expiry.

Exam trap

The trap here is that candidates often assume that regenerating storage account keys (which invalidates account-level SAS tokens) is the fastest way to revoke access, but that approach is overly broad and disruptive, whereas a stored access policy provides granular, immediate revocation for a specific container without affecting other resources.

How to eliminate wrong answers

Option B is wrong because a user delegation key is used to sign a user delegation SAS, but revoking the key requires regenerating the storage account's delegated key, which invalidates all SAS tokens signed with that key, not just those for a specific container. Option C is wrong because an account-level SAS token grants access to multiple services (blobs, queues, tables, files) and cannot be scoped to a single container; revoking it would require regenerating the storage account keys, affecting all SAS tokens and applications. Option D is wrong because a service-level SAS token with IP address restrictions only limits the source IP addresses from which the token can be used, but it does not provide a mechanism to revoke the token before its expiry; the token remains valid until its expiration time.

Practice this question →

114

MCQmedium

You are reviewing an Azure Policy definition. You need to determine the effect of this policy when a user attempts to create a new storage account with 'Secure transfer required' set to 'Disabled'. What happens?

A.The storage account is created but 'Secure transfer required' is automatically enabled.

B.The creation request is denied.

C.The creation is allowed but an audit event is generated.

D.The creation is allowed and no action is taken.

AnswerB

This is correct: when the Azure Policy definition contains the effect 'deny', the policy engine evaluates the incoming resource creation request and, if the defined condition (for example, a storage account lacking 'Secure transfer required') is true, the request is rejected before any resource is provisioned. The operation fails with an error such as 403 Forbidden or a policy enforcement error, and no storage account is created. Policy enforcement is deterministic and prevents the non-compliant resource from entering the environment.

Why this answer

The correct answer is B: the creation request is denied. This policy uses a Deny effect, which blocks any request that violates the policy rule—here, creating a storage account with 'Secure transfer required' set to Disabled—so the deployment fails before the resource is provisioned. Option A is wrong because Deny does not remediate or modify the request; auto-enabling would require a Modify or DeployIfNotExists effect.

Option C is wrong because generating an audit event corresponds to the Audit effect, which only logs non-compliance without blocking. Option D is wrong because Deny actively prevents the non-compliant creation rather than allowing it silently.

Practice this question →

115

MCQmedium

A company enables Azure SQL Database auditing to log database events to a storage account. The security policy requires that the audit logs be protected from tampering and deletion after they are written. Which storage account feature should the company enable to ensure that audit log files cannot be modified or deleted by anyone for a specified retention period?

A.Soft delete

B.Immutable storage

C.Hierarchical namespace

D.Firewall and virtual networks

AnswerB

Immutable storage is correct because it enforces a Write-Once-Read-Many (WORM) policy at the container or version level, blocking any delete or modify operation on blobs for a set retention period. This time-based retention lock makes the stored audit logs tamper-proof and compliant with regulatory frameworks such as SEC 17a-4f. After the policy is locked, even an account administrator cannot shorten the retention interval or disable immutability, ensuring that Azure SQL Database audit records remain intact until the policy expires.

Why this answer

Immutable storage for Azure Blob Storage provides a WORM (Write Once, Read Many) policy that prevents audit log files from being modified or deleted by any user, including administrators, for a specified retention period. This directly meets the security requirement to protect audit logs from tampering and deletion after they are written.

Exam trap

The trap here is that candidates often confuse soft delete with immutable storage, thinking that soft delete's ability to recover deleted blobs is sufficient for tamper-proofing, but soft delete does not prevent modification or deletion in the first place.

How to eliminate wrong answers

Option A is wrong because soft delete only protects against accidental deletion by retaining deleted blobs for a configurable period, but it does not prevent intentional modification or deletion by authorized users during the retention period. Option C is wrong because hierarchical namespace is a feature of Azure Data Lake Storage Gen2 that organizes blobs into a directory hierarchy, but it provides no data immutability or tamper-proof protection. Option D is wrong because firewall and virtual networks restrict network access to the storage account but do not prevent modification or deletion of blobs by users who have legitimate access through the network.

Practice this question →

116

MCQhard

You are designing a solution to store sensitive documents in Azure Blob Storage. The documents must be encrypted at rest using a customer-managed key that is automatically rotated every 90 days. Microsoft Entra ID must be used to control access to the key. What should you use?

A.Azure Storage Service Encryption (SSE) with platform-managed keys.

B.Azure Storage encryption with infrastructure encryption enabled.

C.Azure Storage Service Encryption (SSE) with a customer-managed key stored in Azure Key Vault and configure key rotation.

D.Client-side encryption (CSE) using Azure Key Vault.

AnswerC

Azure Storage Service Encryption (SSE) with a customer-managed key stored in Azure Key Vault allows you to bring your own key (BYOK) and retain full control over key lifecycle, including enabling automatic rotation on schedule. By configuring key rotation, you can replace keys periodically to meet security and compliance policies, and you can audit key usage through Key Vault and Azure Monitor. This provides the necessary customer control and rotation that are missing from Microsoft-managed key options.

Why this answer

Azure Storage Service Encryption (SSE) with a customer-managed key (CMK) stored in Azure Key Vault allows you to control the encryption key used for data at rest in Blob Storage. By storing the key in Key Vault, you can configure automatic key rotation every 90 days, and you can use Microsoft Entra ID (formerly Azure AD) to control access to the key via RBAC roles such as Key Vault Crypto Officer. This meets all requirements: encryption at rest, customer-managed key, automatic rotation, and Entra ID-based access control.

Exam trap

The trap here is that candidates often confuse client-side encryption (CSE) with server-side encryption (SSE), mistakenly thinking CSE is required for customer-managed keys, when in fact SSE with CMK in Key Vault provides the same key control with automatic rotation and simpler management.

How to eliminate wrong answers

Option A is wrong because SSE with platform-managed keys uses Microsoft-managed keys, which cannot be rotated on a customer-defined schedule (e.g., every 90 days) and do not allow customer control over the key. Option B is wrong because infrastructure encryption is an additional layer of encryption that uses platform-managed keys at the storage infrastructure level; it does not involve customer-managed keys or automatic rotation. Option D is wrong because client-side encryption (CSE) encrypts data before it is sent to Azure Storage, which requires managing encryption keys on the client side and does not natively support automatic key rotation or direct Entra ID-based access control for the key in the same way as SSE with CMK.

Practice this question →

117

MCQhard

You are designing a secure compute solution for a critical application that must comply with PCI DSS. The application runs on Azure Virtual Machines with sensitive data. You need to ensure that ephemeral disks are encrypted at the host level. Which Azure Disk Encryption option should you use?

A.Server-side encryption (SSE) with platform-managed keys

B.Azure Disk Encryption (ADE) with Key Vault

C.Double encryption (SSE with CMK and ADE)

D.Encryption at host

AnswerD

Encryption at host encrypts the VM's temp disk and the caches of the OS and data disks at the physical compute host, using platform-managed or customer-managed keys. This is the only option that directly covers the ephemeral disk, which is where unencrypted cardholder data could otherwise be written. When enabled, it satisfies the PCI DSS at-rest encryption requirement for all disk types in the VM, including managed disks, temp disk, and caches.

Why this answer

Encryption at host encrypts data at the VM host level, including ephemeral disks, before it is transmitted to Azure Storage. This meets the PCI DSS requirement for encrypting ephemeral disks at rest without relying on the guest OS or key management. It uses server-side encryption with platform-managed or customer-managed keys directly on the host node.

Exam trap

The trap here is that candidates confuse guest OS encryption (ADE) with host-level encryption, assuming ADE covers ephemeral disks when it only encrypts OS and data disks within the VM.

How to eliminate wrong answers

Option A is wrong because Server-side encryption (SSE) with platform-managed keys encrypts only managed disks and snapshots at the Azure Storage service level, not ephemeral disks on the host. Option B is wrong because Azure Disk Encryption (ADE) with Key Vault uses BitLocker (Windows) or DM-Crypt (Linux) within the guest OS, which does not encrypt ephemeral disks at the host level. Option C is wrong because Double encryption (SSE with CMK and ADE) combines two layers of encryption for managed disks but still does not address host-level encryption of ephemeral disks.

Practice this question →

118

MCQeasy

You need to enable transparent data encryption (TDE) for an Azure SQL Managed Instance. What is the prerequisite?

A.Configure a backup policy for the managed instance.

B.Enable a service endpoint for Azure SQL.

C.No additional configuration is needed; TDE is enabled by default.

D.Create an Azure Key Vault and configure a customer-managed key.

AnswerC

Azure SQL Managed Instance is created with Transparent Data Encryption already enabled by default, using a service-managed key that Microsoft rotates automatically. No configuration, such as creating a key or modifying settings, is required on the managed instance to activate TDE. The encryption of data and log files happens automatically in real time, making this the correct choice because the question's requirement is already satisfied.

Why this answer

Transparent Data Encryption (TDE) is enabled by default for Azure SQL Managed Instance. When you create a new managed instance, TDE is automatically turned on using a service-managed key, so no additional configuration is required. This default behavior ensures data at rest is encrypted without any prerequisite steps from the user.

Exam trap

The trap here is that candidates often assume TDE requires manual setup or a key vault, but Azure SQL Managed Instance enables TDE by default with a service-managed key, making options like D a common distractor for those familiar with on-premises or IaaS-based SQL Server configurations.

How to eliminate wrong answers

Option A is wrong because configuring a backup policy is unrelated to enabling TDE; backup policies manage retention and recovery, not encryption at rest. Option B is wrong because service endpoints are used for network connectivity and access control, not for enabling TDE on a managed instance. Option D is wrong because while you can optionally use customer-managed keys from Azure Key Vault for TDE (bring your own key), it is not a prerequisite; TDE works with a service-managed key by default without any key vault configuration.

Practice this question →

119

MCQeasy

You are designing a solution for Azure Blob Storage that must prevent data from being overwritten or deleted for a specified retention period. Which feature should you enable?

A.Blob versioning

B.Immutable storage with time-based retention policy

C.Lifecycle management policies

D.Soft delete for blobs

AnswerB

Immutable storage with a time-based retention policy applies a WORM (write once, read many) state to blobs within a container, preventing deletion and overwrite for the configured retention interval. The policy is set at the container level and, when locked, cannot be removed or shortened by any user, including administrators, making it the correct choice for regulatory or compliance-based retention. During the retention period, attempts to delete the blob, its versions, or even the underlying container will fail, ensuring the data remains intact.

Why this answer

Immutable storage with a time-based retention policy (WORM – Write Once, Read Many) is the correct feature because it explicitly prevents any user, including the storage account owner, from overwriting or deleting blobs until the retention period expires. This is enforced at the container level and overrides all other permissions, making it the only option that guarantees data cannot be altered or removed for a specified duration.

Exam trap

The trap here is that candidates confuse blob versioning or soft delete with true immutability, not realizing that those features allow the current blob to be overwritten or deleted and only provide recovery or history, not a hard write-once lock.

How to eliminate wrong answers

Option A is wrong because blob versioning preserves previous versions of a blob when overwrites or deletes occur, but it does not prevent the current version from being overwritten or deleted; it simply retains a history. Option C is wrong because lifecycle management policies automate tiering or deletion of blobs based on age or conditions, but they do not enforce a retention lock that blocks deletion or overwrite operations. Option D is wrong because soft delete for blobs retains deleted blobs for a recovery period, but it does not prevent overwrites or deletions from happening in the first place; it only allows recovery after the fact.

Practice this question →

120

MCQmedium

A company uses Azure SQL Database for a critical application. Security policy requires that all client connections use at least TLS 1.2 encryption and that connections not meeting this requirement are rejected. Which configuration should they implement on the Azure SQL Server?

A.Configure firewall rules to allow only trusted IP addresses

B.Enable Transparent Data Encryption (TDE)

C.Set the 'Minimum TLS version' on the SQL server

D.Enable Advanced Threat Protection (ATP)

AnswerC

Setting the 'Minimum TLS version' on the Azure SQL Server enforces that every inbound client connection must negotiate at least TLS 1.2 at handshake time; if a client attempts to connect using TLS 1.0 or 1.1, the server rejects the connection entirely. This server-side enforcement is applied by the Azure SQL Gateway before any authentication or data exchange occurs, making it the correct control to ensure all traffic between the application and database is encrypted with a modern protocol version. The setting can be configured as 1.2 (or higher if supported) and is a hard policy, unlike client-side connection string options which a user could omit.

Why this answer

Azure SQL Server allows you to enforce a minimum TLS version for all client connections. By setting the 'Minimum TLS version' to 1.2, the server will reject any connection attempt using TLS 1.0 or 1.1, ensuring compliance with the security policy that requires at least TLS 1.2 encryption.

Exam trap

The trap here is that candidates often confuse encryption in transit (TLS) with encryption at rest (TDE) or network access controls (firewall rules), leading them to select options that address different security layers rather than the specific requirement to enforce a minimum TLS version.

How to eliminate wrong answers

Option A is wrong because firewall rules control network access based on IP addresses, not encryption protocol version; they cannot enforce TLS 1.2. Option B is wrong because Transparent Data Encryption (TDE) encrypts data at rest, not data in transit; it does not affect the TLS version used for client connections. Option D is wrong because Advanced Threat Protection (ATP) provides security monitoring and alerts for suspicious activities, but it does not enforce encryption protocols or reject connections based on TLS version.

Practice this question →

121

MCQhard

A company stores business records in Azure Blob Storage. Due to a legal investigation, they must prevent any modification or deletion of the blobs for an indefinite period until the legal hold is released. They also need to ensure that even storage account owners cannot alter the data during the hold. Which blob storage feature should they enable?

A.Time-based retention policy

B.Legal hold

C.Soft delete

D.Blob versioning

AnswerB

Legal hold is the correct choice because it applies an indefinite, immutable lock on blob storage, preventing any modification or deletion until the hold is explicitly released by an authorized user. This hold is designed for legal and compliance scenarios where records must be preserved for an unknown or open-ended duration, such as active litigation or an ongoing investigation. Unlike time-based retention, legal hold does not expire automatically and continues protecting data until the hold is removed, ensuring that records remain untouched for as long as legally required.

Why this answer

Legal hold (option B) is the correct choice because it is designed to protect blobs from any modification or deletion for an indefinite period, even by storage account owners. Unlike time-based retention policies, a legal hold has no expiration and cannot be removed until explicitly cleared by an authorized user, making it ideal for indefinite legal investigations.

Exam trap

The trap here is that candidates often confuse time-based retention policies (which have a fixed duration) with legal holds (which are indefinite), or assume that soft delete or versioning can prevent modification or deletion by privileged users, when in fact they only provide recovery options and do not block destructive operations.

How to eliminate wrong answers

Option A is wrong because a time-based retention policy enforces a fixed retention period (e.g., 1–146,000 days) and automatically expires, which does not meet the indefinite hold requirement. Option C is wrong because soft delete only protects against accidental deletion by retaining deleted blobs for a configurable retention period (default 7 days), but it does not prevent modification or allow indefinite holds, and storage account owners can still permanently delete blobs if soft delete is disabled. Option D is wrong because blob versioning preserves previous versions of blobs but does not prevent modification or deletion of the current version; storage account owners can still overwrite or delete blobs, and versioning alone cannot enforce an indefinite legal hold.

Practice this question →

122

MCQmedium

A company stores highly sensitive data in Azure Blob Storage. The security policy requires that all data is encrypted at rest using a key that is stored in Azure Key Vault, and that the storage account uses its system-assigned managed identity to access the key. Which encryption configuration should they use?

A.Server-side encryption with service-managed keys

B.Server-side encryption with customer-managed keys (CMK)

C.Client-side encryption

D.Azure Disk Encryption

AnswerB

Server-side encryption with customer-managed keys (CMK) encrypts data at rest using a data encryption key wrapped by a customer-controlled key encryption key stored in Azure Key Vault. The storage account's system-assigned managed identity authenticates to Key Vault to perform encryption and decryption of the underlying data key, giving the organization direct control over key rotation, auditing, and revocation. This satisfies the requirement of using a customer-managed key stored in Key Vault and is the appropriate mechanism for enforcing separation of duties and meeting compliance obligations.

Why this answer

Server-side encryption with customer-managed keys (CMK) is required because the security policy mandates that the encryption key be stored in Azure Key Vault and that the storage account uses its system-assigned managed identity to access that key. CMK allows you to bring your own key (BYOK) into Key Vault and grants the storage account access via a managed identity, ensuring the key is under your control and not managed by Azure. Service-managed keys (option A) use Microsoft-managed keys, which do not satisfy the requirement for customer-controlled key storage.

Exam trap

The trap here is that candidates confuse 'encryption at rest' with 'client-side encryption' or 'Azure Disk Encryption', failing to recognize that the requirement for a managed identity to access a Key Vault key directly points to server-side CMK, not client-side or disk-level encryption.

How to eliminate wrong answers

Option A is wrong because server-side encryption with service-managed keys uses keys managed entirely by Microsoft, not stored in the customer's Azure Key Vault, and does not involve a managed identity for access. Option C is wrong because client-side encryption encrypts data before it is sent to Azure Blob Storage, meaning the storage account never accesses the key via its managed identity; the key is managed on the client side. Option D is wrong because Azure Disk Encryption is used to encrypt virtual machine disks (OS and data disks) using BitLocker or DM-Crypt, not Azure Blob Storage data.

Practice this question →

123

MCQmedium

Your company uses Azure Files shares to store business documents. You need to ensure that access to the shares is restricted to users who have been granted explicit permissions. What should you configure?

A.Configure a firewall rule to allow only corporate IP ranges.

B.Use storage account access keys to mount the file share.

C.Enable identity-based authentication for Azure Files using Microsoft Entra ID and set share-level permissions.

D.Generate a shared access signature (SAS) with read permissions.

AnswerC

Identity-based authentication via Microsoft Entra ID maps a user's token to a share-level role assignment (Storage File Data SMB Share Reader, Contributor, or Elevated Contributor), so only principals explicitly granted those roles gain access. This satisfies the stem's requirement that access be restricted to users holding granted permissions, unlike storage account key access, which grants unrestricted share access.

Why this answer

Identity-based authentication for Azure Files using Microsoft Entra ID allows you to assign share-level permissions (e.g., Storage File Data SMB Share Contributor) to specific users or groups, ensuring only explicitly authorized identities can access the share. This meets the requirement of restricting access to users with explicit permissions, as opposed to relying on network rules or shared keys.

Exam trap

The trap here is that candidates often confuse network-level restrictions (firewall rules) or token-based access (SAS) with identity-based access control, mistakenly believing that restricting IP ranges or using SAS tokens satisfies the requirement for explicit user permissions, when in fact only identity-based authentication with Microsoft Entra ID provides per-user authorization.

How to eliminate wrong answers

Option A is wrong because configuring a firewall rule to allow only corporate IP ranges restricts access based on network location, not on user identity or explicit permissions; any user from a corporate IP could still access the share if they have the storage account key or SAS. Option B is wrong because using storage account access keys grants full administrative access to the entire storage account, not just the file share, and cannot be scoped to individual users or groups, violating the principle of least privilege. Option D is wrong because a shared access signature (SAS) with read permissions provides time-limited, token-based access that is not tied to a specific user identity and cannot enforce per-user explicit permissions; it also exposes the share to anyone possessing the SAS token.

Practice this question →

124

MCQeasy

You are configuring an Azure Kubernetes Service (AKS) cluster. You need to ensure that pods can securely access Azure Container Registry (ACR) without storing image pull secrets in the pod specification. What should you do?

A.Create a service principal and store the secret in a Kubernetes secret, then reference it in the pod spec

B.Enable admin account on ACR and use the admin username and password in the pod spec

C.Enable managed identity on AKS and assign the AcrPull role to the kubelet identity

D.Use the storage account key of the attached Azure storage account

AnswerC

When managed identity is enabled on an AKS cluster, the kubelet runs with its own managed identity (the kubelet identity) that can be granted the AcrPull role on the target Azure Container Registry. The kubelet then authenticates to ACR using an Azure AD token obtained from the Azure Instance Metadata Service, eliminating any stored secrets in the cluster. Scoping the AcrPull role to only the registry and the identity to only pulling images follows least privilege, and the token is automatically rotated by Azure.

Why this answer

Enabling managed identity on AKS creates a kubelet identity that can be granted the AcrPull role via Azure RBAC. This allows AKS to authenticate to ACR automatically without storing any secrets in the pod specification, as the kubelet uses the managed identity to pull container images on behalf of the pods.

Exam trap

The trap here is that candidates often confuse using a service principal (Option A) with managed identity, not realizing that a service principal still requires storing a secret, whereas managed identity eliminates the need for any stored credentials in the cluster.

How to eliminate wrong answers

Option A is wrong because it still requires storing a secret (the service principal secret) in a Kubernetes secret and referencing it in the pod spec, which violates the requirement to avoid storing image pull secrets in the pod specification. Option B is wrong because enabling the admin account on ACR and using its username/password in the pod spec stores credentials directly in the pod spec, which is insecure and does not meet the requirement. Option D is wrong because storage account keys are used for accessing Azure Blob Storage, not for authenticating to Azure Container Registry, and they have no relevance to ACR image pull authentication.

Practice this question →

125

MCQmedium

Refer to the exhibit. You are querying the sys.column_master_keys view in an Azure SQL Database. What is the purpose of this query?

A.To check the Dynamic Data Masking policies.

B.To retrieve the column master key configuration for Always Encrypted.

C.To verify the configuration of Transparent Data Encryption (TDE).

D.To list the encryption keys used for column-level encryption.

AnswerB

The sys.column_master_keys catalog view is the correct place to retrieve the column master key (CMK) configuration for Always Encrypted. It contains one row per CMK in the database, including the key name, key store provider name (for example, 'MSSQL_CERTIFICATE_STORE' or 'AZURE_KEY_VAULT'), the key path, and settings such as allow_enclave_computations. This metadata is essential for managing and rotating the keys that protect column encryption keys in the Always Encrypted feature.

Why this answer

The sys.column_master_keys view in Azure SQL Database specifically returns metadata about column master keys (CMKs) used by Always Encrypted. These keys protect the column encryption keys (CEKs) that encrypt sensitive data columns. Therefore, querying this view retrieves the column master key configuration for Always Encrypted, making option B correct.

Exam trap

The trap here is that candidates confuse the sys.column_master_keys view with sys.column_encryption_keys or assume it covers all encryption types (like TDE or Dynamic Data Masking), when it is exclusively for Always Encrypted's master key metadata.

How to eliminate wrong answers

Option A is wrong because Dynamic Data Masking policies are stored in sys.database_scoped_configurations or managed via ALTER TABLE statements, not in sys.column_master_keys. Option C is wrong because Transparent Data Encryption (TDE) configuration is verified using sys.dm_database_encryption_keys or sys.databases, not the column master keys view. Option D is wrong because column-level encryption keys (CEKs) are listed in sys.column_encryption_keys, while sys.column_master_keys only stores the master keys that protect those CEKs.

Practice this question →

126

MCQhard

A company uses Azure SQL Database with Transparent Data Encryption (TDE) encrypted using a customer-managed key (CMK) stored in Azure Key Vault. The Key Vault is protected by a firewall that denies all public access. The SQL server must be able to access the key for TDE operations. Which additional configuration is necessary in the Key Vault to allow this?

A.Configure a private endpoint for the Key Vault and assign it to the SQL server's virtual network.

B.Enable soft-delete on the Key Vault.

C.Enable the 'Allow trusted Microsoft services to bypass this firewall' setting.

D.Add a firewall rule to allow traffic from the Azure SQL Database's public IP address.

AnswerC

This setting allows Azure services like Azure SQL Database, which are trusted by Azure, to access the Key Vault even when the firewall is enabled to deny public traffic. It is the required configuration to allow TDE operations.

Why this answer

When Azure Key Vault is protected by a firewall that denies all public access, the Azure SQL Database service (a trusted Microsoft service) must be explicitly allowed to bypass the firewall to retrieve the customer-managed key for TDE operations. Enabling the 'Allow trusted Microsoft services to bypass this firewall' setting permits the SQL server's managed identity to authenticate and access the key vault without requiring a public IP address or network rule.

Exam trap

The trap here is that candidates often confuse network-level controls (private endpoints, firewall rules) with the Azure platform's built-in trust mechanism, mistakenly thinking that a private endpoint or a static IP rule is required when the simpler 'trusted Microsoft services' bypass is the correct and intended solution for PaaS services like Azure SQL Database.

How to eliminate wrong answers

Option A is wrong because a private endpoint for Key Vault would require the SQL server to be on the same virtual network, but Azure SQL Database is a PaaS service that does not reside in a customer's virtual network by default; the SQL server's managed identity accesses Key Vault over the Azure backbone, not via a private endpoint. Option B is wrong because soft-delete is a data protection feature that prevents permanent deletion of keys, secrets, or certificates, but it does not control network access or firewall bypass for TDE operations. Option D is wrong because Azure SQL Database does not have a static public IP address; its outbound IPs can change and are not assigned to the logical server, making a firewall rule based on a public IP unreliable and unnecessary when the trusted Microsoft services bypass is available.

Practice this question →

127

MCQhard

Refer to the exhibit. You are reviewing an ARM template for an Azure Storage account. Which of the following is true about the deployment?

A.The storage account will use customer-managed keys from Azure Key Vault.

B.The storage account will use locally redundant storage (LRS).

C.The storage account will have a firewall rule to restrict access to specific IPs.

D.The storage account will enforce HTTPS traffic and replicate data to a paired region.

AnswerD

The template sets 'supportsHttpsTrafficOnly' to true, which enforces HTTPS for all client requests and rejects any plaintext HTTP traffic. Additionally, the 'Standard_GRS' SKU enables geo-redundant replication, storing copies in both the primary region and a paired secondary region for disaster recovery. Together, these properties guarantee secure HTTPS-only traffic and automatic data replication to the paired region, which makes this statement correct.

Why this answer

The ARM template configures the storage account with the 'supportsHttpsTrafficOnly' property set to true, which enforces HTTPS for all requests. Additionally, the 'sku.name' is set to 'Standard_GRS', which replicates data to a paired region for geo-redundancy. Therefore, option D correctly identifies both HTTPS enforcement and geo-replication to a paired region.

Exam trap

In Azure exams, candidates often confuse the ARM template properties for encryption (e.g., 'encryption.keySource') with those for network access (e.g., 'networkAcls'). Also, the distinction between storage SKU redundancy levels (LRS, GRS, RA-GRS, ZRS) is frequently tested, and many mistakenly think 'Standard_GRS' means only geo-redundancy without understanding that HTTPS enforcement is a separate property.

How to eliminate wrong answers

Option A is wrong because the template does not include any 'encryption.keySource' or 'keyvaultproperties' settings to indicate customer-managed keys from Azure Key Vault; it defaults to Microsoft-managed keys. Option B is wrong because the SKU is 'Standard_GRS', not 'Standard_LRS', so it uses geo-redundant storage, not locally redundant storage. Option C is wrong because the template lacks any 'networkAcls' or 'ipRules' properties to define a firewall rule restricting access to specific IPs.

Practice this question →

128

MCQmedium

You are reviewing an Azure Resource Manager template for a storage account. The exhibit shows a snippet of the template. Which statement about the template is true?

A.Encryption is disabled for the storage account.

B.The storage account will use customer-managed keys from Azure Key Vault.

C.The storage account will use Microsoft-managed keys for encryption.

D.Encryption is enabled only for blob storage.

AnswerC

The encryption.keySource value of Microsoft.Storage indicates Azure's default encryption mechanism, where Microsoft owns, stores, and rotates the AES-256 keys used to encrypt the storage account. This is the platform-managed key model, applied automatically whenever no Key Vault key is referenced. Combined with enabled: true for blob and file, the account will use Microsoft-managed keys for both services.

Why this answer

The template snippet does not include any encryption-related properties, such as `encryption.keySource` or `encryption.services`, which means the storage account will use the default Microsoft-managed keys for encryption. By default, Azure Storage encrypts all data at rest using Microsoft-managed keys, and no explicit configuration is required. Option C correctly identifies this default behavior.

Exam trap

The trap here is that candidates may assume encryption must be explicitly enabled or that the absence of encryption properties means encryption is disabled, but Azure Storage encryption is always on by default and cannot be turned off.

How to eliminate wrong answers

Option A is wrong because encryption is enabled by default for all Azure Storage accounts; the absence of encryption properties in the template does not disable encryption. Option B is wrong because customer-managed keys require explicit configuration of `encryption.keySource` as `Microsoft.Keyvault` and a reference to a Key Vault key, which is not present in the snippet. Option D is wrong because Azure Storage encryption applies to all storage services (blob, file, queue, table) by default, not just blob storage.

Practice this question →

129

MCQeasy

You need to prevent data exfiltration from Azure Storage accounts by controlling which networks can access them. Which Azure feature should you use?

A.Azure Storage shared access signatures (SAS)

B.Azure Firewall

C.Azure Private Link

D.Azure Storage firewalls and virtual network rules

AnswerD

Azure Storage firewalls and virtual network rules allow you to define a set of virtual networks and IP address ranges that are permitted to access the storage account, and all other requests are denied. This directly controls the network origin of clients, so if an attacker outside your trusted networks tries to connect using the storage account endpoint, the request is blocked before it reaches the data. By restricting access to only trusted networks, this feature effectively prevents data exfiltration from unauthorized network locations.

Why this answer

Azure Storage firewalls and virtual network rules (Option D) are the correct choice because they allow you to restrict access to your storage account based on specific IP addresses, IP ranges, or virtual networks, effectively preventing data exfiltration by blocking unauthorized network traffic. This feature works at the network layer, enabling you to create a perimeter around your storage account that only allows trusted sources to connect, which directly addresses the requirement to control network-level access.

Exam trap

The trap here is that candidates often confuse network-level access control (storage firewalls and VNet rules) with identity-based access control (SAS tokens) or connectivity solutions (Private Link), leading them to select Azure Firewall or Private Link instead of the dedicated storage network security feature.

How to eliminate wrong answers

Option A is wrong because Azure Storage shared access signatures (SAS) provide delegated, time-limited access to storage resources at the application level, not network-level access control; they cannot restrict which networks can reach the storage account. Option B is wrong because Azure Firewall is a managed, cloud-based network security service that protects Azure Virtual Network resources, but it does not natively integrate with Azure Storage to control inbound access to storage accounts; storage firewalls and virtual network rules are the dedicated feature for this purpose. Option C is wrong because Azure Private Link enables private connectivity from a virtual network to Azure PaaS services over a private endpoint, but it does not provide granular network-level access control rules (like IP whitelisting or VNet rules) to prevent data exfiltration; it focuses on network isolation rather than access restriction.

Practice this question →

130

MCQhard

You have an Azure SQL Database that stores credit card numbers. You need to encrypt the column containing the credit card numbers so that only authorized applications can decrypt the data. The database administrator should not be able to view the plaintext data. Which feature should you use?

A.Transparent Data Encryption (TDE)

B.Column-level encryption using SQL Server built-in functions

C.Dynamic Data Masking

D.Always Encrypted with secure enclaves

AnswerD

Always Encrypted with secure enclaves encrypts sensitive columns such that the database engine never sees the plaintext. The column encryption key is protected by a column master key stored outside SQL Server, so a DBA with full server access only sees ciphertext. An enclave allows the engine to perform computations on encrypted values by loading the keys into a protected memory region, but the DBA cannot access that enclave or the keys. This is the only option that truly prevents a DBA from reading the credit card numbers.

Why this answer

Always Encrypted with secure enclaves (Option D) is correct because it ensures that credit card numbers are encrypted at rest and in memory, and only client applications with the column encryption key can decrypt the data. The database administrator (DBA) cannot access the plaintext because the encryption keys are never revealed to SQL Server or Azure SQL Database, and secure enclaves allow rich computations (e.g., equality, pattern matching) on encrypted data without exposing the plaintext to the database engine.

Exam trap

The trap here is that candidates often confuse Dynamic Data Masking (which only hides data from query results but does not encrypt it) with Always Encrypted, or assume TDE provides column-level protection, when in fact TDE does not prevent the DBA from viewing plaintext data.

How to eliminate wrong answers

Option A is wrong because Transparent Data Encryption (TDE) encrypts the entire database at rest but does not protect data from the DBA or from being viewed in plaintext by authorized users—the DBA can still query and see the credit card numbers. Option B is wrong because column-level encryption using SQL Server built-in functions (e.g., ENCRYPTBYPASSPHRASE) requires the encryption key to be stored in the database or managed by the DBA, allowing the DBA to access the plaintext if they have the key. Option C is wrong because Dynamic Data Masking only obfuscates data in query results for unauthorized users, but the underlying data remains unencrypted in storage and can be read by the DBA or anyone with direct database access.

Practice this question →

131

MCQeasy

You need to securely store secrets, such as connection strings and API keys, for use by an Azure Functions app. The solution must automatically rotate the secrets and audit access. What should you use?

A.Azure Key Vault

B.Azure Blob Storage with encryption

C.Managed Identity

D.Application settings in the function app configuration

AnswerA

Azure Key Vault is the correct choice because it is a purpose-built secret management service that stores connection strings and other secrets encrypted at rest, with granular access policies integrated with Azure AD. It provides native secret versioning and rotation, full audit logging via diagnostics, and soft-delete/purge protection to prevent accidental or malicious loss. Applications can securely retrieve secrets at runtime using service principals or Managed Identity, eliminating the need to embed credentials in code or configuration.

Why this answer

Azure Key Vault is the correct choice because it provides a centralized, secure store for secrets like connection strings and API keys, with built-in support for automatic rotation via integration with Azure Key Vault references in Azure Functions and access auditing through diagnostic logs and Azure Monitor. This meets the requirements of secure storage, automated secret rotation, and audit trail generation.

Exam trap

The trap here is that candidates often confuse Managed Identity with a secret storage solution, but Managed Identity is an authentication mechanism, not a store for secrets like connection strings or API keys.

How to eliminate wrong answers

Option B is wrong because Azure Blob Storage with encryption only provides at-rest encryption for stored data, but lacks native secret rotation capabilities and does not offer granular access auditing for secret retrieval. Option C is wrong because Managed Identity provides an identity for the function app to authenticate to Azure services without storing credentials, but it does not store or rotate secrets like connection strings or API keys. Option D is wrong because application settings in the function app configuration store secrets in plain text (though encrypted at rest by Azure App Service), but they cannot be automatically rotated and do not provide detailed access auditing for secret usage.

Practice this question →

132

MCQeasy

A company stores sensitive data in Azure Blob Storage. They want to ensure that the data is encrypted at rest using a customer-managed key (CMK) stored in Azure Key Vault. Additionally, they need the ability to immediately make the data inaccessible in case of a security breach. Which configuration on the storage account enables this?

A.Enable Azure Storage encryption with a customer-managed key (CMK)

B.Enable infrastructure encryption

C.Enable soft delete for the storage account

D.Enable Azure AD authentication for Blob Storage

AnswerA

Customer-managed keys (CMK) give you explicit control over the key hierarchy used to encrypt Azure Storage. Under envelope encryption, the CMK is a key encryption key (KEK) stored in Azure Key Vault that protects the data encryption key (DEK) used for blob encryption. Revoking or disabling the CMK in Key Vault causes Azure Storage to reject any attempt to decrypt the DEK, effectively making the data inaccessible almost immediately. This provides a deliberate, auditable kill switch that meets the requirement to block access on demand.

Why this answer

Enabling Azure Storage encryption with a customer-managed key (CMK) stored in Azure Key Vault allows the customer to control the encryption key used for data at rest. In the event of a security breach, the customer can immediately revoke access to the CMK in Key Vault (e.g., by disabling the key or deleting the key vault), which renders the encrypted Blob Storage data inaccessible because Azure Storage cannot decrypt it without the key. This satisfies both the encryption-at-rest requirement and the ability to make data inaccessible on demand.

Exam trap

The trap here is that candidates often confuse soft delete (which protects against accidental deletion) with the ability to make data inaccessible via key revocation, or they assume infrastructure encryption or Azure AD authentication provide the same control as CMK, but only CMK with key revocation in Key Vault gives the customer direct, immediate control over data accessibility.

How to eliminate wrong answers

Option B is wrong because infrastructure encryption provides an additional layer of encryption at the storage infrastructure level using platform-managed keys, but it does not use customer-managed keys and does not allow the customer to revoke access to make data inaccessible. Option C is wrong because soft delete for the storage account protects against accidental deletion by retaining deleted data for a retention period, but it does not provide encryption with customer-managed keys or the ability to immediately make data inaccessible during a breach. Option D is wrong because Azure AD authentication for Blob Storage controls access to data via identity-based authorization, but it does not encrypt data at rest with customer-managed keys or provide a mechanism to revoke encryption keys to make data inaccessible.

Practice this question →

133

MCQmedium

A company stores confidential data in Azure Blob Storage. They need to ensure that all data at rest is encrypted and they must be able to quickly rotate the encryption key on demand in case of a security breach. They also want to minimize administrative overhead. Which encryption option should they use?

A.Server-side encryption with Microsoft-managed keys

B.Server-side encryption with customer-managed keys (CMK) stored in Azure Key Vault

C.Client-side encryption

D.Azure Disk Encryption

AnswerB

Server-side encryption with customer-managed keys (CMK) stored in Azure Key Vault allows your organization to control the root encryption key used for encrypting Azure Blob Storage. With CMK, you can rotate keys on your own schedule, disable or revoke a key immediately if compromised, and audit key usage through Key Vault diagnostics, which helps meet compliance and governance requirements. Azure Storage implements CMK through envelope encryption, where the key in Key Vault encrypts the data encryption key, providing both strong encryption and operational flexibility without requiring application changes.

Why this answer

Server-side encryption with customer-managed keys (CMK) stored in Azure Key Vault allows the organization to control and rotate the encryption key on demand, meeting the security breach response requirement. This option encrypts data at rest in Azure Blob Storage while minimizing administrative overhead because Azure manages the encryption process, and the customer only manages the key lifecycle in Key Vault.

Exam trap

The trap here is that candidates confuse Azure Disk Encryption (which encrypts VM disks) with Azure Storage encryption, or assume that Microsoft-managed keys support on-demand rotation, when in fact only customer-managed keys allow the customer to control the key lifecycle.

How to eliminate wrong answers

Option A is wrong because Microsoft-managed keys cannot be rotated on demand by the customer; the rotation schedule is controlled by Microsoft, which fails the requirement for quick key rotation in a breach. Option C is wrong because client-side encryption requires the application to manage encryption and key rotation, increasing administrative overhead and complexity, which contradicts the goal of minimizing overhead. Option D is wrong because Azure Disk Encryption is designed for encrypting virtual machine disks (OS and data disks), not for Azure Blob Storage data at rest.

Practice this question →

134

MCQmedium

Refer to the exhibit. You are deploying an Azure Disk Encryption Set using this ARM template. The deployment succeeds, but when you try to create a disk using this encryption set, the disk creation fails with an error about key vault permissions. What is the most likely cause?

A.The identity type should be UserAssigned

B.The key vault URI is malformed

C.The disk encryption set's system-assigned identity lacks Get, WrapKey, and UnwrapKey permissions on the key vault

D.The key source should be Microsoft.Storage

AnswerC

The disk encryption set (DES) carries a system-assigned managed identity that Azure uses to authenticate to Key Vault when it must unwrap or wrap the disk encryption key. That identity needs explicit permissions on the key vault: Get on the key to read its attributes and WrapKey/UnwrapKey to perform the envelope encryption operations. Without these permissions, the DES cannot access the key material, and disk encryption or decryption operations will fail with an authorization error. Even though the URI is valid and the key exists, missing crypto permissions are the precise root cause.

Why this answer

The disk encryption set uses a system-assigned managed identity to authenticate to Azure Key Vault. When the ARM template deploys the encryption set, this identity is created but must be explicitly granted Get, WrapKey, and UnwrapKey permissions on the key vault's access policy. Without these permissions, the encryption set cannot retrieve the key or perform wrapping operations, causing disk creation to fail.

Exam trap

The trap here is that candidates assume the ARM template automatically grants the necessary key vault permissions to the disk encryption set's managed identity, when in fact this must be explicitly configured via an access policy.

How to eliminate wrong answers

Option A is wrong because the ARM template shown uses 'type': 'SystemAssigned' for the identity, which is correct for disk encryption sets; UserAssigned identities are not supported for this resource. Option B is wrong because the key vault URI in the template is syntactically valid (https://kvdemovault.vault.azure.net/keys/...), and a malformed URI would cause a deployment failure, not a post-deployment permission error. Option D is wrong because 'Microsoft.Storage' is a valid key source for Storage Service Encryption, not for Azure Disk Encryption; disk encryption sets require 'Microsoft.Keyvault' as the key source.

Practice this question →

135

MCQmedium

You have an Azure Cosmos DB account with multiple containers. You need to ensure that data is encrypted at rest using a customer-managed key stored in Azure Key Vault. Which steps should you take?

A.Use Azure Disk Encryption on the VMs hosting Cosmos DB.

B.Configure the Cosmos DB account to use a customer-managed key from Key Vault and assign the appropriate RBAC role.

C.Enable Transparent Data Encryption (TDE) and bring your own key (BYOK) from Key Vault.

D.Enable Always Encrypted on the Cosmos DB account and reference the key from Key Vault.

AnswerB

Configuring the Cosmos DB account to use a customer-managed key (CMK) from Azure Key Vault is the correct approach because Cosmos DB natively supports CMK for encrypting your data at rest. To enable this, you must assign an appropriate RBAC role, such as Key Vault Crypto Service Encryption User, to the Cosmos DB account's system-assigned managed identity or the principal you designate. This ensures that your application uses the key in Key Vault, allowing you to control key rotation, auditing, and revocation while relying on Key Vault's FIPS 140-2-validated HSM protection.

Why this answer

Azure Cosmos DB supports encryption at rest using customer-managed keys (CMK) stored in Azure Key Vault. To enable this, you must configure the Cosmos DB account to use a CMK from Key Vault and assign the appropriate RBAC role (e.g., 'Key Vault Crypto Service Encryption User') to the Cosmos DB system-assigned managed identity, allowing it to access the key for encryption and decryption operations.

Exam trap

The trap here is that candidates confuse Azure SQL Database encryption features (TDE, Always Encrypted) with Cosmos DB's encryption-at-rest mechanism, or incorrectly assume that VM-level encryption (Azure Disk Encryption) applies to PaaS database services.

How to eliminate wrong answers

Option A is wrong because Azure Disk Encryption encrypts the OS and data disks of Azure VMs, not the underlying storage of a PaaS service like Cosmos DB; Cosmos DB data is stored in a managed storage layer, not on VM disks. Option C is wrong because Transparent Data Encryption (TDE) is a SQL Server and Azure SQL Database feature, not applicable to Cosmos DB; Cosmos DB uses its own encryption-at-rest mechanism. Option D is wrong because Always Encrypted is a client-side encryption feature for SQL Server and Azure SQL Database, not supported by Cosmos DB; Cosmos DB does not have an 'Always Encrypted' setting.

Practice this question →

136

MCQhard

A company plans to enable Azure Disk Encryption (ADE) on a fleet of Windows virtual machines. They want to use a key stored in Azure Key Vault to encrypt the disks. Which additional access configuration must be made in the Key Vault to allow ADE to succeed?

A.Grant the Azure Disk Encryption service principal (Microsoft.Azure.Security) appropriate key permissions in the Key Vault access policy.

B.Assign a managed identity to each VM and grant that identity key permissions in the Key Vault.

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

D.Assign the 'Key Vault Contributor' RBAC role to the Azure Disk Encryption service principal.

AnswerA

ADE on Windows VMs unwraps the disk-encryption key using the Microsoft.Azure.Security service principal, so that principal needs key permissions (wrapKey, unwrapKey, get) in the Key Vault access policy. Without this grant, the Key Vault refuses the wrap/unwrap calls and encryption fails.

Why this answer

Azure Disk Encryption (ADE) uses the Azure platform's built-in service principal (Microsoft.Azure.Security) to access the Key Vault and retrieve the disk encryption key. Without granting this service principal the necessary 'Get', 'WrapKey', and 'UnwrapKey' key permissions in the Key Vault access policy, ADE cannot authenticate and perform the encryption operations. This is a mandatory configuration step for ADE to succeed.

Exam trap

The trap here is that candidates often confuse the need to grant permissions to the VM's managed identity (Option B) with the actual requirement to grant permissions to the Azure Disk Encryption service principal, because ADE does not use the VM's identity to access the Key Vault.

How to eliminate wrong answers

Option B is wrong because assigning a managed identity to each VM and granting that identity key permissions is not the required access configuration for ADE; ADE uses the Azure platform service principal, not the VM's identity, to access the Key Vault. Option C is wrong because enabling soft-delete and purge protection is a recommended security feature for Key Vault but is not an additional access configuration required for ADE to succeed; ADE can work without these settings. Option D is wrong because assigning the 'Key Vault Contributor' RBAC role to the Azure Disk Encryption service principal grants management plane permissions (e.g., to modify the vault itself), not the data plane key permissions (e.g., WrapKey, UnwrapKey) that ADE needs to encrypt disks.

Practice this question →

137

MCQhard

Your company uses Azure SQL Database. You need to ensure that all queries from a specific application use Always Encrypted to protect sensitive columns. The application is developed in C#. What must you configure in the application and database?

A.Enable Transparent Data Encryption (TDE) on the database and use integrated security.

B.Configure Dynamic Data Masking and use ODBC driver.

C.Define column master key and column encryption key in the database, and update the connection string to include 'Column Encryption Setting=enabled'.

D.Use Azure Information Protection labels and configure the application to enforce protection.

AnswerC

Always Encrypted is the correct approach for requiring column-level encryption because it encrypts data client-side and never allows the database engine to see either the encryption keys or the plaintext data. You must define a column master key (CMK) and a column encryption key (CEK) in the database, and then set the connection string keyword 'Column Encryption Setting=enabled' so the client driver (ODBC/JDBC) knows to perform the decrypt/encrypt operations transparently. With this configuration, the Azure SQL Database service can store ciphertext, and only the client application with access to the key can read or write plaintext.

Why this answer

Always Encrypted requires a column master key and column encryption key to be defined in the database to encrypt sensitive columns, and the client application must enable the feature in its connection string by adding 'Column Encryption Setting=enabled'. This ensures that encryption and decryption occur on the client side, protecting data in transit and at rest from the database engine.

Exam trap

The trap here is that candidates often confuse Always Encrypted with Transparent Data Encryption (TDE) or Dynamic Data Masking, thinking any encryption or masking feature will suffice, but only Always Encrypted provides client-side encryption with explicit key management and connection string configuration.

How to eliminate wrong answers

Option A is wrong because Transparent Data Encryption (TDE) encrypts data at rest but does not provide client-side encryption or protect data from database administrators, and integrated security is unrelated to Always Encrypted. Option B is wrong because Dynamic Data Masking only obfuscates data at query time for unauthorized users, not encrypting it, and using an ODBC driver is not sufficient without the proper encryption keys and connection string setting. Option D is wrong because Azure Information Protection labels are for classifying and protecting documents and emails, not for encrypting database columns at the application level.

Practice this question →