AZ-400 security and compliance explained
Develop a security and compliance plan is 10-15% of AZ-400. It covers how pipelines authenticate, where secrets live, and how code and containers are scanned for vulnerabilities. The recurring theme is to remove long-lived secrets and to shift security checks into the pipeline. If a question offers a secretless option that fits, it is usually the right one.
Authentication and authorization
Service principals, managed identities and federation
| Option | What it is | Prefer when |
|---|---|---|
| Service principal with a secret or certificate | An app identity in Microsoft Entra ID with a credential you manage | Nothing else is available; you accept rotation |
| Managed identity (system-assigned) | An identity tied to one Azure resource’s lifecycle | Code running on that resource calls other Azure services |
| Managed identity (user-assigned) | A standalone identity that several resources can share | Several resources need the same permissions, or the identity must outlive a resource |
| Workload identity federation (OpenID Connect) | A service principal or managed identity that trusts tokens from GitHub or Azure DevOps | A pipeline deploys to Azure and you want no stored secret |
A managed identity works only for resources running in Azure. A hosted GitHub runner is not an Azure resource, so it cannot use one directly; federation is the answer there. Self-hosted agents on an Azure VM can use the VM’s managed identity.
GitHub and Azure DevOps credentials
- GITHUB_TOKEN is a short-lived token created for each workflow run, with permissions you can restrict in the workflow. It is the default choice for actions within the same repository.
- GitHub Apps act with granular, installation-scoped permissions and are preferred over personal access tokens (PATs) for automation.
- PATs belong to a person and break when that person leaves; use them sparingly with minimum scopes and short expiry.
- Azure DevOps service connections let pipelines access Azure and other services. Create them with workload identity federation where possible and scope them to what the pipeline needs.
Permissions and access levels
Know the building blocks: GitHub roles (Read, Triage, Write, Maintain, Admin), teams and outside collaborators; Azure DevOps security groups, project and team structure and access levels, including Stakeholder access for people who only need limited, free access to Boards.
Managing secrets in automation
- Azure Key Vault stores secrets, keys and certificates. Pipelines read them at run time using a managed identity or federated credential; in Azure Pipelines a Key Vault-linked variable group or a task fetches them.
- Secure files in Azure Pipelines hold certificates or provisioning profiles that must not sit in the repository.
- Secrets in logs. Mark values as secret so they are masked; avoid echoing them, never pass them on the command line where they may be logged, and avoid exposing secrets to pull requests from forks.
- Secretless authentication. OIDC from GitHub Actions to Azure uses a federated credential and a short-lived token; nothing is stored in repository secrets.
Automating security and compliance scanning
| Type | What it finds | Tool |
|---|---|---|
| Static code analysis | Vulnerabilities in your code | CodeQL (GitHub Advanced Security) |
| Secret scanning | Committed credentials | GitHub secret scanning, push protection |
| Dependency scanning | Known-vulnerable libraries | Dependabot alerts and security updates, dependency review |
| Licence scanning | Disallowed licences | Dependency review, third-party tools |
| Container scanning | Vulnerable images | Defender for Cloud, CodeQL in containers, scanning actions |
GitHub Advanced Security is also available for Azure DevOps. Microsoft Defender for Cloud DevOps security connects GitHub and Azure DevOps organizations and shows code and pipeline security findings next to cloud posture, so security teams see everything in one place.
Common mistakes
- Choosing a managed identity for a GitHub-hosted runner.
- Storing a PAT in repository secrets when
GITHUB_TOKENor a GitHub App suffices. - Believing that deleting a committed secret fixes the exposure; it must be rotated.
Example questions
Question 1. A GitHub Actions workflow running on GitHub-hosted runners deploys to Azure. The security team forbids stored credentials. Which solution meets the requirement?
- A. A federated credential and OpenID Connect login
- B. A system-assigned managed identity on the runner
- C. A personal access token stored in repository secrets
- D. A certificate stored in repository secrets
Show answer
Answer: A
Federated credentials let the workflow exchange a GitHub OIDC token for a short-lived Entra ID token, so no secret is stored. A system-assigned managed identity cannot be attached to a GitHub-hosted runner because it is not an Azure resource. A PAT and a certificate stored in secrets are still stored credentials.
Want more questions like this? Full AZ-400 practice tests →
Question 2. A pipeline must use a database password at deployment time. The password must be stored centrally, rotatable and auditable, and must not appear in the repository. What should you use?
- A. A variable in the YAML file marked as secret
- B. A page in the project wiki
- C. A secret in Azure Key Vault read at run time
- D. A constant in the deployment script
Show answer
Answer: C
Azure Key Vault is the central, auditable store for secrets, and the pipeline reads the value at run time. Hard-coding the value or placing it in a YAML variable puts it in the repository. A wiki page is readable by many people and is not a secret store.
Want more questions like this? Full AZ-400 practice tests →
Question 3. Your organization wants automatic pull requests that update vulnerable open-source dependencies in its GitHub repositories. What should you enable?
- A. CodeQL code scanning
- B. Dependabot alerts and security updates
- C. Secret scanning push protection
- D. A branch protection rule requiring two reviewers
Show answer
Answer: B
Dependabot alerts detect vulnerable dependencies and Dependabot security updates open pull requests to fix them. CodeQL analyses your own code rather than updating dependencies. Secret scanning looks for committed credentials, and branch protection controls merging but does not detect or fix vulnerable packages.
Want more questions like this? Full AZ-400 practice tests →
Next
Finish the domains with instrumentation.