How Google Cloud Resources Are Managed practice questions

The billing account has not been linked to the project

Why wrong: Linking the billing account to the project is a prerequisite for enabling export, but the export configuration would fail during setup if the link were missing. An existing export table with no rows suggests that the account is correctly linked; otherwise, the table likely would not exist or the export job wouldn't be available. The persistent empty table is due to the dataset being in an incompatible region, not to the billing project association.

The BigQuery dataset is in a different region than the billing account's default region

Why wrong: The Cloud Billing export service requires the BigQuery dataset to reside in the same multi-regional location (US or EU) as the billing account's country. When the dataset is created in a single region such as us-central1 or europe-west1, the scheduled export job cannot legitimately write data, resulting in zero rows. The billing account's default region is part of its configuration, so moving the dataset to the matching multi-region (or recreating it there) resolves the issue.

The billing export tables are only updated monthly

Why wrong: Billing export tables are updated daily (or even more frequently for detailed usage data), not monthly. If data were only updated monthly, you would still see a monthly aggregation once the export runs; the symptom of entirely missing rows points to a configuration failure like a region mismatch, not a scheduling interval. This misconception can lead teams to wait for a refresh that will never fix the actual problem.

Set up budget alerts to monitor spending

Why wrong: Budget alerts are a financial governance tool: they notify you when forecasted or actual spend crosses thresholds (e.g., 50%, 90%, 100%) but they do not change the infrastructure behind the spending. Setting an alert simply gives visibility into costs after they accrue, and it cannot prevent charges or reclaim unused resources. An alert may prompt you to take corrective action, but the alert itself is never a cost-optimization mechanism in the same way as resizing, discounting, or choosing interruptible instances.

Rely solely on sustained use discounts for all instances

Why wrong: Sustained use discounts (SUDs) are automatic and require no commitment: any VM that runs for more than 25% of a month earns incremental discounts per month of sustained usage, with maximum savings of roughly 20–30% for most machine types. For an always-on 24/7 workload that runs 100% of the month, SUDs do apply automatically—but they cap out well below the 70% discount available from a committed use discount. Therefore, relying solely on SUDs leaves significant savings on the table for predictable, always-on workloads, because you are not making the tradeoff of a commitment that CUDs reward.

Set up a budget alert to notify when untagged resources are created.

Why wrong: A budget alert monitors actual cost against a budget threshold and sends a notification, but it does not inspect resource labels or metadata. It triggers based on spending amounts, not on the creation of untagged resources, so it neither prevents nor corrects missing labels. As a result, this approach has no effect on enforcing a 'team' label at creation time.

Create a folder per team and apply labels at the folder level.

Why wrong: Labels are not inherited in Google Cloud: placing a label on a folder only tags the folder resource itself, not the projects or resources inside it. Folder-level labels can help with billing aggregation at the folder level, but they do not propagate to individual compute instances, buckets, or other resources. Therefore, this approach would still leave resources untagged and fail to provide per-team spending at the granularity required.

Run a weekly script to tag untagged resources.

Why wrong: A weekly script that retroactively tags untagged resources is a corrective measure, not a preventive one, leaving a window where resources created after the script run remain unlabeled. Scripts also depend on the script's execution schedule and may fail to catch resources that are terminated or modified before tagging. This approach is fragile and does not guarantee that every resource is labeled from the moment it is provisioned, so it cannot reliably enforce the tagging requirement.

The resourcemanager.projects.create permission

Why wrong: The resourcemanager.projects.create permission is required to create a project. Without it, you cannot create a project even with the CLI.

A billing account linked to the project

Why wrong: A billing account must be linked to the project because projects require a valid billing account to use billable resources.

Enabling the Cloud Resource Manager API

Why wrong: The Cloud Resource Manager API must be enabled to create projects. It is enabled by default in new projects, but it must be enabled if using the CLI or API for the first time.

Apply an allow policy at the project level and a deny policy at the resource level.

Why wrong: This approach misunderstands where organization policy constraints can be applied: they are set at the project, folder, or organization node, not on individual resources such as a VM instance. Moreover, if a deny policy were somehow applied at a lower resource level, it would still conflict with and be superseded by higher-level deny rules, and a project-level allow would not override an effective deny from any ancestor. This design also provides no mechanism to identify the specific exception project as an exception.

Apply a deny policy at the organization node and an allow policy at the project level.

Why wrong: Because deny policies take precedence over allow policies at any level of the hierarchy, an organization-wide deny would block all projects, including the one you want to exempt, regardless of a project-level allow. This design also misses the need to conditionally scope the deny based on tags; without a conditional enforcement, the exception project has no way to opt out. The only way to carve out an exception is to use a tag-based condition on the deny policy itself, not to append an allow.

Use IAM roles to restrict VM creation only in the production folder.

Why wrong: IAM roles govern who can perform actions (e.g., `compute.instances.create`) and apply to identities, whereas the requirement is to prevent a specific configuration—assigning a public IP—across all departments. Restricting VM creation to the production folder would stop teams from creating VMs elsewhere, but the actual business need is to allow VM creation everywhere while blocking only public IP address assignment. That configuration-level constraint must be enforced by an organization policy, not IAM authorization.

Use the gcloud command 'gcloud compute instances list --filter labels:team' to list resources with the label.

Why wrong: This lists only resources that have the label, not missing ones.

Use the Cloud Console to manually check each resource.

Why wrong: Manual checking is inefficient for many resources.

Set up a budget alert for resources without labels.

Why wrong: Budget alerts are not label-aware.

Enhanced

Why wrong: Incorrect. Enhanced Support provides a 1-hour response time for P1 incidents and does not include a Technical Account Manager (TAM).

Standard

Why wrong: Standard support is designed for businesses running production workloads, but it only guarantees business-hours access for non-critical issues and a response time of 4 hours for P2 during those hours. For P1 incidents, the target is generally 1 hour, which is still far short of the 15-minute requirement. This limitation makes Standard ineligible for the stated need.

Basic

Why wrong: Basic support is the free tier bundled with all Google Cloud accounts, providing only access to documentation, community forums, and no direct technical support from Google engineers. There are no response-time SLAs at all, so it cannot meet any critical response requirement. The 15-minute escalation time is therefore completely out of reach with the Basic plan.

IAM Conditions

Why wrong: IAM Conditions can restrict a principal's access to resources based on attributes like resource tags, name, or creation timestamp, but they are evaluated during an access attempt, not during resource creation or update. Even if a condition references a label, it cannot require that a resource be created with that label—it only denies operations when the attribute is absent, leaving the resource unlabeled and non-compliant. Thus, IAM Conditions are a fine-grained authorization tool, not an enforcement mechanism for resource metadata like labels.

Active Assist recommendations

Why wrong: Active Assist recommendations are advisory insights generated by machine learning to help optimize cost, security, and performance—for example, suggesting idle resource deletion or IAM policy simplification. These appear in the Recommender console and can be used to detect resources that lack labels, but they never block resource creation or mutation operations. Relying on Active Assist would only flag problems after the fact and still require manual or scripted remediation, so it cannot enforce label presence as a policy.

Cloud Audit Logs

Why wrong: Cloud Audit Logs record who performed which administrative or data-access actions, and when, producing an immutable trail that can be queried to identify unlabeled resources after they were created. They are purely observational: logs are written after an operation completes, so they cannot prevent the creation of a resource that violates labeling rules. Enforcement of label requirements must happen at the policy layer, not through logging, making Audit Logs a detection tool rather than an enforcement mechanism.

The project has exceeded the default service quota

Why wrong: Exceeding the default service quota is unrelated to budget alerts. Quotas limit resource usage, not spending.

The budget amount is lower than the committed use discount amount

Why wrong: Committed use discounts affect costs but do not prevent budget alerts from triggering. The budget amount being lower than the discount amount is not a relevant factor.

The budget was created at the project level, but alerts can only be set on billing account budgets

Why wrong: This is incorrect because project-level budgets also support alerts. Budget alerts can be set at both project and billing account levels.

Change all VMs to n1-standard-1 instances

Why wrong: Changing all VMs to n1-standard-1 instances is a blunt, uniform sizing action that ignores each workload's actual CPU/memory requirements, potentially causing performance degradation, OOM errors, or the need to spin up additional instances to compensate. It does not invoke any Google Cloud discount mechanism such as committed use discounts (CUDs) or sustained use discounts, and instead may increase total cost if the minimal machine type forces horizontal scaling. For a product running 24/7, this action is not a reliable cost-reduction strategy.

Enable sustained use discounts

Why wrong: Sustained use discounts are automatically applied for each Compute Engine VM that runs for more than 25% of a billing month, with discounts increasing incrementally up to 30% for full-month usage. For a 24/7 product, all always-on VMs will automatically qualify, providing a direct, no-commitment cost reduction. This makes enabling sustained use a valid and immediate action, though note that committed use discounts (CUDs) may provide even larger savings for steady-state workloads.

Use preemptible VMs instead of regular VMs

Why wrong: Preemptible VMs offer deeply discounted prices but are designed for fault-tolerant, batch-style workloads because Compute Engine can terminate them at any time within 24 hours (typically after a short notice). A 24/7 product relying on these VMs would risk sudden downtime, loss of work, and inability to meet availability SLAs. Therefore, they are not a suitable cost-reduction mechanism for a continuous service, despite their lower price.

Create separate Cloud SQL instances for each team

Why wrong: Creating a separate Cloud SQL instance per team eliminates resource sharing, so each team's costs are directly attributable to its own instance. However, this approach duplicates infrastructure, increases administrative overhead, and underutilizes capacity because each instance requires its own compute, storage, and backup resources. It doesn't allocate costs of a shared instance; it avoids sharing altogether, typically raising total cost of ownership.

Purchase committed use discounts for the instance

Why wrong: Committed use discounts (CUDs) are a purchasing model that reduces the effective hourly price of a Cloud SQL instance in exchange for a 1- or 3-year commitment to a minimum usage level. While CUDs lower the total bill, they are purely a pricing optimization and provide no mechanism to identify which team or workload consumed the resources. They do not assign costs to cost centers; they just reduce the amount of money that would need to be allocated.

Use a budget for each team at the project level

Why wrong: Project-level budgets in Google Cloud are threshold alerts that notify billing administrators when cumulative spending exceeds a defined amount, helping monitor overruns. Budgets do not allocate or break down costs of a shared resource across teams; they only track the aggregate spend against a limit. To attribute a shared Cloud SQL instance's cost to multiple teams, you need granular usage and labeling data, not a spend alert mechanism.

Organization node

Why wrong: The organization node is the root of the GCP resource hierarchy and is designed for organization-wide governance, such as defining globally applicable IAM policies, audit logging, and VPC Service Controls. It does not function as a grouping container for related projects; instead, it serves as a single top-level administrative boundary. Using it to group projects by team or environment would conflate organization-level governance with project organization, and it cannot provide the independent, sub-hierarchical structure needed for project grouping.

Project

Why wrong: A project is the base-level container that holds all of your GCP resources, such as Compute Engine instances, Cloud Storage buckets, and BigQuery datasets. It is an isolated unit with its own IAM policy, quotas, and billing account, and it cannot contain other projects as children. While projects can be linked through Shared VPC or organization policies, the project itself is not a hierarchical grouping construct; rather, it is the level at which resources are managed and monitored.

Resource

Why wrong: In GCP, the term 'resource' refers to the individual services you provision, such as a virtual machine, a storage bucket, or a Cloud SQL instance. These resources reside inside projects and are the finest-granularity entities in the hierarchy; they have no capability to contain or organize other resources or projects. Resources inherit policies from their parent project or folder, but they cannot act as grouping containers, making them entirely unsuitable for the requirement to group related projects.

Configure a service perimeter in VPC Service Controls

Why wrong: VPC Service Controls establishes security perimeters around Google-managed APIs such as BigQuery, Cloud Storage, and Pub/Sub to prevent data exfiltration by untrusted networks. It does not intercept Compute Engine resource creation calls, so a VM can still be created with an external IP address; the perimeter would only restrict API access after the resource exists.

Use a deny IAM policy at the folder level

Why wrong: An IAM deny policy, like an allow policy, authorizes or refuses actions based on principals and permissions, but it cannot condition on resource attributes such as the presence of an external IP. To block external IP creation you would need to deny the compute.instances.create permission entirely, which would halt all VM creation across the folder instead of just preventing external IP addresses.

Set a VPC firewall rule in each project

Why wrong: VPC firewall rules are stateful packet filters that evaluate traffic at the network interface level, allowing or denying connections based on source/destination IP, port, and protocol. They are never consulted during the resource creation workflow, so a VM can still receive an ephemeral or static external IP even if inbound internet traffic is entirely blocked.

The billing export has not been enabled in the Cloud Console

Why wrong: Export is enabled when the dataset is linked; tables should populate after a few hours.

The engineer does not have the Billing Administrator IAM role

Why wrong: Billing Account Administrator is needed to set up export, but the engineer already linked the dataset, so permissions are likely sufficient.

The billing account is not linked to the project containing the BigQuery dataset

Why wrong: Linking is required, but the issue is dataset location.

Committed use discounts

Why wrong: Committed use discounts (CUDs) require you to purchase a fixed quantity of vCPUs, memory, GPUs, or other resources for a 1-year or 3-year term in a specific region. You pay for that committed capacity regardless of whether you actually use it, so this model assumes a predictable baseline and financially penalizes unpredictable demand. A startup with variable usage could end up paying for unused capacity, making CUDs the wrong choice for this scenario.

Spot VM discounts

Why wrong: Spot VMs are a non-guaranteed capacity offering that can be reclaimed by Compute Engine at any time; their discounts vary based on spot market prices and are not an automatic function of monthly usage. They are designed for fault-tolerance workloads that can withstand abrupt termination, not for generalized unpredictable always-on compute. Since the question asks about a discount that handles unpredictable usage without additional architectural constraints, Spot VMs do not fit the requirement.

Preemptible VM discounts

Why wrong: Preemptible VMs offer a flat, lower price but have a hard 24-hour maximum lifetime and can be terminated by Google at any time, making them unsuitable for workloads that must continue running. When terminated, the instance is not automatically restarted, so the workload must implement checkpointing or external orchestration to recover. This is not an automatic monthly discount but a tradeoff of cost for capacity risk, and does not solve the startup's need for unpredictable but continuous compute usage.

Cost Management dashboard

Why wrong: The Cost Management dashboard provides high-level billing data and filtering by existing label keys/values, but it is a visualization tool rather than an analyzer of resource configuration. It cannot inspect individual resources to detect that a required label is absent, nor does it generate prescriptive recommendations. To get label suggestions, you need a recommender service like Active Assist.

Cloud Asset Inventory

Why wrong: Cloud Asset Inventory offers a historical, searchable inventory of all cloud resources and their complete metadata, including current labels, across projects and orgs. While you could query it to find resources with missing labels, that is a manual, build-your-own audit process—it does not provide automated recommendations or contextual insights about why labels should be added. It is a system of record, not an advisor.

Organization Policy Service

Why wrong: Organization Policy Service lets you define constraint policies (e.g., a list constraint on label values) that are enforced when resources are created or updated, blocking deployments that violate them. This is a mandatory control valve, not an advisory mechanism—it can reject unlabeled resources but cannot suggest what labels should be applied to legacy or existing resources. Active Assist complements this by providing recommendations for resources already in your estate.

Billing export to BigQuery

Why wrong: Billing export to BigQuery is a post-hoc analytics pipeline that streams detailed usage and cost data from Cloud Billing into BigQuery for querying and visualization. It only reflects costs that have already been incurred after resources are running, so it cannot generate forward-looking estimates for a planned workload; it answers 'what did we spend?' not 'what will we spend?'

Active Assist Recommendations

Why wrong: Active Assist Recommendations, including Recommender and Advisor, analyze existing cloud usage patterns to suggest optimizations such as downsizing idle VM instances or removing unused IP addresses. These recommendations are data-driven and reactive, relying on current resource metadata and historical metrics, so they cannot model a hypothetical new deployment or estimate its costs before any infrastructure exists.

Cost Management dashboard

Why wrong: The Cost Management dashboard (part of the Cloud Billing console) provides an interactive view of current and past invoice totals, budget alerts, and cost trends across projects, folders, and labels. Since it aggregates actual billed charges and real-time usage, it is a monitoring and reporting tool rather than a simulation/estimation engine, making it unsuitable for predicting the monthly cost of a workload that has not yet been deployed.

Create a budget alert in Cloud Monitoring with a metric threshold of 80%

Why wrong: Cloud Monitoring alerting policies are designed for operational telemetry such as CPU utilization, latency, and error rates, not for financial thresholds. There is no native budget-alert rule type in Cloud Monitoring, and it cannot directly evaluate spend against a billing-account budget. Budget notifications must be created in the Billing section of Cloud Console, which is the service that owns spend tracking. Using Cloud Monitoring would require building a custom, indirect pipeline from billing exports, which is neither the intended nor supported approach for this requirement.

Use the Google Cloud Pricing Calculator to set a spending limit

Why wrong: The Google Cloud Pricing Calculator is a planning tool that estimates future costs based on user-selected services and configurations; it does not connect to live billing data. It cannot create a spending limit, enforce alerts, or monitor actual monthly spend, because it is entirely disconnected from the billing system. The calculator produces static estimates only, so it is incapable of generating notifications when a real budget threshold is exceeded. For proactive spend alerts, the company must use Cloud Billing budgets, not a cost-estimation utility.

Configure a Cloud Scheduler job to check billing data in BigQuery and send a notification

Why wrong: Cloud Scheduler triggers jobs on a fixed schedule, not in response to real-time spending thresholds; the requirement demands an alert when a specific budget percentage is exceeded, which requires an event-driven trigger such as a budget alert rule. It is tempting because Cloud Scheduler can query BigQuery billing data and send notifications, making it suitable for periodic cost reports, but it cannot react to an instantaneous spending condition without a polling loop that introduces latency.

Create a project for each business unit

Why wrong: Projects are leaf-level containers that hold resources such as VMs, buckets, and services; they cannot contain folders or other projects. If you create one project per business unit, you flatten your hierarchy and lose the ability to group projects under a higher-level node for shared IAM or policy inheritance. A business unit with multiple workloads would require multiple projects, but there would be no folder to group them together. This approach makes it harder to manage permissions, quotas, and billing across the organization, and it does nothing to set up the required organization root.

Create a folder for each business unit

Why wrong: Folders are indeed the correct construct for grouping projects by business unit, but they only exist beneath an organization node. In Google Cloud, you cannot create a folder at the root of your hierarchy unless an organization node has already been linked to your Workspace or Cloud Identity account. Attempting to create a folder before that link exists will fail because there is no parent container in the hierarchy. Therefore, while folders are part of the intended final structure, they are a later step and not the initial action required here.

Enable the Cloud Resource Manager API

Why wrong: The Cloud Resource Manager API provides programmatic access to manage projects, folders, and organization resources, but enabling it has no effect on whether an organization node exists. In fact, this API is enabled by default for all projects, and you can still use the Google Cloud console without it. The organization node is created solely as a result of Google Workspace or Cloud Identity setup, not from an API toggle. So this action neither replaces nor supports the linking step that is required to establish the organization root.

Organization policy constraints

Why wrong: Organization policy constraints are governance rules applied at the organizational or folder level to restrict resource usage, such as limiting allowed compute regions or disabling service APIs. They are enforced by Resource Manager and do not attach metadata to individual resources. Rather than describing a resource's purpose or ownership, they define compliance boundaries, making them unsuitable for key-value tagging.

IAM custom roles

Why wrong: IAM custom roles consist of curated permission lists that govern what actions principals (users, groups, or service accounts) can perform on resources. They are access management constructs, not metadata descriptors. Even though they carry names and descriptions, they cannot be attached to resources as key-value tags, and they have no role in cost allocation or resource organization.

Tags (network tags)

Why wrong: Network tags in Google Cloud are simple strings attached to VM instances, not key-value pairs. Their primary purpose is to control ingress/egress traffic via firewall rules and enable route configurations. Because they lack the structured key-value format and aren't designed for cost allocation or resource tracking, they cannot serve as the metadata tagging mechanism the organization requires.