A pipeline holds the keys to production, which makes it a favorite target for attackers. The AZ-400 security and compliance domain asks how pipelines authenticate, where secrets live, how to stop them leaking, who gets which access level, and how to scan code, dependencies, and containers automatically. This set covers managed identities, workload identity federation, GITHUB_TOKEN, GitHub Apps, stakeholder access, Azure Key Vault, secure files, GitHub Advanced Security, Microsoft Defender for Cloud, Dependabot, and CodeQL.
This is the sixth post in our AZ-400 series (Questions 51-60). The previous set, AZ-400 Questions 41-50: Infrastructure as Code and Pipeline Maintenance, covers Bicep, configuration management, and pipeline health. Every question here is an original practice scenario, not a copy of a real exam item.
Question 51: Secretless Authentication to Azure
Contoso’s Azure Pipelines service connection to Azure uses a service principal with a client secret that expires every year and has caused outages twice. The team wants to remove stored secrets from the connection entirely. What should they use?
A) A personal access token stored in a variable group
B) An Azure Resource Manager service connection that uses workload identity federation
C) A longer client secret expiry of ten years
D) The subscription owner’s username and password
👁 Reveal Answer
Correct Answer: B
Explanation: With workload identity federation, Azure DevOps issues a short-lived token (OpenID Connect) that Microsoft Entra ID trusts for the app registration or managed identity, so no secret is stored or rotated. A authenticates to Azure DevOps, not to Azure, and is still a stored secret. C keeps the secret and increases the damage if it leaks. D ties automation to a person and breaks with MFA. GitHub Actions supports the same approach: the azure/login action with OIDC and the id-token: write permission.
Question 52: Managed Identity or Service Principal?
A self-hosted build agent runs on an Azure VM and needs to read secrets from Azure Key Vault. The team wants no credentials to manage at all. Which identity should the agent use?
A) A managed identity assigned to the VM
B) A service principal with a certificate stored on the VM disk
C) A shared user account with a password in an environment variable
D) An anonymous access policy on the Key Vault
👁 Reveal Answer
Correct Answer: A
Explanation: Managed identities are Microsoft Entra identities for Azure resources; Azure creates and rotates their credentials automatically, so there is nothing to store. A system-assigned identity lives and dies with the VM; a user-assigned identity is a separate resource that several VMs or scale set instances can share. B works but leaves a credential on disk to protect and rotate. C is insecure and unauditable. D is not possible and would be dangerous.
Question 53: Least Privilege for GITHUB_TOKEN
A GitHub Actions workflow only needs to check out code and read packages. Security wants the automatically issued token in that workflow limited to the minimum it needs. What should you do?
A) Store GITHUB_TOKEN in an organization secret
B) Replace GITHUB_TOKEN with an administrator’s personal access token
C) Add a permissions block that grants read-only access to contents and packages
D) Nothing — GITHUB_TOKEN always has read-only access
👁 Reveal Answer
Correct Answer: C
Explanation: GitHub creates GITHUB_TOKEN automatically for each workflow run; it is scoped to the repository and expires when the job ends. The permissions key sets exactly which scopes it gets, at workflow or job level, and any scope you do not list is set to none. B grants far more access and does not expire with the job. A is unnecessary — the token is created per run. D is wrong because default permissions depend on repository and organization settings and can include write access.
Question 54: Automation That Does Not Belong to a Person
Fabrikam has an internal tool that labels issues and comments on pull requests across 60 repositories in its GitHub organization. Today it uses a developer’s personal access token, which broke when that developer left. What should it use instead?
A) GITHUB_TOKEN from a workflow in one repository
B) A new personal access token from another developer
C) A shared “bot” user account whose password is emailed to the team
D) A GitHub App installed on the organization with only the required permissions
👁 Reveal Answer
Correct Answer: D
Explanation: A GitHub App acts as its own identity, not as a person. It is installed on the organization or selected repositories, requests fine-grained permissions, and uses short-lived installation tokens — so it keeps working when people leave. B repeats the original problem. C is insecure and breaks the “one account per person” principle. A is scoped to the repository whose workflow is running, so it cannot act across 60 repositories.
Question 55: Access for Business Reviewers
Northwind Traders’ product owners need to view and update work items and dashboards in Azure DevOps. They never touch code or pipelines, and the company wants to avoid buying them Basic licenses. Which access level should they get?
A) Basic + Test Plans
B) Stakeholder
C) Project Collection Administrator
D) Project Administrator
👁 Reveal Answer
Correct Answer: B
Explanation: Stakeholder access is free and lets users work with work items, boards, and dashboards with some limitations, without access to code repositories in private projects. It is designed for exactly this kind of business user. A is a paid level with test management features they do not need. C and D are administrative roles that grant far more power than required. In GitHub, the comparable idea is giving people outside the organization outside collaborator access to only the repositories they need.
Question 56: Stopping Secrets from Leaking in Logs
A script step in an Azure Pipelines YAML pipeline needs a secret variable called dbPassword. A developer notices the script cannot see the value in its environment. What is the correct way to pass it?
A) Change it to a normal, non-secret variable
B) Echo the value to the log at the start of the job so the script can read it
C) Map it explicitly with an env entry on the step, such as DB_PASSWORD: $(dbPassword)
D) Write it to a file in the repository during the build
👁 Reveal Answer
Correct Answer: C
Explanation: Secret variables are not automatically exposed as environment variables to scripts; you must map them deliberately on the step that needs them. This limits where secrets can leak. Azure Pipelines also masks secret values in logs. A and B both expose the secret. D puts it on disk and possibly in source control. Other leak-prevention habits: do not pass secrets on command lines, and do not expose secrets to pull request builds from forks.
Question 57: Using a Signing Certificate in a Pipeline
Woodgrove Bank’s release pipeline must sign an app with a .pfx certificate. The file must not be stored in the repository. Besides Azure Key Vault, which Azure Pipelines feature is designed for this?
A) A public Azure Storage container
B) A pipeline artifact published from an earlier build
C) A variable group with the certificate pasted as text
D) Secure files, downloaded at run time with the Download Secure File task
👁 Reveal Answer
Correct Answer: D
Explanation: Secure files store sensitive files — certificates, signing keys, provisioning profiles — in the Azure DevOps library, encrypted and outside source control. Pipelines must be authorized to use each file, and the Download Secure File task places it on the agent for the job only. Storing the certificate in Azure Key Vault is the other strong option. B is meant for build outputs and is downloadable by anyone with access to the run. C is awkward and easy to leak. A is public.
Question 58: Code and Secret Scanning in Azure Repos
Adventure Works stores code in Azure Repos and wants built-in code scanning with CodeQL, secret scanning with push protection, and dependency scanning — without moving to GitHub. What should it enable?
A) GitHub Advanced Security for Azure DevOps
B) Azure Policy on the Azure DevOps organization
C) Branch policies requiring two reviewers
D) Azure Monitor Application Insights
👁 Reveal Answer
Correct Answer: A
Explanation: GitHub Advanced Security for Azure DevOps brings GitHub’s security features to Azure Repos and Azure Pipelines: secret scanning with push protection, dependency scanning, and code scanning with CodeQL. Microsoft has since split these into separately licensed products (secret protection and code security), but the exam outline uses the original name. B governs Azure resources, not repository content. C adds human review but no automated scanning. D monitors running applications, not source code.
Question 59: One View of DevOps Security Findings
Tailspin Toys has repositories in both GitHub and Azure DevOps. The security team wants a single place to see code, secret, dependency, and IaC findings across all of them, alongside cloud security posture. What should they configure?
A) Azure Advisor
B) A separate dashboard in each repository
C) Microsoft Defender for Cloud DevOps security, with connectors for GitHub and Azure DevOps
D) Azure Boards queries
👁 Reveal Answer
Correct Answer: C
Explanation: Defender for Cloud DevOps security connects to GitHub, Azure DevOps (and GitLab) organizations and brings findings from GitHub Advanced Security and other scanners into one view, linked to the cloud resources the code deploys. That is the “integrate GitHub Advanced Security with Defender for Cloud” skill from the outline. B fragments the view. A focuses on reliability, cost, and performance recommendations. D tracks work items, not security findings.
Question 60: Vulnerable Open-Source Dependencies
A GitHub repository at Litware uses dozens of npm packages. The team wants to be notified when any dependency has a known vulnerability and, where possible, receive a pull request that updates it to a fixed version. What should they enable?
A) CodeQL code scanning only
B) Dependabot alerts and Dependabot security updates
C) Branch protection rules
D) GitHub Pages
👁 Reveal Answer
Correct Answer: B
Explanation: Dependabot alerts compare the repository’s dependency graph with the GitHub Advisory Database and raise alerts for known vulnerabilities. Dependabot security updates go further and open pull requests that bump the vulnerable package to a patched version. A analyzes your own code for vulnerabilities, not third-party packages. C protects branches but does not detect vulnerable dependencies. D hosts static websites. For containers, add image scanning — for example, Defender for Cloud scanning images in Azure Container Registry.
Study Tips for Security and Compliance
- Prefer secretless authentication. Managed identities for Azure resources and workload identity federation (OIDC) for pipelines remove stored secrets.
- Know GitHub’s three identities.
GITHUB_TOKENfor one workflow run, GitHub Apps for organization-wide automation, personal access tokens only as a last resort. - Match the access level to the job. Stakeholder for business users; Basic for developers; administrator roles only for administrators.
- Know where secrets live. Values in Key Vault or secret variables (mapped explicitly), files in secure files, never in the repository.
- Map each scanner to its target. CodeQL scans your code, Dependabot scans dependencies, secret scanning finds credentials, and Defender for Cloud brings it all together.
Keep Practicing for AZ-400
This completes the first six sets of the series. Next we cover instrumentation with Azure Monitor and KQL, more pipeline scenarios, and a final mixed review. Until then, revisit Questions 1-10 or read Microsoft’s guide to connecting to Azure with workload identity federation alongside Question 51.
