Release pipeline basics in Azure - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Understanding artifact sources in Azure release pipelines

In an Azure release pipeline, what happens when you configure multiple artifact sources?

A The pipeline triggers when any one of the artifact sources has a new version available.

B The pipeline triggers only when all artifact sources have new versions available.

C The pipeline ignores artifact sources and triggers manually only.

D The pipeline triggers only if the primary artifact source has a new version, ignoring others.

💡 Hint

Think about how pipelines react to changes in any input source.

Azure release pipelines trigger when any configured artifact source has a new version. This allows the pipeline to react to changes from multiple sources independently.

❓ Architecture

intermediate

Stages and approvals in release pipelines

Which statement best describes the role of stages and approvals in an Azure release pipeline?

A Stages define deployment steps; approvals are manual gates before or after stages to control flow.

B Stages are manual checkpoints; approvals automatically deploy to next environment.

C Approvals replace stages and automate all deployment steps.

D Stages and approvals are unrelated and used for different pipelines.

💡 Hint

Consider how deployment steps and manual checks work together.

Stages represent deployment phases like Dev, Test, Prod. Approvals are manual gates that pause the pipeline before or after stages to ensure human review.

❓ security

advanced

Securing secrets in release pipelines

Which method is the most secure way to handle sensitive information like passwords in Azure release pipelines?

A Hardcode secrets in the application code deployed by the pipeline.

B Embed secrets in scripts within the pipeline YAML file.

C Store secrets directly in pipeline variables marked as secret.

D Use Azure Key Vault and link it to the pipeline to fetch secrets at runtime.

💡 Hint

Think about centralized secret management and runtime retrieval.

Using Azure Key Vault linked to the pipeline ensures secrets are stored securely and accessed only at runtime, reducing exposure risk.

❓ Configuration

advanced

Pipeline variable scopes and overrides

Given a variable named connectionString defined at both pipeline and stage levels, which value is used during deployment in that stage?

A The variable is ignored and must be passed manually.

B The stage-level <code>connectionString</code> value overrides the pipeline-level value for that stage.

C Both values are merged and concatenated during deployment.

D The pipeline-level <code>connectionString</code> value is always used.

💡 Hint

Consider how variable scopes work in layered configurations.

Stage-level variables override pipeline-level variables for that stage, allowing environment-specific customization.

✅ Best Practice

expert

Optimizing release pipeline deployment speed

You want to speed up deployments in a release pipeline that has multiple independent stages. Which approach achieves this best?

A Configure stages to run sequentially, one after another.

B Add manual approvals between every stage to ensure quality.

C Configure stages to run in parallel where dependencies allow.

D Combine all stages into a single stage to reduce overhead.

💡 Hint

Think about how tasks can run at the same time safely.

Running independent stages in parallel reduces total deployment time while maintaining separation and control.

Practice

1. What is the main purpose of a release pipeline in Azure DevOps?

easy

A. To monitor user activity on a website

B. To automate the delivery of applications through different stages

C. To write code for applications

D. To store application data securely

Solution

1. Step 1: Understand the role of a release pipeline

   A release pipeline automates the process of delivering software through stages like testing and production.

2. Step 2: Identify the correct purpose

   Among the options, only automating delivery matches the release pipeline's function.

3. Final Answer:

   To automate the delivery of applications through different stages -> Option B

4. Quick Check:

   Release pipeline = automate delivery [OK]

Hint: Release pipelines automate app delivery stages [OK]

Common Mistakes:

• Confusing release pipeline with coding or monitoring tools
• Thinking it stores data instead of deploying apps

2. Which syntax correctly defines a stage in an Azure release pipeline YAML?

easy

A. stage:
- Build
jobs: []

B. jobs:
- stage: Build

C. stages:
Build:
jobs: []

D. stages:
- stage: Build
jobs: []

Solution

1. Step 1: Review YAML structure for stages

   In Azure pipelines, stages are defined under 'stages:' as a list with '- stage:' entries.

2. Step 2: Match correct syntax

   stages: - stage: Build jobs: [] correctly uses 'stages:' followed by '- stage: Build' and an empty jobs list.

3. Final Answer:

   stages: - stage: Build jobs: [] -> Option D

4. Quick Check:

   Stages list starts with 'stages:' and '- stage:' [OK]

Hint: Stages use 'stages:' then '- stage:' list items [OK]

Common Mistakes:

• Using singular 'stage:' instead of 'stages:'
• Placing 'stage' inside 'jobs' incorrectly
• Incorrect indentation or list syntax

3. Given this YAML snippet in a release pipeline:

stages:
  - stage: Test
    jobs:
      - job: RunTests
        steps:
          - script: echo Testing

What will be the output when this pipeline runs?

medium

A. It will print 'Testing' in the job logs

B. It will print 'echo Testing' literally

C. No output will be shown

D. The pipeline will fail due to syntax error

Solution

1. Step 1: Understand the script step in pipeline

   The 'script' step runs the command given, here 'echo Testing', which prints 'Testing'.

2. Step 2: Predict output

   Since the script runs successfully, the output 'Testing' appears in the job logs.

3. Final Answer:

   It will print 'Testing' in the job logs -> Option A

4. Quick Check:

   Script runs command, prints output [OK]

Hint: Script steps run commands and show output [OK]

Common Mistakes:

• Thinking script prints the command text instead of output
• Assuming syntax error without checking YAML correctness
• Expecting no output from script step

4. You have this YAML snippet in a release pipeline:

stages:
  - stage: Deploy
    jobs:
      - job: DeployJob
        steps:
          - script: echo Deploying
          - script: echo Done
        dependsOn: Build

What is wrong with this pipeline configuration?

medium

A. 'dependsOn' should be inside the stage, not inside jobs

B. 'dependsOn' must be a job, not a stage

C. The 'steps' section cannot have multiple scripts

D. The 'jobs' keyword is not allowed inside stages

Solution

1. Step 1: Locate 'dependsOn' usage

   'dependsOn' controls stage dependencies and must be placed at the stage level, not inside jobs.

2. Step 2: Identify correct placement

   In the snippet, 'dependsOn: Build' is incorrectly placed inside the job, it should be directly under the stage.

3. Final Answer:

   'dependsOn' should be inside the stage, not inside jobs -> Option A

4. Quick Check:

   'dependsOn' belongs to stage level [OK]

Hint: 'dependsOn' goes under stage, not job [OK]

Common Mistakes:

• Placing 'dependsOn' inside jobs instead of stages
• Thinking 'dependsOn' applies to jobs only
• Believing multiple scripts in steps is invalid

5. You want to create a release pipeline with two stages: Build and Deploy. Deploy should only run if Build succeeds. Which YAML snippet correctly sets this up?

hard

A. stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
jobs:
- job: DeployJob
steps:
- script: echo Deploying

B. stages:
- stage: Build
dependsOn: Deploy
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
jobs:
- job: DeployJob
steps:
- script: echo Deploying

C. stages:
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building
- stage: Deploy
dependsOn: Build
jobs:
- job: DeployJob
steps:
- script: echo Deploying

D. stages:
- stage: Deploy
dependsOn: Build
jobs:
- job: DeployJob
steps:
- script: echo Deploying
- stage: Build
jobs:
- job: BuildJob
steps:
- script: echo Building

Solution

1. Step 1: Understand stage dependencies

   To run Deploy only after Build succeeds, Deploy stage must depend on Build.

2. Step 2: Check YAML for correct 'dependsOn'

   stages: - stage: Build jobs: - job: BuildJob steps: - script: echo Building - stage: Deploy dependsOn: Build jobs: - job: DeployJob steps: - script: echo Deploying places 'dependsOn: Build' under Deploy stage, correctly setting the dependency.

3. Step 3: Verify order and jobs

   Build stage is first, Deploy second, with proper jobs and steps defined.

4. Final Answer:

   Correctly sets Deploy to depend on Build -> Option C

5. Quick Check:

   'dependsOn' on Deploy stage = correct dependency [OK]

Hint: Use 'dependsOn' on Deploy stage to wait for Build [OK]

Common Mistakes:

• Reversing 'dependsOn' causing wrong execution order
• Omitting 'dependsOn' so stages run in parallel
• Placing stages in wrong order without dependencies