4 of the 22 questions we have for this objective, shown with the answer and the reasoning.
Design and implement pipelines
Kingsmere Logistics has 18 GitHub repositories in the organization kingsmere that each deploy a container app with the same three jobs: build, scan, and deploy, including a deployment environment with protection rules. The platform team wants to maintain the full job sequence once in the repository kingsmere/platform-workflows and let each repository call it with its own app name and Azure credentials secret.
What should you create?
- AA composite action in kingsmere/platform-workflows that each workflow calls as a stepA composite action packages steps within a single job; it cannot define multiple jobs or reference a deployment environment.
- BA reusable workflow with on: workflow_call, inputs for the app name, and a declared secret, called from each repository with jobs.deploy.uses: kingsmere/platform-workflows/.github/workflows/deploy.yml@mainA reusable workflow can contain several jobs and environments, receives inputs and secrets from the caller, and is invoked at the job level with uses.
- CA workflow template in the organization's .github repositoryWorkflow templates only create a starting copy in each repository, so later fixes would still have to be made 18 times.
- DAn organization variable that contains the workflow YAMLVariables store configuration values; GitHub Actions does not execute workflow definitions stored in variables.
Why: GitHub Actions offers two reuse mechanisms. Composite actions bundle steps that run inside one job of the caller, while reusable workflows triggered by workflow_call define complete jobs, including runners, environments, and job dependencies, and are called with uses at the job level. When the shared unit is a multi-job sequence with environments, a reusable workflow is the right choice, and secrets can be passed explicitly or with secrets: inherit. Workflow templates are starter files, not live references.
Design and implement pipelines
Corrigan Media has a stage with two jobs, Build and Publish. In Build, a script step named setVer computes a version and runs echo "##vso[task.setvariable variable=appVersion;isOutput=true]2.7.14". The Publish job must run after Build and use the version in a variable named ver.
How should you define the Publish job?
- A- job: Publish with dependsOn: Build and variables: { ver: $[ dependencies.Build.outputs['setVer.appVersion'] ] }An output variable from another job in the same stage is read through dependencies.<job>.outputs['<step>.<variable>'] in a runtime expression, and the job must depend on Build.
- B- job: Publish with dependsOn: Build and variables: { ver: $(setVer.appVersion) }The step-qualified macro syntax works only in later steps of the same job, not in a different job.
- C- job: Publish with dependsOn: Build and variables: { ver: ${{ dependencies.Build.outputs['setVer.appVersion'] }} }Template expressions are evaluated at compile time, before Build has run, so the output does not exist yet.
- D- job: Publish with variables: { ver: $[ stageDependencies.Build.outputs['setVer.appVersion'] ] } and no dependsOnstageDependencies is for outputs from a different stage, and without dependsOn the jobs may run in parallel.
Why: Passing data between jobs requires three things: the step must set the variable with isOutput=true, the step must have a name, and the consuming job must declare dependsOn on the producing job. The consumer then maps the value with a runtime expression, $[ dependencies.Build.outputs['setVer.appVersion'] ], because the value only exists after Build runs. Across stages the syntax becomes stageDependencies.<stage>.<job>.outputs['<step>.<variable>']. Mixing compile-time and runtime syntax is the most common error in these scenarios.
Design and implement pipelines
Thornbury Civil Engineering keeps its code in Azure Repos Git and tracks work in Azure Boards. Auditors require that every production deployment links back to the work items and commits it contains, and that deployments to a shared production environment are gated by approvals that pipeline authors cannot remove. The company does not want to migrate repositories.
Which deployment automation solution should you recommend?
- AGitHub Actions workflows that check out the Azure Repos repository with a personal access tokenGitHub Actions cannot trigger on Azure Repos events natively, and a PAT-based checkout adds secrets and loses built-in Azure Boards deployment traceability.
- BAzure Pipelines YAML pipelines with deployment jobs that target an environment protected by approvals and checksAzure Pipelines triggers natively from Azure Repos, links runs to commits and work items, and environment approvals are owned by the resource rather than the YAML file.
- CAzure Pipelines YAML pipelines with an approval step written as a script that polls a SharePoint listA script in the YAML can be removed by the pipeline author and is custom code, so it does not meet the governance requirement.
- DA newly created classic release pipeline with pre-deployment approvalsClassic release pipelines are legacy and disabled by default in new organizations; YAML environments provide the same approvals as code-adjacent configuration.
Why: When source control and work tracking are in Azure DevOps, Azure Pipelines gives the tightest integration: CI triggers from Azure Repos, automatic linking of runs to commits and work items, and deployment status visible on Azure Boards. Approvals and checks are configured on the environment, so they apply to every pipeline that deploys there and cannot be bypassed by editing YAML. GitHub Actions is the better fit for GitHub-hosted code, but it cannot natively react to Azure Repos pushes.
Design and implement pipelines
Birchwood Apps is a 10-person team that builds a public-facing .NET and Node.js web application with Azure Pipelines. Builds use only common tools such as the .NET SDK, Node.js, and Docker, and deploy to Azure App Service over the public internet. The team does not want to patch, update, or scale build machines.
Which agent type should you use?
- ASelf-hosted agents on two Azure virtual machinesSelf-hosted VMs require the team to install tools, apply OS updates, and size capacity, which it wants to avoid.
- BA self-hosted agent installed on a developer workstationA workstation agent depends on one machine being online and maintained, and it mixes personal and build environments.
- CA VM scale set agent pool built from a custom imageScale set agents autoscale but still require the team to build and maintain the image and the scale set.
- DMicrosoft-hosted agents using the windows-latest or ubuntu-latest imageMicrosoft-hosted agents come with the .NET SDK, Node.js, and Docker preinstalled, are patched by Microsoft, and provide a fresh VM for every job.
Why: Microsoft-hosted agents are the default choice when builds need only standard tooling and targets are reachable over the internet, because Microsoft maintains the images and every job starts on a clean VM. Self-hosted options, including scale set agents and Managed DevOps Pools, become worthwhile when you need private network access, custom software, larger machines, or persistent caches. The deciding constraint here is that the team will not maintain build machines.