CCNA Build Release Pipelines Questions

11 of 461 questions · Page 7/7 · Build Release Pipelines topic · Answers revealed

451
MCQmedium

Refer to the exhibit. You have this GitHub Actions workflow YAML. The workflow does not trigger when you push to the main branch. What is the most likely issue?

A.The branch name should be in a list under 'branches' inside 'push'.
B.The 'vmImage' should be 'windows-latest' for scripts.
C.The correct keyword is 'on', not 'triggers'.
D.The 'triggers' keyword is misspelled; it should be 'trigger'.
AnswerC

GitHub Actions uses 'on' to define events.

Why this answer

Option B is correct. The 'triggers' keyword is incorrect. In GitHub Actions, the correct keyword is 'on'.

The workflow should use 'on: push: branches: [main]' instead of 'triggers'. Option A is incorrect because the push event is valid. Option C is not the issue.

Option D is not the cause.

452
MCQhard

Your release pipeline deploys to multiple environments (Dev, Test, Prod) using approval gates. Recently, the Prod deployment failed because a manual validation task timed out after 30 minutes. You need to ensure that if the manual validation is not approved within 15 minutes, the pipeline automatically rejects the deployment and sends a notification. What should you do?

A.Set the 'Timeout in minutes' for the entire stage to 15.
B.In the Manual Validation task, set 'Timeout' to 15 and 'On timeout' to 'Reject'.
C.Configure a pre-deployment approval with a timeout of 15 minutes.
D.Add a PowerShell task after the manual validation that checks the status and cancels the pipeline if not approved.
AnswerB

This automatically rejects the deployment if the validation is not completed within 15 minutes.

Why this answer

Option D is correct because the Manual Validation task has a 'Timeout' setting; setting it to 15 minutes and configuring the 'On timeout' option to 'Reject' will automatically reject the deployment. Notifications can be set via subscription. Option A is wrong because pre-deployment approvals don't have a timeout that triggers rejection.

Option B is wrong because the pipeline-level timeout is not granular enough. Option C is wrong because the 'Cancel' action would cancel the entire pipeline, not just reject the validation.

453
MCQmedium

You are implementing a release pipeline that deploys a web app to Azure App Service. The deployment must be approved by a manager before proceeding to the production slot. However, the manager is on leave and the deployment is critical. What should you do to ensure the deployment can proceed without delaying the release?

A.Skip the approval for this deployment by overriding the settings.
B.Add an additional approver in the pre-deployment approval settings.
C.Configure the approval to time out after 24 hours and automatically approve.
D.Remove the approval requirement from the pipeline.
AnswerB

Adding another approver ensures the deployment can proceed if the primary is unavailable.

Why this answer

The best practice is to have a backup approver or a temporary override process, but since the question asks what you should do, setting up a timeout that auto-approves after a period is not secure. The correct approach is to add an additional approver (the manager's backup) in the approval settings. Skipping approval violates compliance.

Changing the pipeline permanently removes approval for future releases.

454
MCQhard

You are designing a release pipeline for a multi-tenant SaaS application that is deployed to Azure App Service. Each tenant has its own App Service instance. The pipeline must deploy a new version of the application to a staging slot for each tenant, run smoke tests, and then swap the staging slot to production. You need to ensure that if the smoke tests fail for any tenant, the swap is not performed for that tenant, while other tenants continue. Which release pipeline configuration should you use?

A.Create a release with multiple jobs (one per tenant) in the same stage, each deploying to a tenant's staging slot, running tests, and conditionally swapping. Set the 'Run this job' condition to 'Only when all previous jobs have succeeded' or use custom conditions to skip swap on failure.
B.Create a single stage with a 'foreach' loop over tenants, and if smoke tests fail, skip the swap using a condition.
C.Create a single job with parallel tasks for each tenant, and configure failure conditions to skip the swap.
D.Create a single stage with multiple deployment tasks, one per tenant, and use a 'continue on error' option on each task.
AnswerA

Multiple jobs can run in parallel, and each job can independently handle success/failure for its tenant.

Why this answer

Option D is correct because using a multi-job release allows each tenant deployment to be independent, and you can configure pre-deployment conditions or failure conditions to skip the swap for that tenant if tests fail. Option A is wrong because stages are sequential and a failure in one tenant would block others. Option B is wrong because a single job with multiple tasks would still block all tenants if one fails.

Option C is wrong because a parallel execution in a single job is not possible; you need multiple jobs.

455
Multi-Selecthard

Which THREE of the following are valid steps to implement a trunk-based development workflow in Azure Repos? (Select THREE.)

Select 3 answers
A.Run CI builds on the main branch.
B.Use feature flags and pair programming.
C.Merge to main only once per week.
D.Use short-lived feature branches that are merged within a day.
E.Create release branches for each production release.
AnswersA, B, D

CI ensures main is always stable.

Why this answer

Options A, C, and E are correct. Short-lived feature branches (A) are key; CI builds on main (C) ensure quality; pair programming (E) reduces need for long-lived branches. Option B is wrong because frequent merges are encouraged, not weekly.

Option D is wrong because release branches are not part of trunk-based development; everything is done on main.

456
MCQmedium

Refer to the exhibit. You are deploying this Bicep file using Azure Pipelines. The 'environment' parameter should be set to 'dev', 'qa', or 'prod' based on the release stage. How should you pass the parameter value?

A.Define the parameter in the 'parameters:' section of the YAML pipeline.
B.Set a pipeline variable named 'environment' and reference it in the AzureResourceManagerTemplateDeployment task's overrideParameters.
C.Use a task to replace the string '${environment}' in the Bicep file before deployment.
D.Modify the Bicep file to include a default value for environment.
AnswerB

Correct: Override parameters allows passing values to ARM/Bicep.

Why this answer

Option B is correct because you can set the 'environment' parameter as a pipeline variable and pass it to the Bicep deployment task. Option A is wrong because ARM template parameters are not set in the YAML file directly. Option C is wrong because the Bicep file does not have a default value.

Option D is wrong because you cannot modify the Bicep file dynamically.

457
MCQhard

Your team uses Azure Pipelines to deploy a multi-tier application to Azure. The application consists of a web frontend, an API backend, and a database. You need to deploy the database schema changes using a DACPAC file. The deployment should be idempotent and support rollback. You must use the Azure SQL Database deployment task. What should you do?

A.Use the 'Azure SQL Database deployment' task with the 'Deploy' action, specifying the DACPAC file and setting the 'Additional Arguments' to include 'p:BlockOnPossibleDataLoss=False' for safety.
B.Use the 'Azure SQL Database deployment' task with the 'Query' action to run schema changes.
C.Use a 'PowerShell' task to run 'SqlPackage.exe' with the DACPAC file.
D.Use the 'Azure SQL Database deployment' task with the 'Run SQL Script' action, and execute the schema changes as SQL scripts.
AnswerA

This deploys the DACPAC incrementally and allows rollback by redeploying the previous version.

Why this answer

Option A is correct: The 'Azure SQL Database deployment' task supports incremental deployment from a DACPAC and allows rollback via additional steps. Option B is incorrect because SQL scripts do not provide the same level of idempotency as DACPAC. Option C is incorrect because executing the DACPAC manually is not automated.

Option D is incorrect because the task does support DACPAC deployment.

458
Multi-Selectmedium

Which TWO are benefits of using deployment groups in Azure Pipelines compared to using individual virtual machines?

Select 2 answers
A.Built-in secrets management for connection strings.
B.Reduced cost because VMs are shut down when not in use.
C.Automatic scaling of virtual machines based on load.
D.Simplified targeting of multiple machines with a single pipeline run.
E.Rolling deployment support with health checks.
AnswersD, E

Deployment groups group machines together for parallel deployment.

Why this answer

Deployment groups allow you to target multiple machines with a single pipeline run and manage rolling updates. They do not directly improve security or reduce cost by themselves.

459
Multi-Selecthard

Which THREE components are required to set up a self-hosted agent pool in Azure Pipelines?

Select 3 answers
A.The agent software installed on the target machine
B.A deployment group target
C.The agent pool name and URL of the Azure DevOps organization
D.Azure VM extension for Azure Pipelines Agent
E.A personal access token (PAT) for authentication
AnswersA, C, E

The agent software is essential for the self-hosted agent.

Why this answer

Option A is correct because the self-hosted agent requires the Azure Pipelines agent software to be installed on the target machine. This software, which includes the agent listener and worker processes, is what registers the machine with the agent pool and executes pipeline jobs. Without the agent software, the machine cannot communicate with Azure Pipelines or run any tasks.

Exam trap

The trap here is that candidates often confuse the Azure VM extension (a convenience tool) with a mandatory requirement, or they mistakenly think a deployment group target is needed for agent pools, when in fact deployment groups are for targeting specific machines in a release context, not for agent registration.

460
MCQeasy

Your team uses GitHub Actions for CI/CD. You need to ensure that secrets are not exposed in build logs. What should you use?

A.Hardcoded values in the workflow YAML
B.Environment variables in the workflow
C.GitHub Secrets
D.Artifact storage
AnswerC

Secrets are encrypted and masked in logs.

Why this answer

GitHub Actions encrypts secrets and masks them in logs. Option B is wrong because environment variables can be printed. Option C is wrong because workflow files are public.

Option D is wrong because artifact upload does not mask secrets.

461
Multi-Selectmedium

Your release pipeline deploys a web app to Azure App Service. You need to implement safe deployment practices that minimize downtime and enable quick rollback. Which THREE strategies should you recommend?

Select 3 answers
A.Deploy to a staging slot first, validate, then swap.
B.Use rolling deployment with manual step to approve each instance.
C.Deploy directly to the production slot.
D.Configure monitoring and alerts to trigger automatic rollback if error rate increases.
E.Use deployment slots with swap and auto-swap.
AnswersA, D, E

Staging slot allows testing before production.

Why this answer

Option A is correct because slot swapping allows zero-downtime deployment. Option C is correct because deployment slots enable testing before swapping. Option E is correct because monitoring alerts trigger automatic rollback.

Options B and D are not safe deployment practices.

← PreviousPage 7 of 7 · 461 questions total

Ready to test yourself?

Try a timed practice session using only Build Release Pipelines questions.