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.

• ✗

  Code scanning.

  Why it's wrong here

  Code scanning uses GitHub's CodeQL engine to perform static analysis over source code, modeling data flow and control flow to detect vulnerabilities like SQL injection, cross-site scripting, or unsafe deserialization. Its queries are oriented toward code patterns and taint paths, not toward recognizing high-entropy credential strings in files, so a committed Expo API key would not match any default rule set. Although a custom CodeQL query could theoretically be authored to search for token-like formats, that is not the purpose of the feature and would require substantial configuration, making code scanning an incorrect answer for automatic secret detection.

• ✗

  Dependabot.

  Why it's wrong here

  Dependabot is a supply-chain security tool that scans manifest and lock files—such as package.json, Gemfile.lock, or Pipfile—against vulnerability advisory databases and automatically opens pull requests to update dependencies containing known CVEs. Its scope is entirely limited to package versions and transitive dependency resolution; it never reads or analyzes the contents of application files, environment configuration, or credential material. Consequently, an Expo API key stored anywhere in the repository would be completely invisible to Dependabot, regardless of whether the key appears in a `.env` file or a constants module. Unlike secret scanning, Dependabot exists to keep libraries patched, not to prevent credential leakage.

• ✓

  Secret scanning.

  Why this is correct

  Secret scanning is GitHub's native security feature that applies pattern recognizers—curated definitions provided by GitHub and partner organizations—to identify known credential formats such as API keys, access tokens, OAuth secrets, and private keys across the repository, including new pushes and existing history. When an Expo API key is committed, secret scanning triggers an immediate alert and, if push protection is enabled for the repository, even blocks the push itself to prevent the secret from ever being stored. This detection is format-specific and proactive, giving organizations a chance to revoke the exposed key before attackers can exploit it, which is exactly the correct mechanism for identifying an exposed Expo API key.

• ✗

  GitHub Actions.

  Why it's wrong here

  GitHub Actions is an event-driven CI/CD engine that executes workflows on triggers such as push, pull_request, or schedule, typically to build, test, publish artifacts, or deploy applications. The platform does not include any intrinsic secret-detection capability; you would need to explicitly write a workflow step that runs a third-party scanner or contains custom grep-like logic to search for API keys, which is not a built-in behavior. In short, Actions gives you the building blocks to automate scans, but it is not the dedicated GitHub security feature that automatically detects an exposed Expo API key when it is pushed to a repository, so it is not the correct answer.

Go deeper

Related to this question