Exam Domain
A major section of the exam covering related topics.
Getting Started: Your AZ-400 Journey
Free knowledge base
Microsoft Certified: DevOps Engineer Expert — key terms, tricks & tips
Everything from the course in one searchable place: 313 entries. Use it to review before a practice test or look up a word you forgot.
313 results · showing first 300, refine your search
Objective
A specific skill or knowledge area tested on the exam.
Getting Started: Your AZ-400 Journey
Weighting
Percentage indicating question proportion from a domain.
Getting Started: Your AZ-400 Journey
Case Study
Exam question format presenting a business scenario.
Getting Started: Your AZ-400 Journey
Lab Simulation
Interactive exam task performed in a simulated environment.
Getting Started: Your AZ-400 Journey
Passing Score
Minimum score (700/1000) required to pass the exam.
Getting Started: Your AZ-400 Journey
Retake Policy
Rules governing reattempting a failed certification exam.
Getting Started: Your AZ-400 Journey
Understanding the AZ-400 Exam Structure & Objectives
DOMAINS have WEIGHTS, OBJECTIVES are your GOALS. QUESTIONS come in FORMS, and 700 is the PASSING SCORE. Remember D-W-O-G-Q-F-P-S!
Getting Started: Your AZ-400 Journey
Understanding the AZ-400 Exam Structure & Objectives
The AZ-400 exam objectives are dynamic. Always check the official Microsoft Learn page for the latest exam skills outline. Keywords like 'design,' 'implement,' and 'manage' indicate practical, hands-on knowledge is required.
Getting Started: Your AZ-400 Journey
Understanding the AZ-400 Exam Structure & Objectives
Studying outdated exam objectives and weightings.
Getting Started: Your AZ-400 Journey
Understanding the AZ-400 Exam Structure & Objectives
Focusing solely on theoretical knowledge without hands-on practice.
Getting Started: Your AZ-400 Journey
Understanding the AZ-400 Exam Structure & Objectives
Ignoring the different question formats, especially case studies and labs.
Getting Started: Your AZ-400 Journey
Azure DevOps Organization
Top-level container for projects and users.
Getting Started: Your AZ-400 Journey
Azure DevOps Project
Workspace for a specific development effort.
Getting Started: Your AZ-400 Journey
Work Item Process
Defines how work items are tracked (e.g., Agile).
Getting Started: Your AZ-400 Journey
Version Control
System for managing changes to code (e.g., Git).
Getting Started: Your AZ-400 Journey
Service Connection
Secure link to external services like Azure.
Getting Started: Your AZ-400 Journey
Least Privilege
Granting only necessary permissions to users.
Getting Started: Your AZ-400 Journey
Azure Active Directory
Microsoft's cloud-based identity and access management.
Getting Started: Your AZ-400 Journey
Setting Up Your Azure DevOps Environment
ORG-PRO-BRP-TA: Organization, Project, Boards, Repos, Pipelines, Test Plans, Artifacts – the core hierarchy and services!
Getting Started: Your AZ-400 Journey
Setting Up Your Azure DevOps Environment
The AZ-400 exam expects you to know the hierarchy: Azure Tenant > Azure AD > Azure DevOps Organization > Project. Be familiar with the purpose of each core service within a project (Boards, Repos, Pipelines, Test Plans, Artifacts) and the implications of choosing a region for your organization.
Getting Started: Your AZ-400 Journey
Setting Up Your Azure DevOps Environment
Not selecting the correct region for data residency during organization creation, leading to compliance issues.
Getting Started: Your AZ-400 Journey
Setting Up Your Azure DevOps Environment
Granting overly broad permissions to users or groups instead of adhering to the principle of least privilege.
Getting Started: Your AZ-400 Journey
Setting Up Your Azure DevOps Environment
Choosing an inappropriate version control system or work item process that doesn't fit the team's workflow.
Getting Started: Your AZ-400 Journey
Azure Boards
Agile tools in Azure DevOps for planning, tracking, and discussing work.
Module 1: Mastering DevOps Processes & Communication
Work Item
Fundamental unit for tracking work in Azure Boards (e.g., Epic, Feature, User Story).
Module 1: Mastering DevOps Processes & Communication
Branching Strategy
Rules for using branches in version control to manage code changes.
Module 1: Mastering DevOps Processes & Communication
GitFlow
Structured branching model with master, develop, feature, release, hotfix branches.
Module 1: Mastering DevOps Processes & Communication
GitHub Flow
Lightweight strategy where main is always deployable; short-lived feature branches.
Module 1: Mastering DevOps Processes & Communication
GitLab Flow
Extends GitHub Flow with environment or release branches for CI/CD.
Module 1: Mastering DevOps Processes & Communication
Branch Policies
Rules enforced on branches (e.g., PR review, build validation) to ensure quality.
Module 1: Mastering DevOps Processes & Communication
Pull Request (PR)
Mechanism to propose changes, review code, and merge a branch into another.
Module 1: Mastering DevOps Processes & Communication
Agile Work Management & Branching in Azure DevOps
To remember the flows: GitHub Flow is 'Go Fast' (simple, deploy often). GitLab Flow is 'Go Live' (more structure for environments). GitFlow is 'Go Formal' (structured, complex releases).
Module 1: Mastering DevOps Processes & Communication
Agile Work Management & Branching in Azure DevOps
The exam often presents scenarios where you must choose the most appropriate branching strategy. Look for keywords like 'continuous delivery,' 'daily deployments' (suggesting GitHub Flow/GitLab Flow) or 'scheduled releases,' 'multiple versions,' 'long-term support' (suggesting GitFlow). Also, know the purpose of Azure Boards' components.
Module 1: Mastering DevOps Processes & Communication
Agile Work Management & Branching in Azure DevOps
Using GitFlow for a continuous delivery project, leading to unnecessary overhead and slower releases.
Module 1: Mastering DevOps Processes & Communication
Agile Work Management & Branching in Azure DevOps
Not enforcing branch policies (like required reviews or build validations), which can lead to unstable code being merged into main branches.
Module 1: Mastering DevOps Processes & Communication
Agile Work Management & Branching in Azure DevOps
Creating long-lived feature branches without frequent integration, resulting in complex merge conflicts.
Module 1: Mastering DevOps Processes & Communication
Branch Policy
Rules enforced on a branch to maintain code quality and consistency.
Module 1: Mastering DevOps Processes & Communication
Code Review
Systematic examination of computer source code by peers.
Module 1: Mastering DevOps Processes & Communication
Versioning
Assigning unique identifiers to different states of software.
Module 1: Mastering DevOps Processes & Communication
Semantic Versioning (SemVer)
MAJOR.MINOR.PATCH versioning scheme indicating change types.
Module 1: Mastering DevOps Processes & Communication
MAJOR Version
Incremented for incompatible API changes.
Module 1: Mastering DevOps Processes & Communication
MINOR Version
Incremented for new, backward-compatible features.
Module 1: Mastering DevOps Processes & Communication
PATCH Version
Incremented for backward-compatible bug fixes.
Module 1: Mastering DevOps Processes & Communication
Implementing Effective Pull Request & Versioning Strategies
PR-V: 'P'ull 'R'equests 'V'alidate code. Remember to 'V'alidate your PRs!
Module 1: Mastering DevOps Processes & Communication
Implementing Effective Pull Request & Versioning Strategies
On the exam, pay close attention to questions involving Azure DevOps branch policies. You'll need to know which types of policies can be configured (e.g., minimum reviewers, build validation, linked work items, comment resolution) and how they contribute to code quality and compliance.
Module 1: Mastering DevOps Processes & Communication
Implementing Effective Pull Request & Versioning Strategies
Merging pull requests without proper review or automated checks, leading to bugs in the main branch.
Module 1: Mastering DevOps Processes & Communication
Implementing Effective Pull Request & Versioning Strategies
Creating large, long-lived pull requests that are difficult and time-consuming to review.
Module 1: Mastering DevOps Processes & Communication
Implementing Effective Pull Request & Versioning Strategies
Inconsistent or absent versioning, making it hard to track releases and manage dependencies.
Module 1: Mastering DevOps Processes & Communication
Continuous Delivery
Software changes are always in a releasable state, ready for production.
Module 1: Mastering DevOps Processes & Communication
Blue/Green Deployment
Two identical environments, switch traffic between them for zero downtime.
Module 1: Mastering DevOps Processes & Communication
Canary Release
Gradually roll out new software to a small subset of users.
Module 1: Mastering DevOps Processes & Communication
Feature Flag
Toggle features on/off without deploying new code.
Module 1: Mastering DevOps Processes & Communication
Rolling Update
Update application instances incrementally, one by one.
Module 1: Mastering DevOps Processes & Communication
Dark Launch
Release a feature to production but keep it hidden from users.
Module 1: Mastering DevOps Processes & Communication
Rollback
Reverting to a previous, stable version of the application.
Module 1: Mastering DevOps Processes & Communication
Designing Robust Release Strategies for Continuous Delivery
Imagine a 'Blue' ocean and 'Green' forest. You switch between them for a fresh view (new version). A 'Canary' bird tests the air for danger before you enter the mine (new feature). A 'Feature Flag' is like a light switch for a room (feature).
Module 1: Mastering DevOps Processes & Communication
Designing Robust Release Strategies for Continuous Delivery
The exam emphasizes understanding the *purpose* and *benefits* of each strategy. Keywords like 'zero downtime', 'gradual rollout', 'risk mitigation', and 'decoupling deployment from release' are critical to associate with their respective patterns.
Module 1: Mastering DevOps Processes & Communication
Designing Robust Release Strategies for Continuous Delivery
Confusing Blue/Green with Canary: Blue/Green switches all traffic at once (after testing), Canary gradually introduces traffic.
Module 1: Mastering DevOps Processes & Communication
Designing Robust Release Strategies for Continuous Delivery
Not having a rollback plan: Every release strategy, no matter how robust, needs a clear and tested rollback procedure.
Module 1: Mastering DevOps Processes & Communication
Designing Robust Release Strategies for Continuous Delivery
Overlooking monitoring: Without robust monitoring, you can't effectively evaluate the success or failure of a release strategy.
Module 1: Mastering DevOps Processes & Communication
Communication Workflow
Defined sequence of interactions and tools for information exchange.
Module 1: Mastering DevOps Processes & Communication
Transparency
Openness and visibility of information across all team members.
Module 1: Mastering DevOps Processes & Communication
Feedback Loop
Systematic process for receiving and acting on information.
Module 1: Mastering DevOps Processes & Communication
Silo
Isolation between teams or departments, hindering collaboration.
Module 1: Mastering DevOps Processes & Communication
Post-mortem
Review after an incident to identify causes and prevent recurrence.
Module 1: Mastering DevOps Processes & Communication
Retrospective
Meeting to reflect on a period of work and identify improvements.
Module 1: Mastering DevOps Processes & Communication
Shared Understanding
Common knowledge and perspective across team members.
Module 1: Mastering DevOps Processes & Communication
Establishing Clear Communication & Collaboration Workflows
To remember key communication tools, think 'CHAT-DOCS-CODE-TRACK': Chat for quick talks, Docs for knowledge, Code for collaboration, Track for tasks.
Module 1: Mastering DevOps Processes & Communication
Establishing Clear Communication & Collaboration Workflows
The AZ-400 exam often tests your ability to select the RIGHT communication tool for a specific scenario. Look for keywords like 'real-time discussion,' 'structured documentation,' 'code review,' or 'incident response' to guide your tool choice (e.g., Teams, Wiki, Pull Requests, dedicated chat channel).
Module 1: Mastering DevOps Processes & Communication
Establishing Clear Communication & Collaboration Workflows
Relying solely on informal, ad-hoc communication channels, leading to lost information and misunderstandings.
Module 1: Mastering DevOps Processes & Communication
Establishing Clear Communication & Collaboration Workflows
Not documenting critical decisions or architectural changes, causing confusion for new team members or future reference.
Module 1: Mastering DevOps Processes & Communication
Establishing Clear Communication & Collaboration Workflows
Failing to establish clear escalation paths for issues, resulting in delays during critical incidents.
Module 1: Mastering DevOps Processes & Communication
TFVC
Team Foundation Version Control, a centralized version control system.
Module 2: Designing & Implementing Source Control
Git-SVN
A Git command to interact with Subversion repositories.
Module 2: Designing & Implementing Source Control
Big Bang Migration
Moving all data at once; faster but higher risk.
Module 2: Designing & Implementing Source Control
Phased Migration
Moving data incrementally; slower but lower risk.
Module 2: Designing & Implementing Source Control
OAuth
Open standard for access delegation, often used for integrations.
Module 2: Designing & Implementing Source Control
PAT (Personal Access Token)
A token used for authentication to access services.
Module 2: Designing & Implementing Source Control
Source Control Migration & Integration
To remember migration strategies: 'Big Bang' is a quick, risky explosion; 'Phased' is like eating an elephant one bite at a time.
Module 2: Designing & Implementing Source Control
Source Control Migration & Integration
The exam often tests your knowledge of how to migrate from TFVC to Git and how to integrate GitHub/Bitbucket with Azure Pipelines using Service Connections. Look for keywords like 'migrate existing TFVC', 'connect to external Git repository', or 'GitHub service connection'.
Module 2: Designing & Implementing Source Control
Source Control Migration & Integration
Forgetting to preserve historical data during migration, leading to lost commit history.
Module 2: Designing & Implementing Source Control
Source Control Migration & Integration
Not testing the migrated repositories and pipelines thoroughly, causing production issues.
Module 2: Designing & Implementing Source Control
Source Control Migration & Integration
Ignoring team communication and training, resulting in resistance and confusion after migration.
Module 2: Designing & Implementing Source Control
Build Agent
A computing resource executing CI/CD pipeline jobs.
Module 2: Designing & Implementing Source Control
Agent Pool
A logical grouping of build agents with shared capabilities.
Module 2: Designing & Implementing Source Control
Demand
A condition an agent must meet to run a specific job.
Module 2: Designing & Implementing Source Control
Microsoft-Hosted Agent
Agents managed by Microsoft, pre-configured with common tools.
Module 2: Designing & Implementing Source Control
Self-Hosted Agent
Agents managed by the user, offering custom environments.
Module 2: Designing & Implementing Source Control
Parallelism
The number of jobs that can run concurrently in an organization.
Module 2: Designing & Implementing Source Control
VM Scale Set
Azure service for managing a group of identical, auto-scaling VMs.
Module 2: Designing & Implementing Source Control
Building & Managing Robust Build Infrastructure
HOST (Hosted) vs. SELF (Self-hosted): Hosted are easy, Self are custom. Remember the 'S' for 'Security' and 'Scaling' when thinking about self-hosted agents.
Module 2: Designing & Implementing Source Control
Building & Managing Robust Build Infrastructure
On the AZ-400 exam, be prepared to distinguish between Microsoft-hosted and self-hosted agents, knowing when to use each. Also, understand agent pools, demands, and scaling strategies like VM Scale Sets.
Module 2: Designing & Implementing Source Control
Building & Managing Robust Build Infrastructure
Not understanding when to use self-hosted agents, leading to pipeline failures due to missing tools or network access.
Module 2: Designing & Implementing Source Control
Building & Managing Robust Build Infrastructure
Neglecting to secure self-hosted agents, potentially exposing sensitive code or credentials.
Module 2: Designing & Implementing Source Control
Building & Managing Robust Build Infrastructure
Under-provisioning agents, causing long build queues and slow feedback loops for developers.
Module 2: Designing & Implementing Source Control
Azure Pipelines
Cloud service for CI/CD to build, test, and deploy code.
Module 2: Designing & Implementing Source Control
Agent
Compute infrastructure that executes jobs in a pipeline.
Module 2: Designing & Implementing Source Control
Job
A unit of work that runs on an agent within a stage.
Module 2: Designing & Implementing Source Control
Task
A script or built-in operation executed as part of a job.
Module 2: Designing & Implementing Source Control
Artifact
Files produced by a build, such as binaries or test results.
Module 2: Designing & Implementing Source Control
Caching
Storing frequently used data to speed up subsequent builds.
Module 2: Designing & Implementing Source Control
Conditional Execution
Running tasks or jobs only when specific criteria are met.
Module 2: Designing & Implementing Source Control
Crafting Efficient Build Pipelines for CI/CD
Remember 'PAC' for Pipeline Optimization: Parallelize, Agent Pools, Caching. These three are your go-to for faster builds!
Module 2: Designing & Implementing Source Control
Crafting Efficient Build Pipelines for CI/CD
The exam often tests your knowledge of optimizing pipeline performance. Look for keywords like 'reduce build time,' 'cost efficiency,' or 'faster feedback loop.' Be prepared to identify which pipeline features (e.g., parallel jobs, caching, self-hosted agents) address these goals.
Module 2: Designing & Implementing Source Control
Crafting Efficient Build Pipelines for CI/CD
Running all pipeline tasks sequentially even when they are independent, leading to unnecessarily long build times.
Module 2: Designing & Implementing Source Control
Crafting Efficient Build Pipelines for CI/CD
Not using caching for dependencies, causing agents to download the same packages repeatedly on every build.
Module 2: Designing & Implementing Source Control
Crafting Efficient Build Pipelines for CI/CD
Using Microsoft-hosted agents for highly specialized or resource-intensive builds that would be more cost-effective on self-hosted agents.
Module 2: Designing & Implementing Source Control
Package Manager
Tool to automate installation, upgrade, configuration of software packages.
Module 2: Designing & Implementing Source Control
Package Feed
Repository storing software packages, either public or private.
Module 2: Designing & Implementing Source Control
Azure Artifacts
Azure DevOps service for managing and hosting various package types.
Module 2: Designing & Implementing Source Control
Upstream Source
A public feed configured to proxy and cache packages within a private feed.
Module 2: Designing & Implementing Source Control
Dependency Hell
Conflict arising from different software components requiring incompatible versions of a shared dependency.
Module 2: Designing & Implementing Source Control
NuGet
The package manager for the .NET ecosystem.
Module 2: Designing & Implementing Source Control
npm
The default package manager for Node.js and JavaScript.
Module 2: Designing & Implementing Source Control
Implementing & Managing Package Management Solutions
To remember the key benefits of package management: 'C.A.R.E.': Consistent builds, Automated dependencies, Reusable components, Easy sharing.
Module 2: Designing & Implementing Source Control
Implementing & Managing Package Management Solutions
The AZ-400 exam frequently tests your knowledge of Azure Artifacts. Pay close attention to how to configure upstream sources, manage feed permissions (Reader, Contributor, Owner), and differentiate between project-scoped and organization-scoped feeds.
Module 2: Designing & Implementing Source Control
Implementing & Managing Package Management Solutions
Not using private feeds for internal components, leading to manual copying and versioning issues.
Module 2: Designing & Implementing Source Control
Implementing & Managing Package Management Solutions
Failing to configure upstream sources, resulting in slower builds and direct exposure to public feed outages.
Module 2: Designing & Implementing Source Control
Implementing & Managing Package Management Solutions
Granting overly broad permissions to package feeds, creating security vulnerabilities for proprietary code.
Module 2: Designing & Implementing Source Control
Implementing & Managing Package Management Solutions
Ignoring semantic versioning, which leads to unpredictable behavior when updating dependencies.
Module 2: Designing & Implementing Source Control
A/B Testing
Comparing two versions of a feature/app with different user segments.
Module 3: Designing & Implementing Pipelines
Dark Launching
Deploying features hidden from users, enabled by feature flags.
Module 3: Designing & Implementing Pipelines
Deployment Slot
Pre-configured environment for Azure App Services, used for staging/swapping.
Module 3: Designing & Implementing Pipelines
Advanced Release Strategy Design & Management
Remember 'Canary in a Coal Mine' for Canary releases – a small test group warns of danger before it's too late for everyone.
Module 3: Designing & Implementing Pipelines
Advanced Release Strategy Design & Management
The exam often asks you to choose the BEST deployment strategy for a given scenario. Look for keywords like 'minimal downtime' (Blue/Green), 'risk mitigation for new features' (Canary, Dark Launch), or 'comparing user experience' (A/B Testing). Understand the resource implications of each.
Module 3: Designing & Implementing Pipelines
Advanced Release Strategy Design & Management
Not having adequate monitoring in place for Canary releases, making it impossible to detect issues quickly.
Module 3: Designing & Implementing Pipelines
Advanced Release Strategy Design & Management
Underestimating the infrastructure costs for Blue/Green deployments, especially for large applications.
Module 3: Designing & Implementing Pipelines
Advanced Release Strategy Design & Management
Failing to properly test the traffic switching mechanism in Blue/Green deployments, leading to unexpected downtime during the swap.
Module 3: Designing & Implementing Pipelines
Release Gate
Automated quality check in a release pipeline that evaluates conditions.
Module 3: Designing & Implementing Pipelines
Pre-deployment Gate
Gate that runs before a release is deployed to an environment.
Module 3: Designing & Implementing Pipelines
Post-deployment Gate
Gate that runs after a release has been deployed to an environment.
Module 3: Designing & Implementing Pipelines
Azure Monitor Alerts Gate
Built-in gate type checking for active alerts in Azure Monitor.
Module 3: Designing & Implementing Pipelines
Invoke Azure Function Gate
Built-in gate type executing custom logic via an Azure Function.
Module 3: Designing & Implementing Pipelines
Sampling Interval
Frequency at which a gate re-evaluates its conditions.
Module 3: Designing & Implementing Pipelines
Gate Timeout
Maximum duration a gate will wait for conditions to pass.
Module 3: Designing & Implementing Pipelines
Setting Up & Managing Release Gates for Quality Assurance
Pre-deployment is 'Prevent' bad releases. Post-deployment is 'Prove' good releases.
Module 3: Designing & Implementing Pipelines
Setting Up & Managing Release Gates for Quality Assurance
The exam frequently tests your ability to choose the correct gate type for a given scenario. Pay close attention to whether the check needs to happen before or after deployment, and what kind of external service or data source is involved. For example, 'monitoring application health after deployment' points to post-deployment gates and potentially Azure Monitor or custom functions.
Module 3: Designing & Implementing Pipelines
Setting Up & Managing Release Gates for Quality Assurance
Not setting appropriate timeout values, leading to gates failing prematurely or taking too long.
Module 3: Designing & Implementing Pipelines
Setting Up & Managing Release Gates for Quality Assurance
Using gates for approvals that should be manual, confusing automated checks with human decisions.
Module 3: Designing & Implementing Pipelines
Setting Up & Managing Release Gates for Quality Assurance
Over-complicating gate logic with too many dependencies, making them brittle and hard to troubleshoot.
Module 3: Designing & Implementing Pipelines
Canary Deployment
Gradually roll out new version to small user subset.
Module 3: Designing & Implementing Pipelines
Infrastructure as Code (IaC)
Managing infrastructure through machine-readable files.
Module 3: Designing & Implementing Pipelines
ARM Templates
Azure native declarative IaC for resource deployment.
Module 3: Designing & Implementing Pipelines
Bicep
Domain-specific language for deploying Azure resources.
Module 3: Designing & Implementing Pipelines
Terraform
Cloud-agnostic IaC tool for provisioning infrastructure.
Module 3: Designing & Implementing Pipelines
Deployment Slots
Pre-production environments for Azure App Services.
Module 3: Designing & Implementing Pipelines
Implementing Diverse Deployment Strategies & Infrastructure
Blue/Green: Think of traffic lights! Blue is STOP (old), Green is GO (new). Canary: Like a canary in a coal mine, test the air first with a small group.
Module 3: Designing & Implementing Pipelines
Implementing Diverse Deployment Strategies & Infrastructure
The exam frequently tests your understanding of when to use blue/green vs. canary deployments. Look for keywords like 'zero downtime' (blue/green) or 'minimize risk/gradual rollout' (canary). Also, be ready to identify the correct Azure services for implementing each strategy (e.g., App Service deployment slots, Traffic Manager, Front Door).
Module 3: Designing & Implementing Pipelines
Implementing Diverse Deployment Strategies & Infrastructure
Confusing blue/green with canary deployments: Blue/green switches all traffic at once after testing, while canary gradually routes traffic.
Module 3: Designing & Implementing Pipelines
Implementing Diverse Deployment Strategies & Infrastructure
Not having a rollback plan: Regardless of the strategy, always ensure you can quickly revert to a stable previous version.
Module 3: Designing & Implementing Pipelines
Implementing Diverse Deployment Strategies & Infrastructure
Ignoring infrastructure as code: Manually provisioning infrastructure for complex strategies like blue/green is error-prone and defeats the purpose of automation.
Module 3: Designing & Implementing Pipelines
Bottleneck
A stage in a process that limits overall throughput or speed.
Module 3: Designing & Implementing Pipelines
Parallelization
Executing multiple tasks simultaneously to reduce total execution time.
Module 3: Designing & Implementing Pipelines
DORA Metrics
Key performance indicators for software delivery and operational performance.
Module 3: Designing & Implementing Pipelines
Shift Left
Moving quality and security activities earlier in the development lifecycle.
Module 3: Designing & Implementing Pipelines
Incremental Deployment
Deploying only changed components, rather than the entire application.
Module 3: Designing & Implementing Pipelines
Optimizing Deployment Processes for Efficiency
To OPTIMIZE your pipeline, remember PASTE: Parallelize, Automate, Shift Left, Track, Eliminate bottlenecks.
Module 3: Designing & Implementing Pipelines
Optimizing Deployment Processes for Efficiency
The exam often tests your understanding of how to use Azure DevOps features like pipeline caching, parallel jobs, and artifact management to improve efficiency. Look for keywords like 'reduce deployment time,' 'increase throughput,' or 'minimize manual steps.'
Module 3: Designing & Implementing Pipelines
Optimizing Deployment Processes for Efficiency
Failing to establish a baseline before implementing optimizations, making it impossible to measure improvements.
Module 3: Designing & Implementing Pipelines
Optimizing Deployment Processes for Efficiency
Over-automating without proper testing, leading to automated failures that are harder to diagnose.
Module 3: Designing & Implementing Pipelines
Optimizing Deployment Processes for Efficiency
Neglecting continuous monitoring and feedback loops, allowing new inefficiencies to creep in unnoticed.
Module 3: Designing & Implementing Pipelines
Release Pipeline
Automated process to deploy software across environments.
Module 3: Designing & Implementing Pipelines
Stage
A logical environment or set of tasks within a release pipeline.
Module 3: Designing & Implementing Pipelines
Environment
A specific deployment target like Dev, QA, or Production.
Module 3: Designing & Implementing Pipelines
Pre-deployment Condition
Rules determining when a stage can begin execution.
Module 3: Designing & Implementing Pipelines
Post-deployment Condition
Actions or checks performed after a stage completes.
Module 3: Designing & Implementing Pipelines
Approval
A manual human check required before a stage can proceed.
Module 3: Designing & Implementing Pipelines
Gate
An automated validation check before or after a stage.
Module 3: Designing & Implementing Pipelines
Variable Group
A collection of variables shared across multiple pipelines or stages.
Module 3: Designing & Implementing Pipelines
Managing Complex Release Pipelines in Azure DevOps
To remember the flow: 'A P P L E S' - Artifacts, Pre-deployment, Pipeline, Live, Environments, Stages.
Module 3: Designing & Implementing Pipelines
Managing Complex Release Pipelines in Azure DevOps
The exam frequently tests your understanding of pre-deployment and post-deployment conditions, especially the difference between manual approvals and automated gates. Pay close attention to how variable groups are used for environment-specific configurations.
Module 3: Designing & Implementing Pipelines
Managing Complex Release Pipelines in Azure DevOps
Forgetting to configure environment-specific variables, leading to hardcoded values or incorrect deployments.
Module 3: Designing & Implementing Pipelines
Managing Complex Release Pipelines in Azure DevOps
Over-relying on manual approvals for every stage, which slows down the release process and negates automation benefits.
Module 3: Designing & Implementing Pipelines
Managing Complex Release Pipelines in Azure DevOps
Not implementing automated gates for critical quality checks, allowing faulty code to progress to later environments.
Module 3: Designing & Implementing Pipelines
CIA Triad
Confidentiality, Integrity, and Availability; foundational security principles.
Module 4: Developing a Security & Compliance Plan
Defense in Depth
Layering multiple security controls to protect against threats.
Module 4: Developing a Security & Compliance Plan
GDPR
General Data Protection Regulation; EU law on data protection and privacy.
Module 4: Developing a Security & Compliance Plan
PCI DSS
Payment Card Industry Data Security Standard; for handling credit card data.
Module 4: Developing a Security & Compliance Plan
DevSecOps
Integrating security practices throughout the entire DevOps lifecycle.
Module 4: Developing a Security & Compliance Plan
SAST
Static Application Security Testing; analyzes source code for vulnerabilities.
Module 4: Developing a Security & Compliance Plan
Designing a Comprehensive Security & Compliance Strategy
To remember the core principles: 'CIA's Little Defense Shifts Left.' (Confidentiality, Integrity, Availability, Least Privilege, Defense in Depth, Shift Left).
Module 4: Developing a Security & Compliance Plan
Designing a Comprehensive Security & Compliance Strategy
The exam frequently tests your understanding of 'shift left' principles and how various compliance standards (like GDPR, HIPAA, PCI DSS) impact architectural and development decisions in Azure. Look for keywords like 'early integration,' 'automated security gates,' and specific regulatory acronyms.
Module 4: Developing a Security & Compliance Plan
Designing a Comprehensive Security & Compliance Strategy
Treating security as an afterthought or a separate phase at the end of the development cycle.
Module 4: Developing a Security & Compliance Plan
Designing a Comprehensive Security & Compliance Strategy
Failing to understand which specific compliance regulations apply to your organization's data and operations.
Module 4: Developing a Security & Compliance Plan
Designing a Comprehensive Security & Compliance Strategy
Over-relying on a single security control instead of implementing a layered 'defense in depth' approach.
Module 4: Developing a Security & Compliance Plan
Shift-Left Security
Integrating security practices early in the SDLC.
Module 4: Developing a Security & Compliance Plan
SAST (Static Application Security Testing)
Analyzes source code for vulnerabilities without running it.
Module 4: Developing a Security & Compliance Plan
DAST (Dynamic Application Security Testing)
Tests running applications for vulnerabilities by attacking them.
Module 4: Developing a Security & Compliance Plan
Policy-as-Code
Defining and enforcing compliance rules using code.
Module 4: Developing a Security & Compliance Plan
SIEM (Security Information and Event Management)
Centralized logging and analysis of security events.
Module 4: Developing a Security & Compliance Plan
WAF (Web Application Firewall)
Protects web applications from common web exploits.
Module 4: Developing a Security & Compliance Plan
Incident Response
Planned actions to handle and recover from security breaches.
Module 4: Developing a Security & Compliance Plan
Dependency Scanning
Identifies known vulnerabilities in third-party libraries.
Module 4: Developing a Security & Compliance Plan
Implementing Security & Compliance Processes
SECURE: **S**hift-left, **E**nforce policies, **C**ontinuously monitor, **U**se automation, **R**espond to incidents, **E**valuate and improve.
Module 4: Developing a Security & Compliance Plan
Implementing Security & Compliance Processes
The exam frequently tests your understanding of 'shift-left' principles. Be prepared to identify security activities that occur in the early stages of the SDLC, such as threat modeling, SAST, and dependency scanning, as opposed to later stages like DAST or penetration testing.
Module 4: Developing a Security & Compliance Plan
Implementing Security & Compliance Processes
Treating security as a gate at the end of the development cycle, leading to costly last-minute fixes.
Module 4: Developing a Security & Compliance Plan
Implementing Security & Compliance Processes
Relying solely on manual security checks, which are slow, inconsistent, and don't scale with DevOps velocity.
Module 4: Developing a Security & Compliance Plan
Implementing Security & Compliance Processes
Failing to integrate security tools into the CI/CD pipeline, making them optional rather than mandatory steps.
Module 4: Developing a Security & Compliance Plan
Azure Policy
Service to enforce organizational standards and assess compliance.
Module 4: Developing a Security & Compliance Plan
Azure Key Vault
Securely stores and manages cryptographic keys, secrets, and certificates.
Module 4: Developing a Security & Compliance Plan
Managed Identities
Azure AD identities for Azure resources, eliminating credential management.
Module 4: Developing a Security & Compliance Plan
Network Security Groups (NSG)
Filters network traffic to and from Azure resources in a VNet.
Module 4: Developing a Security & Compliance Plan
Secrets Management
Practices for securely handling sensitive information like API keys.
Module 4: Developing a Security & Compliance Plan
Building Secure & Compliant DevOps Infrastructure
KISS (Keep It Secure, Stupid!) for IaC: Key Vault for secrets, IAM for access, Segmentation for networks, and Scans for code.
Module 4: Developing a Security & Compliance Plan
Building Secure & Compliant DevOps Infrastructure
The exam frequently tests your knowledge of Azure Key Vault for secrets management and Azure Policy for compliance and governance. Be prepared to differentiate between auditing and enforcing policies.
Module 4: Developing a Security & Compliance Plan
Building Secure & Compliant DevOps Infrastructure
Hardcoding secrets directly into IaC templates or application code.
Module 4: Developing a Security & Compliance Plan
Building Secure & Compliant DevOps Infrastructure
Granting overly permissive roles (e.g., 'Owner' or 'Contributor') to service principals or users when a more specific role would suffice.
Module 4: Developing a Security & Compliance Plan
Building Secure & Compliant DevOps Infrastructure
Neglecting to segment networks, allowing unrestricted traffic flow between different application tiers.
Module 4: Developing a Security & Compliance Plan
Building Secure & Compliant DevOps Infrastructure
Not regularly reviewing or updating Azure Policies, leading to outdated compliance enforcement.
Module 4: Developing a Security & Compliance Plan
SIEM
Security Information and Event Management; centralizes security data.
Module 4: Developing a Security & Compliance Plan
IDS/IPS
Intrusion Detection/Prevention System; detects/blocks malicious activity.
Module 4: Developing a Security & Compliance Plan
Audit Trail
Chronological record of system activities for security review.
Module 4: Developing a Security & Compliance Plan
Incident Response Plan
Documented procedure for handling security breaches.
Module 4: Developing a Security & Compliance Plan
Compliance Reporting
Documenting adherence to regulatory and internal policies.
Module 4: Developing a Security & Compliance Plan
Configuration Drift
Deviation from an approved baseline configuration.
Module 4: Developing a Security & Compliance Plan
Vulnerability Management
Process of identifying, assessing, and remediating security flaws.
Module 4: Developing a Security & Compliance Plan
Monitoring & Auditing Security & Compliance Posture
MONITOR: M-Metrics, O-Ongoing, N-Notifications, I-Incidents, T-Tools, O-Oversight, R-Reporting.
Module 4: Developing a Security & Compliance Plan
Monitoring & Auditing Security & Compliance Posture
The AZ-400 exam frequently tests your understanding of how to integrate security monitoring and auditing into Azure DevOps pipelines. Look for keywords like 'Azure Monitor,' 'Azure Security Center,' 'Azure Sentinel,' 'compliance policies,' and 'audit logs' in questions. Remember that continuous feedback loops are key.
Module 4: Developing a Security & Compliance Plan
Monitoring & Auditing Security & Compliance Posture
Forgetting to regularly review and update monitoring rules and audit policies.
Module 4: Developing a Security & Compliance Plan
Monitoring & Auditing Security & Compliance Posture
Not integrating security alerts into a centralized SIEM or incident management system.
Module 4: Developing a Security & Compliance Plan
Monitoring & Auditing Security & Compliance Posture
Failing to conduct regular drills or tests of the incident response plan.
Module 4: Developing a Security & Compliance Plan
Instrumentation
Adding code/config to collect data on system behavior.
Module 5: Implementing an Instrumentation Strategy
Metrics
Numerical measurements over time (e.g., CPU, requests).
Module 5: Implementing an Instrumentation Strategy
Logs
Timestamped records of discrete events for context.
Module 5: Implementing an Instrumentation Strategy
Traces
End-to-end view of a request across multiple services.
Module 5: Implementing an Instrumentation Strategy
Observability
Ability to infer system state from external outputs.
Module 5: Implementing an Instrumentation Strategy
Application Insights
Azure service for application performance management (APM).
Module 5: Implementing an Instrumentation Strategy
Azure Monitor
Azure service for collecting, analyzing, and acting on telemetry.
Module 5: Implementing an Instrumentation Strategy
OpenTelemetry
Open standard for collecting and exporting telemetry data.
Module 5: Implementing an Instrumentation Strategy
Designing an Effective Instrumentation Strategy
MILT: Metrics for trends, Logs for details, Traces for journeys. Remember the 'MILT' of data types!
Module 5: Implementing an Instrumentation Strategy
Designing an Effective Instrumentation Strategy
The AZ-400 exam expects you to differentiate between metrics, logs, and traces, and understand when to use each. Keywords to spot include 'end-to-end transaction visibility' (traces), 'trend analysis' (metrics), and 'detailed event context' (logs).
Module 5: Implementing an Instrumentation Strategy
Designing an Effective Instrumentation Strategy
Over-instrumenting: Collecting too much data can be costly and overwhelming, obscuring important signals.
Module 5: Implementing an Instrumentation Strategy
Designing an Effective Instrumentation Strategy
Under-instrumenting: Not collecting enough data, leading to blind spots when issues arise.
Module 5: Implementing an Instrumentation Strategy
Designing an Effective Instrumentation Strategy
Ignoring business metrics: Focusing only on technical metrics and missing key insights into user experience or business impact.
Module 5: Implementing an Instrumentation Strategy
Structured Logging
Logs in a machine-readable format, like JSON, with key-value pairs.
Module 5: Implementing an Instrumentation Strategy
Log Level
Categorizes log messages by severity (e.g., Error, Warning, Info).
Module 5: Implementing an Instrumentation Strategy
Log Sink (Destination)
Where log data is stored (e.g., file, database, cloud service).
Module 5: Implementing an Instrumentation Strategy
Correlation ID
Unique identifier linking related log entries across systems.
Module 5: Implementing an Instrumentation Strategy
Azure Application Insights
Azure service for application performance monitoring and logging.
Module 5: Implementing an Instrumentation Strategy
Azure Monitor Log Analytics
Azure service for collecting, querying, and analyzing log data.
Module 5: Implementing an Instrumentation Strategy
Log Retention Policy
Rules defining how long log data is stored.
Module 5: Implementing an Instrumentation Strategy
Implementing Robust Logging Solutions for Applications
To remember log levels (Trace, Debug, Info, Warn, Error, Critical): 'TD I WEC' - 'Today I Wrecked Every Car'.
Module 5: Implementing an Instrumentation Strategy
Implementing Robust Logging Solutions for Applications
The AZ-400 exam frequently tests your knowledge of integrating application logging with Azure Monitor and Application Insights. Pay close attention to how different Azure services (App Service, Functions, AKS) send logs to these central services. Memorize the purpose of log levels and how to configure retention policies.
Module 5: Implementing an Instrumentation Strategy
Implementing Robust Logging Solutions for Applications
Logging too much sensitive data without masking, leading to security and compliance issues.
Module 5: Implementing an Instrumentation Strategy
Implementing Robust Logging Solutions for Applications
Using unstructured text logs in distributed systems, making troubleshooting nearly impossible.
Module 5: Implementing an Instrumentation Strategy
Implementing Robust Logging Solutions for Applications
Not centralizing logs, resulting in fragmented visibility and difficulty correlating events.
Module 5: Implementing an Instrumentation Strategy
Log Analytics
Azure Monitor service for collecting, indexing, and querying log data.
Module 5: Implementing an Instrumentation Strategy
Dashboards
Visual displays of key monitoring data and metrics.
Module 5: Implementing an Instrumentation Strategy
Alert Fatigue
Overwhelm from too many non-actionable or redundant alerts.
Module 5: Implementing an Instrumentation Strategy
APM
Application Performance Management, monitoring app health.
Module 5: Implementing an Instrumentation Strategy
Setting Up Comprehensive Monitoring for DevOps Systems
Remember 'MAD' for Monitoring: Metrics, Alerts, Dashboards. These are the three pillars of effective monitoring.
Module 5: Implementing an Instrumentation Strategy
Setting Up Comprehensive Monitoring for DevOps Systems
For the AZ-400 exam, be prepared to differentiate between Azure Monitor Logs and Metrics, and understand the core capabilities of Application Insights, including its role in distributed tracing and dependency mapping. Know how to configure diagnostic settings for various Azure services.
Module 5: Implementing an Instrumentation Strategy
Setting Up Comprehensive Monitoring for DevOps Systems
Over-alerting: Setting too many alerts for non-critical issues, leading to 'alert fatigue' and ignored warnings.
Module 5: Implementing an Instrumentation Strategy
Setting Up Comprehensive Monitoring for DevOps Systems
Under-monitoring: Not collecting enough data or monitoring critical components, resulting in blind spots when issues arise.
Module 5: Implementing an Instrumentation Strategy
Setting Up Comprehensive Monitoring for DevOps Systems
Siloed monitoring: Using disparate tools that don't integrate, making it hard to get a unified view of system health.
Module 5: Implementing an Instrumentation Strategy
Alert Rule
Defines conditions for triggering an alert in Azure Monitor.
Module 5: Implementing an Instrumentation Strategy
Action Group
Collection of notification preferences and automated actions.
Module 5: Implementing an Instrumentation Strategy
Metric Alert
Alert based on numeric data points exceeding thresholds.
Module 5: Implementing an Instrumentation Strategy
Log Alert
Alert based on specific patterns or counts in log data.
Module 5: Implementing an Instrumentation Strategy
Activity Log Alert
Alert based on events in the Azure activity log.
Module 5: Implementing an Instrumentation Strategy
Severity
Level of urgency for an alert, from 0 (critical) to 4 (verbose).
Module 5: Implementing an Instrumentation Strategy
Webhook
HTTP callback to trigger external systems or custom code.
Module 5: Implementing an Instrumentation Strategy
Configuring Alerting Strategies for Proactive Detection
A.C.T.I.O.N. - Alerts Create Timely Incidents On Notification. Remember that actions follow alerts!
Module 5: Implementing an Instrumentation Strategy
Configuring Alerting Strategies for Proactive Detection
For the AZ-400 exam, be prepared to differentiate between metric, log, and activity log alerts, and understand how to configure action groups for various notification types and automated actions. Pay attention to the role of severity levels.
Module 5: Implementing an Instrumentation Strategy
Configuring Alerting Strategies for Proactive Detection
Over-alerting: Creating too many alerts for non-critical events, leading to 'alert fatigue' and ignored warnings.
Module 5: Implementing an Instrumentation Strategy
Configuring Alerting Strategies for Proactive Detection
Under-alerting: Not having alerts for critical failures or key performance indicators, leading to delayed incident response.
Module 5: Implementing an Instrumentation Strategy
Configuring Alerting Strategies for Proactive Detection
Ignoring severity: Treating all alerts with the same urgency, which can lead to critical issues being overlooked.
Module 5: Implementing an Instrumentation Strategy
Site Reliability Engineering (SRE)
Applying software engineering principles to operations problems.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Service Level Indicator (SLI)
A quantifiable metric reflecting a service's health.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Service Level Objective (SLO)
A target value or range for an SLI, defining desired reliability.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Error Budget
The maximum allowable unreliability for a service, derived from SLOs.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Toil
Manual, repetitive, automatable work that provides no lasting value.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Blameless Postmortem
An analysis of an incident focused on systemic improvements, not blame.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Availability
The proportion of time a system is operational and accessible.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Designing a Foundational SRE Strategy for Reliability
To remember the SRE core concepts: 'SLI-SLO-Budget': SLI is the 'I'nput (what you measure), SLO is the 'O'utput (your desired target), and Budget is the 'B'rake (when to slow down).
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Designing a Foundational SRE Strategy for Reliability
The AZ-400 exam frequently tests your understanding of SLI, SLO, and Error Budget. Be prepared to differentiate them and explain their relationship. Keywords like 'quantifiable metric,' 'target for a metric,' and 'allowable unreliability' are crucial.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Designing a Foundational SRE Strategy for Reliability
Confusing SLIs with SLOs: SLIs are raw data points, SLOs are the targets for those data points.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Designing a Foundational SRE Strategy for Reliability
Setting unrealistic SLOs: SLOs should be challenging but achievable, not aspirational marketing claims.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Designing a Foundational SRE Strategy for Reliability
Ignoring the error budget: The error budget is a critical decision-making tool, not just a number to track.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Health Monitoring
Continuous collection and analysis of system data to assess well-being.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Golden Signals
Key metrics: Latency, Traffic, Errors, Saturation (LTES).
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Alerts
Notifications triggered when monitoring data crosses predefined thresholds.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
KQL
Kusto Query Language, used for querying data in Azure Monitor Log Analytics.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Implementing Health Monitoring for System Performance
To remember the Golden Signals: LTES - 'Let The Errors Stop!' (Latency, Traffic, Errors, Saturation).
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Implementing Health Monitoring for System Performance
The AZ-400 exam frequently tests your knowledge of Azure Monitor's capabilities. Pay close attention to how Application Insights and Log Analytics integrate, and how to configure metric alerts, activity log alerts, and diagnostic settings for various Azure resources.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Implementing Health Monitoring for System Performance
Setting too many alerts, leading to 'alert fatigue' where critical warnings are ignored.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Implementing Health Monitoring for System Performance
Monitoring only 'uptime' without considering performance or user experience metrics.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Implementing Health Monitoring for System Performance
Failing to regularly review and adjust monitoring thresholds as system behavior changes.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
MTTD
Mean Time To Detect: average time to identify a system failure.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
MTTR
Mean Time To Recover: average time to restore a system after failure.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Runbook
Step-by-step guide for diagnosing and resolving specific incidents.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Self-healing
Systems that automatically detect and fix their own issues.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Automated Rollback
Reverting to a previous stable version upon detection of issues.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Liveness Probe
Kubernetes check for a running container's health.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Readiness Probe
Kubernetes check if a container is ready to serve traffic.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Developing Failure Detection & Recovery Mechanisms
To remember the recovery cycle, think: 'Monitor, Detect, Diagnose, Recover, Verify, Post-mortem' – MDDRVP. It's like a doctor's visit for your system!
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Developing Failure Detection & Recovery Mechanisms
The AZ-400 exam frequently tests your understanding of metrics like MTTD and MTTR, and the practical application of automated recovery strategies. Look for questions involving Azure Monitor, Application Insights, and Azure DevOps pipelines for automated rollbacks.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Developing Failure Detection & Recovery Mechanisms
Over-relying on manual recovery processes, which are slow and prone to human error during high-stress incidents.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy
Developing Failure Detection & Recovery Mechanisms
Not adequately testing automated recovery mechanisms, leading to false confidence or unexpected failures during actual incidents.
Module 6: Implementing a Site Reliability Engineering (SRE) Strategy