Natural Language Processing

Assuming you can tell that a scenario involves human language at all, this domain leaves you able to run a single, repeatable two-step decision on any NLP question: name the capability, then map it to the Azure service. Every question in it is some variation of that decision. Step one is conceptual: read the stated goal and classify it as one of a small set of NLP capabilities: text analysis (key phrase extraction, named entity recognition, sentiment analysis, language detection), translation, speech (speech-to-text or text-to-speech), or conversational AI (language understanding plus question answering). Step two is the service-selection drill: each capability maps to exactly one of four Azure services: Azure AI Language for understanding written text, Azure AI Speech for any audio input or output, Azure AI Translator for text-to-text translation between languages, and Azure AI Bot Service for hosting a conversational interface. The two subtopics in this domain are precisely these two passes: 'NLP Scenarios' teaches the capability vocabulary, and 'Azure NLP Services' teaches the service mapping. Keeping the passes separate is the single most reliable way to answer a question correctly, because a stem that names a capability you recognize ('extract the key talking points', 'detect the language', 'transcribe a call') immediately narrows to one service.

Once you know the capability, the cleanest mechanical rule for picking the service is to ask what is going in and what is coming out. If audio is the input or the output (spoken to written, written to spoken, or speech-to-speech) the service is Azure AI Speech. If the operation is text-in and text-out across languages, it is Azure AI Translator. If the operation extracts meaning, structure, or labels from written text (sentiment, entities, key phrases, the language a document is written in, intent, an FAQ answer), it is Azure AI Language. The fourth service, Azure AI Bot Service, sits at a different layer entirely: it is the framework that hosts a chatbot and connects it to channels such as Microsoft Teams or web chat, and it delegates the actual understanding back to Azure AI Language. This modality axis is why the same word, 'detection', splits across services: detecting the language of a block of text is Azure AI Language (language detection), while detecting the language being spoken in an audio clip is Azure AI Speech (language identification). Anchoring on input/output modality resolves the majority of service-selection questions without memorizing a feature list.

The most consistently tested confusion in this domain is where translation lives, and the trap exploits the natural assumption that anything called 'translation' belongs to the Translator service. It does not. Azure AI Translator is strictly text-to-text: its input and output are always written text, covering real-time text translation, document translation that preserves formatting, and Custom Translator for domain terminology. The moment either side of a translation is audio (a stem that mentions spoken input, a voice, a call, or real-time spoken conversation) the capability is speech translation, which is a feature of Azure AI Speech, not Translator. This is the same modality rule from the previous principle applied to its hardest case, and it is worth isolating because the wrong answer (Translator) is always present as a distractor. The reliable tell: scan the stem for any audio cue before choosing a translation service. If you find one, the answer is Azure AI Speech; if both sides are text, the answer is Azure AI Translator. The composite nature of speech translation (it chains speech recognition with translation) is exactly why Microsoft houses it in the audio service.

Not every NLP scenario maps to a single service in a single step; the domain also tests whether you recognize that a realistic application orchestrates several capabilities. Conversational AI (chatbots, virtual agents, voice assistants) is the headline composite: Azure AI Bot Service provides the hosting and channel layer, while the understanding underneath comes from Azure AI Language through conversational language understanding (CLU), which predicts a user's intent and extracts entities, and question answering, which returns a stored answer from a curated knowledge base of question/answer pairs. A voice assistant extends this further by adding Azure AI Speech on both ends: speech-to-text to hear the user and text-to-speech to reply aloud. The same chaining appears in analytics workflows: to get sentiment or entities out of a recorded call, you transcribe the audio with Azure AI Speech first, then analyze the resulting transcript with Azure AI Language, because Speech itself does not perform sentiment or entity analysis. The exam signal for a composite is an end-to-end, interactive, or multi-format scenario; the correct approach is to decompose it into its capability steps and assign each step its own service rather than searching for one service that does everything.