Automatic Dependabot Scan Triggers from a Dependency Graph Change or a New Advisory
You manage code by using GitHub. You plan to use Dependabot to scan for code dependencies. You need to identify when scanning will be triggered automatically. Which two actions will trigger a scan? Each correct answer presents a complete solution. NOTE: Each correct solution is worth one point.
Community Votes
100% of anonymous learners picked answer AE. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
Dependabot alerts are triggered when the dependency graph of a repository changes, such as when a dependency is added or updated, and when a new advisory is added to the GitHub Advisory Database. Pull requests, forks, and plain commits are not scan triggers.
Code is managed on GitHub and Dependabot will scan for vulnerable code dependencies, so the triggers that cause a scan to run automatically must be identified. Dependabot alerts are driven by the state of the dependency graph and by newly published vulnerability data, not by ordinary source control activity.
Treating ordinary development activity as a scan trigger. Creating a pull request, forking a branch, or pushing any commit are all normal source control events, and most commits touch no dependency declaration at all, so none of them causes Dependabot to rescan.
Community Discussion (3 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
Dependabot alerts answer two questions: whether the repository depends on something newly known to be vulnerable, and whether the code has started depending on something vulnerable. The first is driven by new vulnerability information entering the GitHub Advisory Database, and the second is driven by a change in what the repository depends on, so both the dependency graph changing and a new advisory being added are automatic scan triggers. The vote was unanimous at 100 for A and E. freddyneen, the highest-liked commenter, linked the Dependabot alerts documentation section on detection of insecure dependencies, which lists exactly these triggers, and Alandt restated the same two mechanisms in plain terms.Why the Other Options Are Wrong
Creating a pull request (B) is ordinary development activity. Even if the pull request changes a manifest, the alert condition is the dependency graph state rather than the pull request itself, so a pull request is not a Dependabot scan trigger. Forking a branch (C) does not change what the repository depends on and has no effect on scanning, and a fork is frequently done for experimental work that is never merged. Pushing any commit (D) is the broadest of the distractors, since most commits touch no dependency declaration at all, so commit pushes cannot be a trigger for vulnerability scanning. In all three cases, a scan may eventually follow from a resulting dependency graph change, but the commit, pull request, or fork is not itself the trigger the question asks about.Community Comment Notes
The community was unanimous at 100 for A and E, and the two substantive comments converge on the same authoritative source. freddyneen linked the Dependabot alerts documentation on detection of insecure dependencies, which enumerates the automatic triggers. Alandt gave the most explanatory account, describing both the dependency graph change on adding or updating dependencies and the check that runs when a new advisory is added to the GitHub Advisory Database. The absence of any counter-comment is consistent with a question whose answer is a direct lookup from documented behavior rather than a judgment call.Official Reference
Related Analysis
Practice All AZ-400 Questions
Access 100 questions with complete answers and detailed explanations.
View Full AZ-400 Practice Test →