Computer Vision

Assuming you can already tell that a scenario is about interpreting images, this domain leaves you able to make two stacked decisions for any vision item (which vision task it is, then which Azure service runs that task) the two subtopics mapping onto them exactly. The first decision is conceptual and vendor-neutral: which of the recognized vision solution types does the scenario describe, image classification, object detection, optical character recognition (OCR), or facial detection and analysis? The second decision is about Azure resources: given that task, which managed service implements it, Azure AI Vision, Azure AI Document Intelligence, Azure AI Custom Vision, or Azure AI Face? Getting the first decision right narrows the second, but the mapping is not one-to-one (for example, OCR-the-concept is served by Azure AI Vision for loose text and by Azure AI Document Intelligence for structured fields). The falsifiable test is that any correct answer must satisfy both layers: a response that names the right task but the wrong service, or the right service for the wrong task, is wrong. Treat the solution-type subtopic as the 'what' and the Azure-services subtopic as the 'with what'. [1][2]

Across both subtopics the single most reliable discriminator is the output the scenario asks for, because the input is identical for every vision type: a picture. A single category for the whole picture is image classification; a label plus a bounding box for each item (so you can also count) is object detection; the recognized characters themselves are OCR; the location of a face (and optionally described attributes) is facial detection and analysis. This output-first rule is what makes the concept layer testable, and it carries straight into service selection: 'objects, tags, and a caption out of the box' implies Azure AI Vision Image Analysis; 'key-value pairs and tables from an invoice' implies Document Intelligence; 'a model that predicts my own labels' implies Custom Vision; 'who is this person / verify identity' implies Azure AI Face. The decisive corollary is that classification can never tell you where or how many objects there are, and detection's coarse box can never trace an object pixel-for-pixel: only semantic segmentation (a per-pixel mask, covered in the solution-types subtopic) does that. If two options differ only in granularity of output, pick the one whose output matches the stem's verb ('classify', 'locate and count', 'read', 'find faces'). [1][2]

Once the task type is fixed, the dominant service-selection rule is whether the scenario provides your own labeled examples. If it does not, the answer is almost always a prebuilt, pretrained Microsoft service that you simply call: Azure AI Vision for general image analysis and loose-text OCR, Document Intelligence's prebuilt invoice/receipt/ID models for structured documents, or Azure AI Face for faces, with no training on your part. If the scenario hands you labeled images of domain-specific subjects ('train on roughly 50 images per label of our products'), the answer is Azure AI Custom Vision (or a custom Document Intelligence model for bespoke forms). This single distinction resolves the most common distractor traps: Custom Vision is wrong whenever pretrained categories already suffice, and it is also wrong against Document Intelligence when the input is a form needing named fields rather than a whole-image label. The rule is falsifiable: presence of caller-supplied labeled training data is the signal for a custom service; its absence is the signal for a prebuilt one. [2][3][5]

The face workflow straddles both subtopics in a way the exam likes to test. As a solution type, facial detection locates faces and facial analysis describes attributes, and crucially neither identifies who the person is: that is facial recognition, a separate capability. As a service decision, Azure AI Vision can notice that a face is present during broad image analysis, but recognition, verification, and identification belong specifically to Azure AI Face. Some of Face's recognition and identity features sit behind Microsoft's Limited Access responsible-AI controls, and that gating is itself an exam signal that identity-oriented face work is a sensitive workload requiring the dedicated service. So a stem about merely detecting or blurring faces can be satisfied by general image analysis, while any stem about confirming an identity or matching to a known person must route to Azure AI Face. The falsifiable boundary: 'is a face here / what does it look like' may stay in Vision; 'who is this / are these the same person' must be Face. [2][4]