Your DevOps team deploys Azure Virtual Desktop host pools and session hosts through Bicep. Domain-join credentials and an SSL certificate for reverse connect must be supplied at deployment time without putting secrets in source code or parameter files. Auditors require that secrets be recoverable if accidentally deleted. Which two actions should you take? Each correct answer presents part of the solution.

Storing credentials and certificates in Azure Key Vault with soft-delete and purge protection enabled meets the requirement for secure storage, preventing secrets from being in source code, and ensuring recoverability if accidentally deleted. Assigning a user-assigned managed identity to the deployment and granting it get and list permissions to the Key Vault allows the Bicep deployment to securely retrieve the secrets at deployment time using the listSecret function, without hardcoding them. Placing secrets in an Azure DevOps variable group, even if marked secret, still involves passing them as parameters, which can be less secure than Key Vault integration and doesn't inherently provide the same level of auditability and recoverability. Embedding the certificate PFX directly in the Bicep file, even if marked secure, is not a best practice for secret management and exposes the secret in the template. Storing secrets in an Automation Account credential asset and fetching them from a runbook after deployment introduces unnecessary complexity and doesn't directly integrate with the Bicep deployment process for initial provisioning.