Free Google Cloud Professional ML Engineer Practice Questions: Low-Code AI Architecture

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: Architecting Low-Code AI Solutions

A retailer is using BigQuery ML for a low-code model. The requirement is to predict weekly units sold for each product for the next 8 weeks from three years of weekly sales history. A data scientist trains a LINEAR_REG model using product ID and week fields as features. It performs acceptably on a random validation split, but error is much worse on the most recent 8 weeks and the output does not generate future time periods. What is the most likely diagnostic conclusion?

Options:

• A. Use LOGISTIC_REG for classification.

• B. Use KMEANS for clustering.

• C. Use ARIMA_PLUS for forecasting.

• D. Keep LINEAR_REG and remove product ID.

Best answer: C

Explanation: The core issue is a model-type mismatch. The business problem asks for future values over time, not a one-row numeric prediction from an arbitrary feature set. In BigQuery ML, ARIMA_PLUS is designed for time-series forecasting and can forecast future periods from timestamped historical data. A random validation split can hide this problem because it mixes past and future observations; evaluating on the most recent 8 weeks better reflects the production forecasting task. LINEAR_REG is appropriate for general continuous-value regression, but it does not provide the same forecasting workflow for future time periods.

• Classification confusion fails because units sold is a numeric quantity, not a class label.
• Clustering first fails because grouping products is not the stated goal and does not produce forecasts.
• Feature removal fails because the main issue is the forecasting model type, not the presence of product ID.

Question 2

Topic: Architecting Low-Code AI Solutions

An online marketplace needs a moderation assistant for short product reviews. It must classify policy violations and produce a short reviewer-facing reason. The team has 12,000 labeled examples, needs a production candidate in six weeks, and cannot fund large-scale GPU pretraining. Which engineering decision BEST satisfies these constraints?

Options:

• A. Use Document AI API for review extraction.

• B. Train a multilingual transformer from scratch.

• C. Fine-tune a Model Garden text foundation model.

• D. Build a BigQuery ML logistic regression model.

Best answer: C

Explanation: Model Garden is the right starting point when the task matches capabilities that pretrained foundation or open-source models already provide, especially text understanding and generation. The team has modest labeled data, a short timeline, and no budget for large-scale pretraining, so adapting an existing text model is more practical than building the language model from scratch. Fine-tuning or prompt-based evaluation can focus effort on the marketplace policy labels and reviewer-facing output while using managed Google Cloud tooling. Training from scratch is reserved for cases with very large proprietary datasets, specialized architecture needs, and substantial compute resources.

• Training from scratch is too costly and slow for 12,000 examples and a six-week delivery target.
• BigQuery ML regression can support structured prediction, but it does not address natural-language reasoning and generated explanations.
• Document AI extraction targets document parsing, not moderation decisions over short product-review text.

Question 3

Topic: Architecting Low-Code AI Solutions

A finance team built a low-code invoice intake prototype that sends each full PDF and a few examples to Gemini to extract 12 fixed fields. In production testing, p95 latency is 8 seconds against a 2-second target, model cost is 3x budget, output parsing breaks after prompt edits, and the operations team requires managed high availability with minimal custom code. Which architecture should the team validate as the next diagnostic step?

Options:

• A. Increase Gemini retries and output token limits

• B. Fine-tune Gemini for every invoice layout

• C. Use Document AI for fixed extraction and Gemini only for exceptions

• D. Deploy an open-source vision-language model on GKE

Best answer: C

Explanation: The evidence points to an architectural mismatch, not just a prompt-quality problem. The workload has standard documents and fixed fields, while the failed requirements are latency, cost, output stability, and low operational maintenance. A managed, task-specific low-code service such as Document AI is usually the first architecture to validate for document extraction. Gemini can still be useful for exception handling, summarization, or ambiguous cases, but making it process every full PDF with few-shot examples increases token usage and can make output contracts harder to maintain. Moving to custom serving or broad fine-tuning adds complexity before proving that the task-specific managed API is insufficient.

• Fine-tuning first may help some generative tasks, but it does not directly address fixed-field extraction cost, parsing stability, or operational simplicity.
• Self-managed serving on GKE conflicts with the requirement for minimal custom code and managed high availability.
• More retries and tokens would likely increase latency and cost instead of diagnosing the architecture mismatch.

Question 4

Topic: Architecting Low-Code AI Solutions

A finance team receives 50,000 supplier invoices per month as PDFs and scanned images. They need vendor name, invoice total, due date, and line items within minutes of upload. They do not have a labeled training set and want to minimize model operations. What is the best engineering decision?

Options:

• A. Use Document AI API with a prebuilt invoice processor.

• B. Train a custom OCR model on Agent Platform.

• C. Fine-tune Gemini using labeled invoices in BigQuery.

• D. Build regex extraction on Vision API OCR output.

Best answer: A

Explanation: For standard document understanding tasks, prefer a managed API before building a custom model. Invoice parsing is already supported by Document AI API with prebuilt processors that extract structured fields from PDFs and scanned images. This avoids collecting a labeled training set, reduces MLOps burden, and provides a production-ready API pattern for high-volume processing. Custom training or fine-tuning is more appropriate when the task is novel, the schema is highly specialized, or the managed API cannot meet accuracy or field requirements after validation.

• Custom OCR adds training data and serving work for a capability that is already managed.
• Vision OCR plus regex may read text, but it is brittle for varied invoice layouts and line items.
• Gemini fine-tuning requires labeled examples and is unnecessary when a purpose-built invoice processor exists.

Question 5

Topic: Architecting Low-Code AI Solutions

A support organization is building a managed low-code model on Gemini Enterprise Agent Platform. The goal is to score new tickets for likelihood of missing a 4-hour SLA so they can be escalated. The BigQuery table has 3 million historical tickets with ticket text, queue, timestamps, resolution outcome, and assigned team. The current Agent Platform AutoML plan uses assigned team as the label because it is complete; the pilot has high team-prediction accuracy but poor recall on actual SLA misses. What is the BEST engineering decision?

Options:

• A. Retrain with an SLA-miss target label.

• B. Fine-tune Gemini to predict assigned team.

• C. Add more assigned-team training rows.

• D. Tune thresholds on the team classifier.

Best answer: A

Explanation: The issue is a mismatched training objective. The business needs a binary risk score for SLA misses, but the model is trained to predict assigned team. High accuracy on the wrong label does not imply useful escalation performance. Because the BigQuery table includes timestamps and resolution outcome, the team can derive a historical SLA-miss label and train an Agent Platform AutoML classifier against the actual decision target. After retraining, evaluation should focus on metrics that reflect escalation risk, such as recall for SLA misses and precision at the chosen operating point. Adding rows or tuning thresholds cannot fix a model trained on the wrong outcome.

• Assigned-team labels are complete, but they represent routing history rather than SLA risk.
• More same-label data may improve team prediction while leaving SLA-miss recall poor.
• Threshold tuning only helps when the model output is already aligned to the decision being optimized.

Question 6

Topic: Architecting Low-Code AI Solutions

A retailer wants to use Agent Platform AutoML to build a low-code demand forecasting model for 5,000 store-SKU combinations. Historical sales are in BigQuery as transaction-level rows, and promotion and calendar data are in separate tables. The team needs a reliable first model quickly and wants to avoid using information that would not be known at forecast time. Which data-preparation action is the best engineering decision before training?

Options:

• A. Convert the tables to prompt-response examples for Gemini fine-tuning.

• B. Aggregate to daily store-SKU rows with timestamp, target, series ID, and known-ahead features.

• C. Train directly on transaction rows and let AutoML infer the forecast horizon.

• D. Randomly split all rows and include future inventory and return outcomes as features.

Best answer: B

Explanation: For an Agent Platform AutoML forecasting workload, the training data should represent the forecasting unit and time grain the model must predict. Here, that means one row per store-SKU per day, with a timestamp column, a target such as daily units sold, and a time-series identifier such as store-SKU. Joining calendar and promotion fields is useful only when those fields are known at prediction time. This preparation makes the dataset match the serving problem and reduces leakage. Transaction-level rows are usually the wrong grain for demand forecasting because multiple rows can represent the same item and day, and random splits across time can hide leakage.

• Raw transactions do not provide a clean per-period target or series structure for forecasting.
• Random splitting with future outcomes leaks information that would not be available when generating forecasts.
• Gemini fine-tuning is for generative tasks, not the best low-code path for structured demand forecasting.

Question 7

Topic: Architecting Low-Code AI Solutions

A team uses BigQuery ML logistic regression to predict whether active subscribers will churn in the next 30 days. Offline evaluation shows AUC = 0.99, but the first production batch scores perform near random. The top weighted feature is cancellation_request_timestamp, which is populated only after a customer requests cancellation.

What is the most likely cause and next diagnostic step?

Options:

• A. Remove the post-outcome feature and retrain

• B. Normalize all numeric features before prediction

• C. Switch the model to BigQuery ML k-means

• D. Increase the training window to include older subscribers

Best answer: A

Explanation: Feature selection for BigQuery ML should exclude columns that are irrelevant, redundant, or leakage-prone for the prediction task. Here, cancellation_request_timestamp is created after the event the model is supposed to predict, so it lets the model learn a shortcut during offline evaluation. In production, that value is missing or not meaningful when scoring active subscribers, causing the metric to collapse. The next step is to remove features that would not be known at the prediction timestamp, then retrain and re-evaluate using the same feature availability assumptions as serving.

• Clustering model fails because churn prediction with labels is a supervised classification task, not k-means clustering.
• More history does not fix leakage from a feature populated after the prediction point.
• Normalization may help some models, but it does not address a feature that reveals the label offline and is unavailable at serving time.

Question 8

Topic: Architecting Low-Code AI Solutions

A retailer wants to build a BigQuery ML classification model to predict subscription churn. The training data is already in BigQuery and includes raw timestamps, plan and region codes, monetary amounts, discounts, and free-text support notes that may contain PII. The team needs daily batch predictions with ML.PREDICT, low operational overhead, and consistent preprocessing between training and prediction. Which is the BEST engineering decision before model training?

Options:

• A. Apply feature transformations only after ML.PREDICT returns scores.

• B. Train on all raw columns and rely only on automatic preprocessing.

• C. Use TRANSFORM to derive recency/ratios, encode categories, and exclude PII.

• D. Export the data to notebooks for manual one-hot encoding.

Best answer: C

Explanation: Feature engineering is appropriate when raw fields do not directly represent the predictive signal or should not be used as-is. In this scenario, timestamps should become useful churn signals such as tenure or days since last activity, monetary fields can be combined into ratios such as discount percentage, categorical fields can be encoded or grouped, and PII-bearing text should be excluded or safely transformed. Using BigQuery ML’s TRANSFORM clause keeps these changes inside the model workflow, so ML.PREDICT can apply the same preprocessing to new rows and reduce training-serving skew. Exporting or post-processing adds operational risk and does not satisfy the low-code BigQuery ML constraint.

• Raw-column training misses domain-specific transformations and risks using PII-bearing text directly.
• Notebook encoding adds data movement and maintenance overhead when SQL-based BigQuery ML preprocessing fits the requirement.
• Post-prediction transforms are too late because the model must be trained and served on the engineered features.

Question 9

Topic: Architecting Low-Code AI Solutions

A retail company is building a Gemini-based shopping assistant for live chat. Users abandon the session if they do not see a response quickly, and evaluation shows that a faster Gemini model is accurate enough for the recommendations. Which configuration should you recommend to optimize the interactive user experience?

Options:

• A. Run the chat workflow in Agent Platform Pipelines

• B. Generate recommendations with batch predictions

• C. Use Gemini Flash with response streaming

• D. Fine-tune a larger Gemini model using BigQuery

Best answer: C

Explanation: For a Gemini-based interactive application, latency is improved at the serving and interaction layer. A faster model variant such as Gemini Flash is designed for lower-latency, cost-efficient responses, and streaming lets the user see tokens as they are generated instead of waiting for the full answer. This fits a live chat workflow where perceived response time matters and quality is already acceptable with the faster model.

Fine-tuning, pipeline orchestration, and batch prediction can be useful in other lifecycle stages, but they do not directly optimize real-time chat responsiveness.

• Larger fine-tuning can improve task adaptation, but it often increases complexity and does not directly reduce interactive response latency.
• Pipeline orchestration is for repeatable ML workflows, not low-latency request handling for live chat.
• Batch prediction is designed for offline throughput, not immediate user-facing responses.

Question 10

Topic: Architecting Low-Code AI Solutions

A utility company built a Gemini-based support triage assistant that must assign one of 40 internal outage categories. The prompt includes the JSON schema, category descriptions, and few-shot examples; the app validates JSON and retries invalid responses.

Evaluation finding: output format is valid, retrieval returns the right policy pages, but held-out tickets are still mapped to the wrong nuanced domain categories. What is the best next step?

Options:

• A. Add more JSON validation and retry logic

• B. Rewrite the prompt with stricter formatting instructions

• C. Fine-tune Gemini on representative labeled tickets

• D. Increase the number of retrieved policy pages

Best answer: C

Explanation: Fine-tuning is appropriate when the model needs to learn a task-specific pattern that is not solved by clearer instructions, output validation, or more context. In this case, the app already produces valid JSON and retrieves relevant policy pages, so the remaining failure is the semantic mapping from ticket language to the utility company’s internal category taxonomy. Representative labeled examples can teach that mapping more directly than adding more prompt text or application rules.

Prompt engineering is usually the first step for formatting, tone, tool use, and simple task guidance. Tuning becomes more defensible when repeated prompt and logic changes plateau on a stable evaluation set for a specialized use case.

• More validation fails because the responses are already valid JSON; the issue is category correctness.
• Stricter formatting fails because formatting is not the failing requirement in the evaluation.
• More retrieval fails because the retrieved policy pages are already accurate, so missing context is unlikely.

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
• Data and Model Collaboration
• Scaling ML Models
• Serving and Scaling Models
• ML Pipeline Automation
• Monitoring AI Solutions