Fundamentals of Generative AI practice questions

The max_output_tokens is too low; increase it to allow more diverse output.

Why it fails: Max tokens controls length, not repetition.

The model is overfitted; switch to a smaller model.

Why it fails: Overfitting is unlikely in pre-trained models; repetition is a decoding issue.

The temperature is too low; increase temperature to add randomness.

Why it fails: Low temperature makes output more deterministic, increasing repetition.

Vertex AI Grounding with their compliance database.

Why it fails: Grounding improves accuracy but does not block specific phrases.

Prompt engineering with instructions to avoid guarantees.

Why it fails: Prompt engineering is not foolproof; safety filters are more robust.

Reinforcement learning from human feedback (RLHF) on the model.

Why it fails: RLHF is costly and not a real-time filter.

Increase the max_output_tokens parameter.

Why it fails: Length does not affect factual accuracy.

Increase the top_p parameter.

Why it fails: Higher top_p increases diversity, which can reduce accuracy.

Add a post-processing step to verify facts using a database.

Why it fails: This is not a parameter adjustment.

Use a system prompt instructing the model to avoid PII.

Why it fails: Prompt instructions are not always followed reliably.

Fine-tune the model on a dataset that excludes PII.

Why it fails: Fine-tuning does not guarantee PII filtering.

Manually review each output before sending.

Why it fails: Manual review is not scalable or real-time.

Cost per million tokens.

Why it fails: Cost is operational, not a performance metric.

BLEU score against human-written moderation guidelines.

Why it fails: BLEU is for text generation, not classification.

Cloud Storage

Why it fails: Cloud Storage is object storage, not optimized for semantic search.

BigQuery

Why it fails: BigQuery is for analytics, not vector search.

Vertex AI Matching Engine

Why it fails: Matching Engine is the legacy name; Vector Search is the current service.

Add more diverse training data

Why it fails: May not address existing biases without analysis.

Manually review all generated emails before sending

Why it fails: Not scalable for large volumes.

Switch to a different generative model

Why it fails: Other models may also have bias.

Cost of API calls per request

Why it fails: Prompt engineering is cheaper per request.

Size of the base model

Why it fails: Model size is not a primary factor.

The IAM permissions are insufficient

Why it fails: Permission errors are different.

The endpoint does not exist

Why it fails: Error mentions model status, not endpoint.

The model is already deployed to another endpoint

Why it fails: Error says not in READY state.

The safety score is very low (0.01)

Why it fails: Low score indicates low harmful content.

The deployed model ID is not recognized

Why it fails: ID appears valid.

The prediction content is incorrect

Why it fails: Content may be correct but still risky.

Store all patient data in Cloud Storage with object versioning.

Why it fails: Object versioning preserves historical copies of objects; it neither restricts access nor encrypts protected health information, so it does not satisfy HIPAA safeguards. It tempts because versioning supports audit and recovery, which would be correct for tracking data lineage, not for meeting privacy and security requirements.

Enable encryption at rest for all resources.

Why it fails: Encryption at rest protects stored data but leaves the deployed endpoint, access controls and audit logging unaddressed, so it alone does not satisfy HIPAA. It tempts because encryption is a recognised safeguard, and it would be correct as one component within a broader compliant deployment.

Use a publicly accessible endpoint for faster response times.

Why it fails: A publicly accessible endpoint exposes protected health information to unauthenticated access, directly breaching HIPAA's access-control requirements. It tempts because public endpoints reduce latency and simplify integration, and that would be correct for non-sensitive workloads where response speed outweighs confidentiality.

Reduce the model size by decreasing the number of layers.

Why it fails: Cutting layers shrinks parameter memory but alters model capacity and requires retraining, so it does not address activation memory driving the OOM. Reducing size is tempting because it genuinely lowers memory, and it is right when the model itself exceeds device capacity rather than the training configuration.

Increase the batch size to maximize TPU utilization.

Why it fails: A larger batch increases activation memory per step, worsening the OOM rather than relieving it. Raising batch size is tempting because it genuinely improves TPU utilisation and throughput, and it is the correct lever once memory headroom exists and training is under-utilising the accelerator.

Use mixed precision training (bfloat16) to reduce memory footprint.

Why it fails: Mixed precision reduces memory but may not be sufficient for very large models causing OOM.

Model's support for multiple programming languages.

Why it fails: Multi-language support matters only if the team writes in several languages; the scenario generates Python, so Python-specific benchmark performance and context length dominate. Breadth across languages is tempting because it genuinely indicates generalisation, and it is correct when a model must serve polyglot codebases rather than one language.

Model's training data recency.

Why it fails: Training data recency affects currency of libraries and idioms, not a model's fundamental code-generation capability; a model trained on older but vast, high-quality code can still excel. Recency matters when the task depends on newly released APIs or framework versions absent from training.

Model's parameter count (size).

Why it fails: Parameter count alone does not determine code-generation quality; architecture, training data and fine-tuning matter more, and larger models cost more to serve. Size is relevant when latency and cost budgets permit, or when a task needs greater reasoning capacity than a smaller model provides.

Increase the model's temperature to make outputs more conservative.

Why it fails: Raising temperature increases sampling randomness and typically amplifies toxic or erratic outputs rather than suppressing them. It is tempting because temperature is a familiar generation control, and lowering it would be the correct direction for more conservative, predictable responses.

Use a separate language model to rephrase the outputs before sending to users.

Why it fails: Rephrasing with a second model adds latency and cost while leaving the underlying toxic generation unaddressed; the rephraser can also fail to sanitise meaning. It is tempting because output post-processing suits style or tone rewriting, but immediate toxicity reduction is achieved through safety filters.

Fine-tune the model on a curated dataset of polite conversations.

Why it fails: Fine-tuning requires curated data, training time and evaluation, so it cannot be implemented immediately; it also risks degrading general capability. It is tempting because fine-tuning genuinely aligns tone over time, and would be correct for a longer-term behavioural change rather than an urgent mitigation.

Grant the user roles/aiplatform.specialist at the project level.

Why it fails: roles/aiplatform.specialist grants broad Vertex AI administration, not the specific aiplatform.pipelineJobs.create permission the user lacks. It tempts administrators because specialist roles suit managing platform-wide resources, and it would be correct when a user must administer Vertex AI services across a project rather than run pipeline jobs.

Add the user roles/aiplatform.user at the model level to allow pipeline creation.

Why it fails: roles/aiplatform.user cannot be granted at model level; Vertex AI IAM policies are set at project, folder or organisation level, so this binding fails. It tempts because aiplatform.user does include pipeline job creation, and it would be correct when granted at the project level to a user needing to run pipelines.

Remove the service account from roles/aiplatform.admin.

Why it fails: Removing the service account from roles/aiplatform.admin revokes permissions the service account needs to run Vertex AI operations, worsening the failure. It tempts as least-privilege hygiene, and it would be correct where an unused or over-privileged service account poses a security risk that must be eliminated.

The user is not authorized to use Vertex AI at all

Why it fails: The exhibit shows a role granting some Vertex AI permissions, so the user is authorised for the platform; the failure stems from missing endpoint deployment permissions within that role. It is tempting because a wholly absent Vertex AI role would also cause failure, but that contradicts the permissions visible in the exhibit.

The model artifact is not in the same region as the endpoint

Why it fails: Vertex AI permits cross-region model artefacts to be deployed to an endpoint in another region, so region mismatch does not block deployment. It is tempting because co-locating resources is a latency and data-residency best practise, but the actual failure here is the role lacking endpoint deployment permissions.

The user needs the roles/aiplatform.admin role

Why it fails: roles/aiplatform.admin grants full platform control, exceeding what deployment needs; the least-privilege fix is adding roles/aiplatform.user or a custom role with endpoint permissions. It is tempting because admin certainly works, but the stem asks the most likely cause, which is the specific missing permission.

Use a zero-shot model with context in prompt

Why it fails: Zero-shot prompting with context still transmits the proprietary documents into the prompt, so they reach the model, violating the requirement not to expose them. It is tempting because prompt-based context avoids retraining, and it would be correct when documents are non-sensitive or already permitted to leave the environment.

Fine-tune the model on the documents

Why it fails: Fine-tuning ingests the proprietary documents into model weights, directly exposing them to the model and its provider, which the scenario forbids. It is tempting because fine-tuning specialises a foundation model on domain data, and it would be correct when the corpus may be shared and the goal is embedded domain style rather than retrieval.

Use prompt engineering to instruct the model

Why it fails: Prompt engineering alone cannot answer questions over a large proprietary corpus; without retrieval, the documents never reach the model, so answers are ungrounded. It is tempting because prompting is lightweight and needs no training, and it would be correct for steering tone or format on tasks requiring no private knowledge.

The prompt is too vague

Why it fails: A vague prompt cannot make a model emit confidential strings it never learned; the leakage originates in the fine-tuning data. It is tempting because prompt quality genuinely affects outputs, and prompt refinement would be the answer if the model were disclosing only information already present in its context.

The model is too large

Why it fails: Parameter count does not cause disclosure of specific confidential strings; memorisation of training examples does. It is tempting because larger models can memorise more, but model size alone is not the mechanism, and scaling up would be the answer for a capacity or capability shortfall.

Overfitting to the training data leading to memorization

Why it fails: Overfitting can cause memorization, but the root cause is usually the dataset itself.

Training dataset size

Why it fails: Training dataset size describes the data a model was built on, not how well it summarises; evaluation criteria such as output quality, latency, cost and supported context length drive selection. Dataset size matters when judging reproducibility or bias. Summarisation quality is measured on task-specific benchmarks.

Cost per token

Why it fails: Cost per token governs inference billing, not output quality, so it cannot rank summarisation accuracy or faithfulness. It is tempting because budget planning genuinely matters at scale, and cost per token would be a leading criterion when selecting between models of comparable summarisation quality under a fixed spend cap.

Model size in parameters

Why it fails: Parameter count is an architectural property, not a measure of summarisation fidelity; a smaller fine-tuned model can outperform a larger base model. It is tempting because parameter count often correlates with capability, and it would be a valid criterion when estimating serving latency, memory footprint or hardware requirements.

model_type

Why it fails: model_type declares the serving framework and prediction interface; omitting it leaves the resource without a deployable container contract. It is tempting because model_type appears in many Vertex AI model schemas, yet it would be the correct answer only where the framework is genuinely unspecified rather than the artifact location being absent.

artifact_uri

Why it fails: artifact_uri points to the saved model files; without it the resource references no trained artifacts, so no container can load weights and deployment fails. It is tempting because artifact_uri is a required field in Vertex AI model configuration, and it would be the correct answer whenever the model files' Cloud Storage path is genuinely missing.

description

Why it fails: description is optional metadata for human readability and plays no part in deployment validation, so its absence cannot cause a not-deployable error. It is tempting because documentation fields feel mandatory, but it would be the correct answer only for a question about labelling or governance, not deployability.