SC-100 A company uses Azure DevOps for CI/CD Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use environment variables in the pipeline YAML

  Why it's wrong here

  Environment variables defined directly in pipeline YAML are stored in plain text within the pipeline definition and may be surfaced in pipeline logs, making them visible to anyone with log access. Moreover, they are not encrypted at rest in Azure DevOps and lack fine-grained access control, so any user who can edit the pipeline can view or modify them. Azure DevOps secret variables, which are masked and encrypted, are a safer alternative, but the best practice is to avoid hardcoding secrets in the pipeline and instead fetch them from an external secure store.

• ✓

  Use Azure Key Vault references in Azure DevOps variable groups

  Why this is correct

  Azure Key Vault references in variable groups are the secure, recommended approach because secrets are stored only in Key Vault and are fetched at pipeline runtime via a managed identity or service principal. This eliminates the need to store secrets in the pipeline definition or repository, and access to the secrets is controlled by Azure role-based access on the Key Vault, allowing fine-grained permissions and auditability. Secrets can also be rotated in Key Vault without modifying the pipeline, and the variable group automatically retrieves the latest value, making this solution both secure and maintainable.

• ✗

  Encrypt secrets using Git-secret and commit to repo

  Why it's wrong here

  Using Git-secret to encrypt secrets and commit them to the repository is fundamentally unsafe because the encryption keys must be distributed to all developers and CI/CD agents, creating a key-management burden and a single point of compromise. Additionally, encrypted secrets in git history are vulnerable to offline brute-force attacks if the encryption algorithm or key strength is inadequate, and they remain in the repository indefinitely, even if later removed. Microsoft best practice explicitly forbids committing any form of secret to source control, warning that decryption keys can leak or be compromised, so this approach is not a viable secure alternative.

• ✗

  Store secrets in Azure App Configuration with encryption

  Why it's wrong here

  Azure App Configuration is designed for feature flags and non-sensitive configuration settings, not for secret management, as it does not provide secret-specific features like automatic rotation, expiry, or advanced access policies tied to Azure AD principals. While App Configuration encrypts data at rest, that encryption is only for general protection and does not eliminate the need for a dedicated secret store, because a compromised configuration file or unauthorized read could expose sensitive values. Key Vault, by contrast, offers role-based access control, audit logs, and integration with Azure DevOps and other Azure services, making it the proper choice for storing and retrieving secrets in a CI/CD pipeline.

Go deeper

Related to this question