ScenarioCert
Sign inStart free test
GCP PCA ยท Ensuring solution and operations excellence (12.5-12.5%)

Evaluating quality control measures

Practice questions and explanations for the "Evaluating quality control measures" objective of the Google Cloud Professional Cloud Architect exam. Skills measured as of 2026-10-22.

Skills in this objective

  • Evaluating quality control measures

Test yourself on this domain

Take the free 15-question test, or unlock all 150 questions and practice this domain on its own.

Free testUnlock for $29

Sample questions

2 of the 2 questions we have for this objective, shown with the answer and the reasoning.

Evaluating quality control measures

Kingsley Learning's CI pipeline in Cloud Build runs only a compile step before images are promoted by Cloud Deploy. Over the last quarter, 40 percent of production incidents were caused by logic bugs that unit tests would have caught, and three were caused by container images with critical known vulnerabilities. The VP of engineering wants quality gates that stop such releases automatically, with no manual review step added.

Which two actions should you take? Each correct answer presents part of the solution.

  1. AAdd unit and integration test steps to the Cloud Build configuration so that a failing test fails the build and no image is produced for promotionAutomated tests as blocking build steps stop logic regressions before an artifact exists, which is the earliest and cheapest quality gate.
  2. BFail the build when Artifact Analysis on-demand scanning reports critical vulnerabilities in the built imageScanning the image in the pipeline and failing on critical findings stops vulnerable images from being promoted, without manual review.
  3. CRequire a release manager to read every pull request before mergeManual review was explicitly ruled out and does not reliably catch logic bugs or vulnerable packages.
  4. DIncrease the production error budget so that incidents no longer exhaust itChanging the budget hides the quality problem rather than preventing defective releases.
  5. ERun the tests nightly against production after deploymentTests that run after deployment detect problems only once users are already affected.
Why: Quality control in a delivery pipeline works best as automated gates that run as early as possible, often called shifting left. Blocking unit and integration tests in CI catch logic defects before an image is built, and vulnerability scanning of the built image with a policy threshold catches known security defects before promotion. Later gates, such as canary analysis and Binary Authorization, add further layers. Manual reviews and post-deployment testing are the traps because they are slow or too late.
Evaluating quality control measures

Juniper Streaming's video API has an availability SLO of 99.95 percent per 28 days. Product managers push for weekly feature releases, and in the last two months the error budget was exhausted twice by release-related incidents, while releases continued as usual. Engineering leadership wants an objective, agreed rule that balances release speed with reliability.

What should you recommend?

  1. AAdopt an error budget policy agreed by product and engineering that freezes feature releases and prioritizes reliability work when the error budget is exhausted, until it recoversAn error budget policy turns the SLO into a decision rule: while budget remains, teams release freely; when it is spent, they focus on reliability, which aligns both groups on data rather than opinion.
  2. BRaise the SLO to 99.99 percent so engineers take reliability more seriouslyA stricter target with the same practices would only exhaust the budget faster and does not change behavior.
  3. CRequire the CTO to approve every releaseCentral approval slows all releases regardless of reliability and does not use the SLO data.
  4. DStop measuring the SLO until the release cadence slows downRemoving measurement eliminates the signal needed to manage the trade-off.
Why: SLOs and error budgets are quality control tools: the budget is the amount of unreliability the business has agreed to accept, and spending it on feature velocity is legitimate. An error budget policy states in advance what happens when the budget runs out, such as a release freeze or mandatory postmortems, so the decision is not argued during each incident. This is an operational excellence and reliability practice because it links engineering priorities to measured user experience. The distractors either ignore the data or change the target instead of the behavior.

Written from the public documentation. Not affiliated with Google Cloud. Official study guide.