Question 1

The correct option is Create a single Cloud Logging sink with an advanced filter that exports only required entries to BigQuery and set table or partition expiration to control retention and costs.

This approach filters at the source so only the logs you actually need are exported to BigQuery which directly lowers ingestion and storage costs. You can use the Logging query language to build precise filters and the export remains simple to manage with one single sink with an advanced filter.

BigQuery provides native lifecycle controls so you can set table or partition expiration to automatically remove older data. This keeps long term analytics feasible while preventing unnecessary spend without building extra pipelines or manual deletion jobs.

Export all logs to Cloud Storage without filtering, process with Dataflow to remove unwanted records, then load curated results into BigQuery for historical reporting is inefficient because it exports everything and stores it before curation which increases storage and processing cost and complexity. It also adds unnecessary steps when you can filter directly at the sink and load only the needed entries into BigQuery.

Create one sink per log category and route to Pub/Sub for streaming analysis, then write into BigQuery using a Dataflow pipeline adds operational overhead and cost that the scenario does not require. Pub/Sub and Dataflow are suited to real time streaming use cases, yet the goal here is controlled long term analytics in BigQuery with simple retention, which is met by filtering at export and using BigQuery expiration.

Export every log to BigQuery without filters and later use SQL to select the needed records, then rely on BigQuery Data Transfer Service to manage retention drives up ingestion and storage cost and does not solve retention. The BigQuery Data Transfer Service does not manage table retention, while table or partition expiration is the correct mechanism.

Question 2

The correct option is Artifact Registry scanning with Cloud Build gate.

This approach uses Artifact Registry vulnerability scanning to evaluate images as they are pushed and it records severity information that can be queried. A Cloud Build pipeline can check the scan results and fail the build when high severity issues are found which prevents the deployment to GKE. Because the gate runs before deployment it ensures that noncompliant images never reach the cluster.

Binary Authorization with signed images focuses on verifying signatures and provenance rather than evaluating vulnerability severity. Without a policy tied to vulnerability scan results or an attestation for vulnerabilities it would not automatically block deployment for high severity findings, so it does not meet the requirement as stated.

GKE default configuration does not perform vulnerability scanning and it does not block deployments based on vulnerability severity by default.

Cloud Deploy only orchestrates releases and can run verifications, yet it does not scan images on its own and cannot enforce a severity based block without integrating with a scanner or a build step.

Question 3

The correct choice is Create a regional managed instance group that distributes instances across at least two zones in the region.

This design places identical instances in multiple zones within the region, which removes the single zone as a point of failure. When you place the group behind an external HTTP(S) Load Balancer, health checks quickly detect a zonal failure and the load balancer routes traffic only to healthy instances in the surviving zones. This provides automatic failover without manual steps and can meet a recovery time objective under 45 seconds with typical health check settings.

Managed instance groups also provide autohealing and uniform configuration which increases resilience and keeps the fleet consistent as traffic shifts across zones.

Use a zonal managed instance group and enable automatic restart and live migration is not sufficient because a zonal group keeps all instances in one zone. Automatic restart only restarts a VM in the same zone and live migration helps during host maintenance events. Neither solves a full zonal outage and traffic cannot shift to another zone automatically.

Configure an external HTTP(S) Load Balancer with a single backend service in one zone does not meet the requirement because when that zone fails all backends become unhealthy and the load balancer has nowhere else to send traffic. There is no cross zone redundancy.

Use Cloud DNS failover to switch between two unmanaged instance groups that both run in the same zone cannot work because both groups are in the same zone and would fail together. DNS based failover is also constrained by record time to live and client caching which can exceed 45 seconds, and unmanaged instance groups do not provide autohealing.

Question 4

The correct option is Cloud KMS with automatic rotation.

Cloud KMS centrally manages cryptographic keys with fine grained IAM, audit logging, and organization wide visibility. It supports key rotation policies that automatically create new key versions on a schedule which limits the blast radius if a key is exposed. For the strongest protection, Cloud KMS also allows HSM backed keys using the HSM protection level while still benefiting from the same central management and automatic rotation capabilities.

VPC Service Controls protects access to Google Cloud APIs by creating service perimeters to reduce data exfiltration risk. It does not create, store, rotate, or manage cryptographic keys, so it does not meet the requirement.

Secret Manager stores application secrets such as API keys and passwords and is not a key management system. While you can rotate secrets, it does not centrally manage or automatically rotate cryptographic keys like Cloud KMS.

Inject secrets at provisioning describes an operational pattern rather than a Google Cloud service. It does not provide centralized key management or enforce automatic key rotation.

Question 5

The correct option is Add an exclusion on the _Default sink that filters out workload entries with resource.type = “k8s_container” and severity ⇐ DEBUG.

This exclusion prevents chatty application container logs at low severities from being ingested into Cloud Logging, which directly reduces logging costs. It leaves GKE system and control plane logs untouched because those are not emitted with the k8s_container resource type. Developers can continue to use kubectl logs for development troubleshooting while the project retains GKE operational visibility in Cloud Logging.

Run gcloud container clusters update dev-west1 –logging=SYSTEM for the development cluster is not the best choice because it disables all workload log collection and it also omits API server logs unless you explicitly include them. The requirement is to keep GKE operational logs for troubleshooting and this change can remove important control plane visibility.

Run gcloud logging sinks update _Default –disabled in the development project is incorrect because disabling the default sink broadly stops routing most logs, including crucial GKE system and control plane logs. That violates the requirement to retain operational logs.

Create a Log Router sink that exports all k8s_container logs to BigQuery and set table expiration to 2 days does not reduce Cloud Logging ingestion costs because logs are ingested before export, and it introduces additional BigQuery storage and query costs. It also adds little value given the lack of a common schema and the developers reliance on kubectl logs.

Question 6

The correct option is Private pools for Cloud Build.

Private pools for Cloud Build run your builds on dedicated workers in your project that you can connect to your VPC. Builds run without public IP addresses and can reach internal endpoints over private RFC 1918 addresses. This directly satisfies the need to call internal APIs without using public endpoints. Because private pools are a managed Cloud Build feature, you get minimal operational overhead while keeping network control in your project.

Cloud Deploy is a release orchestration service that promotes artifacts to targets. It does not provide a private network execution environment for builds and therefore does not meet the requirement for private VPC access during build time.

Internal HTTP(S) Load Balancer exposes internal services behind an internal frontend, but it does not change how Cloud Build workers connect. Using this alone would not place builds inside your VPC, so it does not ensure private build connectivity without public endpoints.

External HTTP(S) Load Balancer with Cloud Armor is designed for public endpoints with web security policies. It relies on public access which conflicts with the requirement to avoid public endpoints for build traffic and it adds unnecessary complexity for this use case.

Question 7

The correct option is Appoint an Incident Commander, assign distinct Communications and Operations leads, and coordinate in a persistent real time chat channel for collaboration and decision tracking.

This approach creates clear ownership and decision making which reduces confusion and speeds restoration. The Incident Commander directs priorities and risk, the Operations lead focuses on technical diagnosis and changes, and the Communications lead provides timely and consistent stakeholder updates. A persistent real time chat channel gives all responders a single place to collaborate, capture decisions, and maintain context which supports handoffs and later review.

Ask one engineer to fill every role including Incident Commander, Communications Lead, and Operations Lead and use only email threads to share updates is inefficient and risky because it overloads one person and creates bottlenecks. Email is not a real time medium for coordination and it fragments information which slows decision making during a critical outage.

Let all responders work independently without assigning roles and coordinate through ad hoc messages to reduce overhead leads to duplicated work, conflicting actions, and unclear authority. High severity incidents need explicit roles and a single channel to keep actions aligned and safe.

Create a Cloud Pub/Sub topic for the incident and post updates there while leaving roles informal to save time misuses a system to system messaging service and does not support human collaboration. Leaving roles informal increases confusion and risk while Pub/Sub does not provide the interactive discussion and decision tracking that incident response requires.

Question 8

The correct option is Standard Tier with a regional external HTTP(S) Application Load Balancer.

This choice keeps traffic within the region and uses the Envoy based regional external Application Load Balancer that is designed for localized audiences. It avoids global anycast and long haul transit which reduces egress and data processing costs while still providing a public endpoint for users in the UK.

Premium Tier with a global external HTTP(S) load balancer is unnecessary for a UK only audience because it uses global anycast and worldwide edge presence which typically costs more and is intended for global reach.

Standard Tier with a regional internal HTTP(S) load balancer cannot serve a public website because it is only reachable on internal IP addresses within your VPC and therefore does not meet the requirement for an external site.

Premium Tier with a regional external HTTP(S) load balancer provides no benefit for a single region UK audience and generally costs more than Standard Tier for the same regional delivery so it does not minimize cost.

Question 9

The correct option is Require peer review and approval for every change before it is rolled out.

Requiring peer review and approval adds a second knowledgeable person to validate intent, scope, and blast radius before any configuration is applied. This practice helps catch mistakes like an overly broad deny rule and creates an auditable control point. You can implement peer review and approval with infrastructure as code and gated promotions in your build and deploy pipelines which aligns with recommended safe change practices.

Perform firewall updates only during a scheduled maintenance window is not a preventive control. The incident already happened during a change window and a window does not reduce the chance of a bad rule being pushed. It only limits when changes occur.

Automate all infrastructure updates so that humans do not edit resources directly is valuable but incomplete. Automation without peer review and approval can push a bad change faster to more systems. The better control is to combine automation with review.

Enable VPC Firewall Rules Logging and alert on high deny rates in Cloud Monitoring helps with detection after the fact. It does not prevent the misconfiguration and users can still be impacted before alerts are processed and acted upon.

Question 10

The correct option is Secret Manager with IAM for Cloud Build and GKE.

This service centrally stores secrets and provides fine grained access control through IAM which lets you grant only the Cloud Build service account and the GKE Autopilot workloads the permissions they need. You can set a rotation policy for every 60 days and rely on secret versioning so pipeline and workload configurations can reference the latest version without any code changes. It reduces the risk of leaking values in source or logs because the platform retrieves secrets at runtime and masks secret values in build logs when used through supported integrations.

Cloud Storage with CMEK is designed for object storage and customer managed encryption keys do not provide secret specific features like automatic rotation, versioned secret access, or tight IAM bindings at the secret level. Using it for secrets increases operational overhead and the risk of accidental exposure.

Check Kubernetes Secrets into Git exposes sensitive data in source control and audit trails which violates best practices and makes rotation error prone and manual.

Cloud KMS encrypted blobs in repo uses a key management service rather than a secret management service which requires custom encryption and decryption handling in the pipeline, risks accidental logging during decryption, and complicates rotation since you would have to re encrypt and update references rather than simply advancing a secret version.

Question 11

The correct options are Use Cloud Trace to analyze distributed latency and pinpoint bottlenecks so you can tune the service and Configure Cloud Monitoring to collect CPU and memory metrics for all services and create alerting policies with threshold conditions.

Use Cloud Trace to analyze distributed latency and pinpoint bottlenecks so you can tune the service directly addresses application performance in a microservices environment. Tracing shows end to end request paths and highlights where latency is introduced so you can focus optimization on the most impactful services and calls. It also helps validate improvements by comparing traces before and after changes.

Configure Cloud Monitoring to collect CPU and memory metrics for all services and create alerting policies with threshold conditions provides the resource visibility you need. System metrics like CPU utilization and memory usage reveal saturation and inefficiencies across services. Threshold based alerting notifies you early when resources approach unsafe levels so you can intervene or scale appropriately and it ties cleanly into dashboards and SLO monitoring.

Turn off Cloud Logging to reduce latency and lower resource usage is incorrect because turning off logs removes critical observability and does not reliably improve performance. A better approach is to tune log levels, use sampling and exclusions, and retain essential logs for troubleshooting and security.

Publish a custom “requests_per_second” metric to Cloud Monitoring and configure Cloud Run to autoscale directly from that metric is incorrect because Cloud Run fully managed does not autoscale from custom Cloud Monitoring metrics. It scales based on request concurrency and configured min and max instances so you cannot wire a custom requests per second metric to control scaling.

Deploy an in house Prometheus and Grafana stack instead of using the operations suite for monitoring is incorrect because the requirement is to use the operations suite. Running your own stack adds operational overhead and duplicates capabilities that are already provided natively including integrations, alerting, and dashboards.

Question 12

The correct option is Diff the last known good cloudbuild.yaml against the current Git revision and revert or fix the regression.

This approach follows change focused troubleshooting and safe rollback practices. The build broke right after a configuration change which strongly suggests the failure is change induced. Comparing the last known good configuration with the current revision quickly isolates the exact regression. Reverting to the known good state restores delivery fast while you continue root cause analysis in a controlled and auditable way. Using version control keeps the pipeline reproducible and prevents side effects from ad hoc fixes.

Disable the build trigger then build and push images from a developer laptop is risky and violates reproducibility and supply chain controls. It bypasses Cloud Build automation and auditability and can introduce untracked differences in toolchains and credentials which increases risk during an incident rather than reducing it.

Increase the Cloud Build timeout and run the build again treats a symptom that is not indicated by the scenario. The failure started after a configuration change which points to a logic or config error rather than a time limit. Increasing the timeout delays feedback and does not address the root cause.

Rotate the credentials used by the Cloud Build push step then run the build again is not aligned with the trigger for the failure. The issue followed a cloudbuild.yaml change rather than an authentication event. Rotating credentials without evidence can add new variables and create further disruptions.