AZ-400 Questions 81-90: Containers, GitHub Actions, and Advanced Pipelines

Real pipelines rarely stop at “build and deploy a web app.” This set covers the more complex scenarios AZ-400 likes to test: building and pushing container images, deploying to Azure Kubernetes Service, canary strategies in deployment jobs, passing values between jobs, conditions, GitHub Actions reusable workflows, environments, matrices and concurrency, connecting GitHub repositories to Azure Pipelines, and scanning containers.

This is the ninth post in our AZ-400 series (Questions 81-90). The previous set, AZ-400 Questions 71-80: Repositories, Permissions, and DevOps Metrics, covers roles, CODEOWNERS, and DORA metrics. Every question here is an original practice scenario, not a copy of a real exam item.

Question 81: Building and Pushing a Container Image

Contoso’s Azure Pipelines YAML must build a Docker image from a Dockerfile and push it to Azure Container Registry, tagged with the build ID. What is the most direct approach?

A) The Docker task with the buildAndPush command and a Docker registry service connection to the registry

B) Copying the Dockerfile to a storage account

C) Publishing the source code as a pipeline artifact

D) Running docker save and emailing the file

👁 Reveal Answer

Correct Answer: A

Explanation: The Docker task’s buildAndPush command builds the image and pushes it to the registry defined by a service connection, and you can pass tags such as $(Build.BuildId). Tagging with a unique build ID keeps every image traceable to the run that produced it. B and C move files around without producing an image in a registry. D is not a deployment practice. For better security, the service connection can use workload identity federation instead of stored credentials.

Question 82: Letting AKS Pull from ACR

After the pipeline pushes images to Azure Container Registry, pods in Fabrikam’s AKS cluster fail with “unauthorized” errors when pulling them. The team does not want to store registry passwords in Kubernetes secrets. What should they do?

A) Make the registry public

B) Store the registry admin password in a ConfigMap

C) Rebuild the images with a different base image

D) Attach the registry to the AKS cluster so the kubelet identity gets the AcrPull role

👁 Reveal Answer

Correct Answer: D

Explanation: Attaching ACR to AKS (for example, az aks update --attach-acr) grants the cluster’s kubelet managed identity the AcrPull role on the registry, so nodes can pull images with no stored passwords. A exposes private images to everyone. B stores a secret in plain text and uses the admin account, which should normally be disabled. C does not change authentication at all.

Question 83: A Canary Rollout to Kubernetes in YAML

Northwind Traders deploys to AKS with a YAML deployment job that targets a Kubernetes environment. They want to send the new version to 10% of pods, then 25%, pausing for checks before promoting fully or rolling back. Which deployment job strategy fits?

A) runOnce

B) canary with increments: [10, 25]

C) A matrix strategy

D) A scheduled trigger

👁 Reveal Answer

Correct Answer: B

Explanation: Deployment jobs support three strategies: runOnce, rolling, and canary. The canary strategy deploys in increments and provides lifecycle hooks — such as preDeploy, deploy, routeTraffic, postRouteTraffic, and on: failure/success — where you can run checks and roll back. A deploys everything in one go. C runs the same job with different variables, not a staged rollout. D controls when a pipeline starts, not how it deploys.

Question 84: Passing a Value Between Jobs

In an Azure Pipelines YAML pipeline, job Build calculates a version number in a script step named setver. Job Deploy, which depends on Build, needs that value. How should you pass it?

A) Write it to a local file in Build and read the same file path in Deploy

B) Set an environment variable in Build; it is visible in every later job automatically

C) Set an output variable with ##vso[task.setvariable variable=ver;isOutput=true] and read it in Deploy through dependencies.Build.outputs['setver.ver']

D) Hard-code the version in both jobs

👁 Reveal Answer

Correct Answer: C

Explanation: Jobs can run on different agents, so they do not share files or environment variables. An output variable, created with isOutput=true, is published by the step; a dependent job maps it through dependencies.<job>.outputs['<step>.<variable>']. Across stages, the syntax uses stageDependencies. A fails when Deploy lands on another agent. B is wrong because variables set in one job do not flow to others. D defeats the purpose of calculating the version.

Question 85: Running a Step Only on Failure

You want a step that uploads diagnostic logs only when an earlier step in the job has failed. Which condition should the step use?

A) condition: succeeded()

B) condition: failed()

C) condition: always()

D) No condition

👁 Reveal Answer

Correct Answer: B

Explanation: failed() runs the step only when a previous step has failed — ideal for collecting diagnostics. A is the default and runs only when everything so far succeeded. C runs regardless of outcome (and even when the run is cancelled), which would upload logs every time. D behaves like succeeded(). In GitHub Actions, the equivalent is if: failure().

Question 86: Sharing a Whole Workflow in GitHub Actions

Woodgrove Bank has 30 repositories that need the same build, test, and deploy jobs. The platform team wants to maintain the job logic once, and let each repository call it with a few inputs. What should they create?

A) A reusable workflow triggered by workflow_call

B) A copy of the workflow file in each repository

C) A repository secret containing the workflow

D) A GitHub Pages site documenting the steps

👁 Reveal Answer

Correct Answer: A

Explanation: A reusable workflow declares on: workflow_call with inputs and secrets, and other workflows call it with uses: org/repo/.github/workflows/file.yml@ref. Entire jobs are shared and maintained in one place. Composite actions are the lighter option for sharing a group of steps. B creates 30 copies that drift. C is not a way to store or run workflows. D documents but does not automate.

Question 87: Requiring Approval in GitHub Actions

Adventure Works’ GitHub Actions workflow deploys to production. Two named reviewers must approve each production deployment, and only the main branch may deploy there. What should you configure?

A) A repository variable named production

B) A concurrency group

C) A matrix with a production entry

D) A production environment with required reviewers and a deployment branch rule for main, referenced by the job

👁 Reveal Answer

Correct Answer: D

Explanation: GitHub environments support protection rules: required reviewers, wait timers, and deployment branch or tag restrictions. A job that sets environment: production pauses until reviewers approve and can only run from allowed branches; environment secrets are released only after approval. A stores a value, not a protection rule. B controls overlapping runs. C runs a job several times with different values but adds no approval.

Question 88: Stopping Overlapping Deployments

Developers at Tailspin Toys push to main several times in a few minutes. Each push starts a staging deployment, and overlapping deployments sometimes collide. They want only the newest run to deploy, cancelling any older run still in progress. What should they add to the GitHub Actions workflow?

A) A concurrency group for the staging deployment with cancel-in-progress: true

B) A matrix strategy

C) A longer job timeout

D) A scheduled trigger every hour

👁 Reveal Answer

Correct Answer: A

Explanation: A concurrency group ensures only one run in that group is active at a time. With cancel-in-progress: true, a new run cancels older in-progress runs, so the latest commit wins and deployments do not collide. B runs jobs in parallel across combinations, the opposite of what is needed. C lets collisions run longer. D delays deployments and still allows overlaps if runs take long.

Question 89: Building GitHub Code with Azure Pipelines

Coho Winery keeps code in GitHub but its release process, environments, and approvals live in Azure Pipelines. It wants pull requests in GitHub to show the Azure Pipelines build result as a status check that can block merging. What should it set up?

A) A webhook from GitHub to an Azure Storage account

B) A mirror of the GitHub repository into Azure Repos every night

C) The Azure Pipelines GitHub App connection, a YAML pipeline with a pr trigger, and a branch protection rule requiring that check

D) A manual build started by a reviewer

👁 Reveal Answer

Correct Answer: C

Explanation: With the Azure Pipelines GitHub App, Azure Pipelines builds GitHub pull requests and reports results back as GitHub checks. A branch protection rule or ruleset in GitHub can then require that check to pass before merging. A only delivers raw events to storage. B delays feedback and creates a second source of truth. D is slow and unreliable. This is the “integration between GitHub repositories and Azure Pipelines” skill from the outline.

Question 90: Scanning Images Before They Ship

Litware wants every container image to be checked for known operating-system and package vulnerabilities, both in the pipeline before push and continuously while images sit in Azure Container Registry. What combination fits best?

A) Code coverage analysis in the pipeline

B) An image vulnerability scanner step in the pipeline, plus Microsoft Defender for Containers for images in the registry

C) CodeQL only

D) Dependabot version updates only

👁 Reveal Answer

Correct Answer: B

Explanation: Container scanning has two parts: scan in the pipeline so vulnerable images are caught before they are pushed or deployed, and scan continuously in the registry because new vulnerabilities are published after images are built. Microsoft Defender for Containers assesses images in Azure Container Registry and surfaces findings in Defender for Cloud. A measures tests, not vulnerabilities. C analyzes your source code, not the OS packages inside an image — though CodeQL can run inside a container job. D keeps dependencies up to date but does not scan built images.

Study Tips for Advanced Pipelines

• Know the deployment strategies in YAML. runOnce, rolling, and canary, with lifecycle hooks for checks and rollback.
• Pass data deliberately. Output variables with isOutput=true between jobs; artifacts for files.
• Learn the condition functions. succeeded(), failed(), always() in Azure Pipelines; success(), failure(), always() in GitHub Actions.
• Map GitHub Actions features. Reusable workflows share jobs, composite actions share steps, environments add approvals, and concurrency prevents overlap.
• Use identities for registries. Attach ACR to AKS rather than storing registry passwords.

Keep Practicing for AZ-400

Finish the series with AZ-400 Questions 91-100: Final Mixed Review. For reference, read Microsoft’s guide to deployment jobs alongside Question 83, and GitHub’s documentation on reusing workflows with Question 86.