Managing implementation of cloud architecture practice questions

Answer: A) Create a second MIG from the new instance template behind the same load balancer, validate it, then route traffic to it while the original MIG keeps running

Blue/green on Compute Engine uses two MIGs, old and new, behind one load balancer. Traffic moves to the new MIG in one step while the old MIG stays running for immediate rollback. Rolling and canary updates replace instances in place, so rollback is slower.

• ACorrect. This is blue/green. The new MIG runs at full capacity next to the old one and can be validated before any users reach it. Traffic moves at the load balancer in one step, and the old MIG stays running so traffic can be switched back right away.
• BIncorrect. A rolling update replaces the old instances. Rolling back means running another rolling update to recreate them, which is not an immediate switch.
• CIncorrect. A canary update serves both versions from one MIG and moves traffic over gradually. It does not bring the new version up at full capacity and switch all traffic in one step, and rollback still means replacing instances.
• DIncorrect. Deleting the original MIG removes the standby environment. Rollback would mean provisioning and booting new instances, which is slow.

Answer: A) A release runbook that lists each deployment step, verification check and rollback action

Runbooks give teams a standard, step-by-step reference for operational procedures, which makes deployments and their verification consistent. Postmortems, SLO documents and diagrams serve other purposes.

• ACorrect. A runbook documents a standard procedure step by step, so every engineer follows the same sequence and skipped checks become less likely. Google Cloud guidance says runbooks should be reviewed and updated regularly to stay current.
• BIncorrect. A postmortem looks back at an incident to find root causes and follow-up actions. It's useful, but it isn't the procedure engineers follow during each release.
• CIncorrect. SLOs and error budgets set reliability targets and can guide when releases go ahead. They don't describe how to perform or verify a deployment.
• DIncorrect. A diagram shows how the system is built, not the ordered actions and checks needed for a release.

Answer: A) Submit a request to raise the regional CPU quota well before the launch date

Regional CPU quota limits how many VMs, and reservations, a project can have, and committed use discounts and autoscaling don't change that limit. To support the launch, the team should request a quota increase ahead of time.

• ACorrect. Running VMs are limited by the regional CPU quota. Google recommends requesting quota adjustments ahead of a large expected rise in usage, because requests may need review.
• BIncorrect. Reservations count against CPU quota just like running VMs. A reservation larger than the available quota can't be created, so the quota still has to be raised.
• CIncorrect. The autoscaler can only create VMs within the project's available quota. Once the quota is used up, scale-out fails.
• DIncorrect. Committed use discounts lower the price of resources you commit to use. They don't increase quota.

Answer: A) Cloud Shell opened from the Google Cloud console in the browser

Cloud Shell gives a browser-based terminal with gcloud preinstalled. It needs no local install and no user-provisioned infrastructure.

• ACloud Shell is a web-based terminal with the gcloud CLI and other tools preinstalled. It needs nothing installed on the laptop and nothing provisioned by the user.
• BThis command is part of the gcloud CLI, so the CLI would have to be installed on the laptop, and that is not allowed.
• CCloud Workstations needs a workstation cluster and configuration to be set up, and it is billed. That breaks the no-provisioning requirement and is not the quickest option.
• DThis works through the browser, but the engineer has to create and pay for a VM, which the scenario rules out.

Answer: A) Artifact Analysis automatic scanning on the Artifact Registry repositories

Artifact Analysis automatic scanning starts whenever an image is pushed to Artifact Registry. It reports OS package vulnerabilities and keeps the results current as new vulnerability data arrives.

• AWith automatic scanning enabled, Artifact Analysis scans each new image when it is pushed to Artifact Registry. It then keeps updating vulnerability metadata for images that were pulled in the last 30 days.
• BOn-Demand Scanning only scans an image when someone explicitly calls it. That adds a step to every build and doesn't trigger automatically on push.
• CBinary Authorization decides at deploy time whether to admit an image based on attestations. It doesn't scan images for vulnerabilities itself.
• DWeb Security Scanner crawls deployed web applications for issues such as XSS. It doesn't inspect OS packages inside container images.

Answer: A) Shared VPC Admin enables the host project, creates the subnets, attaches the service project, then grants Network User on the two subnets before the app deploys

A Shared VPC rollout depends on order: enable the host project, attach the service projects, then grant compute.networkUser at the subnet level before the application deploys. This keeps central control of the network and least privilege for the app team.

• ACorrect. A Shared VPC Admin must enable the host project before attaching service projects. Granting compute.networkUser on only the selected subnets limits the Service Project Admin to those subnets. Doing these steps before the application deployment removes the dependency that would otherwise block the app team.
• BIncorrect. compute.xpnAdmin is a highly privileged role meant for central administrators. Granting it to an application team breaks the separation of duties and gives far more access than two subnets.
• CIncorrect. This bypasses central control of the network and creates rework. Moving VMs to another network later is a disruptive change rather than a coordinated rollout.
• DIncorrect. A project-level Network User grant allows use of every subnet in the host project, including subnets added later. That violates the requirement to use only two subnets.

Answer: A) Put both clusters behind a multi-cluster Gateway and raise the new cluster's HTTPRoute backend weight in steps while error rates stay healthy

A multi-cluster Gateway with weighted HTTPRoute backends lets you move traffic between clusters in small steps and revert right away by changing the weights. DNS cutovers, rolling updates and node draining can't do this.

• ACorrect. Multi-cluster Gateways support weight-based traffic splitting across cluster backends. You can send, for example, 10% of traffic to the new cluster, increase it gradually, and restore the old weights right away if errors appear. Because the change is made at the load balancer, client DNS caching doesn't slow it down.
• BIncorrect. Repointing a single record is an all-at-once cutover, not a gradual shift. Resolvers and clients may still ignore or cache past the TTL, so rolling back is neither instant nor fully controlled.
• CIncorrect. A rolling update controls how Pods are replaced inside one cluster. It does not split user traffic between two separate clusters, so it can't move traffic gradually from the old cluster to the new one.
• DIncorrect. Draining evicts Pods onto other nodes in the same cluster only. Workloads never move to a different cluster this way, and there's no traffic control to shift back to.

Answer: A) The APIs Explorer panel on the method's REST reference page

The APIs Explorer ('Try this API') on each REST reference page lets you fill in parameters, run a real request, and see the response without writing code. The API Library, Cloud Code, and client libraries either don't run individual methods or require installing tools and writing code.

• ACorrect. The APIs Explorer is a widget, titled 'Try this API', attached to each REST method's reference page. It shows a form for the method's parameters. When you click Execute, it sends a real request and shows the HTTP status and response body.
• BIncorrect. The API Library is where you find and enable APIs and view overview information. It doesn't provide a form for running individual API methods and inspecting their responses.
• CIncorrect. Cloud Code helps developers write, run, and debug applications from an IDE. It requires installing an extension and is not a no-code form for running individual REST methods from the documentation.
• DIncorrect. Client libraries are the recommended way to call Google Cloud APIs from application code, but using them means installing packages and writing code, which the developer wants to avoid.

Answer: A) Generate and save a terraform plan for each change, require infrastructure-owner approval of it, and apply it in staging before production

Google's Terraform guidance is to always plan first, save the plan, get approval from an infrastructure owner, and apply through an automated pipeline, with staging validated before production. Validation checks, workstation applies, and state versioning don't stop destructive changes.

• ACorrect. Google recommends always generating a plan, saving it, and applying it only after an infrastructure owner approves it. Reviewing the plan exposes planned deletions, and applying the change in staging first catches problems before production.
• BIncorrect. These steps check syntax, internal consistency, and formatting. They don't show which real resources would be changed or destroyed, so they would not have caught an unintended deletion.
• CIncorrect. Google recommends running Terraform through automated tooling so that every run has the same execution context and credentials. A code diff also doesn't show the planned resource changes the way a plan does.
• DIncorrect. Versioning state is useful for recovering the state file, but it neither prevents a destructive apply nor restores deleted resources or data.

Answer: A) Apply changes only through a Cloud Build pipeline that runs reviewed Terraform plans, and remove engineers' direct write IAM roles

To keep Terraform the source of truth, make a reviewed CI/CD pipeline the only way to apply changes and remove direct write permissions. Hiding diffs or patching state treats the symptom, not the cause.

• ACorrect. When the only way to change resources is a version-controlled pipeline that plans and applies Terraform, every change goes through code review. Removing direct write access stops out-of-band console edits, so drift doesn't build up and later plans stay predictable.
• BIncorrect. This hides drift instead of preventing it. The code stops describing the real configuration and unreviewed changes go unnoticed.
• CIncorrect. Editing state doesn't update the configuration code, so the code still differs from reality. Manual state edits also risk corrupting state, and console changes still bypass review.
• DIncorrect. Smaller modules may make plans easier to read, but engineers can still change resources outside Terraform, so the drift continues.