AZ-400 Practice Question: Design and implement a source control strategy

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 tools like GitLeaks to scan for accidentally committed secrets

  Why this is correct

  GitLeaks and similar secret-scanning tools inspect repository history, staging areas, and CI/CD diffs for high-entropy strings and known provider patterns (e.g., AWS Access Key IDs, GitHub tokens). They are typically run as a pre-commit hook or a separate pipeline stage, so leaks are caught early before they propagate to forks or downstream branches. This is a detection control, not a prevention control; it complements secure storage options by providing visibility and enforcing policy on legacy codebases.

• ✗

  Store secrets in a separate encrypted file committed to the repository

  Why it's wrong here

  Committing an encrypted secrets file is fundamentally flawed because the ciphertext remains accessible to anyone with repository access, and the encryption key must be distributed via another channel, effectively recreating the problem of key management. Additionally, encrypted files are opaque to static analysis, so a misconfigured commit that includes plaintext or a weak-passphrase unknown to CI will break the build or be unprotected. Even with strong encryption, secrets in git history persist forever, and if the repo or a clone is compromised, the attacker can exfiltrate the encrypted blob and attack the key offline.

• ✓

  Use GitHub Secrets or Azure Pipelines secret variables

  Why this is correct

  GitHub Secrets and Azure Pipelines secret variables are encrypted at rest and only decrypted into the pipeline agent's environment during execution, with logging redaction of the values. They support per-environment and per-branch scoping, rotation through UI or REST APIs, and are never written to source control or build artifacts. However, they are appropriate for build/release-time parameters, not for application runtime secrets; those should come from a dedicated vault such as Key Vault, which adds centralized access policy and auditability.

• ✓

  Use Azure Key Vault to store and retrieve secrets at build/release time

  Why this is correct

  Azure Key Vault provides a centralized, hardware-backed secret store where access is governed by Azure Active Directory identities and policies, with full audit logs of every read and write. In Azure Pipelines, you can either use the Key Vault task to download secrets into pipeline variables or bind a variable group to a Key Vault, allowing secrets to be fetched at build/release time without being stored in pipeline configuration. This enables automatic rotation: update the secret in the vault and subsequent pipeline runs automatically retrieve the new value, eliminating the need to edit pipeline definitions or redeploy code.

• ✗

  Commit a .env file with default values to the repository

  Why it's wrong here

  Committing a .env file, even with only default or placeholder values, normalizes the anti-pattern of storing configuration alongside code and risks accidental inclusion of real credentials when the file is modified locally and never re-ignored. Because .env files are auto-loaded by many frameworks (e.g., dotenv), a committed file can silently override environment variables in production or testing, causing incorrect behavior or exposing non-default secrets. The only safe alternative is to commit a .env.example with clearly non-secret placeholders and rely on environment-specific secrets injected from a secret store.

Go deeper

Related to this question