Question

Difficulty: HardManaging Storage and Database Solutions

An enterprise application running on Google Cloud uses a Cloud SQL instance for transactional workloads requiring complex relational SQL queries and joins. Additionally, the application stores daily audit log files in a Cloud Storage Standard bucket. These audit logs are frequently accessed and analyzed during the first 30 days after creation, but access drops significantly after 30 days while retention is required for compliance. The operations team reports high CPU utilization on the Cloud SQL primary instance due to reporting queries, as well as rising storage costs for the audit log bucket.

Which TWO architectural and operational management actions should the Cloud Engineer implement to resolve these issues? (Select TWO.)

  1. Provision a Cloud SQL read replica and redirect reporting and analytical read queries away from the primary database instance.Answer
  2. Configure an Object Lifecycle Management rule on the Cloud Storage bucket to transition objects from Standard to Nearline storage after 30 days.Answer
  3. C
    Configure an Object Lifecycle Management rule to transition log files to Archive storage after 5 days to minimize storage costs while continuing weekly analysis.
  4. D
    Migrate the transactional database tables requiring complex SQL joins to Cloud Bigtable to eliminate CPU bottlenecks on the database tier.

Answer

The team should provision a Cloud SQL read replica to offload reporting queries and set a Cloud Storage lifecycle rule to move log files to Nearline storage after 30 days.
Provisioning a Cloud SQL read replica successfully isolates analytical and reporting queries from the primary instance, relieving primary CPU saturation while preserving full relational SQL functionality. Transitioning Cloud Storage objects to Nearline storage after 30 days matches the operational access pattern—where access drops after one month—minimizing storage fees without incurring excessive retrieval costs.

Step-by-Step Solution

1
Analyze database performance bottleneck
Identify that read-heavy reporting queries are consuming primary Cloud SQL CPU resources.
Creating a read replica handles read traffic horizontally without impacting write performance on the primary instance.
2
Analyze storage access patterns and cost requirements
Identify that audit logs are accessed frequently for 30 days and rarely thereafter.
Nearline storage is designed for data accessed less than once a month, making a 30-day lifecycle transition ideal for cost optimization.
3
Evaluate unsuitable database engine and storage class alternatives
Reject Cloud Bigtable migration and premature Archive tiering.
Cloud Bigtable lacks SQL join capabilities, and Archive storage imposes heavy retrieval penalties when accessed frequently within 30 days.

Key Concept

Cloud SQL Read Replicas & Cloud Storage Lifecycle Management
Rate this question