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

Ensuring the reliability of solutions in production (e.g., chaos engineering, penetration testing, and load testing)

Practice questions and explanations for the "Ensuring the reliability of solutions in production (e.g., chaos engineering, penetration testing, and load testing)" objective of the Google Cloud Professional Cloud Architect exam. Skills measured as of 2026-10-22.

Skills in this objective

  • Ensuring reliability in production with chaos engineering, penetration testing, and load testing

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

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

Ensuring the reliability of solutions in production (e.g., chaos engineering, penetration testing, and load testing)

Nettleford Insurance's auditors require an annual external penetration test of its customer portal, which runs on Cloud Run and Compute Engine in projects that Nettleford owns. The security team asks what must be arranged with Google before the testers begin.

What should you tell the security team?

  1. ASubmit a penetration testing request form to Google and wait for written approvalGoogle does not require customers to request approval before testing their own resources.
  2. BGoogle does not need to be notified; the testers must limit testing to Nettleford's own projects and follow the Acceptable Use Policy and Terms of ServiceCustomers may penetration test their own Google Cloud deployments without contacting Google, provided they stay within their own resources and comply with the AUP and terms.
  3. COpen a Premium Support case so Google can add the testers' IP addresses to an allowlistNo allowlisting by Google is required, and Premium Support is not a prerequisite for testing.
  4. DMove the portal to an Assured Workloads folder before the testAssured Workloads applies compliance controls for regimes; it is unrelated to permission to perform penetration testing.
Why: Penetration testing is one of the reliability and security validation activities an architect plans for production. On Google Cloud, customers do not need to notify Google or request permission to test their own resources, but tests must stay within the customer's own projects and comply with the Acceptable Use Policy and Terms of Service, which forbid actions such as denial-of-service attacks against shared infrastructure. Planning should also include scope, timing, and coordination with the team's own monitoring so alerts are expected. The distractors invent approval processes that other providers or older practices may have used.
Ensuring the reliability of solutions in production (e.g., chaos engineering, penetration testing, and load testing)

Brookfield Tickets expects traffic for a stadium concert sale to reach 20 times normal peak within two minutes of opening. The application runs on GKE Autopilot with Cloud SQL for PostgreSQL behind an external Application Load Balancer. The team must prove before the sale that the system meets its latency SLO at that load, and wants to avoid surprises from limits outside the application code.

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

  1. ARun the load test against a production-like environment with the same configuration and representative data volumes, using distributed load generators such as Locust workers on GKE to reach the target rateTesting a faithful copy of production with load generators that can scale out is the only way to measure realistic behavior at 20 times peak.
  2. BModel the two-minute ramp in the test profile and measure latency against the SLO, including autoscaling and connection-pool behavior during the rampA sudden ramp exposes cold-start, autoscaling lag, and database connection limits that a steady-state test would hide.
  3. CReview the Compute Engine, GKE, and Cloud SQL quotas and limits for the test and production projects and request increases ahead of the saleProject quotas such as regional CPUs and in-use IP addresses, and service limits such as the Cloud SQL instance's maximum connections for its machine size, can block scaling regardless of application quality, so they must be checked and raised in advance.
  4. DRun the load test from a single VM to keep the test simpleA single generator usually becomes the bottleneck long before the target rate and gives misleading results.
  5. ESkip load testing because GKE Autopilot scales automaticallyAutopilot scales pods and nodes, but scaling takes time and downstream components such as Cloud SQL have their own limits, which only a test reveals.
Why: Load testing validates that a system meets its SLOs at the expected load and reveals the first bottleneck. A credible test uses a production-like environment and data, generates load from a scalable, distributed tool, and reproduces the shape of the traffic, including sudden ramps. Platform quotas and service limits are a frequent cause of launch failures, so capacity planning includes requesting increases early. Assuming autoscaling makes testing unnecessary is the main trap, because scaling speed and downstream limits are exactly what such events stress.
Ensuring the reliability of solutions in production (e.g., chaos engineering, penetration testing, and load testing)

Lowther Mobility runs a ride-booking service on regional GKE clusters with a Memorystore for Redis cache and Spanner. The architecture is designed to survive the loss of the cache and of a single zone, but this has never been tested. The SRE lead wants to start a chaos engineering practice without causing a major customer outage.

How should the team begin?

  1. ADelete the production Spanner instance during peak hours to test recoveryDestroying a primary data store is not a controlled experiment, risks data loss, and has an unbounded blast radius.
  2. BWait for a real zonal outage and observe how the system behavesWaiting gives no control over timing or preparation and is the opposite of proactively building confidence.
  3. CRun a load test at three times peak trafficLoad testing is valuable but tests capacity, not the system's response to dependency or zone failures.
  4. DDefine a steady-state hypothesis from SLO metrics, inject a limited fault such as cache unavailability or pod failures in a staging environment first, with abort conditions, then expand carefully to productionChaos engineering starts with a measurable hypothesis, a small blast radius, and a way to stop the experiment, and moves toward production as confidence grows.
Why: Chaos engineering is the disciplined practice of injecting failures to verify that a system behaves as designed. Each experiment states a steady-state hypothesis in terms of user-facing metrics, introduces a realistic fault, limits the blast radius, and has clear abort criteria. Teams usually begin in pre-production and with low-impact faults, then run carefully scoped experiments in production, because production is where real failure modes appear. The distractors are either reckless, passive, or test a different property.

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