Design and implement appropriate metrics and queries for DevOps

Wexford Capital has a GitHub Enterprise Cloud organization named wexford-cap with 140 repositories that have code scanning (GitHub Code Security), secret scanning (GitHub Secret Protection), and Dependabot alerts enabled. The CISO wants a single place to see open alert counts by severity across all repositories, filter to repositories owned by the payments team, and track how quickly alerts are remediated. Minimizing administrative effort is the deciding factor.

What should you use?

1. AThe Security tab of each repository, reviewed one repository at a timeThe repository Security tab shows alerts for that repository only, so reviewing 140 repositories individually gives no organization-wide view and takes significant effort.
2. BThe organization-level security overview, filtered by repository topic or custom property for the payments teamSecurity overview aggregates code scanning, secret scanning, and Dependabot alerts across the organization, supports filtering by repository topic, team, and custom property, and its overview dashboard shows alert trends and mean time to remediate.
3. CAn organization webhook for code_scanning_alert events that writes alerts to an Azure SQL database for reportingA webhook pipeline into a database could support custom reports, but it requires building and running an integration that duplicates built-in reporting.
4. DThe Insights tab of each repository, using the Dependency graph pageThe dependency graph lists a repository's dependencies; it does not summarize code scanning or secret scanning alerts across the organization.

Kingsbridge Telecom's site reliability team logs every production incident in an Azure DevOps project named NetCore as a Bug with the tag prod-incident. The operations manager wants a shared query, used by a Query Tile widget on the operations dashboard, that always counts prod-incident Bugs created in the last 30 days as a rolling window, regardless of their current state. The query must never need manual edits.

Which query clauses should you use?

1. AWork Item Type = Bug, Tags Contains prod-incident, and Created Date >= @StartOfMonth@StartOfMonth resets on the first day of each calendar month, so early in a month the query covers only a few days rather than a rolling 30-day window.
2. BWork Item Type = Bug, Tags Contains prod-incident, State = Active, and Created Date >= @Today - 30Adding State = Active drops incidents that were already resolved or closed, but the manager wants every incident regardless of current state.
3. CWork Item Type = Bug, Tags Contains prod-incident, and Created Date >= @Today - 30@Today - 30 is evaluated each time the query runs, producing a rolling 30-day window on the creation date, and no state clause means all incidents are counted.
4. DWork Item Type = Bug, Tags Contains prod-incident, and Changed Date >= @Today - 30Changed Date updates whenever anyone edits the Bug, so older incidents that receive a comment would be counted and the metric would no longer reflect incidents created in the window.

Saltmarsh Media deploys a streaming API named sm-playback with GitHub Actions to production environments. The VP of Engineering wants a delivery scorecard that follows the current DORA software delivery performance model and reports throughput, meaning how often and how quickly the team ships changes, separately from instability metrics such as change fail rate.

Which two of the following metrics belong in the throughput section of the scorecard? Each correct answer presents part of the solution.

1. ADeployment frequency to productionDeployment frequency measures how often the team deploys to production and is one of the DORA throughput metrics.
2. BLead time for changes, from commit to running in productionChange lead time measures how long a change takes to go from committed to version control to deployed in production and is a DORA throughput metric.
3. CChange fail rateChange fail rate is the ratio of deployments that require immediate intervention, such as a rollback or hotfix, which DORA classifies as an instability metric, not throughput.
4. DSprint velocity in story pointsVelocity measures planned effort completed per sprint; it says nothing about how often or how fast changes reach production.
5. ECode coverage percentage of the main branchCode coverage is a quality indicator for tests and does not measure delivery speed or frequency.

Corvane Energy runs a YAML pipeline named meter-service-ci in Azure Pipelines that publishes unit and integration test results on every run. The QA lead wants a tile on the team dashboard that shows the test pass rate and the count of failed tests across pipeline runs for the last 30 days, so trends are visible at a glance. The solution must use a built-in widget.

Which widget should you add?

1. ABuild HistoryBuild History shows the outcome and duration of recent runs, but a run can fail for reasons other than tests and the widget does not report test pass rate.
2. BChart for Test PlansChart for Test Plans reports on manual test points and test case authoring in Azure Test Plans, not on automated results published by pipeline runs.
3. CRequirements QualityRequirements Quality shows test status for requirements linked to test cases, which does not give a pipeline-wide trend of automated test pass rate.
4. DTest Results Trend (Advanced)Test Results Trend (Advanced) uses Analytics data to chart pass rate, passed and failed test counts, and duration for selected build or release pipelines over a chosen period, with optional filters for branch, test file, and owner.