AZ-400 Develop a security and compliance plan 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.

• ✓

  Require approval for pipeline runs that use external resources

  Why this is correct

  Approvals on pipeline runs that consume external resources (e.g., packages from public feeds, or services outside the organization) prevent unauthorized or malicious use of those resources. By adding an approval gate, you ensure that every run touching external dependencies is explicitly authorized, reducing the risk of supply chain attacks like typosquatting or compromised upstream packages.

• ✓

  Use Dependabot to automatically update vulnerable dependencies

  Why this is correct

  Dependabot continuously monitors dependency manifests (e.g., package.json, requirements.txt, NuGet.config) and automatically opens pull requests to update vulnerable or outdated dependencies to patched versions. This reduces the window of exposure to known CVEs and ensures that the pipeline builds against secure dependency versions, a key supply chain hardening practice.

• ✗

  Implement code coverage thresholds in pull requests

  Why it's wrong here

  Code coverage thresholds enforce a minimum percentage of lines or branches exercised by tests during pull request validation. While valuable for maintaining test quality, it does not address the security of third-party dependencies, artifact integrity, or unauthorized pipeline resource usage, so it is not a supply chain security control.

• ✗

  Enable secret scanning for all repositories

  Why it's wrong here

  Secret scanning detects hard-coded credentials, API keys, and tokens in repositories and alerts admins or blocks commits to prevent leakage. Although secret hygiene is an important security safeguard, it does not mitigate risks from compromised dependencies, unsafe external resources, or untrusted pipeline steps, so it falls outside the scope of supply chain security.

• ✗

  Use release gates to validate deployment health

  Why it's wrong here

  Release gates (e.g., monitoring health metrics, incident alerts, or manual sign-offs) validate that a deployment is safe to promote to the next environment. They are operational quality checks for deployment health, not mechanisms to secure the supply chain against malicious or vulnerable artifacts entering the build or release process.

Go deeper

Related to this question