Troubleshooting Scenario Questions

Immediately upgrade all infrastructure to the latest generation hardware for better efficiency.

Why wrong: Upgrading to the latest hardware generation does not inherently reduce costs; newer machine families often carry the same or higher list prices, and any efficiency gains may be offset by increased per-hour rates. This approach overlooks the actual source of wasted spend — idle and oversized resources — so you would be paying more for resources that are still not fully utilized. Cost optimization should begin with rightsizing and eliminating waste, not with refreshing infrastructure that may not even be the bottleneck, which is why this is not an effective first move.

Migrate all workloads to Spot VMs immediately to reduce costs by 90%.

Why wrong: Migrating all workloads to Spot VMs would be disastrous because Spot VMs are preemptible capacity with no availability SLA — Google can reclaim them at any moment with only a 30-second warning. Running production workloads on them would cause constant, unpredictable interruptions and data-loss risks, far outweighing the claimed 90% savings, which are also unrealistic for most workloads. Spot VMs are best suited for batch jobs and fault-tolerant stateless workloads, not as a wholesale cost-reduction strategy.

Switch cloud providers to whoever has the lowest advertised list price.

Why wrong: Switching providers based purely on advertised list price ignores the massive hidden costs of migration: re-architecting for different APIs, retraining engineers, data transfer fees, and potential downtime during cutover. The lowest list price rarely translates to the lowest total cost of ownership once your specific workload profiles, networking costs, and operational overhead are factored in. Committed use contracts and sustained use discounts on GCP alone often deliver 20–40% savings without the expense and risk of a provider switch, and optimizing the current environment should always come first.

Requiring all cloud resource creation to go through a central IT approval process to prevent accidental VM creation

Why wrong: A central IT approval process is a preventive governance control that could reduce accidental VM creation, but it does not provide any monitoring of actual spending patterns or trigger an alert when expenditure deviates from expected baselines. In practice, it becomes a manual bottleneck that slows development, is often bypassed via pre-approved projects or direct IAM permissions, and does not scale to dynamic environments where developers need agility. The core requirement is early detection of abnormal cost behavior, not preventing all resource creation, so budget alerts are the appropriate control because they are automated, real-time, and focused on spend thresholds.

Reviewing cloud bills at the end of each month to identify cost anomalies and address them retroactively

Why wrong: A monthly bill review is a lagging indicator: Cloud Billing data is aggregated and exported only periodically, so by the time the bill is examined the abnormal spending has already fully accrued. Budget alerts, in contrast, evaluate spending continuously against thresholds and push notifications in near-real-time, allowing the team to investigate a Saturday-morning spike before a full weekend of overage builds up. Retroactive reconciliation can help optimize future spending, but it cannot prevent or limit the cost impact of an ongoing anomaly.

Using Reserved Instances for all VM workloads to reduce per-hour costs, making accidental long-running VMs less expensive

Why wrong: Committing to reserved capacity for all VMs (including accidentally running ones) would reduce the per-hour rate but not prevent or detect the accidental over-spending. Budget alerts address detection; reserved pricing only addresses cost per unit.

Cloud Profiler

Why wrong: Cloud Profiler provides continuous profiling of CPU and memory consumption across a service, identifying which functions consume the most resources, but it does not capture per-request latency, trace spans, or the end-to-end path of a specific request. Therefore, it cannot pinpoint where a particular slow response spends its time in terms of request propagation through services or API calls.

Cloud Logging

Why wrong: Cloud Logging stores structured and unstructured log entries, but logs alone do not contain the distributed latency information needed to correlate a slow request across services unless you explicitly integrate Cloud Trace and use trace IDs as log correlation keys. Without this integration, you can only see individual service logs, missing the holistic view that reveals where the delay occurs. Thus, Logging is insufficient for direct end-to-end latency analysis.

Cloud Debugger

Why wrong: Cloud Debugger lets you take snapshot captures of the state of a running application at specific lines of code without stopping it, useful for inspecting variable values and logic, but it does not record request timing, traversal paths, or span durations. It operates in a point-in-time manner rather than capturing the whole request lifecycle, so it cannot show why a response is slow across distributed components. Hence, it is not the tool for latency analysis.

Enable automatic storage increase

Why wrong: Enabling automatic storage increase only expands the persistent disk volume when the instance approaches its capacity limit, which addresses disk space depletion but does nothing to reduce memory usage. RAM exhaustion is a separate resource constraint; the flag does not alter buffer pool sizing, connection overhead, or any memory allocation. Thus it would leave the troubleshooting unchanged.

Add a read replica

Why wrong: A read replica is used to redirect SELECT queries to a separate instance, reducing CPU and I/O load on the primary, but it does not remove the per-connection memory buffers already allocated on the primary. Writes still go to the source, and each existing session still holds memory; the replica itself also consumes its own RAM. This offloads read traffic, not memory pressure.

Switch from InnoDB to MyISAM

Why wrong: MyISAM does not support row-level locking or crash recovery, and Cloud SQL does not allow you to migrate tables to that engine as a supported configuration. More importantly, the memory problem is caused by connection thread buffers, not by the storage engine's access method, so changing engines would not reduce RAM usage. It also sacrifices transactional integrity without addressing the root cause.

Cloud Logging

Why wrong: Cloud Logging is a log management and aggregation service that stores logs from Google Cloud services and custom applications. While it can store and query logs, it lacks advanced SIEM capabilities such as automated correlation, threat detection rules, and incident response workflows. It is incorrect because it serves as a data source for a SIEM like Chronicle, but does not provide the security-specific analytics and hunting features needed for large-volume security log analysis.

BigQuery

Why wrong: BigQuery is a serverless, scalable data warehouse that can run SQL queries over massive datasets, including log exports. However, it does not have built-in security threat detection, correlation rules, or SIEM functionality; an analyst would have to manually construct detection queries and manage alerting pipelines. It is wrong because it is a general-purpose analytics tool, not a security platform, and lacks the purpose-built threat hunting and detection capabilities that Chronicle offers.

Security Command Center

Why wrong: Security Command Center is a security and risk management platform that identifies assets, scans for vulnerabilities, and aggregates security findings from Google Cloud and third-party sources. It does not perform raw log analysis or threat hunting on large volumes of data; instead, it focuses on asset posture and policy compliance. It is incorrect because its primary purpose is to report findings and risks, not to analyze log data, making it complementary to a SIEM rather than a replacement for Chronicle.