Design and implement a strategy for managing sensitive information in automation

Alpine Ski House builds an Android app named TrailMap in Azure Pipelines. The release build must sign the package with a Java keystore file named trailmap-release.jks. The keystore must never be committed to the repository, only the pipeline TrailMap-Release may use it, and the file must not remain on the agent after the job finishes.

How should you provide the keystore to the pipeline?

1. ACommit an encrypted copy of the keystore to the repository and decrypt it in a script step with a secret variableThis places the keystore in source control, which the requirement forbids, and leaves decrypted copies behind unless every step cleans up correctly.
2. BUpload the keystore as a secure file in Library, grant pipeline permission only to TrailMap-Release, and download it with the DownloadSecureFile@1 taskSecure files are stored encrypted in Azure DevOps, access is controlled per pipeline, the task exposes the path through the secureFilePath output variable, and the file is deleted from the agent when the job completes.
3. CCopy the keystore to a shared folder on the self-hosted agent and reference it by pathA file left on the agent persists after the job, is readable by any pipeline that runs on that agent, and cannot be restricted to one pipeline.
4. DPublish the keystore as a pipeline artifact from a one-time pipeline run and download it in TrailMap-ReleasePipeline artifacts are readable by anyone with read access to the producing pipeline and are not designed to protect signing material.

Trey Research has a YAML pipeline in Azure Pipelines with a secret variable named sqlAdminPassword. A Bash step runs a migration script that reads the password from the environment variable SQL_ADMIN_PASSWORD, but the variable is empty at run time. While troubleshooting, a developer added a step that prints the password encoded as Base64, and the encoded value now appears in clear text in the logs. You must make the script work and prevent the secret from appearing in logs in any form.

Which two actions should you perform? Each correct answer presents part of the solution.

1. AMap the secret explicitly on the Bash step with env: SQL_ADMIN_PASSWORD: $(sqlAdminPassword)Secret variables are not mapped into environment variables automatically, so each step that needs one must map it explicitly through env, which keeps the secret available only to that step.
2. BRemove the troubleshooting step that encodes and prints the passwordMasking only replaces the exact secret value; a transformed value such as Base64 is a different string and is written to the log unmasked, so any step that echoes or transforms a secret must be removed.
3. CClear the Keep this value secret option on sqlAdminPassword so that it is mapped to the environment automaticallyMaking the variable non-secret would map it automatically, but it also removes masking and exposes the value in the UI and logs, which is the opposite of the goal.
4. DSet the system.debug variable to true to confirm the value is passed correctlyDebug logging increases log verbosity and can surface additional values; it does not fix the mapping and adds risk.
5. EPass the password as a command-line argument to the migration script instead of an environment variableCommand-line arguments can be visible in process listings and are easier to log accidentally; Microsoft guidance is to pass secrets through explicitly mapped environment variables.

Margie's Travel uses OIDC with azure/login in the GitHub repository margies/itinerary-svc. The Microsoft Entra app registration has one federated credential with subject repo:margies/itinerary-svc:ref:refs/heads/main, and deployments from pushes to main succeed. A new job that runs on the pull_request event must run a Bicep what-if against a non-production resource group, but azure/login fails with an error that no matching federated identity record was found. No client secret may be added.

What should you do?

1. AAdd a second federated credential to the app registration with subject repo:margies/itinerary-svc:pull_requestOIDC tokens issued for pull_request events carry the subject repo:<owner>/<repo>:pull_request, so Microsoft Entra ID needs a federated credential with that exact subject, ideally on an identity with only Reader access to the non-production resource group.
2. BChange the existing federated credential subject to repo:margies/itinerary-svc:ref:refs/heads/*A standard federated credential matches the subject claim exactly and does not support wildcards, and a pull_request token does not use a ref-based subject anyway; changing the subject would also break the main deployment.
3. CAdd permissions: id-token: read to the pull_request jobRequesting an OIDC token requires id-token: write; and the error shows a token was issued but did not match any federated credential, which is a subject problem.
4. DStore a fine-grained personal access token as a repository secret and pass it to azure/loginA GitHub PAT cannot authenticate to Microsoft Entra ID, and storing a credential contradicts the secretless requirement.

Proseware Finance has 14 YAML pipelines in the Azure DevOps project Ledger that all need the same database connection strings and API keys. The secrets are stored in a key vault named kv-ledger-prod that uses the Azure RBAC permission model, and the security team rotates them monthly directly in Key Vault. Pipelines must always use the current secret values without any pipeline edits after rotation, and the secret list must be defined once and shared by all 14 pipelines.

What should you implement?

1. AA variable group in Library linked to kv-ledger-prod through an Azure Resource Manager service connection whose identity has the Key Vault Secrets User role, and authorize the 14 pipelines to use the variable groupA Key Vault-linked variable group is defined once in Library, fetches the latest secret values at run time, and is shared through pipeline permissions; the service connection identity only needs read access to secrets.
2. BA variable group in Library that stores the secrets as secret variables, updated by the security team after each rotationCopying secrets into a variable group creates a second copy that must be updated manually after every rotation, so pipelines would use stale values in between.
3. CAn AzureKeyVault task in each of the 14 pipelines, using a service connection whose identity has the Key Vault Administrator roleThe task does fetch current values, but the secret list is repeated in 14 pipelines rather than defined once, and Key Vault Administrator grants management rights far beyond reading secrets.
4. DExport the secrets from kv-ledger-prod to a JSON file and upload it as a secure file that all pipelines downloadAn exported file is a static snapshot that goes stale after each rotation and must be re-uploaded, which defeats the purpose of Key Vault.