Free Google Cloud Professional Machine Learning Engineer practice test

Options A, C, and E are correct. (E) Lowering the classification threshold reduces false negatives at the cost of more false positives—directly addressing the business concern of missing defaulters; threshold tuning is the most direct lever after training. (A) Class weighting or oversampling the minority class forces the model to pay more attention to defaulters during training, addressing the root cause of the imbalance problem. (C) AUC-PR is specifically recommended for severely imbalanced datasets because it focuses on the minority class performance, unlike AUC-ROC which can appear artificially high even when the model performs poorly on the minority class. Option D is incorrect: switching optimization objectives from AUC-ROC to log-loss does not specifically target imbalance handling; neither objective directly addresses the class imbalance problem the way resampling or threshold tuning does. Option F is incorrect: adding more features increases complexity and risks overfitting; it does not address class imbalance or the false negative problem. Option B is incorrect: adding more majority-class examples worsens the class imbalance ratio, making the problem worse rather than better.

Option A is correct. Vertex AI AutoML Tabular is optimized for low-latency inference (<100ms) on structured tabular data, and AutoML handles the imbalanced dataset automatically. It provides the best balance of ease (low-code), performance, and latency for this scenario. Option D (BigQuery ML queried via federation) would incur BigQuery query latency, exceeding 100ms. Option B (custom XGBoost) adds operational complexity without guaranteed latency improvement. Option C is incorrect—Google Cloud does not offer a pretrained fraud detection API; this would require custom modeling.

Option A is correct: The Cloud Natural Language API is a pretrained, immediately available API that supports both sentiment analysis (analyzeSentiment) and entity extraction (analyzeEntities) out of the box, with no training data or model management required—perfectly matching 'fastest time-to-value with minimal engineering overhead.' Option B is incorrect: AutoML Natural Language requires labeled training data and model training time, which contradicts the constraint that no custom training data is available and undermines the fastest time-to-value goal. The Natural Language API portion for entity extraction would work but the hybrid approach is unnecessary. Option C is incorrect: ARIMA_PLUS is a time-series forecasting model, not a text analysis tool, and the Translation API translates languages rather than normalizing or analyzing sentiment/entities. Option D is incorrect: AutoML Text Classification and Entity Extraction both require labeled training data and training pipelines, which are unavailable and add significant engineering overhead.

Using a custom container image stored in Artifact Registry is the recommended, cloud-native approach. It encapsulates all dependencies and configurations, and any team member can launch an identical Workbench instance from the same image, ensuring full reproducibility with minimal manual effort. Option A (requirements.txt) is fragile because pip may resolve slightly different transitive dependency versions across environments and requires manual steps. Option B (README documentation) is purely informational and does nothing to enforce reproducibility. Option C (disk snapshot) is operationally heavy, not version-controlled, and does not integrate cleanly with Vertex AI's managed notebook workflow.

Vertex AI Feature Store is purpose-built to ensure feature consistency between batch and online serving by storing feature definitions, transformations, and computed values in a centralized managed service. Option 0 is correct because Feature Store handles both batch ingestion (via Dataflow) and online retrieval with guaranteed consistency. Option 1 is wrong because executing the same logic separately in different systems (Dataflow vs. Cloud Run) risks subtle divergences and lacks versioning. Option 2 is wrong because exporting to Pandas doesn't scale to real-time serving and offers no consistency guarantees. Option 3 is wrong because BigQuery views and manual replication in Predictions duplicates logic and is error-prone.

Option B is correct. Converting notebook code into a tested, modular Python module is the production-ready approach. This ensures reproducibility, testability, and reusability. Option D skips testing and introduces technical debt. Option A adds unnecessary complexity and makes the pipeline dependent on notebook infrastructure, which is not designed for orchestration. Option C introduces unnecessary complexity and language switching without clear benefits. Professional ML engineering requires separating exploration (notebooks) from production (versioned modules).

Sublinear scaling in distributed training commonly results from three sources present in this scenario: (E) All-reduce communication overhead — as worker count grows, the time spent synchronizing gradients across workers increases, reducing the fraction of time spent on actual computation. (F) Data pipeline bottlenecks — if the tf.data pipeline is not parallelized (e.g., missing prefetch, parallel_interleave) or cannot sustain the aggregate throughput required by multiple workers, GPUs sit idle waiting for data. (A) Cloud Storage I/O contention — when multiple workers read the same files concurrently from GCS without sharding or caching, read bandwidth becomes a bottleneck. Option C is incorrect because Vertex AI does not impose an artificial throughput cap on training jobs. Option B is incorrect because keeping batch size constant actually means each worker processes a full batch independently (data parallelism), and in synchronous training the effective batch size grows with worker count; the scaling issue is not caused by this. Option D is incorrect because MultiWorkerMirroredStrategy fully supports many workers on Vertex AI and is not limited to 2 workers.

Option 0 is correct. High-memory GPUs (A100s) provide sufficient VRAM for 200 GB data partitions, and gpu_hist enables efficient GPU-accelerated tree construction. Option 1 is wrong because XGBoost doesn't require a separate CPU worker when using GPU acceleration; XGBoost can handle distributed training natively. Option 2 is suboptimal because relying only on CPU multi-threading forgoes GPU acceleration benefits and limits throughput. Option 3 is wrong because T4 GPUs have limited VRAM and won't efficiently handle large data partitions; disabling distributed training wastes GPU resources.

When using the Python package (non-container) approach for Vertex AI custom training, you bundle your code as a source distribution (sdist) with a setup.py that declares install_requires dependencies. Vertex AI installs the package via pip, which resolves and installs all declared dependencies before training begins. Option D is incorrect because executorImageUri specifies the base Docker image to use, not a requirements file path; Vertex AI does not accept a requirements.txt reference in that field for Python package jobs. Option A is incorrect because there is no mechanism to pre-install libraries into the Vertex AI-managed environment outside of a job submission; the environment is ephemeral and created fresh for each job. Option C is incorrect because Vertex AI training VMs are not directly accessible via SSH in the standard custom training flow, and manual package installation after job start is not a reproducible or production-appropriate approach.

A, D and F are correct. A: Vertex AI Model Monitoring integrates natively with Vertex AI endpoints to detect training-serving skew and prediction drift; on GKE this needs custom work. D: Vertex AI endpoints split traffic between deployed model versions through a simple setting, whereas GKE needs ingress or service-mesh configuration. F: managed endpoints remove cluster operations such as node upgrades, security patching and networking setup. B is wrong: custom Kubernetes operators and fine-grained node affinity are GKE capabilities, so they favor GKE. C is wrong: node taints and tolerations are Kubernetes scheduling controls; that level of node control is a reason to choose GKE, not Vertex AI managed endpoints. E is wrong: sidecar containers alongside the model server are a Kubernetes pattern that favors GKE.

Option 1 is correct. Knowledge distillation + quantization directly reduces model size and inference latency from 2-3 seconds to sub-second ranges while maintaining reasonable accuracy. Deploying on CPU is feasible for a smaller model. Option 0 improves throughput (batch processing) but doesn't reduce per-request latency; caching helps but doesn't achieve sub-second from 2-3s baseline. Option 2 (async queuing) increases throughput but increases user-perceived latency (they still wait in queue). Option 3 (larger machines) is cost-inefficient and may not achieve sub-second on a 13B model.

Option B is correct because setting minReplicaCount=1 ensures at least one replica is always running, preventing cold-start latency when traffic resumes in the morning. maxReplicaCount=10 allows the endpoint to scale up to handle peak load. A target CPU utilization of 60% provides headroom so scaling triggers before the replica is fully saturated. Option A is wrong because minReplicaCount=0 means the endpoint can scale to zero, which causes significant cold-start latency (potentially minutes for an LLM) when traffic first arrives—unacceptable for a customer-facing chat app. Option C is wrong because keeping 10 replicas at all times wastes significant cost overnight when traffic is minimal. Option D is wrong because fixed-schedule scaling is operationally complex, brittle if traffic patterns change, and still doesn't eliminate the cost/latency trade-off that autoscaling handles automatically.

Pruning (3) is the correct answer. Since you've identified that specific layers contribute minimally to accuracy but consume 40% of inference time, removing them directly addresses the bottleneck without sacrificing model quality. This is a targeted optimization. (0) Quantization is a valid technique but is less efficient than pruning when the problem has been diagnosed to specific layers. (1) Knowledge distillation is overkill for this scenario—you don't need a smaller model trained from scratch when you can simply remove underperforming layers. (2) Increasing batch size increases throughput but not latency per request, and may not be feasible in real-time defect detection scenarios where images arrive individually.

The correct answer is to implement early stopping logic within the training component code, configurable via parameters (e.g., early_stop_patience=10). This keeps the logic where it belongs—in the training logic—and is parameterizable. The pipeline definition does not change; only component code evolves. Option B (separate pipeline with grid search) is overkill and expensive. Option D (manual intervention) defeats automation. Option C (Cloud Composer wrapper) adds unnecessary orchestration layer when the logic should be in the component. Component-level early stopping is standard ML practice and integrates naturally with Kubeflow Pipelines.

The correct answer is option 3. Vertex AI Pipelines supports specifying artifact paths with built-in temporary storage that automatically cleans up after the pipeline run completes (or fails). This is the native, least error-prone approach. Option 1 would work but is overly complex and requires writing additional custom logic. Option 2 using lifecycle policies is too blunt—it would delete artifacts based on time rather than pipeline completion, potentially deleting useful intermediate artifacts. Option 4 adds unnecessary complexity with external services.

The correct answer is to create a separate validation component that evaluates both schema and anomalies and outputs a boolean, then use dsl.Condition() for conditional execution. This decouples validation logic from training, making the pipeline more modular and maintainable. Option B (manual checking) is not automated. Option D (conditional inside training) mixes concerns—validation should be explicit before training. Option C (conditional output) is fragile and doesn't clearly separate validation from training logic. Option A follows best practices for pipeline clarity and automated gating.

The correct answers are options 1 and 3. Option 1 (validation gate in CI/CD) is the most direct preventive measure—it stops non-compliant models from being promoted in the first place. Option 3 (pipeline component for validation) ensures metadata is validated and complete before the model even reaches the registry. Together, they provide layered protection. Option 2 (Cloud Audit Logs) only alerts after the violation occurs, which is reactive. Option 4 (Cloud Function on registration) is similar to option 3 but happens after registration, allowing the non-compliant model to exist temporarily. Option 5 (IAM policies) is too blunt and doesn't actually validate metadata—it only restricts who can promote.

Configuring autoscaling with minimum and maximum replica counts is the correct approach for handling variable traffic on a Vertex AI endpoint. It allows the endpoint to scale out during peak hours and scale in during off-peak hours, optimizing both performance and cost. Option A (fixed replicas at peak capacity) ensures availability but wastes resources and cost during off-peak hours—it does not minimize cost. Option D (Batch Prediction) is designed for offline, asynchronous workloads and cannot serve real-time, low-latency online prediction requests. Option B (single large replica) is a fragile design—a single point of failure with no redundancy—and may still not handle peak traffic if a single machine's throughput is insufficient.

The correct answer is B. Stratified sampling at prediction time (logging 10% of requests) is more cost-effective than post-hoc sampling and maintains statistical validity by ensuring representation across different prediction classes. Vertex AI Model Monitoring can operate on stratified samples. A is incorrect because logging 100% first then sampling wastes storage resources; sampling should happen at prediction time. C is wrong because logging only low-confidence predictions introduces selection bias—you miss high-confidence errors and cannot accurately assess overall model performance. D is incorrect because disabling prediction logging eliminates visibility into prediction quality and would prevent timely detection of performance issues beyond just skew/drift.

When input features are stable but prediction score distributions shift, this is prediction drift (also called concept drift), meaning the underlying relationship between features and the target has changed. The correct first action is to investigate whether real-world dynamics have shifted. Option B is wrong because feature skew refers to discrepancies between training and serving feature values, and immediate retraining without understanding the root cause is premature. Option C is wrong because training-serving skew specifically refers to inconsistencies in how features are computed between training and serving pipelines—not applicable here since features appear stable. Option A is wrong because data drift describes changes in the input feature distribution, which the question states is not occurring here.