Free Google Cloud Professional ML Engineer Practice Questions: Scaling ML Models

Topic snapshot

Sample questions

These are original IT Mastery practice questions aligned to this topic area. They are not official Google Cloud questions, copied live-exam content, or exam dumps. Use them to preview question style and explanation depth before continuing with topic drills, mixed sets, and timed mocks in IT Mastery.

Question 1

Topic: Scaling Prototypes into ML Models

An ML team built a churn model prototype in Agent Platform Workbench from a BigQuery export. Offline AUC is 0.94, so the team wants to wrap the notebook in Agent Platform Pipelines and deploy it. A production readiness check finds that the highest-impact features are cancellation_reason, refund_amount, and support_case_closed, which are populated after the churn event. The online system must score active customers daily. What is the most appropriate next step?

Options:

• A. Redesign the feature set around prediction-time-available signals.

• B. Retrain the same features with Agent Platform AutoML.

• C. Use distributed custom training to improve offline AUC.

• D. Convert the notebook unchanged into Agent Platform Pipelines.

Best answer: A

Explanation: The readiness finding points to target leakage and a production feature-availability problem. Features populated after churn cannot be used when scoring active customers, even if they produce strong offline metrics. A managed workflow such as Agent Platform Pipelines can improve repeatability, lineage, and deployment discipline, but it should not operationalize a prototype whose core inputs are invalid for the serving context. The next step is to redesign the modeling approach around features available at daily scoring time, then rebuild training and serving logic consistently.

• Pipeline unchanged fails because orchestration would automate a flawed prototype rather than fix invalid inputs.
• AutoML retraining fails because changing the training product does not remove post-event leakage.
• Distributed training fails because more compute and higher offline AUC do not address production feature availability.

Question 2

Topic: Scaling Prototypes into ML Models

An insurance team is moving a claim-triage prototype into production. The business requires feature-level explanations for every release, monthly retraining from BigQuery tables, and stable operations. The acceptance target is AUC ≥ 0.80; marginal gains are less important than interpretability and maintenance.

Prototype results

Which training setup should the team choose?

Options:

• A. Train a BigQuery ML logistic regression model

• B. Train a BigQuery ML boosted tree model

• C. Train a custom DNN on GPU workers

• D. Deploy an ensemble of all three models

Best answer: A

Explanation: When a baseline model already meets the acceptance criteria, prefer the simplest model that satisfies the business constraints. Here, logistic regression exceeds the AUC target and provides stable, easy-to-review feature effects. It also fits the monthly retraining requirement because the data is already in BigQuery. The boosted tree and DNN options add only small AUC gains while reducing transparency or increasing tuning and operational burden. In production ML, extra complexity is justified only when it materially improves the business outcome or satisfies a requirement the simpler model cannot meet.

• Boosted trees improve AUC slightly, but the scenario values explainability and stability over a marginal lift.
• GPU-based DNN training adds tuning and serving complexity without a requirement that needs it.
• Ensembling can improve metrics, but it complicates explanations, monitoring, and release operations.

Question 3

Topic: Scaling Prototypes into ML Models

A team is fine-tuning a large foundation model from Model Garden by using Agent Platform custom training. The model weights and activations do not fit in memory on a single accelerator, even with a very small micro-batch. The team wants to distribute training with the least architectural mismatch. Which training setup should they choose?

Options:

• A. Scale multiple Agent Platform Inference endpoints.

• B. Use model parallelism and partition the model across accelerators.

• C. Use gradient accumulation on one accelerator.

• D. Use data parallelism and split each batch across replicas.

Best answer: B

Explanation: The key distinction is what drives the distribution strategy. Model parallelism partitions the model itself across accelerators, so it is appropriate when the model is too large to fit on one device. Data parallelism replicates the full model on each worker and sends different data batches or shards to each replica, which improves throughput but still requires every device to hold the full model. In this scenario, the stated blocker is accelerator memory for the model, not batch-processing throughput. The best setup is therefore to split the model across devices rather than only splitting the data.

• Data parallel replicas fail because each replica still needs the complete model in accelerator memory.
• Gradient accumulation can simulate a larger batch, but it does not make an oversized model fit on one device.
• Inference endpoint scaling is a serving-stage approach, not a training distribution strategy.

Question 4

Topic: Scaling Prototypes into ML Models

A team is scaling a tabular fraud-detection prototype into a production model on Google Cloud. Risk stakeholders will not approve the model unless they can review why individual predictions are made and which features most influence outputs. What is the best implementation choice before promotion?

Options:

• A. Increase training jobs to use GPUs

• B. Run Agent Platform explainability for feature attributions

• C. Use Model Armor safety filters on predictions

• D. Add Model Monitoring drift alerts after deployment

Best answer: B

Explanation: The requirement is interpretability during model review, not faster training or post-deployment operations. For a tabular predictive model, feature attribution explanations show how input features contribute to predictions. Stakeholders can inspect local explanations for individual decisions and aggregate attribution patterns to understand global feature influence before approving the model architecture for production. This review should happen alongside model evaluation and governance steps, before the model is promoted or broadly served.

Drift monitoring is useful after deployment, but it does not explain the current model’s decisions during approval. Compute changes and gen AI safety controls address different layers of the ML lifecycle.

• Drift alerts are operational monitoring signals and do not satisfy a pre-promotion explanation requirement.
• GPU training may reduce training time but does not make predictions interpretable.
• Model Armor is aimed at securing generative AI interactions, not explaining tabular model feature influence.

Question 5

Topic: Scaling Prototypes into ML Models

An ML team has a notebook prototype that predicts subscription churn from a BigQuery table with numeric and categorical features. They need to move to production quickly, use managed feature transformations and training infrastructure, and avoid writing a custom training container. The model will be registered and served from Gemini Enterprise Agent Platform. Which training setup best meets these requirements?

Options:

• A. Convert the notebook into a Cloud Run prediction service

• B. Run distributed TensorFlow custom training on GKE

• C. Train with Agent Platform AutoML for tabular classification

• D. Build a Dataflow preprocessing job and reuse the notebook model

Best answer: C

Explanation: Agent Platform AutoML is appropriate for standard tabular classification or regression problems when the main requirement is to scale a prototype with managed training and reduced custom engineering. It can handle common tabular feature transformations, model search, tuning, and training infrastructure without requiring the team to package a custom container or manage distributed training. The stem does not require a custom model architecture, specialized training loop, or framework-level control, so custom training on GKE would add unnecessary operational complexity. Serving is a later lifecycle step and does not replace production-grade training.

• Custom training overreach fails because GKE and distributed TensorFlow are unnecessary without custom architecture or training-loop requirements.
• Serving stage mismatch fails because Cloud Run hosting does not provide managed model training or tuning.
• Preprocessing only fails because Dataflow can transform data but does not replace managed tabular model training.

Question 6

Topic: Scaling Prototypes into ML Models

A retail risk team is scaling a tabular classification prototype into production. The service must keep p95 prediction latency below 100 ms and provide stable feature-level explanations for audit reviews. Recent experiments show:

Which next step should the ML engineer recommend?

Options:

• A. Replace the tabular model with an LLM from Model Garden.

• B. Move the custom DNN endpoint to GPUs first.

• C. Add more hidden layers to the custom DNN.

• D. Promote the logistic regression baseline as the production candidate.

Best answer: D

Explanation: Model architecture should match the business and operational requirements, not just maximize a small offline metric gain. Here, the DNN improves validation AUC by only 0.004, but it fails the latency requirement and produces unstable attribution signals. The simpler logistic regression baseline already satisfies the required latency and provides more stable, auditable explanations. When performance is effectively tied, the production choice should favor explainability, reliability, maintainability, and simpler operations. Further tuning of the complex model is not the best next step unless the team can show a material benefit that justifies the added operational risk.

• More DNN layers would likely increase complexity and latency, while not addressing unstable explanations.
• GPU serving might reduce latency, but it does not solve the audit requirement for stable explanations.
• LLM replacement is mismatched for a structured tabular classification problem and adds unnecessary complexity.

Question 7

Topic: Scaling Prototypes into ML Models

An ML team scaled a notebook prototype into an Agent Platform custom training pipeline. Curated features are in BigQuery with policy tags and row-level security. The pipeline exports full tables nightly to CSV files in a Cloud Storage bucket in another region before training. Training startup time has increased, duplicate PII stores triggered a governance review, and analysts still need SQL access to the governed dataset. The training service can access BigQuery and run in the dataset region. Which data-location recommendation best addresses the likely cause?

Options:

• A. Package the training data inside the container image.

• B. Replicate the full dataset to every training region.

• C. Compress the exported CSV files before each training run.

• D. Keep BigQuery as canonical and train co-located with it.

Best answer: D

Explanation: The symptom points to unnecessary data movement: full governed BigQuery tables are copied to a separate, cross-region Cloud Storage location before every training run. For large curated datasets, keep the canonical data in the governed system of record and move compute closer to the data when possible. Training can read from BigQuery in the same region, preserving policy tags, row-level controls, and SQL access for analysts. If files are needed, materialize only the required training subset in a co-located location rather than duplicating full tables across regions. The key takeaway is to avoid creating redundant data stores when the existing governed location can serve both collaboration and training needs.

• Compression only may reduce file size, but it does not fix cross-region copying or duplicate PII storage.
• Full replication increases unnecessary movement and expands the governance surface instead of reducing it.
• Container packaging is unsuitable for large, changing training data and removes shared governed access.

Question 8

Topic: Scaling Prototypes into ML Models

A retailer is scaling an image-classification prototype from Agent Platform Workbench to Agent Platform custom training. The full dataset has 12 million product images in Cloud Storage, must use reproducible train/validation/test partitions for model approval, and must retain supplier-region metadata for fairness review. The distributed job reads CSV shards created by different teams; some use label, some use category, and only the notebook sample includes a split column. What is the best engineering decision before launching training?

Options:

• A. Create a versioned manifest and validate image_uri, label, split, and supplier-region fields.

• B. Use class-named folders as labels and drop supplier-region fields.

• C. Begin hyperparameter tuning and rank trials by training loss.

• D. Add more distributed workers and split records randomly per worker.

Best answer: A

Explanation: Scalable training needs a stable data contract before compute is added. In this scenario, the blockers are not model capacity or tuning; they are inconsistent label column names, missing partition assignments, and required fairness metadata that is not present across the full dataset. A versioned manifest or equivalent governed table should define each training example with its Cloud Storage URI, canonical label, split assignment, and required metadata, then run schema validation before the Agent Platform custom training job starts. This makes evaluation reproducible and allows downstream slicing by supplier region. Random splitting or folder-only labels would hide or discard required information.

• More workers fails because random per-worker splits do not restore missing split metadata or make approval metrics reproducible.
• Folder-only labels may work for simple image datasets but loses explicit partitions and supplier-region metadata.
• Hyperparameter tuning assumes reliable training and evaluation data; training loss cannot validate missing labels, splits, or metadata.

Question 9

Topic: Scaling Prototypes into ML Models

A team moves an image classification prototype from a notebook into an Agent Platform custom training pipeline. The images are stored in Cloud Storage, and the pipeline reads a CSV manifest to load training examples. The ingestion step fails with 0 image examples loaded from manifest.

What is the most likely cause?

Options:

• A. The model cannot train without a GPU accelerator.

• B. Image training requires BigQuery instead of Cloud Storage.

• C. The labels must be embedded in the image filenames.

• D. The manifest uses paths not accessible to the training job.

Best answer: D

Explanation: Image training pipelines need both the visual examples and the associated labels or metadata in a form the training job can access. In this case, the manifest contains relative notebook paths like ./images/cat_001.jpg. Those paths may have worked locally, but they are not resolvable from the managed training environment. The manifest should reference the Cloud Storage objects, typically with gs://... URIs, while preserving columns such as label, split, or other metadata needed by the task.

The key ingestion issue is not the model architecture or hardware; it is that the pipeline cannot locate the images described by the manifest.

• Filename labels are optional conventions; labels should be provided explicitly in the manifest or metadata source.
• BigQuery requirement is incorrect because image files are commonly stored in Cloud Storage, with labels in a manifest or table.
• GPU availability affects training speed or feasibility, but it does not explain zero examples loaded during ingestion.

Question 10

Topic: Scaling Prototypes into ML Models

A support organization has a Python prototype that reads a chat transcript, summarizes the issue, and drafts an agent reply in the company’s tone. Historical transcripts and approved replies are stored in BigQuery. The team must productionize in six weeks, avoid managing training infrastructure, and support responsible AI controls. Which approach is the BEST engineering decision?

Options:

• A. Train a custom Transformer model from scratch on GKE

• B. Build a BigQuery ML forecasting model

• C. Fine-tune Gemini with BigQuery examples using managed serving

• D. Train Agent Platform AutoML for text classification

Best answer: C

Explanation: Summarization, draft-response generation, and conversational behavior are LLM tasks. A Gemini foundation model is the right starting point, and fine-tuning with historical BigQuery examples can adapt the model to approved response style without building training infrastructure from scratch. Managed serving also fits the need to scale production traffic while using platform-level responsible AI controls such as safety filters and related evaluation processes.

Classification, forecasting, and custom model training are plausible ML approaches, but they do not best match the required generated text output and operational constraints.

• Text classification can label or route tickets, but it does not generate summaries or natural-language replies.
• Forecasting predicts future numeric values, so it misses the transcript-to-response task.
• Custom training from scratch could produce text, but it conflicts with the six-week timeline and minimal infrastructure requirement.

Continue in the web app

Use IT Mastery for interactive Google Cloud Professional ML Engineer practice with mixed sets, timed mocks, topic drills, explanations, and progress tracking.

Try Google Cloud Professional ML Engineer on Web

Related focused pages

• Free Google Cloud Professional ML Engineer Full-Length Practice Exam
• Low-Code AI Architecture
• Data and Model Collaboration
• Serving and Scaling Models
• ML Pipeline Automation
• Monitoring AI Solutions