Azure AZ-400 key terms

A work tracking service in Azure DevOps that holds epics, features, user stories, bugs, and tasks. Teams use boards, backlogs, and sprint views to plan and monitor work against iterations.

Two classification fields on Azure Boards work items. Area paths group work by product or team ownership, while iteration paths place work into sprints or milestones used for scheduling and burndown reporting.

An Azure Boards view that shows work items from several teams side by side on a calendar. It helps stakeholders spot cross-team dependencies and confirm that milestones line up.

Event subscriptions in Azure DevOps that push notifications to external systems, such as Teams or a webhook endpoint, when a build completes, a pull request changes, or a work item is updated.

A version-controlled documentation area inside Azure DevOps. Pages are stored in a Git repository, so teams can review documentation changes through pull requests and keep runbooks next to code.

Rules enforced on a branch in Azure Repos or GitHub that block direct pushes and set conditions for merging, such as required reviewers, a linked work item, or a passing build.

A request to merge changes from one branch into another, giving reviewers a place to comment, run validation builds, and approve before the merge happens.

A branching model where engineers commit small changes to a single shared main branch at least daily, using short-lived feature branches and feature flags to hide unfinished work.

A branching model with long-lived develop and main branches plus feature, release, and hotfix branches. It suits scheduled releases but creates merge-heavy history and slows continuous delivery.

A collaboration model where contributors push to their own copy of a repository and open pull requests back to the upstream project. Common in open source and across organizations that do not share write access.

A file that maps paths in a repository to individuals or teams. Platforms automatically request reviews from the matching owners when a pull request touches those paths.

A merge option that combines all commits from a pull request into one new commit on the target branch, keeping history linear and letting the pull request title become the commit message.

A named pointer to a specific commit, typically used to mark released versions. Annotated tags carry metadata and are the usual trigger for publishing a release build.

A build or deployment definition stored as a YAML file in the repository next to the code. Because it is versioned, pipeline changes follow the same review process as application changes.

A pipeline with several named stages, such as build, test, and deploy, that run in sequence or in parallel. Stages can target different environments and be gated by approvals or checks.

A collection of machines, hosted by Microsoft or self-managed, that run pipeline jobs. Pools let administrators control which agents a pipeline may use and how much concurrency is available.

Files and packages published during a run and downloaded by later stages or jobs. Artifacts decouple building once from deploying many times, so the same binaries reach every environment.

A special pipeline job that runs against an environment and can apply deployment strategies. It records deployment history and supports hooks such as pre-deploy manual validation and rollback of the previous run.

A named deployment target that groups the resources a pipeline deploys to, such as Kubernetes namespaces or virtual machines. Environments hold deployment history and the checks that gate them.

Conditions evaluated before a stage or environment deployment starts. Examples include manual approval by named users, branch control, business hours, and calls to an external service.

A reusable set of pipeline variables stored in the library and shared across pipelines. Groups can link to an Azure Key Vault so secrets are fetched at run time instead of hardcoded.

A reusable YAML file that other pipelines include to share stages, jobs, or steps. Templates enforce organization standards and can require parameters, reducing copy-paste across many repositories.

A stored, authenticated link from Azure DevOps to an external service such as Azure, GitHub, or Docker Hub. Pipelines use it to deploy or fetch resources without embedding credentials.

A release strategy that sends a small slice of live traffic to the new version while most users stay on the old one. Metrics are watched before the rollout widens or is reverted.

A rule that decides when a pipeline run starts, such as a commit to a branch, a schedule, or the completion of another pipeline. Triggers automate continuous integration and chained deployments.

Automated detection of credentials, tokens, and keys committed to a repository. Alerts let teams revoke the exposed secret and remove it from history before it is abused.

A static analysis engine that queries a codebase for security weaknesses such as injection flaws. In GitHub, results appear as code scanning alerts and can block pull requests.

A GitHub service that watches dependency manifests, raises alerts for known vulnerabilities, and opens pull requests that upgrade affected packages to safe versions.

A trust relationship that lets a pipeline exchange its own short-lived identity token for cloud access, removing the need to store a client secret or service principal password.

A scoped credential a user creates to authenticate scripts and tools against Azure DevOps or GitHub. Because it acts as the user, it should be short-lived and limited to the minimum scopes.

A managed service for storing secrets, certificates, and encryption keys with access control and auditing. Pipelines and applications retrieve values at run time rather than storing them in code.

A feature that exports Azure DevOps audit events, such as permission changes and policy edits, to a storage or monitoring sink for long-term retention and investigation.

A cloud security posture service that also surfaces DevOps security findings, including exposed secrets and infrastructure-as-code misconfigurations, from connected repositories into one dashboard.

A deployment check that verifies the pipeline run originated from an allowed branch and repository before releasing to a protected environment, blocking deployments from unapproved source.

An application performance monitoring service in Azure Monitor that collects requests, dependencies, exceptions, and custom telemetry from running applications to support diagnosis and alerting.

A technique that follows a single request across services by propagating a shared operation identifier, so a slow or failing call can be located in the full chain of dependencies.

A telemetry reduction technique that keeps only a percentage of traces while preserving correlation, lowering ingestion cost and traffic from high-volume applications without losing statistical insight.

A synthetic check that calls an endpoint from multiple locations on a schedule and alerts when responses fail or slow down, detecting outages even when no real user traffic arrives.

Kusto Query Language, the read-only query syntax used by Azure Monitor logs and Log Analytics. Engineers write it to filter, summarize, and chart telemetry for workbooks and alert rules.

A reusable list of notification and automation targets, such as email, SMS, webhook, or runbook, that an Azure Monitor alert fires when its condition is met.