Scaling with Google Cloud operations practice questions

~4.3 minutes

Why wrong: 4.3 minutes corresponds to 99.99% (four nines) availability, not 99.9% (three nines). Three nines allows approximately 10× more downtime.

~7.2 hours

Why wrong: 7.2 hours corresponds to approximately 99% availability (two nines). 99.9% is an order of magnitude more restrictive.

~8.6 hours

Why wrong: 8.6 hours is roughly 99% availability. 99.9% availability allows only ~43 minutes of downtime per month.

Threshold alerting — alert when error rate exceeds 0.1%.

Why wrong: Simple threshold alerting fires only when the threshold is crossed — reactive, not predictive. It doesn't account for the rate of consumption or how much budget remains.

Uptime check alerting — alert when health checks fail.

Why wrong: Uptime checks detect complete service unavailability. They don't measure SLO compliance or error budget consumption rates for partial failure scenarios.

Log-based alerting — alert when specific error messages appear in logs.

Why wrong: Log-based alerts detect specific event patterns in logs. They can contribute to monitoring but don't directly measure SLO burn rate.

The IT team will need to hire more staff to manage additional cloud infrastructure.

Why wrong: Cloud managed services typically reduce operational burden, not increase it. Fewer people are needed for routine maintenance when Google handles patching and hardware.

The IT team will still perform the same tasks but remotely via the Cloud Console.

Why wrong: Using managed services means Google handles the maintenance, not the IT team remotely. The tasks are eliminated, not relocated.

The IT team will be fully automated out of their roles by Google's AI.

Why wrong: Managed services eliminate routine infrastructure tasks, but IT teams remain essential for application architecture, access management, cost optimization, and strategic decisions.

VMs are terminated and restarted automatically on new hardware, causing a few minutes of downtime.

Why wrong: VMs are not terminated during live migration. They are transparently moved to the new host while still running, with imperceptible pause time.

VMs are snapshotted, the snapshot is restored on new hardware, and the VM is restarted.

Why wrong: Live migration is a hot migration of the VM's running state, not a snapshot/restore operation. Snapshots would cause significant downtime.

Customers must subscribe to Google Cloud support to receive advance notice and schedule their own maintenance windows.

Why wrong: Live migration is automatic and available to all Compute Engine customers — no support subscription required. Google handles maintenance transparently.

Purchase reserved capacity for peak load and configure it to be active only on weekdays.

Why wrong: Reserved capacity (committed use discounts) provides cost savings on fixed baseline capacity but doesn't automatically scale for variable demand. Autoscaling is the correct solution.

Deploy additional VMs manually each weekday morning and terminate them at night.

Why wrong: Manual scaling is operationally expensive, error-prone, and doesn't meet the 'without manual intervention' requirement.

Use Cloud Monitoring to send an email alert when CPU exceeds 80% so the team can manually scale.

Why wrong: Email alerts inform humans to act — they don't provide automatic scaling. The requirement is automatic response to traffic spikes.

Deploy identical origin servers in every Google Cloud region globally.

Why wrong: Replicating full origin servers in every region is operationally expensive and complex to synchronize. CDN achieves the same performance benefit by caching at edge PoPs without full origin replication.

Use Cloud VPN to route viewer traffic through a direct tunnel to the origin servers.

Why wrong: VPN creates encrypted tunnels between networks — it doesn't cache content or improve CDN-style performance. VPN adds overhead rather than reducing latency.

Increase the origin servers' network bandwidth to handle more simultaneous viewer connections.

Why wrong: More bandwidth on the origin doesn't reduce geographic latency for distant viewers. CDN fundamentally solves the distance problem by moving content closer to users.

Cloud Security Command Center

Why wrong: Security Command Center focuses on security findings, misconfigurations, and vulnerabilities — not application performance metrics, traces, or operational logs.

BigQuery

Why wrong: BigQuery is a data warehouse for analytics. While logs can be exported to BigQuery for long-term analysis, it's not an operational monitoring platform with real-time dashboards and alerting.

Cloud Asset Inventory

Why wrong: Cloud Asset Inventory tracks the state and configuration of GCP resources — useful for governance and compliance, not for operational performance monitoring and alerting.

Deploy in a single region with a Managed Instance Group using 3 availability zones.

Why wrong: Multiple zones in a single region protect against individual zone failures, not regional outages. A regional disaster would affect all zones in that region simultaneously.

Enable Cloud Armor on the load balancer to protect against regional failures.

Why wrong: Cloud Armor is a security service (WAF/DDoS protection), not a geographic availability or failover mechanism.

Use Cloud Storage multi-region buckets for application data.

Why wrong: Multi-region Cloud Storage protects data durability, but data storage redundancy alone doesn't make the application itself available if the compute layer fails in a region.

$30,000 (cloud cost increase of $120K minus the $50K DC savings)

Why wrong: This incorrectly treats cloud costs as an addition rather than a replacement for data center costs.

$50,000 (only the data center cost savings count)

Why wrong: The full comparison is $200K previously vs. $120K now. The total savings is $80K, not just the $50K partial DC savings figure.

$120,000 (the entire cloud bill is savings)

Why wrong: The cloud bill is a cost, not a saving. The saving is the difference between what was previously spent ($200K) and what is now spent ($120K).

Cloud Logging — search logs for error messages across all 15 services.

Why wrong: Log searching finds errors after they occur but doesn't correlate cross-service request timelines or show which service hop added latency in a distributed trace.

Cloud Monitoring dashboards — create per-service CPU utilization graphs.

Why wrong: CPU graphs show resource utilization but don't correlate individual request flows across services or show which service contributed to a specific slow request.

Security Command Center — scan for misconfigurations causing performance issues.

Why wrong: SCC identifies security findings and misconfigurations, not application performance issues or distributed request tracing.

SLI is the contract with customers; SLO is the internal target; SLA is the measurement.

Why wrong: The definitions are scrambled. SLI = measurement (metric), SLO = internal target, SLA = customer contract.

SLI, SLO, and SLA are all the same thing — different names for uptime guarantees.

Why wrong: They are distinct concepts at different layers: measurement (SLI), internal goal (SLO), and customer contract (SLA). Conflating them leads to poor reliability engineering.

SLA is measured in milliseconds; SLO is measured in percentage; SLI has no unit.

Why wrong: SLIs can have any unit appropriate to what's measured (percentage for availability, milliseconds for latency). The distinction is about their roles, not their units.

Performance review — identifying which engineers caused the outage for disciplinary action.

Why wrong: Blameless postmortems explicitly avoid individual blame. Discipline focuses people on hiding mistakes, not sharing learning — the opposite of psychological safety.

Capacity planning review — ensuring enough servers are provisioned to prevent future outages.

Why wrong: Capacity planning reviews size infrastructure for load. Postmortems address the full range of failure causes — not just capacity.

Change advisory board (CAB) review — approving that the outage fix is safe to deploy.

Why wrong: CAB reviews approve changes before deployment. Postmortems are retrospective reviews of incidents after they occur.

Basic support

Why wrong: Basic support provides documentation and community support only — no technical support engineers, no guaranteed response times, no TAM.

Standard support

Why wrong: Standard support provides business-hours support with a 4-hour P1 response — not the 1-hour response or dedicated TAM required.

Enhanced support

Why wrong: Enhanced support provides 1-hour P1 response, but a dedicated TAM is a Premium feature. If both criteria are required, Premium is the correct tier.

Spot VMs — up to 91% savings over on-demand pricing.

Why wrong: Spot VMs provide the deepest discounts but can be preempted with 30 seconds notice. Continuous 24/7 workloads cannot tolerate preemption.

On-demand pricing — pay per minute with no commitment.

Why wrong: On-demand pricing is the baseline rate with no discount. For continuous workloads, CUDs provide significant savings over on-demand.

Sustained Use Discounts — automatically applied to all running VMs.

Why wrong: Sustained Use Discounts apply automatically to VMs running >25% of the month and provide up to ~30% savings. CUDs provide greater savings (37-55%) for known, stable workloads.

Create one large project for all teams and split the bill manually at month-end.

Why wrong: A single project makes cost attribution by team difficult. Separate projects per team is the recommended architecture for cost isolation and accountability.

Purchase dedicated hardware for each team so costs are inherently separate.

Why wrong: Dedicated hardware is contrary to cloud economics and doesn't use GCP's native cost management features. Projects and labels are the cloud-native solution.

Use Cloud Identity to create separate accounts for each team and bill separately.

Why wrong: Cloud Identity manages user identities, not billing. Cost allocation is managed through projects, billing accounts, and labels — not identity accounts.

Zones are continents; regions are individual countries within a continent.

Why wrong: This is incorrect. Regions are metropolitan geographic areas (city/state level). Zones are isolated physical data center areas within a region.

Zones and regions are different terms for the same thing — Google uses them interchangeably.

Why wrong: Zones and regions have distinct, specific meanings in GCP. Confusing them leads to architectural mistakes in availability design.

A zone is a global resource; a region is a local data center.

Why wrong: This is backwards. Regions are geographic areas (local); zones are isolated failure domains within a region. Global resources (like global load balancers) exist independently of both.

Cloud Monitoring dashboards with cost metrics.

Why wrong: Cloud Monitoring tracks infrastructure performance metrics (CPU, latency, etc.), not billing and spend data. Cost data lives in Cloud Billing.

Cloud Asset Inventory — it lists all resources and their costs.

Why wrong: Cloud Asset Inventory tracks resource configurations and metadata, not cost data. Cost analysis requires Cloud Billing tools.

Google Cloud pricing calculator — it shows estimated costs.

Why wrong: The pricing calculator estimates costs before deployment for planning purposes. It doesn't show actual historical spend from existing deployments.

Cloud Logging automatically archives all logs to Cloud Storage with no configuration needed.

Why wrong: Log archival to Cloud Storage requires explicit sink configuration. By default, logs are retained in Cloud Logging for 30–400 days depending on log type, then deleted.

Enable log streaming in Cloud Storage settings to receive logs from Cloud Logging.

Why wrong: Log export is configured in Cloud Logging (not Cloud Storage settings) using log sinks/routers.

Use the Cloud Logging API to periodically download logs and upload them to Cloud Storage.

Why wrong: While possible programmatically, the purpose-built and simpler solution is log sinks — configured once and continuously routing logs without custom code.

`compute/instance/cpu/utilization` per instance group.

Why wrong: CPU utilization shows compute load per instance group but not request traffic distribution from the load balancer perspective.

`networking/vm_flow/egress_bytes_count` per VM.

Why wrong: Network flow egress bytes measure outbound data volume, not request count distribution by load balancer backend.

`logging/log_entry_count` filtered by region.

Why wrong: Log entry count measures logging volume, not load balancer traffic distribution.

Cloud Monitoring — set alerts for low CPU utilization.

Why wrong: Cloud Monitoring can alert on low CPU but doesn't generate specific rightsizing recommendations. Active Assist's Recommender analyzes usage patterns and recommends specific machine type changes.

Cloud Asset Inventory — lists all VMs and their configurations.

Why wrong: Cloud Asset Inventory catalogs resource configurations but doesn't analyze utilization patterns or generate cost optimization recommendations.

Cloud Billing budgets — set spending limits to prevent overspend.

Why wrong: Billing budgets alert when spending thresholds are approached but don't identify specific underutilized resources or recommend configuration changes.