The smallest section of the exam and the one closest to the day job. It asks how an organisation gets from an interest in generative AI to something that changed a number.
The types of solution
Four, and a question will describe a situation that points at one.
Text generation covers drafting, summarising, rewriting, translating, answering and extracting. The broadest category and the one most business problems fall into.
Image generation covers producing and editing visuals, for marketing, product imagery and design exploration.
Code generation covers writing, explaining, translating and testing code, which raises engineering throughput rather than customer facing value.
Personalised user experience covers tailoring what somebody sees to what is known about them, in recommendations, content and interfaces.
What decides the choice
Business requirements first. What outcome are you trying to move, who is affected, what does a wrong answer cost, and what would count as success.
Technical constraints second. Where the data is and whether you may use it, where processing may happen, what latency the experience allows, what it may cost per interaction, and what has to be integrated with.
The cost of a wrong answer is the constraint people underweight. It decides whether a person has to be in the path, and that decision changes the economics of the whole thing far more than the choice of model.
Getting it into an organisation
The sequence Google recommends is unremarkable and mostly ignored.
Start from a business problem rather than the technology. Pick a use case where the outcome is measurable and a wrong answer is survivable. Check the data exists, that you may use it, and that you can reach it. Build the smallest version that answers the question. Measure it against what happened before. Then decide whether to widen, and only then worry about the platform it should sit on permanently.
Two things sit alongside that sequence throughout. Somebody has to own it, and people have to be trained, because a capable system that nobody trusts or knows how to use changes nothing.
Measuring impact
The exam asks for techniques, and the useful ones are ordinary.
Against a baseline. Measure the thing before, then after. Handling time, conversion, time to draft, tickets resolved without escalation.
Against a control group. Some teams get it and some do not, which separates the effect of the tool from everything else changing at once.
Quality alongside volume. Faster output that is worse is not an improvement, so pair a throughput measure with a quality one.
Cost per interaction. Token cost, review time and the engineering to keep it running. A system that helps and costs more than it saves is a decision, not a success.
Adoption as a diagnostic, not a result. Usage tells you whether people came. It does not tell you whether anything changed.
The honest final question is the counterfactual. Not whether the output is impressive, but whether it beats what people were doing before at a cost the result justifies.