Azure AI Language — match the feature to the task

This is a matching exercise more than a conceptual one. A scenario describes a job in ordinary language, and you name the feature. The verb in the question is usually the giveaway.

Reading the verb, naming the feature

What the requirement asks for	The feature
Which language is this text in?	Language detection
Find people, places, organisations, dates	Named entity recognition
Strip or mask sensitive data	Personal information detection and redaction — a separate operation, returning redacted_text
Positive or negative, plus per-attribute opinions	Sentiment analysis with opinion mining
What are the main topics?	Key phrase extraction
Condense it	Summarization
Disambiguate against Wikipedia	Entity linking
Clinical text	Text Analytics for Health

Two of these deserve a second look.

Redaction is a separate operation. It is not a flag on entity recognition. It returns redacted_text as its own result.

Entity linking is not the same as entity recognition. Recognition finds that a string is an organisation. Linking resolves which organisation, against a knowledge base. If the scenario mentions disambiguation — two things with the same name — it is linking.

Extractive against abstractive summarisation

A standing two-option trap, and the distinction is clean:

• Extractive picks existing sentences out of the source.
• Abstractive generates new sentences.

If a requirement says the summary must use only the author's own words, or must be traceable to the source, that is extractive. If it wants something readable and condensed in fresh phrasing, that is abstractive.

Which features need training

Prebuilt features need no training at all — everything in the table above works out of the box.

These do need training: custom named entity recognition, custom text classification, conversational language understanding, and custom question answering. The pattern is simple enough to remember — anything with "custom" in the name, plus the two conversational features.

The Language service or a model

This is the judgement the exam is really testing, and it matters commercially too.

Choose Azure AI Language for lower cost at volume, deterministic and repeatable output, lower latency, and broader language coverage.

Choose a language model for open-ended or novel extraction — the cases where you cannot specify in advance what you are looking for.

In code

• The client is TextAnalyticsClient.
• It is built from an endpoint plus a credential.
• Both DefaultAzureCredential and an API key are accepted here — unlike the project endpoint from card 8, which takes identity only.
• Foundry projects expose Language tools automatically. There is no model deployment step.

The trap

The phrase to listen for is deterministic, repeatable, high volume, low cost. That combination points at Azure AI Language, not at a model — even when the task itself sounds like something a model could obviously do.

It is the same reasoning that sits behind the Defence-AI Radar decision: when you need the same input to produce the same output every time, and you need it cheaply at scale, a language model is the wrong instrument however capable it is.