Google ACE Practice Question: Implementing cost optimization for their Google…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Keep all resources in a single region to avoid data transfer costs.

  Why it's wrong here

  Keeping all resources in a single region eliminates inter-region egress fees, but it sacrifices high availability and can increase latency for distributed users, as Google Cloud's network charges only apply when traffic crosses regions. Single-region placement may also force the use of more expensive resources to meet capacity needs that a multi-region architecture could handle more cost-effectively, so this approach is not a holistic cost-optimization strategy.

• ✗

  Always use premium-tier networking for all traffic.

  Why it's wrong here

  Premium-tier networking always routes traffic over Google's high-speed global network, which provides lower latency and more consistent performance but at a higher price per GB than Standard Tier, which uses the public internet. For workloads that can tolerate slightly higher latency, such as batch data transfer or non-interactive processing, Standard Tier is significantly cheaper, so blanket use of Premium Tier contradicts cost optimization.

• ✓

  Use committed use discounts for predictable workloads.

  Why this is correct

  Committed use discounts (CUDs) are a cost-optimization tool that offer up to 70% lower vCPU, memory, and GPU prices for predictable workloads when you commit to 1- or 3-year usage. This aligns with cost optimization because steady-state baseline resources are paid at a large discount, and the commitment safeguards you against future price increases. However, CUDs are only effective if usage is consistent; they should be matched to historical baseline usage, not spikes.

• ✗

  Use preemptible VMs for all batch jobs irrespective of fault tolerance.

  Why it's wrong here

  Preemptible VMs are up to 80% cheaper than standard VMs but are guaranteed to be terminated within 24 hours and can be reclaimed at any moment due to capacity demands. Batch jobs that are fault-tolerant and support checkpointing or resumable processing are appropriate for preemptible instances, but 'all batch jobs irrespective of fault tolerance' is dangerous because non-fault-tolerant jobs may fail mid-way, incurring extra costs to rerun and delaying completion, which negates the savings.

• ✓

  Delete unused static external IP addresses.

  Why this is correct

  A static external IP address that is reserved but not attached to any running resource still incurs a recurring hourly charge (typically $0.005/hr), so deleting unused static IP addresses directly reduces monthly networking costs. This is a simple best practice for cost optimization because many organizations forget to release IPs after decommissioning instances, leaving them as pure waste. Deleting them has no impact on any running workload since they are detached.

Go deeper

Related to this question