Task 3.6: Maintain pipelines

• AThe Pipeline duration report on the pipeline's Analytics tab

  Incorrect

  The duration report shows how long successful runs take, not which tasks fail.

• BThe Pipeline pass rate report on the pipeline's Analytics tab

  Correct

  The pass rate report shows the pass rate, the failure trend per day and the top failing tasks with their failed runs.

• CThe Pool consumption report of the agent pool, filtered to the pipeline's runs

  Incorrect

  Pool consumption charts running and queued jobs against parallel jobs; it doesn't break down failures.

• DThe organization's audit log, filtered to pipeline events from the last two weeks

  Incorrect

  The audit log records changes such as permissions and settings, not task failures.

Pipeline analytics on the Analytics tab includes the pass rate report, with the pass rate, a failure trend by day (split by stage) and the top failing tasks, the duration report, and the test failures report. The default range is 14 days.

• AA key made of the build ID so each run gets its own cache

  Incorrect

  A new key every run never hits, so nothing is reused.

• BA key that includes the operating system and package-lock.json

  Correct

  A file in the key is hashed, so the cache changes exactly when the lock file changes, per operating system.

• CA key of the static string npm only

  Incorrect

  A key that never changes keeps restoring the first cache after dependencies change.

• DA pipeline artifact of node_modules downloaded by each run

  Incorrect

  Artifacts aren't keyed on the lock file and add upload and download time to every run.

• ErestoreKeys with the same key minus the lock file part

  Correct

  A restore key matches by prefix and returns the most recent cache when the exact key misses.

The Cache task hashes files named in the key, such as a lock file, so a change produces a new key. restoreKeys lists fallback prefixes; the most recent cache that matches a prefix is restored when the exact key misses.

• ARaise the project's days to keep runs to 730

  Incorrect

  That keeps every run for two years, multiplying storage for runs that didn't need it.

• BAdd a step to the production stage that calls the Lease API to set a two-year retention lease on the run

  Correct

  A retention lease keeps that run beyond the policy, so only production runs are kept longer.

• CDownload each production run's logs to a file share after deployment

  Incorrect

  Exported files aren't the run, and the pipeline still deletes the run and its artifacts after 30 days.

• DMark the production branch as protected with a branch policy

  Incorrect

  Protected branches keep a number of latest runs, not every production run for two years.

Run retention policies delete runs after the configured days unless they are among the latest runs kept, marked for indefinite retention, or held by a retention lease. A pipeline can add a lease for a set duration through the Lease API, for example longer for production runs.

• ARe-create the stages as stages of a multi-stage YAML pipeline, since release pipelines can't be exported to YAML

  Correct

  Classic release pipelines don't support YAML export, so the stages and their tasks are re-created in YAML.

• BUse Export to YAML on the release pipeline and commit the downloaded file

  Incorrect

  Export to YAML is available only for classic build pipelines.

• CAdd the approvals to the YAML file with an approvals keyword on each stage

  Incorrect

  Approvals aren't defined in YAML; resource owners configure them as checks.

• DKeep the gates in the classic pipeline and trigger it from YAML

  Incorrect

  That leaves the classic pipeline in place instead of migrating it.

• ERe-create the approvals and the gate as checks on the environments that the deployment jobs target

  Correct

  In YAML, approvals and gates become checks owned by the environments' administrators.

Only classic build pipelines can be exported to YAML; release pipelines have to be rebuilt, typically as a multi-stage YAML pipeline. Approvals and gates in YAML are configured as checks on resources such as environments, not in the YAML file.

• AYes, because the cache key matches

  Incorrect

  Matching keys let it read, but writes into the target branch's scope aren't allowed.

• BYes, but only after the PR is approved

  Incorrect

  Approval doesn't change cache scopes.

• CNo, PR jobs can read the target branch's caches but can't write there

  Correct

  Cache scopes stop pull requests from creating caches in the target branch.

• DNo, PR jobs can't read any cache at all

  Incorrect

  They can read caches from the target branch.

Every cache is stored in a scope that acts as a security boundary. Jobs building pull requests can read caches from the target branch of the same pipeline but can't write caches into the target branch's scope.

• AThe four failed runs, because they're the most recent

  Incorrect

  Failed runs don't count toward the retained latest runs.

• BEvery run, whatever its result

  Incorrect

  Only succeeded and partially succeeded runs are retained.

• CNone, because the days setting overrides the count

  Incorrect

  The count keeps runs beyond the days setting.

• DSucceeded and partially succeeded runs only

  Correct

  The latest-runs setting retains only succeeded and partially succeeded runs.

Run retention keeps a configured number of latest runs, and it retains only succeeded and partially succeeded runs.

• AA shallow fetch on every pipeline

  Incorrect

  Fetch settings don't remove working directories that earlier runs left behind.

• BA shorter run retention in project settings

  Incorrect

  Run retention deletes runs on the server, not files on agents.

• CMore agents in the pool

  Incorrect

  More agents spread the problem; each still fills its disk.

• DA maintenance job schedule in the agent pool's settings

  Correct

  Maintenance jobs clean stale working directories and repositories, but only when a window is scheduled.

Agent pools can run maintenance jobs that periodically clean stale working directories and repositories to stop agents running out of disk space. If no maintenance window is scheduled, the agents don't run it.

• AThe last 24 hours

  Incorrect

  The default range is longer.

• BThe last 90 days

  Incorrect

  That isn't the default.

• CEvery run since the pipeline was created

  Incorrect

  Reports cover a period, defaulting to 14 days.

• DThe last 14 days

  Correct

  The reports default to 14 days, and you can change the range.

The Pipeline pass rate, duration and test failures reports show data for the last 14 days by default, and a filter changes the range.