PMLE Collaborating to manage data and models Practice Question
A company uses BigQuery to store feature data for ML training. A data engineer notices that a Vertex AI Training job is failing with 'Access Denied' errors when reading from a BigQuery table. The training job uses a custom service account that has been granted the 'bigquery.dataViewer' role on the dataset. What is the most likely cause of the failure?
⚠ Common exam trap
Many candidates assume 'bigquery.dataViewer' is sufficient for all read operations, overlooking the requirement for 'bigquery.jobs.create' to initiate the query job that actually reads the data.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The service account lacks the 'bigquery.jobs.create' permission in the project.
The 'bigquery.dataViewer' role grants permissions to read BigQuery data (e.g., bigquery.tables.getData), but it does not include the 'bigquery.jobs.create' permission. When a Vertex AI training job reads from BigQuery, it must first create a BigQuery job (a query job) to retrieve the data. Without 'bigquery.jobs.create' at the project level, the service account cannot initiate the read operation, resulting in an 'Access Denied' error even though it has data-level access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The service account is not in the same project as the BigQuery dataset.
Why it's wrong here
Cross-project access works when the dataset grants the service account a role, so project placement alone does not cause Access Denied. It is tempting because project boundaries often explain permission gaps, but bigquery.dataViewer on the dataset already authorises reads; the missing piece is job-level metadata access.
- ✗
The BigQuery table is partitioned and requires row-level access.
Why it's wrong here
Partitioning does not itself demand row-level access; bigquery.dataViewer permits reading all rows of the table. Row-level security is tempting because it restricts visible rows, but that policy is enforced through separate row access policies, not triggered merely by a partitioned table.
- ✓
The service account lacks the 'bigquery.jobs.create' permission in the project.
Why this is correct
Reading a BigQuery table requires a query job, which needs bigquery.jobs.create in the project. The bigquery.dataViewer role on the dataset grants table-level read access only, so the custom service account cannot start the job and Vertex AI returns Access Denied.
- ✗
The training job does not have the required network access to BigQuery.
Why it's wrong here
Network access is irrelevant here: the job reaches BigQuery, but the custom service account lacks the roles/bigquery.jobUser role at project level, which is required to run query jobs. Granting bigquery.dataViewer alone permits reading data, not job creation. Network controls would be the answer only if Private Google Access or VPC Service Controls blocked egress.
Go deeper
Related to this question
About these practice questions
One of 775 original PMLE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PMLE practice question is part of Courseiva's free Google Cloud certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the PMLE exam.