How Google Cloud Resources Are Managed practice questions

The billing export has not been enabled in the Cloud Console

Why it fails: 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 it fails: 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 it fails: Linking is required, but the issue is dataset location.

The billing account has not been linked to the project

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

4 hours

Why it fails: 4 hours is the committed initial response time for Standard support tier P2 (medium severity) cases, not for Premium support incidents. For a critical production outage (Severity 1), Premium support guarantees a 15-minute response, so 4 hours is far too slow and represents a lower-tier or lower-severity target.

8 hours

Why it fails: 8 hours does not appear as an official committed response time in any Google Cloud support plan—Standard, Enhanced, or Premium. This value likely confuses business-hours delays with contractual SLAs; published response targets are 15 minutes, 1 hour, 2 hours, 4 hours, etc., and 8 hours is not in that matrix.

1 hour

Why it fails: 1 hour is the initial response time for P1 (Severity 1) cases under the Enhanced support tier, not Premium. While Enhanced already provides relatively fast escalation, Premium support goes further with a 15-minute P1 response time, making 1 hour incorrect for the highest-tier plan.

Set up VPC Service Controls to restrict access to the production VPC.

Why it fails: VPC Service Controls builds a security perimeter that restricts data movement to and from Google-managed services, preventing data exfiltration; it does not govern instance attributes such as labels or external IP ranges. Therefore, it cannot enforce either the labeling requirement or the no-public-IP rule.

Create a folder for each environment and apply the label automatically using a Cloud Function triggered by Resource Manager events.

Why it fails: This approach is reactive, not preventive: a Cloud Function triggers only after an instance is created, so an unlabeled instance exists in the interim and the label is added post-creation. It also depends on the function's reliability and cannot guarantee that every instance gets the label, especially if the event is missed or the function fails.

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

Why it fails: 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 it fails: 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 it fails: 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 it fails: This lists only resources that have the label, not missing ones.

Use the Cloud Console to manually check each resource.

Why it fails: Manual checking is inefficient for many resources.

Set up a budget alert for resources without labels.

Why it fails: Budget alerts are not label-aware.

Enhanced

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

Standard

Why it fails: 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 it fails: 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.

Use preemptible VMs for all workloads.

Why it fails: Using preemptible VMs for all workloads is incorrect because preemptible VMs are designed for short-lived, batch, and fault-tolerant workloads. They can be terminated by Compute Engine at any time, with a maximum lifetime of 24 hours, and offer no availability guarantees. Most production systems, especially stateful or latency-sensitive applications, require persistent VMs; relying on preemptible instances for everything would cause widespread service disruption and data loss.

Set up billing export to BigQuery.

Why it fails: Setting up billing export to BigQuery is a cost-management practice that exports detailed billing records to BigQuery for analysis and reporting. It does not directly reduce costs; rather, it provides visibility into spending patterns, which can help you identify waste and inform cost optimization decisions. However, the export feature itself has no discounting effect, so it is not a cost-reduction mechanism in its own right.

The group has full admin access because the folder policy allows it

Why it fails: This answer mistakenly assumes that IAM evaluation is purely additive, where folder allows simply accumulate into effective permissions. In reality, deny policies are evaluated separately from allow bindings and override them uniformly along the resource hierarchy. The folder allow does grant the role, but the matching deny policy for that group removes all allowed permissions, so the group cannot exercise any administrative action. Thus full admin access is impossible when a deny is in effect.

The group has view access only

Why it fails: View-only access is incorrect because a Cloud IAM deny policy does not simply reduce the role's permissions to a read-only subset. Instead, a deny policy that specifies particular permissions—or a wildcard set such as compute.instances.*—denies exactly those permissions, revoking them from the principal entirely. Since the deny matches all permissions included in the assigned role, the group loses even read/list capabilities. There is no partial 'view' permission left behind.

The group retains permissions but cannot modify instances

Why it fails: This option incorrectly suggests that IAM deny policies only block mutating actions like creating or modifying instances, while allowing read operations to pass through. In fact, Cloud IAM deny policies are permission-based and explicit: if a deny rule references compute.instances.*, it denies every permission in that namespace, including read-only actions such as get and list. Unless the group has another allow policy that is not covered by the deny, it retains none of the role's permissions—so it cannot even view instances, let alone modify them.

IAM Conditions

Why it fails: 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 it fails: 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 it fails: 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.

Increase the number of persistent disk snapshots.

Why it fails: Increasing the number of persistent disk snapshots is a storage optimization decision that grows your backup footprint, not a compute cost reducer. Snapshots are incremental and billed based on the amount of data stored in Cloud Storage, so each additional snapshot adds to your storage bill. While snapshots protect data, they have no impact on the compute charges incurred by running virtual machines, making this action orthogonal to compute cost reduction.

Enable sustained use discounts by running instances continuously.

Why it fails: Sustained use discounts (SUDs) are applied automatically to instances running for more than 25% of the month, without any action needed, so there is no 'enable' step. Running instances continuously purely to maximize the SUD is counterproductive because you pay for the entire run time; the discount only applies to the per-second price after the threshold, so leaving an idle VM up increases total compute cost despite the per-hour discount. The correct cost-saving approach is to shut down unused instances, not to keep them running for a discount.

The project has exceeded the default service quota

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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.

Request a quota increase before hitting the limit

Why it fails: Requesting a quota increase raises the ceiling for a specific resource (e.g., CPU, disk) but does not create a notification mechanism when that quota is exceeded. The increase itself is a manual, proactive action that must be approved by Google Cloud, and it does not emit a log or metric that triggers an alert. Thus, it addresses the capacity problem, not the monitoring requirement.

Set up a budget alert with a threshold of 100%

Why it fails: Budget alerts in Google Cloud track the monetary cost incurred by a project or billing account, not resource quota consumption such as the number of vCPUs or API requests per minute. A threshold of 100% simply means you will be notified when your spend reaches the budget amount, which has no correlation to quota exhaustion. Your application could be denied due to quota while your budget is still at 20%, or vice versa, making this option ineffective.

Create a custom role with the necessary read-only permissions and grant it to the auditors group at the organization node, then use an IAM deny policy to prevent project-level administrators from modifying the auditors' access.

Why it fails: A custom role at the organization node provides read-only access, but IAM deny policies are used to deny specific permissions, not to prevent IAM policy changes. Moreover, deny policies do not protect against removal of grants; they only block certain actions. This approach is overly complex and does not guarantee that project-level administrators cannot alter access.

Grant the roles/viewer role to the auditors group at the organization node, and enable IAM policy inheritance so that child resources cannot override it.

Why it fails: Granting roles/viewer at the organization node does allow access to all projects through inheritance, but IAM policy inheritance in Google Cloud is additive; child resources cannot remove a parent grant. However, roles/viewer is a basic role that includes broad permissions beyond read-only auditing, violating the principle of least privilege. Also, there is no 'enable inheritance' toggle; inheritance is automatic.

Grant the roles/editor role to the auditors group at each folder level, and instruct project administrators not to remove these grants.

Why it fails: roles/editor grants broad write access, not read-only, and violates least privilege. Granting at folder level still allows project administrators to potentially remove folder-level grants if they have the necessary permissions, and it does not cover future projects automatically unless folders are used. This approach is both over-privileged and not tamper-proof.

Enable uniform bucket-level access at the organization level and configure default encryption with CMEK using the gcloud command-line tool for each bucket.

Why it fails: Uniform bucket-level access simplifies permissions but does not enforce encryption. Configuring default encryption per bucket is manual and does not prevent project owners from creating buckets without CMEK. This approach lacks centralized enforcement and retroactive application, and can be bypassed by anyone with storage.buckets.create permission.

Create a custom organization policy constraint that checks for CMEK on buckets, apply it at the organization node, and use a Cloud Function to automatically remediate non-compliant buckets.

Why it fails: Custom organization policy constraints can enforce specific configurations, but they require writing a constraint using Common Expression Language (CEL) and are more complex. While this approach can work, it is not the standard method; the predefined constraint storage.bucketEncryption is designed exactly for this purpose. The Cloud Function adds unnecessary complexity and potential delay in remediation.

Use IAM conditions to require that all storage.buckets.create requests include a CMEK key, and apply this at the folder level.

Why it fails: IAM conditions can restrict permissions based on attributes, but they cannot enforce encryption settings on resources. They can deny creation if a condition is not met, but they do not retroactively enforce encryption on existing buckets. Also, applying at folder level does not cover the entire organization and can be bypassed by project owners with sufficient permissions.