Practice Test #2

A multi-cloud approach means using services from multiple cloud providers, such as Google Cloud together with AWS or Azure. The question does not describe a need to distribute workloads across multiple public clouds, avoid vendor lock-in, or compare cloud-native services from different vendors. More importantly, multi-cloud does not inherently address the core requirement that all PHI remain stored only in the on-premises data center. Adding more clouds would usually increase governance, networking, and compliance complexity rather than solve the stated constraint.

A public-cloud approach would place the primary workload and data handling model in the cloud provider environment. That conflicts with the explicit requirement that all patient images and metadata must remain stored only in the hospital’s on-premises data center and that no PHI be persisted in the public cloud. Even if cloud services could be secured, the deployment model itself does not match the data residency and persistence restrictions in the question. Therefore, a pure public-cloud strategy is not appropriate here.

A private-cloud approach focuses on running infrastructure in a privately controlled environment, often entirely on-premises. While that could satisfy the requirement to keep PHI stored locally, it would not align with the goal of using Google Cloud’s advanced managed ML services such as Vertex AI. The question specifically asks for an overall cloud strategy that preserves on-prem data residency while still leveraging Google Cloud capabilities. That combination points to hybrid cloud, not private cloud alone.

Incorrect. Cloud SQL does not automatically train, deploy, or serve machine learning models on its transactional tables. Google Cloud provides machine learning capabilities through services such as Vertex AI and BigQuery ML, not as a built-in feature of Cloud SQL. This option describes functionality outside Cloud SQL’s core purpose as a managed relational database.

Incorrect. Cloud SQL does not include a native dashboarding or intelligent analytics interface for creating charts and business reports by itself. It is designed to run relational database workloads, not to replace BI products. To create executive dashboards or interactive analytics, teams typically connect Cloud SQL to tools such as Looker Studio or Looker.

Incorrect. Cloud SQL is not a built-in ETL or text-processing platform for converting unstructured data into structured relational tables. It stores structured relational data and can participate in data pipelines, but transformation of raw or unstructured data is handled by other services. This option describes data engineering functionality rather than a direct Cloud SQL capability.

A dashboard can help explore trends (descriptive analytics) and may surface correlations, but it is manual, subjective, and not a predictive system. It won’t reliably identify which current users are most likely to cancel, nor will it scale to continuous, proactive interventions. This is better for initial exploration, not for targeted retention at production scale.

Surveys can provide qualitative insights and may complement a churn program, but they are not sufficient for proactive identification of at-risk users. Response rates can be low and biased, and sentiment alone may not correlate strongly with churn. It also delays action compared to using existing behavioral and support data to predict churn now.

A summary report and quarterly discussion is retrospective and too slow for churn prevention. It doesn’t produce user-level risk scores or enable automated, timely interventions. Reporting can inform strategy, but it won’t operationalize AI-driven targeting to reduce cancellations in the near term.

Relying less on data and dashboards is the opposite of SRE best practice. SRE depends on observability (metrics, logs, traces) to make fast, correct decisions during incidents and to validate improvements against SLOs. Reducing dashboards might feel like it speeds decisions, but it typically increases guesswork, slows root-cause analysis, and can lead to more outages and more toil over time.

Having developers participate in on-call can be healthy, but removing SREs from on-call and assigning exclusive production ownership to developers does not address the core issue: repetitive manual operational work. It can also reduce reliability expertise during incidents and weaken systematic reliability engineering. SRE is about engineering reliability and reducing toil, not simply shifting operational burden to another team.

Spending less time measuring and documenting outage impact is not an efficiency best practice in SRE. Understanding impact supports blameless postmortems, prioritization, and SLO/error-budget decisions. Skipping impact analysis may reduce short-term effort but usually increases long-term cost by repeating incidents, misprioritizing fixes, and failing to justify automation or reliability investments.

Cloud Logging centralizes logs and supports auditability (e.g., Admin Activity and Data Access logs) and can help investigations and compliance evidence. However, it does not continuously assess configuration against CIS benchmarks or provide a unified security posture dashboard across an organization. Logging is a data source that SCC and other tools can consume, not the primary compliance posture management solution described.

Identity and Access Management (IAM) is foundational for enforcing least privilege and meeting compliance requirements, but it is not a continuous monitoring or compliance reporting product. IAM can tell you “who has access to what,” yet it won’t automatically detect broad classes of misconfigurations across services, correlate threats, or provide organization-wide compliance dashboards aligned to CIS/PCI on its own.

Google Cloud Armor provides DDoS protection and a web application firewall (WAF) for HTTP(S) Load Balancing, helping mitigate threats like OWASP Top 10 and volumetric attacks. While important for PCI-related security controls, it is not designed for organization-wide posture management, asset inventory, or continuous compliance reporting across all projects and services. It addresses a specific perimeter protection use case.

Built-in consolidated reporting across disparate sources is not a defining NoSQL feature. Cross-source reporting is typically handled by analytics tools and data warehouses (e.g., BigQuery with federated queries, BI tools) rather than an operational NoSQL database. IoT telemetry platforms often land data in a scalable store first, then build reporting pipelines separately.

A strictly enforced, fixed schema is characteristic of relational databases, where tables define columns and types and changes often require migrations. The scenario explicitly wants to avoid frequent schema migrations due to weekly attribute changes, so a fixed schema would increase operational overhead and slow down iteration rather than help.

Native support for complex queries with joins across multiple tables is a hallmark of relational SQL databases, not a defining NoSQL feature. Many NoSQL databases either don’t support joins or discourage them for performance/scalability reasons, favoring denormalization and key-based access patterns. For complex joins, an analytics system is usually a better fit.

Integrated disaster recovery is not the primary serverless benefit being tested. While managed serverless platforms run on highly available Google infrastructure and can be deployed across regions, DR typically involves multi-region design, backups, and failover planning. The requirement is cost efficiency during idle periods and rapid scaling during spikes, not recovery from regional outages.

Lower development costs through prebuilt frameworks can be true in some contexts (e.g., managed services, templates, or opinionated platforms), but it does not directly address fluctuating traffic or paying for idle capacity. The question focuses on operational elasticity and billing model rather than developer productivity features.

Built-in security policies by default is not the best match for the stated requirement. Serverless platforms do provide strong security primitives (IAM, service identity, encryption by default, and managed patching), but these features don’t solve the cost problem of idle capacity or the need to scale from very low to very high request rates.

Cloud Trace is used for distributed tracing—capturing and analyzing end-to-end request latency across microservices (often instrumented apps on GKE, Cloud Run, or Compute Engine). It helps identify slow spans and bottlenecks in application request paths. However, it is not the primary tool for centralized infrastructure metrics dashboards, multi-project alerting, or built-in 1-minute HTTP uptime checks.

Cloud Logging is designed for collecting, storing, searching, and analyzing logs (and can create log-based metrics). While it complements Monitoring and can feed alerting via log-based metrics, it is not the primary service for infrastructure metrics dashboards or for configuring built-in HTTP uptime checks at 1-minute intervals. Logging alone would not satisfy the full set of requirements.

Cloud Profiler continuously profiles application CPU and memory usage to help optimize performance and reduce cost. It is valuable for code-level performance tuning in production with low overhead. However, it does not provide centralized infrastructure metrics dashboards, cross-project alerting as the main function, or built-in HTTP uptime checks for public APIs.

Cloud Profiler continuously analyzes application CPU and memory usage to identify performance bottlenecks (hot paths) in code. It is used for optimizing runtime performance and reducing cost by finding inefficient functions. Profiler does not collect or retain application/system logs, does not provide log indexing/search, and does not create log-based metrics. It’s complementary to logging, not a replacement.

Cloud Monitoring is primarily for metrics collection, dashboards, uptime checks, and alerting (including SLOs). While Monitoring can alert based on log-based metrics, it is not the service that ingests, indexes, and retains logs. In Google Cloud Observability, logs live in Cloud Logging; Monitoring consumes metrics (including those derived from logs) but does not serve as the centralized log store.

Cloud Trace collects distributed traces to analyze end-to-end request latency across microservices, helping pinpoint where time is spent in a request path. It is useful for performance troubleshooting and latency analysis, especially in microservice architectures. However, Trace does not automatically collect stdout/stderr or system logs, does not provide log retention/indexing, and does not support log-based metrics directly.