GenAI Leader sample questions — 25 answered and explained

Reinforcement learning trains an agent by trial and error: it takes actions in an environment, receives rewards or penalties, and learns a policy that maximises total reward. Reinforcement learning from human feedback (RLHF) applies the same idea to refine LLM answers.

The scores for each attempt are rewards and penalties for actions, the signature of reinforcement learning. Supervised learning needs labeled examples, which the stem rules out. Unsupervised learning has no reward signal. Transfer learning is reuse of an existing model, not learning from feedback on one's own actions.

1. Identify the feedback: a score after each action.
2. Positive and negative scores for actions are rewards and penalties.
3. Learning a strategy from rewards = reinforcement learning.

Exam tip: Actions plus rewards and penalties = reinforcement learning.

The ML lifecycle runs data ingestion, data preparation, model training, model deployment and model management. It behaves as a loop: management (monitoring, drift detection, retraining) feeds back into new data and training.

Each stage consumes the previous stage's output: raw data must be ingested before it can be prepared, prepared data feeds training, a trained model is deployed, and only a deployed model can be managed in production. Each wrong sequence swaps exactly one adjacent pair, which is the typical slip.

1. Start with data: collect it (ingestion), then clean and transform it (preparation).
2. Train the model on the prepared data.
3. Deploy it, then manage it in production (monitoring, versions, retraining).

Exam tip: Ingest → prepare → train → deploy → manage, then loop back.

Model management is the final, ongoing lifecycle stage: monitoring a deployed model's performance, catching data or concept drift, managing versions, and retraining or rolling back as needed.

The scenario describes a live model degrading over time, which is a monitoring-and-maintenance concern: model management. Data ingestion and data preparation are pre-training data stages. Model deployment is the act of releasing the model; it ends when the model is live, whereas management continues for the model's entire production life.

1. Recognize the situation: the model is already deployed and its quality is drifting.
2. Recall that post-deployment monitoring, drift detection, and retraining decisions belong to model management.
3. Rule out deployment: it ends once the model is live, while management continues for the model's whole production life.

Exam tip: Model management is the ongoing stage that monitors deployed models and triggers retraining when performance drifts.

Foundation model selection weighs modality, context window, security, availability and reliability, cost, performance, fine-tuning and customization. The context window is the amount of information a model can consider in one request.

Reasoning over a very long document in one pass, without chunking, depends on the context window. Modality is about input types, and this input is text. Fine-tuning changes behaviour, not input capacity. Cost is a secondary factor among models that can already fit the document.

1. Translate the need into a requirement: a very long input handled in one request.
2. Map input size to the context window.
3. Apply secondary factors such as cost and security only among models with a large enough window.

Exam tip: Very long inputs in a single request → check the context window first.

Model selection is a trade-off across factors, not a search for the most powerful model. For simple, high-volume, latency-sensitive tasks, a lighter, lower-cost model that meets the quality bar usually wins; frontier models are reserved for complex reasoning.

The constraints are about one second of latency at peak load and a sustainable cost, and the questions are simple, so a smaller model that is good enough satisfies every requirement. The frontier model is over-provisioned and works against latency and cost. Batch prediction is the tempting cost fix, but it is asynchronous and breaks the real-time requirement. Choosing on context window optimises a factor the scenario does not stress.

1. Identify the binding constraints: about one second of latency, sustainable cost.
2. Check task complexity: short, simple questions.
3. Pick the smallest model that meets the quality bar instead of the most capable one.

Exam tip: Simple, high-volume, latency-sensitive tasks → the lightest model that meets the quality bar.

Google Cloud frames gen AI business value as create, summarize, discover and automate. Summarize condenses long existing content into a short, decision-ready form.

The input is long existing content and the output is a shorter version of the same content, which is summarization. The word 'automatically' tempts toward automation, but the category is decided by what the model produces, not by whether it runs without a click. Creation would be drafting the reply, and discovery would be searching across many sources.

1. Identify the input: one long existing email thread.
2. Identify the output: a shorter overview of that same content.
3. Long content in, condensed content out = summarize, even when it runs automatically.

Exam tip: Classify by what the model produces: condensed existing content is 'summarize'.

Discover is the gen AI pattern of surfacing knowledge that already exists but is hard to find: conversational search across documents, plain-language data analysis and pattern spotting.

The tool's value is finding relevant information buried across thousands of documents, which is discovery. Summarization is the tempting twin because answers are short, but summarization condenses content you already have in hand. Creation produces new material, and automation removes workflow steps.

1. Identify the problem: knowledge exists but is scattered and hard to find.
2. Identify the output: answers located across many sources.
3. Finding existing knowledge across sources = discover.

Exam tip: Finding buried knowledge across many sources is 'discover'; condensing one known document is 'summarize'.

Scalable is the enterprise-ready quality about meeting growth and sudden surges in demand.

Match the quality to the concern the scenario stresses. A fifty-fold spike in requests is a volume problem, which scalability answers. Reliability is the closest distractor, because outages under load are a risk, but reliability is about consistent availability rather than added capacity.

1. Name the concern: a sudden, large increase in requests.
2. Map volume growth to scalability.
3. Separate scalability (capacity) from reliability (availability).

Exam tip: Surge in demand = scalable; staying up = reliable.

Reliable is the enterprise-ready quality about consistent, highly available operation.

The scenario stresses outages, so the matching quality is reliability. Scalability is the near-twin: both relate to keeping a service working, but scalability is about capacity for growth while reliability is about dependable availability. Privacy is relevant in healthcare but is not the concern the stem names.

1. Name the concern: the tool must not go down.
2. Map availability to reliability.
3. Resist privacy just because the data is medical; answer the stated concern.

Exam tip: Must not go down = reliable; must handle more = scalable.

Google's comprehensive AI ecosystem means gen AI is integrated across its products and services, from the Gemini app and Google Workspace to Gemini Enterprise and Google Cloud.

Because the same model family appears on every surface, an organization's investment in skills, governance and trust carries over, and the stack runs from infrastructure through models and platform to prebuilt applications under one security model. The open approach is the tempting near-twin, but interoperability with outside tools is about avoiding lock-in, not integration across Google's products. The other distractors swap integration for a partner model per product or a pricing arrangement.

1. Recall what the ecosystem objective stresses: integration of gen AI across Google products and services.
2. Separate it from the open approach, which is about interoperability and choice.
3. Pick the option where value comes from shared models across Google surfaces.

Exam tip: Ecosystem advantage = one family of AI integrated across every Google surface, so value compounds.

Google Cloud's open approach (open models such as Gemma, Model Garden's first-party, open and third-party catalog, and support for open frameworks) preserves choice and reduces lock-in.

Commercially, openness means the company can pick the best model for each task as needs change, keep workloads portable, and avoid depending on one provider's roadmap. One tempting distractor describes single-model standardization, which simplifies governance but is the lock-in openness avoids; the others misread "open" as free proprietary weights or free serving.

1. Recall the three-word summary of the open approach: choice, flexibility, reduced lock-in.
2. Check which option describes a business benefit of choice rather than of consolidation.
3. Reject claims about free Gemini weights, free serving or a single model for everything.

Exam tip: Open approach = choice of models and frameworks, so a platform decision never becomes a one-way door.

No-code and low-code tools are the democratization lever aimed at people who do not write code.

All three democratization levers lower the bar, but by different amounts. Pre-trained models and APIs remove training, yet APIs still need a developer to call them. No-code tools remove the coding step too, letting a domain expert assemble the helper through a visual interface. Fine-tuning or training a model moves in the opposite direction.

1. Note the constraint: the builder cannot write code.
2. Recognise that APIs still need application code.
3. Choose the tool designed for non-developers.

Exam tip: APIs are for developers; no-code tools are for everyone else.

SAIF is Google's Secure AI Framework: a framework of security practices for AI systems, part of what makes the platform secure.

SAIF extends established security practice to AI-specific risks such as attacks on models, data and AI applications. It sits beside, but is distinct from, Google's AI Principles, which govern responsible use. The distractors confuse SAIF with those principles, with a compliance attestation, or with a product that filters prompts.

1. Recall that SAIF is Google's Secure AI Framework.
2. Place it under the secure quality, not the responsible one.
3. Remember it is guidance, not a certificate or a service.

Exam tip: SAIF = Secure AI Framework (security); AI Principles = responsible use.

AI-optimized infrastructure (AI Hypercomputer, TPUs, GPUs and efficient data centers, delivered as cloud computing) benefits every customer, including those who never train a model.

Managed gen AI services are served on that infrastructure, so its efficiency and scale show up for the consumer as lower cost, faster responses and dependable availability, without capital investment. The tempting distractor assumes infrastructure only matters for training; the others assume the customer must own or pre-buy hardware.

1. Recall that serving (inference) runs on the same infrastructure as training.
2. Connect infrastructure efficiency to the cost, speed and uptime of managed services.
3. Reject options that require customer-owned or pre-purchased hardware.

Exam tip: Even pure consumers of managed AI benefit from the infrastructure underneath it.

Responsible is the enterprise-ready quality grounded in Google's published AI principles and responsible AI tooling.

Auditors asking about documented ethical guidelines, fairness and accountability are asking about responsible AI. Secure and private are the near-twins because they also sound like governance, but SAIF covers security threats and privacy covers data use. Reliability covers availability.

1. Name the concern: ethics, fairness and accountability.
2. Map ethics to the responsible quality and Google's AI principles.
3. Separate it from security (SAIF) and privacy (data use).

Exam tip: Ethics and fairness = responsible; threats = secure; data use = private.

The Gemini app is Google's conversational AI assistant, available on the web and on mobile, where individuals chat with Gemini models to brainstorm, draft, summarize, analyze uploaded files and get answers.

All four options describe real Google offerings, so the question is about positioning. The Gemini app is the standalone chat destination for an individual. Gemini for Google Workspace is the same family of models embedded inside Gmail, Docs and Sheets; Gemini Enterprise is the organization-wide layer grounded in company systems; Contact Center as a Service serves customers, not employees.

1. Identify what the stem asks about: the Gemini app itself, for employees.
2. Recall that the Gemini app is a standalone chat assistant on web and mobile.
3. Separate it from its siblings: Workspace is embedded in the apps, Gemini Enterprise is grounded in company systems.
4. Discard the customer-facing contact-center platform.

Exam tip: Gemini app = standalone chat assistant for an individual; Workspace = inside the apps; Gemini Enterprise = across company data.

Facts that change often, such as prices, policies and product lineups, are best handled by grounding the model in a live knowledge source through retrieval-augmented generation (RAG). The source can be updated instantly while the model stays unchanged.

The requirement is same-day freshness. RAG meets it because each answer is built from the documents as they stand when the question is asked. Monthly fine-tuning could work in principle but always lags and repeats training cost; a fixed prompt goes stale; monitoring only reports the problem.

1. Identify the problem: stale facts, so a freshness gap.
2. Apply the constraint: changes must show on the day they are published.
3. Choose the approach that reads current sources at answer time: RAG.
4. Reject approaches that lag (tuning), freeze (template) or only observe (monitoring).

Exam tip: For facts that change often, update the source and retrieve it; do not retrain the model.

For high-stakes outputs such as medical, legal or financial content, Google-recommended practice is human in the loop: a qualified person reviews and approves model output before it takes effect.

The requirement is to catch every error before release, which only a review step before sending can do. Grounding and prompting reduce how often errors happen, and drift monitoring finds patterns afterwards, but none of them puts a person between the draft and the patient.

1. Note the stakes: patient-facing medical content.
2. Note the requirement: errors must be caught before release.
3. Separate practices that reduce errors (grounding, prompting) from ones that catch them before use (HITL).
4. Choose clinician review and approval.

Exam tip: Grounding makes errors rarer; human review is what catches them before they reach people.

Prompt engineering is the lightest remedy available. When the problem is the shape, tone or structure of output rather than its knowledge, clear instructions and an example in the prompt are the recommended first step.

The facts are already right, so the gap is format, and the team wants the cheapest first move. Google's recommended sequence is prompt engineering first, grounding and RAG for factual gaps, and fine-tuning only when prompting falls short. A human editor would work but adds permanent cost.

1. Classify the gap: format, not facts.
2. Apply the constraint: cheapest and fastest first.
3. Choose prompt engineering, with the structure and an example.
4. Keep fine-tuning in reserve if prompting does not hold.

Exam tip: Fix format and tone in the prompt first; escalate only if that falls short.

Bias and fairness problems arise because foundation models learn from human-generated data that can encode historical and societal bias, then reflect those patterns in their outputs.

A consistent penalty tied to background, with qualifications held equal, is a systematic skew, which is the definition of bias. Google-recommended responses include fairness evaluation, more representative data, and human review of consequential decisions such as hiring.

1. Note that the error is consistent and tied to group membership.
2. Recognise a systematic skew as bias, not scattered errors (hallucination) or rare inputs (edge cases).
3. Trace bias to the training data the model learned from.

Exam tip: A consistent skew against a group is bias inherited from training data, and it needs fairness checks and human oversight.

Versioning tracks which model version, prompt version and dataset version are in production, so changes are deliberate, testable and reversible.

Both symptoms, not knowing which model produced the good outputs and having no way back, are what versioning prevents. Automatic upgrades are a recommended lifecycle practice, but each upgrade should be validated against KPIs, and a pinned, recorded version makes rollback simple. Drift monitoring and a feature store address different problems.

1. Identify the trigger: a model change that degraded output.
2. Identify the two gaps: no record and no rollback.
3. Match both gaps to versioning.
4. Note that upgrades should be validated before production relies on them.

Exam tip: Pin and record model versions so every change can be tested and rolled back.

Impact is measured with KPIs tied to business outcomes, compared against a baseline recorded before launch; activity and system metrics are not impact.

The question is whether the business is better off, so the measure must track outcomes the business cares about and compare them with how things were before. Resolution time and customer satisfaction against a baseline do that. Prompt counts and one-time sign-ins are activity measures that can look healthy while outcomes stay flat, and latency and uptime measure the system, not the business.

1. Restate the question: is the business better off?
2. Prefer outcome KPIs over activity or system metrics.
3. Require a baseline so the change can be shown.
4. Reject prompt counts, sign-ins and uptime as non-impact measures.

Exam tip: Impact = business-outcome KPIs compared with a pre-launch baseline, not usage volume.

ROI compares the value an initiative delivers with its total cost, including model and platform usage, integration, training, and ongoing governance and monitoring.

ROI is a value-versus-cost ratio. The value side includes quantifiable gains such as hours saved and revenue influenced; the cost side includes everything spent to deliver them, from platform usage to integration, training and governance. Hours saved versus training hours is a narrow slice of that calculation, pilot-versus-rollout compares performance, and spend-versus-budget is cost control without any value.

1. Recall that ROI is value relative to cost.
2. Include all value and all costs, not one line item each.
3. Reject comparisons of performance between groups or of spend against budget.

Exam tip: ROI = total value delivered versus total cost, including training and governance.

Gen AI KPIs fall into groups: efficiency (time and cost), quality (accuracy, satisfaction), adoption (who uses it and how often) and business outcomes (revenue, retention).

The figure counts how many of the intended users actually used the assistant, which is adoption. A balanced plan tracks adoption because a capable solution nobody uses delivers no value, and low adoption is often the first sign that training or change management is missing. The other groups measure savings, output quality and strategic results.

1. Ask what the figure counts: people using the tool.
2. Map share of intended users to adoption metrics.
3. Rule out groups that measure savings, output quality or strategic outcomes.

Exam tip: Who uses the tool and how often are adoption metrics; low adoption caps every other benefit.

Choose the simplest build depth that meets the requirement: a ready-to-use solution where possible, a foundation model grounded in company data when answers must reflect current internal knowledge, and tuning only when the need justifies it.

Two facts combine. First, grounding retrieves from the documents at answer time, so monthly revisions flow straight into the answers, while tuning fixes knowledge into the model at training time and goes stale. Second, extra build depth is only worth it when the simpler approach falls short: grounding already meets the requirement, so adding tuning on top costs effort, examples and skills the insurer does not have. The general assistant fails the requirement because it never sees the policies.

1. Requirement: answers from current, monthly-revised policy documents.
2. Constraints: three months, small team, no ML specialists.
3. Drop the general assistant: it cannot see the policies.
4. Drop tuning alone: it goes stale and needs skills the insurer lacks.
5. Drop grounding plus tuning: the extra depth adds cost without meeting an unmet need.

Exam tip: Grounding keeps answers current; add tuning only when grounding alone falls short.