Task 1.2: Secure secrets and keys by using Azure Key Vault

• APin the module to an earlier Key Vault API version for good

  Incorrect

  Control plane API versions before 2026-02-01 retire on February 27, 2027, so pinning isn't a lasting fix.

• BSet enableRbacAuthorization to false in the module for new vaults

  Correct

  From API version 2026-02-01, new vaults default to Azure RBAC unless enableRbacAuthorization is set to false at creation.

• CAssign Key Vault Contributor to each app identity on the new vaults

  Incorrect

  Key Vault Contributor manages vaults on the control plane; it doesn't grant access to secrets, keys or certificates.

• DRedeploy the older vaults with the new API version so that all vaults behave the same way

  Incorrect

  Updating existing vaults with the new API version doesn't change their access model, and it wouldn't fix the new vaults.

With Key Vault API version 2026-02-01 and later, a create operation defaults to Azure RBAC (enableRbacAuthorization = true), so access policies in the template don't grant data access. Existing vaults keep their model unless you change the property. To keep access policies on new vaults, set enableRbacAuthorization to false at creation; Microsoft still recommends migrating to Azure RBAC.

• APipelines on Microsoft-hosted Azure DevOps agents reach the vault through the trusted-services bypass

  Incorrect

  Azure DevOps isn't on the trusted services list, because users can run custom code on it.

• BA storage account using a customer-managed key in the vault keeps working without a private endpoint

  Correct

  Azure Storage is trusted for customer-managed keys, and the bypass still applies when public network access is Disabled.

• CThe trusted-services bypass stops applying as soon as public network access is set to Disabled

  Incorrect

  The bypass continues to apply with public network access Disabled; only Secure by perimeter overrides it.

• DAn App Service app reading secrets through Key Vault references needs a network path to the private endpoint

  Correct

  App Service is trusted only for deploying web app certificates, not for the app's own calls to the vault.

• EAny Azure service that authenticates with a managed identity is treated as trusted

  Incorrect

  Only the services in the trusted services table are trusted, and only for the listed scenarios.

Trusted services are listed per scenario: Azure Storage for customer-managed keys, App Service only for deploying web app certificates, while Azure DevOps isn't listed. Services not in the table are blocked by the firewall whether or not the bypass is on. The bypass continues to apply when publicNetworkAccess is Disabled, so trusted services don't need a private endpoint.

• ASwitch the vault to the Azure RBAC permission model

  Correct

  With Azure RBAC, granting data plane access needs Owner or User Access Administrator, so Contributor can no longer grant itself access.

• BKeep the access policy permission model and turn on purge protection

  Incorrect

  Purge protection stops permanent deletion; it doesn't stop anyone from granting themselves access.

• CCreate a suppression rule for alerts about the engineer

  Incorrect

  Suppression hides alerts; it changes nothing about who can grant access.

• DEnable the vault firewall and allow only the corporate network

  Incorrect

  A network restriction doesn't stop an engineer on an allowed network from granting himself access.

Under the access policy model, anyone with Microsoft.KeyVault/vaults/write, such as Contributor or Key Vault Contributor, can add an access policy that grants themselves data plane access. Azure RBAC restricts permission management to Owner and User Access Administrator. The KV_PutGetAnomaly alert flags a Put policy change followed by Secret Get operations; secrets that were read should also be rotated.

• ADevOps security connectors for the company's repositories

  Incorrect

  DevOps security scans source control, and this template never reached a repository.

• BAgentless machine scanning in the Defender for Servers settings

  Incorrect

  Machine secrets scanning looks at VM disks, not deployment resources.

• CDefender for Resource Manager on the subscriptions

  Incorrect

  It doesn't scan deployment contents for secrets.

• DThe Defender CSPM plan on the subscriptions

  Correct

  Cloud deployment secrets scanning, which reads deployment metadata through the control plane, is available with Defender CSPM.

Defender for Cloud scans cloud deployments, such as ARM deployments with their templates, parameters and outputs, for plaintext secrets through the control plane API. This scanning is available with the Defender CSPM plan, and findings appear as Azure Resource Manager deployments should have secrets findings resolved. Machine secrets scanning, by contrast, looks at VM disks.

• A1 to 30 days

  Incorrect

  The minimum is longer and the maximum much longer.

• B7 to 90 days

  Correct

  The retention period can be set anywhere from 7 to 90 days, with 90 as the default.

• C30 to 365 days

  Incorrect

  The maximum is 90 days.

• DExactly 90 days, with no choice

  Incorrect

  You can choose a value between 7 and 90 days.

Deleted vaults and vault objects remain recoverable for a configurable period of 7 to 90 calendar days, 90 days by default, chosen when the vault is created.

• AKey Vault Reader

  Incorrect

  Reader can read metadata but can't manage keys.

• BKey Vault Crypto Service Encryption User

  Incorrect

  That role reads keys and wraps or unwraps with them for service encryption.

• CKey Vault Contributor

  Incorrect

  Key Vault Contributor manages vaults on the control plane, not keys.

• DKey Vault Crypto Officer

  Correct

  Key rotation requires key management permissions, which this role includes.

Key Vault key rotation requires key management permissions: assign Key Vault Crypto Officer to manage the rotation policy and on-demand rotation. With access policies, the Rotate, Set Rotation Policy and Get Rotation Policy key permissions are needed.

• AOn the key vault's Security page

  Correct

  Alerts appear on Key Vault's Security page and in Workload protections, as well as in security alerts.

• BOnly in the vault's diagnostic logs in Log Analytics

  Incorrect

  Diagnostic logs record operations; alerts are shown in the portal pages.

• CIn the vault's Access policies page

  Incorrect

  Access policies list permissions, not alerts.

• DIn Azure Advisor's Security tab only

  Incorrect

  Defender for Key Vault alerts are shown in Defender for Cloud and on the vault.

Defender for Key Vault detects unusual or harmful attempts to access or exploit key vaults. Its alerts appear on the key vault's Security page, in Workload protections, and on Defender for Cloud's security alerts page, and can be emailed to relevant people.

• AOnly resources in the vault's own virtual network can reach it

  Incorrect

  A vault isn't placed in a virtual network, and by default it isn't restricted to one.

• BOnly trusted Microsoft services can reach it until you add firewall rules

  Incorrect

  Trusted-services bypass applies once the firewall is enabled.

• CAny network can send requests, but each request still needs Microsoft Entra authentication and permissions

  Correct

  The firewall is disabled by default, while authorization still applies.

• DNothing can reach it until you create a private endpoint

  Incorrect

  A private endpoint is optional; public access works by default.

By default, the Key Vault firewall is disabled when a vault is created, so all applications and Azure services can send requests. That doesn't give anyone access: Key Vault still requires Microsoft Entra authentication and permissions for keys, secrets and certificates.