Select Two (Multi-Select) Questions

Use the default Logging retention of 30 days

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Persistent Disk

Why wrong: Persistent Disks are block-level storage that can be attached to Compute Engine instances. While read-only multi-attach is possible, read-write multi-attach is not supported, and Persistent Disks cannot be shared across zones as a writable file system. A legacy application requiring a POSIX-compliant shared file system with NFS semantics therefore cannot rely on Persistent Disk.

Cloud Storage FUSE

Why wrong: Cloud Storage FUSE mounts a Cloud Storage bucket as a local file system using the FUSE kernel interface, but it is not a POSIX-compliant file system. It lacks support for features like file locking, appending writes, and consistent random I/O, and performance is far below that of a managed NFS service. This makes it unsuitable for legacy applications that demand strong consistency and low-latency file access.

Cloud Run

Why wrong: Cloud Run is a fully managed serverless compute platform that runs stateless containers; it is not a storage service. It cannot provide shared file systems or persistent NFS mounts to external resources. While Cloud Run can attach to Filestore or Cloud Storage volumes, it does not offer any storage capability of its own, making it an incorrect answer for a storage-focused migration need.

Deploy functions in a single region to minimize latency.

Why wrong: 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 wrong: 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 wrong: 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.

A log sink

Why wrong: 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 wrong: 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 wrong: 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.

Grant the roles/storage.admin role at the bucket level.

Why wrong: Granting roles/storage.admin at the bucket level is incorrect because this role grants full management control, including deleting the bucket and its objects, overwriting objects, and modifying IAM policies. For a workload that only needs to read data, such as a Compute Engine instance processing files, the principle of least privilege dictates using roles/storage.objectViewer instead. This overly permissive role increases the blast radius if the instance's credentials are compromised.

Grant the roles/storage.objectViewer role at the project level to the service account.

Why wrong: Assigning roles/storage.objectViewer at the project level to the service account would allow the instance to view objects in every bucket within the project, not just the intended one. This broad scope violates least privilege and could expose sensitive data stored in unrelated buckets. The correct approach is to grant this role at the specific bucket level, scoped to the custom service account, so access is limited to only the necessary resources.

Use the default Compute Engine service account.

Why wrong: Using the default Compute Engine service account is problematic because it typically has the project Editor role, which grants read/write access to most Google Cloud services, not just storage. This broad permission set contradicts the least-privilege model and makes it difficult to audit what the instance can actually do. A dedicated custom service account with only the required storage role should be created instead.

roles/secretmanager.viewer

Why wrong: roles/secretmanager.viewer is insufficient because it only allows listing secrets and viewing secret metadata such as labels, replication, and IAM policies, but not reading the actual secret versions. The Viewer role does not include the secretmanager.versions.access permission, so an application needing the real secret value would fail with a permission denied error.

roles/pubsub.admin

Why wrong: roles/pubsub.admin grants full control over the entire Pub/Sub service, including creating and deleting topics and subscriptions, seeking or deleting subscriptions, managing snapshots, and setting IAM policies. Using this role just to publish messages vastly exceeds minimum necessary access and could allow an attacker who compromises the credentials to destroy topics or eavesdrop by creating subscriptions.

roles/secretmanager.admin

Why wrong: roles/secretmanager.admin is a management role that can create, update, and delete secrets and versions, set IAM bindings, and enable or disable versions. Because it includes far more than the read access needed, it violates least privilege and introduces risk of accidental or malicious deletion or exfiltration of all secrets managed by the project.

Create a log sink to BigQuery for the bucket's admin activity logs.

Why wrong: Creating a log sink to BigQuery for the bucket's admin activity logs is incorrect because a log sink merely exports existing log entries to a destination and does not enable any logging itself. Admin Activity logs, even if exported, record configuration changes like bucket IAM updates or lifecycle changes, not read/write access attempts against objects. To capture audit trails of data access, you must enable Data Access audit logs for Cloud Storage, which is the only way to generate the relevant log entries in the first place.

Enable Admin Activity audit logs for the bucket.

Why wrong: Enabling Admin Activity audit logs for the bucket is incorrect because Admin Activity logs capture operational changes to the bucket's configuration, such as creating, deleting, or changing IAM policies, but never capture data access requests like GET or PUT on objects. Since the security engineer wants to audit *attempts to access* the bucket, these logs would miss all object-level reads/writes. Only Data Access audit logs provide that level of detail; Admin Activity logs are enabled by default but serve a completely different purpose.

Use labels to separate departments

Why wrong: Labels are for metadata, not for policy enforcement.

Apply IAM policies at the project level only

Why wrong: To enforce department-level policies, apply at the folder level.

Use Cloud Monitoring to track costs

Why wrong: Monitoring is for resource metrics, not billing.

Create separate billing accounts for each department

Why wrong: Overly complex; labels suffice.

billing.accounts.create

Why wrong: Wrong. The billing.accounts.create permission grants the ability to create new billing accounts, a write operation that changes the billing landscape. Listing existing billing accounts requires no such creation capability, so adding this permission is unnecessary and violates the principle of least privilege by granting harmful administrative power to the role.

resourcemanager.projects.create

Why wrong: Wrong. The resourcemanager.projects.create permission allows the creation of new Google Cloud projects. This is unrelated to listing billing accounts; it does not contribute to the ability to view billing information. Including this permission would broaden the custom role's scope to project lifecycle management, which is far beyond the required functionality.

resourcemanager.projects.delete

Why wrong: Wrong. The resourcemanager.projects.delete permission enables the permanent deletion of Google Cloud projects, a destructive and irreversible action. It provides no assistance in listing billing accounts or projects, and including it in a custom role for read-only billing visibility would introduce a severe security risk and violates least privilege.

Cloud Audit Logs

Why wrong: 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 wrong: 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 wrong: 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.

Billing Account

Why wrong: Billing accounts are not nodes in the GCP resource hierarchy; they operate as separate external entities linked to projects for cost tracking and payment. A single billing account can be attached to many projects and sits at a level independent of Organization, Folders, and Projects. The hierarchy only governs resource containment and policy inheritance, not financial management, so billing accounts are not a hierarchical component.

Cloud Identity

Why wrong: Cloud Identity is incorrect because it is an identity-as-a-service (IDaaS) platform that supplies user accounts, groups, and SSO configuration, but it is not a container within the resource hierarchy. The resource hierarchy consists solely of Organization, Folders, Projects, and resources; Cloud Identity provides the principals (users/groups) that are referenced in IAM policies. Therefore, it exists alongside the hierarchy as an identity source, not as a structural node.

gcloud compute networks subnets create my-subnet --network my-vpc --region us-central1 --range 10.0.0.0/24

Why wrong: This command is incomplete because it creates a subnet but omits the --enable-private-ip-google-access flag, leaving Private Google Access disabled for that subnet. While it successfully creates an IP range and attaches the subnet to my-vpc, instances in that subnet would need external IP addresses or a Cloud NAT to reach Google APIs, which contradicts the requirement for private access. Therefore, the missing flag makes this option fail the full requirement.

gcloud compute firewall-rules create allow-http --allow tcp:80

Why wrong: This command creates a firewall rule allowing TCP port 80 traffic, but it does not contribute to creating a VPC or a subnet, which is the stated goal. Firewall rules are network-level security controls applied after a network and subnets exist, so running this command alone would fail because the network my-vpc may not even exist yet, and it has no effect on subnet mode. It is irrelevant to the task.

gcloud compute networks create my-vpc --subnet-mode auto

Why wrong: This command creates a VPC in auto subnet mode, where Google automatically creates subnets in every Google Cloud region using a predefined IP range. That is the opposite of custom mode, which starts with no subnets and lets the engineer define them manually, so this command would not satisfy the requirement for a custom subnet mode VPC. It could be corrected by changing --subnet-mode auto to --subnet-mode custom.

--timeout

Why wrong: The `--timeout` flag is optional because there is a default timeout of 60 seconds that governs the maximum execution time allowed for your function. You can extend it up to 540 seconds for HTTP-triggered functions, but for Pub/Sub triggers it remains configurable. This flag does not affect how the function is triggered or deployed; it only sets a limit on how long the function can run before being terminated.

--memory

Why wrong: The `--memory` flag is optional and defaults to 256MB, which sets the amount of memory allocated to each function instance. Memory allocation also proportionally affects the CPU and other resources, so a higher value can improve performance, but it is purely a configuration tuning knob. Leaving it unset does not impact the ability to deploy a Pub/Sub-triggered function, since the default is reasonable for many workloads.

--entry-point

Why wrong: The `--entry-point` flag is not required because it defaults to the name of the deployed function (the name you supply in the gcloud command). It is only needed when the exported function name in your source code differs from the deployment name, allowing you to map a short deployment name to a longer or differently named function in code. Omitting it causes the platform to look for a function with the exact deployment name, which works in most cases.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.