Select Two (Multi-Select) Questions

Use the default Logging retention of 30 days

Why it fails: Cloud Logging retains log entries for only 30 days by default (with custom retention options extending up to 3650 days, but still not independent of Logging). For a five-year audit requirement, relying on the default retention guarantees that data access logs older than a month will be permanently deleted. You need a log sink to export to Cloud Storage, where you can apply a bucket retention policy and lifecycle management for long-term archival.

Set up a Cloud Monitoring alert for any Data Access log entries

Why it fails: A Cloud Monitoring alert policy can be set to match Data Access log entries, but its purpose is to trigger notifications when certain events occur, not to store or preserve log data. The alert itself does not create a repository of logs, nor does it affect Logging's retention limits. It may be useful for real-time detection of unusual access, but it cannot substitute for the combination of enabling Data Access logs, exporting via a sink, and securing the destination bucket.

Enable the Service Account Key Rotator in the Google Cloud Console.

Why it fails: There is no built-in Service Account Key Rotator in the Google Cloud Console. While the console provides manual key creation, deletion, and disabling options, it does not offer a native automated rotation feature. To achieve rotation, you must either use the Service Account API's expiration fields or implement a custom automation such as a Cloud Function; a console 'rotator' simply does not exist.

Use IAM to set a condition that keys must have an expiration date.

Why it fails: IAM conditions allow you to grant access based on request-time attributes (e.g., resource tags, date/time, or originating IP) but cannot enforce or alter the properties of service account keys themselves. Key expiration is a lifecycle setting on the key resource, not an authorization constraint. Therefore, you cannot use an IAM condition to require that keys have an expiration date or to automatically rotate them.

Use an Organization Policy to disable service account key creation.

Why it fails: An Organization Policy can restrict or disable user-managed service account key creation across the hierarchy, but that is a safety control, not a rotation strategy. Disabling key creation prevents all new user-managed keys, which would block legitimate rotation workflows that need to create replacement keys. Additionally, this policy does not handle deletion or expiry of existing keys, so it cannot enforce a 90-day rotation cadence.

Deploy functions in a single region to minimize latency.

Why it fails: Deploying Cloud Functions in a single region creates an availability single point of failure: if that region experiences an outage, the function becomes completely unavailable, undermining reliability. While a single region can reduce cross-region latency, reliability demands a multi-region deployment with global load balancing or traffic splitting to decouple availability from regional failures. The latency benefit is typically outweighed by the risk of a total service outage.

Configure a VPC connector for all functions.

Why it fails: A VPC connector is designed solely to give Cloud Functions private access to resources inside a Virtual Private Cloud network, such as databases or internal APIs, not to improve reliability. It does not add redundancy, automatic retries, or failover capabilities, and it does not address the failure modes of the function itself. Enabling a VPC connector for every function can even introduce unexpected latency and deployment complexity without any availability benefit.

Set maximum instances to 1 to avoid resource contention.

Why it fails: Setting maximum instances to 1 artificially caps concurrency at a single running instance, so under load the platform scales only by throttling or queueing invocations, increasing latency and ultimately failing requests during traffic spikes. It also makes the application vulnerable to a single-instance crash, leaving no healthy replica to serve traffic. Reliability requires horizontal scaling and redundant instances, not restricting concurrency to avoid contention.

Cloud Audit Logs

Why it fails: Cloud Audit Logs — These logs record audit trails of administrative actions, data access, and system events within Google Cloud. They are a detective control: they help you review what happened after the fact, but they do not enforce or restrict any action during runtime. Policies are enforced at request time by the Organization Policy service, not by the logging subsystem. Therefore, while useful for compliance monitoring, Audit Logs cannot manage or govern multiple projects by preventing policy violations.

Shared VPC

Why it fails: Shared VPC — Shared VPC lets you centrally administer a common network across multiple projects, sharing subnets, firewall rules, and routes without duplicating network infrastructure. However, its scope is entirely network connectivity and address management; it does not enforce security policies or constraints on resource configurations, IAM permissions, or API usage. Shared VPC cannot block creation of non-compliant resources or mandate a particular setting. Consequently, it addresses networking centralization, not the company’s need for cross-project policy enforcement.

Labels

Why it fails: Labels — Labels are key-value pairs attached to resources to filter, categorize, and track cost allocations; they are metadata, not policy logic. The Organization Policy engine does not use labels to allow or deny actions, so labels cannot enforce constraints like disabling external IPs or restricting resource locations. Although IAM conditions can reference resource labels to grant roles conditionally, that is a fine-grained conditional permission, not an organization-wide enforcement control. Labels are therefore a tool for identifying or grouping resources, not for enforcing governance across multiple projects.

Specify the CMEK key in each instance template used for managed instance groups

Why it fails: Specifying a CMEK key in an instance template only defines the key to use when the template is consumed; it does not prevent someone from creating a VM or disk with a different template or via the plain `disks.create` API without any CMEK key. A managed instance group will happily use a template that omits the `kmsKeyName` field, resulting inGoogle-managed default encryption. Therefore, this is a configuration best practice, not an enforcement control, and it fails the requirement to 'enforce that all instances' use CMEK.

Grant the Cloud KMS Admin role to the project's compute service account

Why it fails: Granting `roles/cloudkms.admin` to the compute service account gives it full management permissions over Cloud KMS resources, including creating new key rings and keys, rotating, disabling, and destroying keys. The compute service account only needs the `roles/cloudkms.cryptoKeyEncrypterDecrypter` role on the specific key to encrypt/decrypt disks — the admin role is grossly over-privileged and actually expands the attack surface. It neither enforces disk encryption nor restricts when disks are created; it merely allows the account to administer keys.

Create a Cloud Audit Logs sink to monitor instances without CMEK

Why it fails: A Cloud Audit Logs sink routes log entries containing the resource data for Compute Engine activities, including `disks.insert` calls, to a destination like BigQuery or Pub/Sub. You could then query for disks that lack `kmsKeyName` in their request or resource metadata, but this is a detective control that only reports after the fact. It provides no prevention or enforcement mechanism, so noncompliant instances can still be created, and someone would have to manually respond to the logs.

Create a Cloud Router to advertise routes to Google.

Why it fails: A Cloud Router is used for dynamic BGP route exchange in Cloud VPN or Interconnect scenarios, not for enabling Private Google Access. Private Google Access relies on a subnet-level flag that instructs the VPC to route traffic destined for Google APIs over Google's private backbone, so there is no need to advertise routes to Google. Even if you created a Cloud Router, it would not grant private instances access to Google APIs; that access is controlled solely by the subnet's Private Google Access setting.

Configure Cloud NAT to route traffic to Google APIs.

Why it fails: Cloud NAT is used to give private instances outbound internet connectivity by translating their private IP addresses to a public IP for traffic to the internet. Private Google Access, in contrast, creates a direct private route to Google APIs over Google's own network, so no NAT is involved and no external IP is used. Configuring Cloud NAT would actually cause traffic to Google APIs to go out to the public internet (unless you add specific NAT rules), which defeats the purpose of Private Google Access and does not replace the subnet-level flag that enables it.

Use persistent disks to store application state.

Why it fails: Persistent disks do not solve the ephemerality of preemptible VMs; if the VM is terminated, a attached persistent disk can remain but you then have orphaned, still-billed storage. More importantly, application state should live in a durable, external service like Cloud Storage or Cloud SQL so that any new preemptible VM can resume work without relying on a specific disk that may not be cleaned up automatically. Relying on persistent disks for state couples your workload to a manually managed resource, which defeats the purpose of stateless, fault-tolerant batch processing.

Use Cloud Functions to monitor instance termination.

Why it fails: Cloud Functions can react to instance lifecycle events, but simply monitoring termination is not a top best practice because preemptible VM termination is an expected, normal occurrence rather than a failure. A more robust approach is to rely on Cloud Audit Logs or state externalized to a queue so work is automatically retried, rather than building a separate monitoring function that just tells you something you already assume will happen. Monitoring does not make the workload more resilient; it only adds cost and complexity without addressing the root cause of how the application handles interruption.

Use persistent disk snapshots for backup.

Why it fails: Persistent disk snapshots are designed to back up durable data on persistent disks, but preemptible VMs are intrinsically ephemeral compute resources; their local or attached disks are not a meaningful source of truth for a batch job because the VM may be terminated mid-run. Snapshots do not help you resume work on a different preemptible VM unless the state itself is already externalized, and they incur additional storage costs. For preemptible workloads, the correct pattern is to write output to Cloud Storage or another durable service and treat the VM as completely disposable.

Deployment

Why it fails: A Deployment manages replicas as interchangeable, stateless pods. It provides rolling updates and replica scaling, but each pod gets only an ephemeral hostname (e.g., `pod-abc123`) and no guarantee of stable storage. If multiple replicas share a PersistentVolume, concurrent writes cause corruption; a stateful app like a database requires each pod to have its own private, surviving disk and a fixed identity, which Deployments cannot provide.

ConfigMap

Why it fails: ConfigMap is an API resource for injecting non-confidential configuration data as environment variables, command-line arguments, or config files. It exists in etcd and is mounted into pods' filesystems as volumes, but those volumes are temporary and cannot store application-generated data. ConfigMap does not create or attach any persistent storage, so it has no role in persisting state for a stateful application.

Ingress

Why it fails: An Ingress resource controls external HTTP(S) access to services by routing traffic based on hostnames or paths, typically through a load balancer. It does not provision or attach any block or file storage, nor does it manage pod identity or persistence. Ingress operates at the network layer above the application and is irrelevant to the data-storage requirements of a stateful workload.

Set up a VPN between the instances and Cloud Storage.

Why it fails: Setting up a VPN between your instances and Cloud Storage is ineffective because Cloud Storage is a public service accessed via HTTPS, not through an encrypted tunnel to a private network. VPN tunnels are designed for hybrid connectivity to on-premises or peered VPCs, and any traffic traversing the tunnel still counts as egress from the VPC, potentially incurring normal data transfer charges. Adding a VPN introduces extra configuration and per-tunnel costs without eliminating the underlying egress meter.

Use a multi-regional Cloud Storage bucket.

Why it fails: A multi-regional Cloud Storage bucket replicates data across multiple geographic locations, but an instance accessing the bucket will be directed to the nearest replication point, which may be in a different region than the instance. That cross-region data read is billed as egress, potentially increasing rather than decreasing the network bill. Additionally, multi-regional storage has higher per-GB pricing than regional buckets, so choosing it works against the goal of reducing egress and storage costs.

Configure a Cloud NAT gateway.

Why it fails: Cloud NAT provides outbound internet connectivity for private instances, but it does not waive or reduce egress fees; every byte sent through the NAT gateway is billed at standard egress rates, plus you pay an hourly processing fee for the gateway itself. Configuring NAT also requires additional network plumbing, such as cloud router and firewall rules, adding operational overhead. Therefore, of these options, a Cloud NAT gateway is the least suitable for cutting egress costs.

API key

Why it fails: API keys are project-level identifiers attached to HTTP requests; they are not credentials that represent a user or service account. The gcloud CLI needs identity-based authentication to authorize actions on your behalf, and an API key cannot prove who you are or which permissions you have. Consequently, gcloud explicitly rejects API keys as an authentication method, although they are suitable for simple public API calls that do not require identity.

IdP token

Why it fails: An IdP token (e.g., a JWT from a third-party identity provider) is used with workload identity federation to exchange for Google-issued credentials via the Security Token Service, not used directly by the gcloud CLI. gcloud expects native credential formats like OAuth2 access tokens, service account keys, or application default credentials. To use an external IdP, you must first set up workload identity federation and call the token exchange API; simply supplying the IdP token to gcloud will not authenticate you.

Using a user account's OAuth2 tokens obtained via a web browser.

Why it fails: Using a user account's OAuth2 tokens obtained via a web browser is invalid for authenticating a service because user tokens represent the identity and consent of an individual end-user, not a service account. The OAuth2 flow for user accounts involves interactive browser login and multi-factor authentication, which is not designed for unattended server-side workloads. Moreover, the resulting tokens carry a different principal and do not grant the same IAM permissions as the service account, so they cannot authenticate or impersonate the service account in API calls.

Using an API key generated from the Cloud Console.

Why it fails: An API key generated from the Cloud Console is wrong for service account authentication because API keys only identify the calling project for quota and billing purposes; they do not authenticate a principal or establish an identity. API keys are typically used for accessing public data or APIs with project-level restrictions, and they are not accepted by IAM-aware methods that require an OAuth2 token or service account credentials. Therefore, an API key cannot prove that a request is being made by a specific service account.

Cloud Storage bucket

Why it fails: A Cloud Storage bucket stores objects; it plays no part in Compute Engine autoscaling. It is tempting because buckets commonly support web content delivery, but autoscaling requires an instance template and a managed instance group, which define the machine image and the scalable set of instances.

Cloud SQL instance

Why it fails: A Cloud SQL instance provides a managed relational database, not compute scaling. It is tempting because web applications typically need a database, but the question asks what enables autoscaling: an instance template and a managed instance group, which the autoscaler resizes on CPU metrics.

Cloud Function

Why it fails: A Cloud Function runs event-driven serverless code and cannot manage Compute Engine instance counts. It is tempting because serverless functions often handle automation, but autoscaling requires an instance template and a managed instance group, which the autoscaler resizes based on CPU utilisation.

A log sink

Why it fails: A log sink exports log entries from Cloud Logging to other destinations like Cloud Storage, BigQuery, or Pub/Sub. It is used for long-term retention, analysis, or streaming, but it does not evaluate log data for alerting conditions. Creating a sink alone will never trigger an alert; it only moves the data out of Logging.

A Cloud Pub/Sub topic

Why it fails: Cloud Pub/Sub can be a notification channel for an alerting policy, but a Pub/Sub topic itself is only a messaging infrastructure. You can publish alert notifications to a topic, but setting up a topic does not create an alert or define any monitoring condition. Alerts require a policy that references a metric and chooses a notification channel; the channel alone is passive.

An uptime check

Why it fails: An uptime check monitors the availability and latency of an external HTTPS or TCP endpoint from Google-managed locations. It does not inspect log content or support log-based conditions. You can configure alerting on an uptime check, but that is resource-availability monitoring, not log-based alerting; it is an entirely different tool from analyzing log entries.

Store the data in BigQuery and set an expiration on the table to delete data after 30 days

Why it fails: Setting a table expiration in BigQuery causes the entire table to be automatically deleted after 30 days, which would destroy all log data and violate the 7-year retention requirement. Table expiration is a blunt mechanism intended for ephemeral or temporary datasets, not for tiering historical data. It cannot be scoped to only old partitions and provides no cost benefit for retention — it simply purges data permanently.

Use BigQuery partitions based on ingestion time and set partition expiration to 30 days

Why it fails: BigQuery partition expiration based on ingestion time automatically deletes entire partitions once the partition reaches the expiration age, so all records older than 30 days are removed. This approach efficiently manages time-bounded, ephemeral datasets, but it does not meet the 7-year compliance requirement because the logs are permanently deleted. Partition expiration does not offer any archival or lower-cost storage tier; it is a data deletion mechanism, not a lifecycle transition.

Ingress

Why it fails: Ingress is an optional layer-7 HTTP/HTTPS routing resource, not a workload controller. It does not define or manage pods, nor does it provide a stable external IP on its own. A Service of type LoadBalancer already exposes the microservice with a static IP, so Ingress only adds value when you need host/path-based routing, TLS termination, or to expose multiple services behind a single load balancer. Without an Ingress controller installed, an Ingress resource has no effect.

ConfigMap

Why it fails: A ConfigMap is an API resource for storing non-confidential configuration data as key-value pairs, such as environment variables, command-line arguments, or config files. It does not manage pod lifecycles, perform scaling, or create external endpoints; it only injects configuration into existing pods. For deploying a new microservice, you can use ConfigMaps optionally to decouple configuration from the container image, but it is not a required component for deployment, exposure, or autoscaling. Omitting a ConfigMap has no effect on the availability or scaling of the microservice.

Set the --ingress=all flag on the Cloud Run service

Why it fails: Setting the --ingress=all flag on the Cloud Run service only controls whether the service accepts public internet traffic; it does not configure any DNS records, TLS certificates, or routing rules. This flag is about network access, not about mapping a custom domain or reducing latency across global regions. Since the service can already be set to allow all traffic by default, this option has no effect on the stated requirements.

Use Cloud CDN to cache content

Why it fails: Cloud CDN caches responses at Google's edge locations to reduce latency for repeated requests, but it does not bind a custom domain to the Cloud Run service. To use Cloud CDN, you must place it behind a global external HTTPS load balancer; by itself it provides no custom domain mapping or first-request latency improvement. The fundamental requirements of domain mapping and global low latency still need a load balancer and per-region deployments.

Deploy the service as a Cloud Run for Anthos on GKE

Why it fails: Deploying the service as Cloud Run for Anthos on GKE is not necessary for a managed Cloud Run application that needs a custom domain and global low latency. It adds cluster management overhead and still requires an external load balancer for global distribution. Cloud Run managed, combined with a global HTTPS load balancer, is a simpler and fully managed alternative that meets the same requirements.

A Service

Why it fails: A Service is not required for HPA to function; it exists to provide a stable network identity and load-balanced access to pods. HPA does not send traffic through a Service, nor does it need one to monitor metrics. Instead, the HPA controller queries the Kubernetes metrics API and directly updates the target workload's `scale` subresource. Services are relevant for exposing applications, not for determining replica counts.

A ConfigMap

Why it fails: A ConfigMap is used to inject non-sensitive configuration data into containers, such as environment variables or configuration files. It plays no role in autoscaling, because HPA makes decisions based solely on observed metrics like CPU, memory, or custom application metrics. The HPA controller never reads ConfigMaps to decide how many replicas to maintain, so its absence or presence has no effect on scaling behavior. ConfigMaps are purely an application-level configuration mechanism.

A NodePort service

Why it fails: A NodePort service is a variation of a Service that opens a specific static port on every node's IP address, used primarily for external access to your cluster. It is entirely unrelated to HPA functionality; autoscaling does not depend on how pods are exposed. Even if you remove all Services, HPA can still scale a Deployment based on metrics. Only networking aspects, such as reaching the application, would need a NodePort or another Service type.

Enable deletion protection on the primary instance

Why it fails: Deletion protection is a safety control that prevents accidental deletion of the instance, but it does not contribute to backup, recovery, or disaster recovery. It offers no data redundancy, no failover capability, and no way to restore lost data. It is an operational safeguard, not a DR mechanism, so it is irrelevant to the stated requirements.

Assign a public IP address to the read replica

Why it fails: A public IP address exposes the read replica to the internet, which is unnecessary and increases the attack surface. Disaster recovery works perfectly over private networking, and Google Cloud recommends using private IPs for better security and reduced latency. Public IP is neither a prerequisite nor a benefit for replicating data or promoting a replica during DR.

Enable uniform bucket-level access

Why it fails: Enabling uniform bucket-level access makes all permissions be controlled solely by IAM bucket-level policies, effectively disabling object-level ACLs. While this is a recommended hardening practice for simpler permission management, it is not required for CMEK or for a service account to access objects. The service account's access is determined by IAM roles like roles/storage.objectAdmin, which function independently of whether ACLs are uniform or fine-grained.

Create a service account and download its JSON key

Why it fails: Creating a new service account and downloading its JSON key is unnecessary because the service account referenced in the scenario already exists and access is granted through IAM bindings, not key files. A JSON key is a credential used for authentication, and downloading one does not itself grant any bucket permissions. In fact, generating a new key would require also assigning the appropriate IAM role to that new account and would introduce additional credentials that need to be securely managed.

Set the timeout to 900 seconds

Why it fails: Setting the request timeout to 900 seconds only controls the maximum duration of a single request; it does not influence how many instances are pre-warmed or how many requests each instance can process concurrently. Cold starts still occur when a new instance is spun up to handle additional traffic, and the per-instance concurrency remains unchanged. Therefore, this setting has no direct effect on mitigating latency spikes or idle-time warm-up.

Set CPU always on to true

Why it fails: Enabling CPU always on ensures that the instance's CPU is allocated even outside of request processing, which prevents throttling during startup or when shuffling data. However, it does not keep instances alive between requests, nor does it increase the number of requests that an instance can serve at once. Cold starts and concurrency limits are governed by instance count and concurrency settings, not by CPU allocation policies.

Set max-instances to a high value

Why it fails: Setting a high max-instances value does not prevent cold starts; it only raises the upper bound on how many instances Cloud Run may create. When traffic spikes, Cloud Run still spins up new instances from zero, and those new instances experience full cold-start latency. In fact, a high max-instances value can even exacerbate cold starts during sudden bursts because it allows the service to scale out aggressively, whereas a lower max might force more requests to queue on existing instances.