Practice Test #3

This describes PaaS: a balance where you deploy code while the provider manages underlying servers/OS. It’s useful for custom applications (e.g., App Engine, Cloud Run) but does not directly deliver a complete email/calendaring/document suite. The nonprofit’s need is to adopt a ready-made collaboration product quickly, not to build and operate one, so PaaS is not the best fit.

This describes IaaS: maximum control over VMs, networking, storage, and operating systems (e.g., Compute Engine). While flexible, it requires significant operational work to meet 99.9% availability (multi-zone design, patching, monitoring), plus backups and upgrades. With only a part-time sysadmin and a 14-day deadline, IaaS would add complexity and risk, and likely increase ongoing operational costs.

This suggests a strategy of dynamically shifting between flexibility and provider management, which is not a standard service model choice for delivering a collaboration suite. While organizations can mix SaaS/PaaS/IaaS across workloads, the question asks for the best fit for this specific need. The nonprofit’s requirements strongly point to SaaS rather than an approach that implies frequent model changes.

A provider that operates only in Brazil may help with residency, but it does not address the need for efficient worldwide access. Without a broad global network, optimized routing, and mature global delivery capabilities, it is less likely to support strong user experience for clinicians on multiple continents. The question requires both compliance and global performance, not just local storage.

This is incorrect because replicating the imaging and EMR data across multiple continents conflicts with the requirement that Brazilian residents’ records be stored within Brazil. Cross-continent copies of the regulated dataset would generally create a residency and compliance problem. Faster reads do not matter if the architecture violates the core legal requirement.

A single private data center in Brazil may keep the data in-country, but it is a poor fit for global access at scale. Users on distant continents would still face latency limits, and a single site also creates availability and resiliency concerns. The option focuses narrowly on location control while failing to address the worldwide access requirement.

Pub/Sub is a fully managed global messaging service ideal for ingesting clickstream events at high throughput and buffering bursts. However, Pub/Sub alone does not provide sliding-window aggregations, enrichment, or transformation logic. It is typically the source feeding a stream processor (like Dataflow) that performs computations before writing to BigQuery. So it’s necessary in the architecture, but not sufficient as the single product requested.

Data Catalog is a managed metadata and data governance service used to discover, classify, and manage metadata for datasets across Google Cloud (e.g., BigQuery tables, Pub/Sub topics, files in Cloud Storage). It does not process streaming events, perform aggregations, or load data into BigQuery. It may complement an analytics platform for governance, but it is not a real-time processing solution.

Dataprep by Trifacta (and its successors in the Google Cloud ecosystem) focuses on interactive, visual data preparation and transformation, typically for batch or exploratory workflows. It is not designed for high-throughput, low-latency streaming pipelines with sliding windows and sub-5-second end-to-end requirements. It also doesn’t provide the same streaming autoscaling execution model needed for 180,000 events/sec bursts.

Validity refers to whether data conforms to defined rules and constraints (correct types, formats, ranges, allowed values). Examples include timestamps in valid formats, station IDs matching a reference list, or ridership counts not being negative. In the scenario, there’s no indication of rule violations; the issue is that useful fields were intentionally left out, not that existing fields are invalid.

Accuracy is about whether the data values correctly represent the real world (e.g., tap-in/out events are correctly captured, counts aren’t systematically underreported, station assignments aren’t wrong). Poor model MAE might tempt you to pick accuracy, but the prompt points to omitted metadata/context rather than incorrect logs. The data could be accurate yet still insufficiently informative for forecasting.

Timeliness measures whether data is current and available when needed. The logs are stored in BigQuery and refreshed daily, which generally supports timely forecasting. Timeliness problems would look like delayed ingestion, missing recent days, or late-arriving events causing the model to train on stale patterns. Here, the degradation is tied to excluding context features, not data freshness.

Bare Metal Solution provides dedicated physical servers in Google Cloud for workloads needing specific hardware, low-level control, or licensing/latency requirements. It is not a domain-specific ML accelerator and does not inherently speed up TensorFlow training compared to using specialized accelerators like TPUs. It’s typically used for migrating legacy enterprise workloads (e.g., certain databases, SAP, or proprietary systems), not for accelerating deep learning training.

Preemptible/Spot VMs are a pricing and capacity option that can significantly reduce compute cost, but they do not provide specialized ML acceleration by themselves. They can be interrupted, which can slow overall time-to-train unless checkpointing and fault tolerance are well designed. They might help run more parallel experiments cheaply, but they are not “designed specifically” to speed up ML training per epoch.

Containers (e.g., Docker on GKE or Cloud Run) are an application packaging and deployment technology. They improve portability, consistency, and operational management, but they do not inherently accelerate model training. Containers can run on CPUs, GPUs, or TPUs, but the performance gain comes from the underlying accelerator, not from containerization itself. Therefore, containers are not the domain-specific hardware requested.

Increased risk of privacy leaks is not the most direct or likely impact of incorrect training labels. Privacy risks typically come from using sensitive data improperly, weak access controls, or models memorizing identifiable information (e.g., PII) and exposing it through outputs. A label merge error changes correctness of ground truth, not confidentiality. While any ML system can have privacy considerations, mislabeled data primarily harms prediction quality rather than increasing data exposure.

Decreased model compatibility is unrelated to label correctness. Compatibility concerns usually involve whether a model can be deployed to a target environment (edge vs cloud), supported formats, latency/throughput requirements, or integration with serving infrastructure. A label merge error does not change the model’s runtime requirements or supported deployment options; it changes what the model learns, affecting performance rather than compatibility.

Decreased model training time is not a likely outcome of mislabeled data. Training time in Vertex AI AutoML is driven by dataset size, image resolution, chosen training budget, and compute resources. Incorrect labels do not reduce the number of images or the compute required. If anything, noisy labels can make learning less efficient and may require more experimentation or retraining cycles, increasing overall time to reach acceptable performance.

Cyber resilience focuses on an organization’s ability to withstand, respond to, and recover from cyber incidents (e.g., backups, disaster recovery, incident response processes, redundancy). While limiting permissions can reduce impact, the scenario is not about recovery or continuity planning. It is specifically about restricting access rights for a role, which aligns more directly with least privilege than resilience.

Zero-trust is a broader security model: “never trust, always verify,” typically involving continuous authentication/authorization, strong identity signals, device posture, and context-aware access. IAM Conditions (like time restrictions) can support a zero-trust approach, but the question’s key phrase is granting the minimum permissions required for duties. That principle is least privilege, not the overall zero-trust model.

Security by default refers to systems and services being configured securely out of the box (secure defaults, baseline protections, guardrails). While Google Cloud provides many secure defaults, the scenario is about deliberate, fine-grained permission assignment and conditional access for a specific job function. That is an access control design choice aligned with least privilege rather than a default configuration principle.

Compute Engine provides virtual machines to run workloads on Google Cloud. It could host middleware that queries the legacy system and exposes endpoints, but the VM itself is not the primary solution concept being tested. It also introduces operational overhead (patching, scaling, security hardening) and can exceed a small integration budget if you build a custom integration stack. The question is about making data accessible, best met by an API approach.

Anthos is a hybrid/multi-cloud application platform for modernizing and operating Kubernetes-based workloads consistently across environments. While Anthos can help manage hybrid deployments, it is not necessary to expose legacy on-prem data to a partner, and it is typically far beyond a $10,000 integration effort. Anthos is a modernization and operations platform, not the simplest integration mechanism for a legacy system.

Google Kubernetes Engine (GKE) is a managed Kubernetes service for running containerized applications. Choosing GKE implies containerizing and operating services, which is unnecessary for the stated requirement and conflicts with the constraint of not replacing or rehosting the legacy system. While you could build an API service on GKE, the exam-relevant concept is the API interface itself, not the container orchestration platform.

This option describes project management reporting, not observability. Sprint burndown charts and delivery dates help teams track work progress and release planning, but they do not provide telemetry about whether services are healthy or performing well in production. Observability is concerned with runtime signals such as logs, metrics, and error conditions from systems. Therefore, this option is outside the scope of cloud operations monitoring.

This option is about customer sentiment and product feedback rather than technical system visibility. NPS scores and app store reviews can indicate whether users are happy, but they do not explain infrastructure health, service latency, or application failures. Observability focuses on internal operational data that helps engineers diagnose and understand system behavior. Because this option measures business perception instead of runtime telemetry, it is not the correct meaning of out-of-the-box observability.

This option refers to financial management and cost analysis, not observability. Auditing cloud spend and forecasting future costs are important FinOps activities, but they do not tell engineers whether services are available, fast, or error-free. The question specifically asks about understanding system health and performance across services during migration. That makes cost reporting irrelevant to the core concept being tested here.