Overview
Domain 4 is about protecting the toolchain and the code that flows through it. Microsoft lists three functional groups. Authentication and authorization covers choosing between Microsoft Entra service principals and managed identities, GitHub Apps, GITHUB_TOKEN and personal access tokens, Azure DevOps service connections, permissions and roles on both platforms, access levels such as Stakeholder, and configuring projects and teams.
The sensitive information group covers Azure Key Vault, secrets and secretless authentication with workload identity federation and OpenID Connect, secure files and pipeline designs that stop leaks. The scanning group covers a strategy for dependency, code, secret and license scanning, Microsoft Defender for Cloud DevOps security, GitHub Advanced Security on GitHub and Azure DevOps, container scanning with CodeQL, and Dependabot alerts for open-source vulnerabilities.
How it's tested
Security questions describe a pipeline, a repository or a team, plus a requirement such as no long-lived secrets, least privilege, external reviewers or vulnerability visibility across organizations. You choose the identity type, token, permission level, secret store or scanning feature that meets the requirement with the least exposure and effort.
-
Remove the secret
A pipeline uses a client secret or PAT, and you replace it with workload identity federation, OIDC or a managed identity.
-
Grant least access
A person or automation needs specific rights, and you choose a GitHub role, Azure DevOps group or access level.
-
Pick the scanner
A risk such as leaked keys, vulnerable packages or insecure code is described, and you choose the matching scanning feature.
A GitHub Actions workflow deploys to Azure using a service principal secret stored as a repository secret, and security wants no long-lived credentials. Rotating the secret more often still leaves one stored. Configuring a federated credential on the Microsoft Entra app registration or a user-assigned managed identity, granting id-token: write in the workflow, and using azure/login with OIDC removes the stored secret entirely. That is the answer the exam expects.
Functional groups 3
Official functional groups from the Microsoft outline, in outline order.
4.1 Design and implement authentication and authorization methodsService principals, managed identities, GitHub tokens, service connections, roles, access levels and teams.
- What it means
- This group covers choosing between Microsoft Entra service principals and system-assigned or user-assigned managed identities, managing GitHub authentication with GitHub Apps, GITHUB_TOKEN and personal access tokens, managing Azure DevOps service connections and PATs, designing permissions in GitHub and Azure DevOps, recommending access levels including Stakeholder and outside collaborator access, and configuring Azure DevOps projects and teams.
- What to understand
- Managed identities have no credentials to manage but only work for code running on Azure resources, such as a self-hosted agent VM; a user-assigned identity can be shared and outlives any one resource. Service principals work anywhere and can use federated credentials. GITHUB_TOKEN is created per job and its scope is set with the permissions key; GitHub Apps give fine-grained, short-lived installation tokens and suit cross-repository automation better than PATs. Azure DevOps service connections should use workload identity federation and be authorized only for specific pipelines. GitHub repository roles run Read, Triage, Write, Maintain and Admin. Azure DevOps uses groups such as Readers, Contributors and Project Administrators, and Stakeholder access gives free, limited Boards access.
- How it shows up
- Expect a question on the right identity for a pipeline or the least access level for a person.
- Common confusion
- Assuming a managed identity works from a Microsoft-hosted agent; it needs a resource in Azure that owns the identity, or federation instead.
4.2 Design and implement a strategy for managing sensitive information in automationKey Vault, secretless authentication, secure files and leak prevention.
- What it means
- This group covers managing secrets, keys and certificates in Azure Key Vault, handling secrets and secretless authentication such as workload identity federation with OpenID Connect in GitHub Actions and Azure Pipelines, managing sensitive files during deployment with Azure Pipelines secure files, and designing pipelines that do not leak sensitive information.
- What to understand
- Key Vault secrets reach Azure Pipelines through the AzureKeyVault task or a variable group linked to a vault, and reach GitHub Actions through azure/login plus a Key Vault read. GitHub stores secrets at repository, environment and organization level; environment secrets are available only to jobs that target that environment and can sit behind required reviewers. Secure files such as certificates or provisioning profiles are uploaded to the Library and fetched with DownloadSecureFile. To prevent leaks, mark values as secret so logs mask them, avoid echoing them, mask dynamic values with add-mask, and remember that secrets are withheld from pull requests built from forks by default.
- How it shows up
- Expect a question about the safest place for a certificate or credential and how a pipeline reads it.
- Common confusion
- Believing masking makes it safe to print secrets; masking is best effort and transformed values can still leak.
4.3 Automate security and compliance scanningScanning strategy, Defender for Cloud DevOps security, GitHub Advanced Security, container and dependency scanning.
- What it means
- This group covers designing scanning for dependencies, code, secrets and licenses, configuring Microsoft Defender for Cloud DevOps security, configuring GitHub Advanced Security for GitHub and for Azure DevOps, connecting GitHub Advanced Security to Defender for Cloud, automating container image scanning and running CodeQL in a container, and using Dependabot alerts for open-source vulnerabilities.
- What to understand
- Secret scanning finds credentials in repositories, and push protection blocks them before they land. Code scanning with CodeQL finds vulnerable code patterns and runs in workflows or default setup. Dependabot alerts flag vulnerable dependencies from the dependency graph, and Dependabot security updates open fix pull requests. GitHub Advanced Security for Azure DevOps brings secret scanning, dependency scanning and CodeQL to Azure Repos and Pipelines. Defender for Cloud DevOps security connects GitHub, Azure DevOps and GitLab organizations and shows findings in one place with posture recommendations. Container images can be scanned in the pipeline and in Azure Container Registry by Defender for Containers. License compliance uses dependency review or third-party tools.
- How it shows up
- Expect a risk described in plain words and a choice between secret scanning, CodeQL, Dependabot and Defender.
- Common confusion
- Using Dependabot to find hardcoded passwords; secret scanning handles credentials, Dependabot handles vulnerable packages.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Workload identity federation
Pipelines exchange a short-lived OIDC token for Microsoft Entra access.
- Remember
- No client secret to store or rotate.
- Tested as
- Secretless authentication questions.
- Trap
- Keeping a client secret as a fallback.
-
Managed identity
Azure-managed identity bound to or assigned to a resource.
- Remember
- Needs code running on that Azure resource.
- Tested as
- Identity choice questions.
- Trap
- Using it from hosted agents.
-
Service principal
Application identity in Microsoft Entra ID.
- Remember
- Can use certificates, secrets or federated credentials.
- Tested as
- Cross-environment identity questions.
- Trap
- Granting Owner at subscription scope.
-
GITHUB_TOKEN
Automatic token scoped to the repository for one job.
- Remember
- Limit it with the permissions key.
- Tested as
- GitHub automation questions.
- Trap
- Using a PAT for same-repo tasks.
-
GitHub App
Installable app with fine-grained, short-lived tokens.
- Remember
- Better than PATs for org-wide automation.
- Tested as
- Cross-repository questions.
- Trap
- Tying automation to a personal account.
-
Service connection
Azure DevOps credential to an external service.
- Remember
- Restrict to approved pipelines and add checks.
- Tested as
- Pipeline access questions.
- Trap
- Granting access to all pipelines.
-
Stakeholder access
Free Azure DevOps access level with limited features.
- Remember
- Good for viewing and editing work items.
- Tested as
- Access level questions.
- Trap
- Expecting repository code access in private projects.
-
Outside collaborator
GitHub user with access to specific repositories only.
- Remember
- Not a member of the organization.
- Tested as
- External access questions.
- Trap
- Adding contractors as full members.
-
Environment secrets
GitHub secrets available only to jobs targeting an environment.
- Remember
- Can sit behind required reviewers.
- Tested as
- Secret scoping questions.
- Trap
- Using repository secrets for production.
-
Secure files
Azure Pipelines Library store for files like certificates.
- Remember
- Downloaded at runtime and cleaned up.
- Tested as
- Sensitive file questions.
- Trap
- Committing certificates to the repository.
-
Secret scanning with push protection
Detects and blocks credentials in pushes.
- Remember
- Stops leaks before they enter history.
- Tested as
- Secret leak questions.
- Trap
- Relying on detection after the push only.
-
CodeQL code scanning
Semantic analysis for vulnerable code patterns.
- Remember
- Can run in a container job.
- Tested as
- Static analysis questions.
- Trap
- Expecting it to scan dependency versions.
-
Dependabot alerts
Notifications for vulnerable dependencies.
- Remember
- Security updates open fix pull requests.
- Tested as
- Open-source risk questions.
- Trap
- Treating it as a license scanner.
-
Defender for Cloud DevOps security
Centralizes DevOps findings and posture across platforms.
- Remember
- Connects GitHub, Azure DevOps and GitLab.
- Tested as
- Cross-platform visibility questions.
- Trap
- Expecting it to replace in-repo scanning.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Pipeline identities
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Service principal with secret | App identity using a stored client secret | Works anywhere but needs rotation | Leaving secrets in variables |
| Workload identity federation | Federated trust using OIDC tokens | No stored secret | Forgetting the subject claim must match |
| Managed identity | Identity owned by an Azure resource | Only from code on that resource | Using it from hosted agents |
GitHub authentication
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| GITHUB_TOKEN | Per-job repository token | Expires when the job ends | Leaving default write permissions |
| GitHub App | Installation token for chosen repos | Fine-grained and not tied to a person | Picking PATs for org automation |
| Personal access token | Token tied to a user account | Breaks when the user leaves | Using classic tokens with broad scopes |
Scanning tools
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Secret scanning | Finds credentials in code and history | Push protection blocks new leaks | Confusing with code scanning |
| CodeQL | Analyzes source code semantics | Finds injection and logic flaws | Expecting package CVE results |
| Dependabot | Tracks vulnerable dependencies | Opens update pull requests | Expecting it to find secrets |
| Defender for Containers | Scans images in registries | Covers images after build | Skipping pipeline-time scans |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Shorter secret lifetime
- What candidates pick
- Reduce the service principal secret expiry to 30 days.
- Why it looks right
- Shorter lifetimes sound safer.
- Why it's wrong
- A stored secret still exists; federation with OIDC removes it, which is what no long-lived secret means.
Clue to watch for No secrets stored in the pipeline.
-
Managed identity on hosted agents
- What candidates pick
- Assign a managed identity to the Microsoft-hosted agent pool.
- Why it looks right
- Managed identities avoid secrets.
- Why it's wrong
- Hosted agents are not your Azure resources; use federation or a self-hosted agent on an Azure VM.
Clue to watch for Microsoft-hosted agents are in use.
-
PAT for org automation
- What candidates pick
- Create a PAT on an admin account for a bot that edits many repositories.
- Why it looks right
- PATs are simple to create.
- Why it's wrong
- PATs are tied to a person and broad; a GitHub App gives scoped, short-lived tokens.
Clue to watch for Automation across many repositories.
-
Basic for reviewers
- What candidates pick
- Give business reviewers Basic access so they can update stories.
- Why it looks right
- Basic seems the default.
- Why it's wrong
- Stakeholder access covers work item tracking at no cost and limits code access.
Clue to watch for Users only need to view or update work items.
-
Dependabot for secrets
- What candidates pick
- Turn on Dependabot to catch committed API keys.
- Why it looks right
- Dependabot is a security feature.
- Why it's wrong
- Dependabot tracks vulnerable packages; secret scanning with push protection catches keys.
Clue to watch for Credentials or tokens in source.
-
Secrets in forked pull requests
- What candidates pick
- Expose secrets to forked pull request builds so tests pass.
- Why it looks right
- Tests need credentials.
- Why it's wrong
- Fork builds run untrusted code; exposing secrets lets contributors exfiltrate them.
Clue to watch for Public repository accepting outside contributions.
Answer framework
Use these steps to choose the security answer in a Domain 4 scenario.
- Identify who or what needs access: a person, a pipeline, a GitHub workflow or an app running on Azure, and on which platform.
- For automation, prefer workload identity federation or OIDC; use managed identities only for code that runs on an Azure resource.
- Grant the smallest role or access level that works, such as Stakeholder, Read or Contributors, and restrict service connections to specific pipelines.
- Store remaining secrets and files in Key Vault, environment secrets or secure files, mark them secret, and keep them away from fork builds.
- Match each risk to its scanner: secret scanning, CodeQL, Dependabot, container scanning, and Defender for Cloud for central visibility.
Practice question
Want more like this? The AZ-400 practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with identities because they appear across the whole exam. Create an Azure DevOps service connection using workload identity federation, then set up a GitHub Actions workflow that signs in with azure/login and a federated credential limited to one environment. Compare that with a self-hosted agent on a VM using a managed identity so the boundary is clear.
Next, map permissions. Write a table of GitHub repository roles and Azure DevOps groups and access levels, noting what Stakeholder users can and cannot do. Restrict a service connection to one pipeline and add an approval check to it.
Then work through secrets: link a variable group to Key Vault, use a secure file, add environment secrets with required reviewers, and observe how masking behaves in logs. Finish with scanning. Enable secret scanning with push protection, CodeQL and Dependabot on a public test repository, enable GitHub Advanced Security for Azure DevOps if available, and view results in Defender for Cloud. Plan twelve to fifteen hours.
FAQ
How much of AZ-400 is Domain 4, Develop a security and compliance plan?
Microsoft weights it at 10–15% with three functional groups: authentication and authorization, sensitive information in automation, and security and compliance scanning.
What is workload identity federation?
A trust between Microsoft Entra ID and an external token issuer such as GitHub or Azure DevOps, letting pipelines sign in with short-lived tokens and no stored secret.
When should I use a managed identity in a pipeline?
When the agent or runner runs on an Azure resource you control, such as a VM or scale set, that can own or be assigned the identity.
What can Stakeholder users do in Azure DevOps?
They can view and edit work items and boards and approve releases, but have limited or no access to code and test features.
What is the difference between secret scanning and Dependabot?
Secret scanning finds credentials committed to code. Dependabot finds dependencies with known vulnerabilities and can open pull requests to update them.
What does Defender for Cloud add to GitHub Advanced Security?
It brings findings from GitHub, Azure DevOps and GitLab into one view with DevOps posture recommendations across organizations.
Other DevOps & Containers certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 4 knowledge
You have covered pipeline identities, permissions, secrets and security scanning. Check whether you can pick the least-privilege, secretless option in exam scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the AZ-400 AI tutor Get any concept explained your way