AZ-500 Secure compute, storage, and databases: 132 practice questions

12 of the 132 Secure compute, storage, and databases questions in the Certsqill AZ-500 bank, shown in full below. Each one carries an explanation for every option, not just the correct one — the wrong answers are where the marks go.

Preparing for AZ-500? Take the free 5-min readiness check →

1. Enable Microsoft Defender for Azure SQL: What must they enable?

1. Enable Azure SQL Auditing and stream the audit logs to Log Analytics, where the built-in analytics rules raise the real-time SQL injection and anomalous query pattern security alerts for the database.

   SQL Auditing captures query events for compliance and forensics but performs no real-time threat analysis; Defender for Azure SQL provides the detection layer.
2. Enable the Defender for Cloud Enhanced Security Features toggle and set the database data sensitivity classification level to High, which turns on the SQL injection and anomaly threat alerts.

   Defender for Cloud uses individual per-resource plans, not one 'Enhanced Security' switch, and data sensitivity classification does not enable SQL threat alerts.
3. Enable Microsoft Defender for Servers on the virtual machines hosting the database application tier, so its agent inspects the SQL traffic and raises the injection and brute force alerts.

   Defender for Servers monitors OS-level threats on VMs, but Azure SQL Database is a managed PaaS service with no VM agent; Defender for Azure SQL is the right plan.
4. Enable Microsoft Defender for Azure SQL — this plan provides advanced threat protection including SQL injection detection, anomalous access patterns, and brute force alerts for Azure SQL databases ✓

   Microsoft Defender for Azure SQL is the specific plan that monitors Azure SQL Database for active threats. It detects SQL injection, anomalous query patterns, unusual access from unfamiliar locations, and brute force attempts. It is separate from CSPM and requires explicit enablement.

Microsoft Defender for Azure SQL provides real-time threat detection including SQL injection and anomalous access pattern alerts — it must be enabled separately from the free CSPM tier.

2. The developer loses all access: What happens to the developer's access after the switch?

1. The developer loses all access — vault access policies are not migrated to Azure RBAC assignments. New RBAC role assignments must be explicitly created to restore access ✓

   When a Key Vault is switched from vault access policy to Azure RBAC authorization mode, all existing vault access policies are retained in storage but are ignored — the RBAC engine takes over. No automatic migration of access policies to RBAC assignments occurs. The developer has no RBAC role assignment on the vault, so they have no access.
2. The developer retains access because switching to Azure RBAC automatically converts the existing 'Get' and 'List' access policy into an equivalent Key Vault Secrets User role assignment.

   No automatic conversion of access policies to RBAC assignments occurs; the two authorization systems are independent and require manual re-creation of equivalents.
3. The switch to Azure RBAC fails because all existing vault access policies must be manually deleted before the vault's authorization model can be changed.

   Existing access policies do not block the switch; they are preserved but become inactive while RBAC takes over, and can be re-examined if switched back.
4. The developer keeps 'Get' but loses 'List' access, because Azure RBAC maps the access policy 'Get' permission onto the built-in Key Vault Reader role during the authorization switch.

   There is no partial mapping of access policy permissions to RBAC roles; after the switch the developer has no role assignment and therefore no access at all.

Switching to RBAC mode deactivates all vault access policies immediately — no access is migrated. RBAC assignments must be created from scratch.

3. Rotate the storage account key that was used to sign: What is the FASTEST way to revoke the SAS token immediat

1. Update the blob container's public access level to Private, which overrides and cancels the write permissions of the SAS token.

   SAS tokens authorize on their own path and bypass container public access settings, so changing public access does not affect a valid SAS token.
2. Rotate the storage account key that was used to sign the SAS token — this immediately invalidates all SAS tokens signed with that key ✓

   Ad-hoc SAS tokens cannot be individually revoked — they are valid until expiry or until the signing key is rotated. Rotating the storage account key (key1 or key2) invalidates all SAS tokens signed with that specific key immediately. This is the only instant revocation mechanism for account-key-signed SAS tokens.
3. Delete the ad-hoc SAS token from the Shared access signature blade of the storage account in the Azure portal to revoke it instantly.

   Ad-hoc SAS tokens are signed strings generated client-side and are not stored in the portal, so there is nothing to delete; key rotation is required.
4. Create a Stored Access Policy with the same permissions but a past expiry date and link it to the ad-hoc SAS token to revoke it immediately.

   Stored Access Policies only govern SAS tokens generated referencing them; an ad-hoc SAS cannot be retroactively linked, so key rotation is the only option.

Ad-hoc SAS tokens cannot be individually revoked — rotating the storage account key that signed them is the only immediate revocation method.

4. No — ADE encrypts data within the VM OS but does not: Does ADE alone satisfy the requirement?

1. No — Azure Disk Encryption is deprecated, so the team should disable ADE and rely on Server-Side Encryption with platform-managed keys, which already encrypts the managed disk storage and can be pointed at a customer-managed key later if that becomes necessary.

   ADE is not deprecated and remains supported for OS-level encryption; the correct answer is that ADE and SSE with CMK coexist for defense in depth.
2. Yes — enabling ADE with Key Vault integration automatically configures Server-Side Encryption with customer-managed keys for the underlying managed disk storage, so the BitLocker key and the storage-layer key both come from your Key Vault.

   ADE and SSE with CMK are independent; ADE with Key Vault only wraps the guest OS BitLocker key and does not configure SSE CMK for the managed disk storage.
3. No — ADE encrypts data within the VM OS (BitLocker/dm-crypt) but does not encrypt at the Azure storage infrastructure layer. Server-Side Encryption (SSE) with customer-managed keys (CMK) is required to encrypt at the Azure storage level, and both can coexist ✓

   ADE uses BitLocker (Windows) or dm-crypt (Linux) within the VM guest OS — it encrypts the data before it reaches the Azure managed disk service layer. However, the unencrypted data-at-rest on Azure's storage infrastructure is protected by SSE. For customer-managed key encryption at the Azure infrastructure layer, SSE with CMK (using a Disk Encryption Set pointing to Key Vault) must be enabled separately. Double encryption is also an option.
4. Yes — ADE using BitLocker or dm-crypt encrypts the guest OS volumes, and because that ciphertext is exactly what lands on Azure's managed disk storage, it also satisfies the customer-managed encryption requirement at the Azure infrastructure layer.

   ADE runs inside the guest OS and does not control encryption at the managed disk service layer; CMK there requires SSE with a Disk Encryption Set in Key Vault.

ADE encrypts at the OS level (BitLocker/dm-crypt) but not at the Azure storage infrastructure layer — SSE with CMK is needed for infrastructure-level customer-managed key encryption.

5. Microsoft Defender for Containers: Which Defender for Cloud plan generated this alert, and what data source wa

1. Azure Policy for Kubernetes — its OPA Gatekeeper admission controller intercepted the privileged host-filesystem mount and blocked the container before it started.

   Azure Policy for Kubernetes (OPA Gatekeeper) enforces admission policies at pod creation and cannot detect runtime behavior after a container is already running.
2. Microsoft Defender for Kubernetes — its cloud connector parsed the Kubernetes API server audit logs and correlated the host filesystem mount call to flag the container escape attempt.

   Defender for Kubernetes analyzes API audit logs for control-plane activity; runtime container filesystem and process behavior is detected by the node-level sensor.
3. Microsoft Defender for Servers — the Log Analytics agent installed on each AKS node observed the container's host filesystem mount syscalls and raised the container escape alert with pod context.

   Defender for Servers monitors OS-level activity but lacks container context such as namespace and pod name; those come from Defender for Containers' sensor.
4. Microsoft Defender for Containers — generated by the Defender sensor (DaemonSet) running on AKS nodes that monitors runtime process and syscall activity within containers ✓

   Defender for Containers deploys a DaemonSet (sensor) on each AKS node. The sensor monitors container runtime events including process execution, file system access, network activity, and syscall patterns. Container escape attempts (e.g., privileged container mounts of host filesystem) are detected by this runtime sensor.

Defender for Containers' runtime sensor (DaemonSet on AKS nodes) detects container escape attempts by monitoring syscalls and filesystem access within running containers.

6. Enable soft delete with a 90-day retention period: Which combination of Key Vault features satisfies both requ

1. Enable soft delete with a 90-day retention period AND enable purge protection — purge protection prevents anyone (including administrators) from purging soft-deleted secrets before the retention period expires ✓

   Soft delete keeps deleted secrets in a soft-deleted state for the configured retention period (7-90 days). Purge protection, when enabled, prevents the soft-deleted secret from being permanently purged (even by administrators with purge permissions) until the retention period expires. Together they enforce the 90-day recovery window with no bypass.
2. Enable soft delete with a 90-day retention period on the Key Vault, relying on the fact that administrators must deliberately call the purge API before a secret can be permanently removed

   Soft delete alone allows administrators with appropriate permissions to call the purge API and permanently delete secrets before the retention period expires. Purge protection is required to remove that administrative bypass and guarantee the full window.
3. Assign an Azure Policy at the subscription that denies deletion of Key Vault secrets, blocking every delete request including administrative purges so that no secret can be removed within 90 days

   Azure Policy can deny creation or modification of Key Vault resources at the ARM level but cannot govern secret operations inside a Key Vault, which use the data plane API rather than ARM. Soft delete plus purge protection are the correct mechanisms for this requirement.
4. Enable Key Vault backup and schedule a daily export of every secret to Azure Storage, so that any secret an administrator deletes can simply be restored from the most recent daily backup at any point within the 90-day window

   Key Vault backup creates point-in-time copies of secrets, but backup is for disaster recovery, not deletion protection, and restoration requires administrative action that could be delayed. Soft delete with purge protection is the built-in, automatic, compliance-grade deletion protection mechanism.

Soft delete provides recovery window (up to 90 days), and purge protection prevents admins from bypassing it — both are required to guarantee the 90-day recovery window.

7. Always Encrypted: Which encryption feature achieves this?

1. Transparent Data Encryption (TDE) configured with customer-managed keys in Azure Key Vault, so that DBAs who lack access to the Key Vault encryption key are unable to decrypt the patient SSN and DOB columns when they connect and query the database directly

   TDE protects data at rest (data files, log files, backups) from offline attacks such as a stolen disk. It does NOT protect against authorized database users or DBAs who connect via SQL; once connected, TDE is transparent and DBAs see plaintext regardless of TDE key management.
2. Always Encrypted — column-level encryption where encryption keys are stored in a key store (Azure Key Vault or Windows Certificate Store) on the client side. DBAs querying the database receive ciphertext; only clients with access to the column master key can decrypt ✓

   Always Encrypted separates those who own the data (applications with key access) from those who manage the database (DBAs). The database engine never sees plaintext for Always Encrypted columns. DBAs can execute queries against those columns but only receive ciphertext, regardless of their SQL permissions.
3. Enable Azure SQL Advanced Threat Protection so that it continuously monitors the database and raises an alert whenever a DBA queries the patient SSN and DOB columns, which is intended to ensure the sensitive personal data can never be read without the activity being noticed

   Advanced Threat Protection detects anomalous query patterns and potential attacks such as SQL injection or unusual access. It does not prevent DBAs from reading sensitive data; it only alerts on suspicious activity after the fact and provides no confidentiality guarantee.
4. Apply Azure SQL Dynamic Data Masking to the SSN and DOB columns so that DBAs and every other privileged user always receive masked placeholder values in query results instead of the real patient data whenever they read those columns

   Dynamic Data Masking (DDM) is a presentation-layer control that returns masked values for unprivileged users, but DBAs or anyone with the UNMASK permission can bypass it and see the real values. DDM is not an encryption solution and does not protect data confidentiality against privileged users.

Always Encrypted encrypts data client-side, meaning the database engine (and DBAs with full SQL access) only ever sees ciphertext for protected columns.

8. Remediate recommendations with the highest 'Max score: Which approach has the greatest impact on Secure Score

1. Remediate recommendations that affect the most resources first — high resource count recommendations have the greatest impact on Secure Score

   Secure Score is not weighted purely by resource count. Score is determined by control weights, not the number of affected resources. A recommendation affecting 100 VMs might be in a control worth 0 additional points if it is already partially remediated.
2. Apply Azure Policy 'DeployIfNotExists' initiatives to all recommendations and wait for automatic remediation

   Only some recommendations support automatic remediation via DeployIfNotExists policies. Many recommendations require manual review and action. Also, Secure Score only increases when the underlying resource configuration actually meets the recommendation — waiting for automatic policies may not be the fastest path.
3. Remediate recommendations with the highest 'Max score increase' first — this directly maximizes points gained per recommendation ✓

   Secure Score is calculated based on controls (groups of related recommendations). Remediating all recommendations in a control unlocks that control's maximum score increase. Prioritizing by 'Max score increase' in the recommendations list targets the controls that contribute most to the overall score.
4. Fix all 'Critical' severity recommendations first — Secure Score is directly proportional to the number of critical alerts resolved

   Severity (Critical/High/Medium/Low) is an independent assessment of risk and does not directly correlate to Secure Score impact. A medium-severity recommendation in a high-weight control may have more Secure Score impact than a critical-severity recommendation in a low-weight control.

Sort recommendations by 'Max score increase' in Defender for Cloud to target the highest-value controls first and maximize Secure Score gain per remediation effort.

9. Create a private endpoint for the storage account: What configuration allows the VNet-B VM without enabling pu

1. Enable the Microsoft.Storage service endpoint on VNet-B's subnet and add VNet-B to the storage account's virtual network rules so the VM is recognized as an allowed private-network source for blob access

   This would technically grant access, but the scenario explicitly requires access without configuring service endpoints on VNet-B. The correct approach uses a private endpoint, which works regardless of whether VNet-B has any Microsoft.Storage service endpoint.
2. Switch the storage account to allow access from 'All networks' during the read operation and rely on scoped SAS tokens to constrain exactly which blobs the VNet-B VM is permitted to retrieve

   Setting 'All networks' allows access from the entire internet, which violates the constraint of not enabling public access for all IPs. SAS tokens control authorization (what a caller may do) but not network-level access control (from where traffic may originate).
3. Add VNet-B's subnet IP range to the storage account firewall as an allowed IP address range so that requests originating from those internal addresses are permitted through the public endpoint

   Storage account IP rules are only for public internet IP addresses. Private VNet IP ranges (RFC 1918 addresses such as 10.x.x.x, 172.16-31.x.x, and 192.168.x.x) cannot be added as IP rules in the storage account firewall settings.
4. Create a private endpoint for the storage account in VNet-B — private endpoints bypass the storage account firewall and allow access from any subnet within VNet-B regardless of service endpoints ✓

   Private endpoints create a dedicated private NIC in the target VNet with a private IP. Traffic from VNet-B to the storage account's private endpoint IP is routed entirely within the VNet and does not pass through the storage account's public firewall. Private endpoints bypass the network rules (virtual network rules) and are always allowed.

Private endpoints bypass storage account firewall network rules — traffic from VNet-B to the private endpoint IP stays within Azure's private network without requiring service endpoints.

10. Enable Azure Container Registry Content Trust for image: What ACR and AKS configuration achieves both requirem

1. Enable ACR geo-replication and configure private endpoints for the registry, so that images are validated across each replicated region and only trusted, non-vulnerable images are ever allowed to be pulled into the production AKS clusters

   Geo-replication replicates registry content to multiple regions for availability and performance, and private endpoints control network reachability. Neither performs image signing verification or CVE scanning, so together they still do not enforce signature or vulnerability gating.
2. Configure an AKS NetworkPolicy that blocks pod-to-pod communication for any container started from an image that has not been signed or scanned for vulnerabilities, thereby isolating the unverified workloads from the rest of the cluster network

   NetworkPolicy controls network traffic between pods and is unrelated to image provenance or vulnerability scanning. It cannot detect whether an image is signed or contains critical CVEs, so it cannot prevent an unverified image from being deployed in the first place.
3. Enable Azure Container Registry Content Trust (Notary) for image signing verification, and enable Microsoft Defender for Containers to scan images for CVEs with an admission controller policy that blocks pods using images with critical vulnerabilities ✓

   Content Trust ensures only signed images can be pulled (Notary signature verification). Defender for Containers scans ACR images for CVEs and integrates with Azure Policy for Kubernetes admission control to block deployments of images with critical vulnerabilities. Together they enforce both signature verification and CVE-gating.
4. Use a Dockerfile linter in the CI/CD pipeline to inspect the base images and flag any known vulnerabilities before the resulting container image is signed and pushed to Azure Container Registry for later deployment to AKS

   Dockerfile linting catches coding issues and best practices, and pipeline scanning helps, but it only checks at build time. The requirement is enforcement at deployment time, preventing vulnerable or unsigned images from reaching AKS even if they slip past the pipeline checks.

Content Trust enforces image signing, and Defender for Containers with Azure Policy for Kubernetes blocks CVE-vulnerable image deployments at AKS admission time.

11. No — Key Vault Premium uses shared HSM infrastructure: Does this meet the requirement?

1. No — Key Vault Premium uses shared HSM infrastructure managed by Microsoft. For a dedicated, single-tenant HSM with FIPS 140-2 Level 3 validation where Microsoft cannot access key material, Azure Managed HSM is required ✓

   Azure Key Vault Premium provides HSM-backed keys using FIPS 140-2 Level 2 validated shared HSMs managed by Microsoft. Azure Managed HSM provides a dedicated, single-tenant FIPS 140-2 Level 3 validated HSM where key material is protected by a security domain controlled by the customer — Microsoft cannot access the keys.
2. Yes — Key Vault Premium combined with customer-managed keys gives the organization exclusive control over the key lifecycle on hardware that is dedicated to them, satisfying the FIPS 140-2 Level 3 single-tenant requirement

   Customer-managed keys mean the customer manages the key lifecycle (rotation, deletion), but the underlying HSM hardware in Key Vault Premium is still multi-tenant and validated to FIPS 140-2 Level 2, not a dedicated Level 3 HSM.
3. Yes — the keys in Key Vault Premium are HSM-protected on hardware provisioned per customer and validated to FIPS 140-2 Level 3, so the current configuration already meets the financial company's regulatory obligation

   Key Vault Premium uses HSMs validated to FIPS 140-2 Level 2, not Level 3, and the HSM infrastructure is shared across customers rather than provisioned per customer. It therefore does not provide a dedicated single-tenant Level 3 HSM.
4. No — FIPS 140-2 Level 3 can only be met with on-premises HSM appliances, so neither Azure Key Vault Premium nor Azure Managed HSM can satisfy this requirement while the keys remain hosted in the Azure cloud

   Azure Managed HSM is specifically certified to FIPS 140-2 Level 3, so the requirement for cloud-hosted keys at Level 3 is met by Managed HSM. On-premises hardware is not required to reach Level 3 validation in Azure.

Azure Key Vault Premium uses multi-tenant FIPS 140-2 Level 2 HSMs. Azure Managed HSM provides dedicated, single-tenant FIPS 140-2 Level 3 HSMs where Microsoft has no access to key material.

12. Enable Microsoft Defender for Servers Plan 2: Which Defender for Cloud configuration enables this?

1. Enable Microsoft Defender for Servers Plan 1 — Plan 1 bundles the integrated Qualys vulnerability scanner that runs agentlessly and continuously streams the discovered CVE findings straight into the Defender for Cloud recommendations blade for remediation

   Plan 1 provides only MDE integration and core server protections; it does NOT include integrated vulnerability assessment. VA via MDVM or the Qualys integration is exclusive to Plan 2, so Plan 1 cannot deliver these scan results.
2. Enable the free Foundational CSPM tier of Defender for Cloud — its built-in security posture scanning already performs agentless CVE detection on every Azure VM and publishes each finding as a Defender for Cloud recommendation

   Foundational CSPM (free tier) delivers posture assessment and hardening recommendations only. It does NOT perform CVE-level vulnerability scanning; that capability requires a paid Defender for Servers plan.
3. Enable Microsoft Defender for Servers Plan 2 — it includes integrated vulnerability assessment using Microsoft Defender Vulnerability Management (MDVM) that uses the MDE sensor (no additional agent) and reports results to Defender for Cloud ✓

   Defender for Servers Plan 2 includes integrated Microsoft Defender Vulnerability Management (formerly TVM), which leverages the existing MDE sensor on the VM for vulnerability discovery. No additional agent is required. Results appear as Defender for Cloud recommendations with CVE details and remediation guidance.
4. Deploy the Azure Monitor Agent to every VM and author a Data Collection Rule that inventories all installed software packages and scans each of them against a live CVE feed to detect known vulnerabilities

   Azure Monitor Agent with a DCR collects performance metrics, event logs, and syslog; it neither inventories vulnerabilities nor scans for CVEs. Vulnerability assessment needs Defender for Servers with MDVM or the Qualys integration.

Defender for Servers Plan 2 includes Microsoft Defender Vulnerability Management integration — uses the existing MDE sensor, no additional agent needed, and surfaces CVEs in Defender for Cloud.

Other AZ-500 domains

• Manage security operations — 137 questions →
• Manage identity and access — 126 questions →
• Secure networking — 105 questions →
• All 500 AZ-500 questions →