An image can be the input, the evidence, or the output
Microsoft’s AI-901 objectives distinguish interpreting visual input, creating visual outputs with generative models, and building a lightweight application with vision capabilities. These are related but not interchangeable tasks. A quality-control application might inspect a photograph and describe a visible defect; a warehouse system might identify whether a package label is readable; a design assistant might produce a new illustration from text. All three work with images, but they require different model capabilities, evaluation methods and safety checks.
Start with the direction of information flow. Image understanding consumes a picture and produces information about it, often in text or labels. Image generation consumes instructions or reference input and produces new image data. Conventional computer-vision operations may classify a scene, locate objects or extract visible text. A multimodal model can sometimes answer questions about an image in conversational language, but a fluent description is not a precise measurement or proof that a small detail was interpreted correctly.
The current Microsoft Azure AI Fundamentals exam expects a candidate to know which task is being requested and how a basic application interacts with a suitable service. If a scenario asks for the number on an invoice in a blurred photo, visual reasoning alone may be less appropriate than a structured extraction and verification workflow. If it asks for an original product concept image, OCR and object detection are not the target. These distinctions should guide model selection before anyone opens the portal.
Computer vision includes several ways of understanding a scene
Image classification identifies which category best describes an image or region. Object detection locates possible objects and may return regions or bounding information. Optical character recognition converts visible text into machine-readable form. Multimodal reasoning can combine image input with a language instruction and respond in text. Each capability answers a different kind of question. A label saying “delivery truck” is not a reliable count of every package inside it. A detected text string is not proof that the surrounding document has been understood correctly.
Consider a fictional shelf photograph showing three colored boxes, two handwritten labels, and a price sign partly obscured by glare. A classification task might identify the shelf as a store display. Detection might find boxes and sign regions. OCR might read some letters. A multimodal model might describe the scene, but could miscount items or infer prices that cannot be seen. The system must not convert a plausible description into an authoritative inventory update without checks against the original image or another record.
A practical evaluator asks what exact evidence the user requires. For a safety inspection, missing a critical warning sign may have high cost; visual false negatives demand targeted review. For a photo-library tagging feature, an occasional wrong category may be correctable through user feedback. Different consequences imply different acceptance conditions. AI-901 learners should be able to name the operation, expected output and failure mode, not merely say that Azure supports “computer vision.”
Using a multimodal model to interpret visual input
A vision-enabled chat model can accept an image together with a textual question, subject to the deployed model and service’s supported input format. The prompt might ask: “Describe the visible objects in this fictional product photo and say which details cannot be determined from the image.” The returned text should be judged against the actual pixels. Microsoft documents vision-enabled chat models and their prerequisites, including the need for a supported deployment. A text-only model should never be assumed to accept image data just because it can discuss photographs in words.
Input handling is part of the application design. The client must provide the image through the supported media representation, authenticate to the intended service and pass the question in the appropriate request structure. Some interfaces accept image URLs, encoded image data or other documented formats; restrictions, sizes and capability limits vary. The safe lesson is to read the exact interface documentation for the selected model and API version, not to invent a universal endpoint or paste a large, arbitrary binary string into a text-only request.
Good test prompts distinguish observation from inference. Ask “What text is legible on this sign?” separately from “What business is this?” Ask for an explicit indication when a detail is unclear rather than demanding a confident answer. Try an occluded object, a low-resolution scan and an ambiguous scene using non-sensitive examples. An answer that invents an unseen serial number has failed the task even if the rest of its description sounds coherent.
Image generation solves a different creative problem
A generative image model creates visual content from a description or a supported reference and edit request. A prompt for a training illustration could specify its subject, composition, lighting, audience and required exclusions. The output must be reviewed for whether it follows the brief, whether important elements are missing and whether the image could mislead viewers. The application should distinguish an illustration from a documentary photograph, especially in educational, journalistic or operational contexts.
The job of an image-generation model is not to certify the accuracy of an existing photo or extract mandatory fields from a form. It may produce convincing-looking text, devices or diagrams that are not faithful to a real system. A generated image of a machine cannot be used as proof that the machine has a certain safety label. Similarly, requesting an invoice image with a numeric total does not guarantee that the visual digits represent a correct calculation. If the product needs exact text, the application should produce and validate that text separately before rendering it into a design.
Foundry’s model catalog includes different model families and deployment conditions. Some image-generation options or versions may be preview-only, licensed differently or region-limited. Microsoft’s guidance on image-model deployments labels specific model versions and preview status. Avoid turning an example screenshot into a blanket promise that a preview model is generally available everywhere. AI-901 requires understanding the capability and flow, not promoting an unverified specific model as the one required for every user.
Build a small image-aware client around one question
A beginner application can accept a fictional equipment photograph and a clear question such as “What visible indicators suggest the device is powered on?” Its responsibilities are to validate the file, enforce permitted input size and type, authenticate, call an image-capable deployment with both image and text, and present the answer for human verification. The model should be asked to identify observable evidence and to acknowledge uncertainty. The application should not silently change device state, submit a maintenance ticket or classify a dangerous condition as safe without a separately authorized procedure.
Test three photos rather than endlessly tweaking one prompt: a clearly visible indicator, an indicator obscured by reflection, and a device photographed from the wrong side. For each, compare the response with what a human can truly see. When evidence is absent, a request for another photograph may be more valuable than a low-confidence guess. This also reveals why camera framing and input quality are functional requirements, not mere design details.
A second lightweight exercise could take a fictional text brief for a workshop poster and request a generated concept image. Check whether the result follows the core visual requirements while accepting that visual generation is stochastic. A caption or legal notice should be composed and validated as text rather than trusted to appear as perfect lettering inside the generated image. These two exercises expose the input/output distinction without claiming a production-grade design or vision system was deployed.
Responsible vision requires data and evidence controls
Photos can contain faces, identity documents, household addresses, customer information and sensitive surroundings. An app should collect only images necessary for its purpose, limit access and retention, and inform users about processing. Facial recognition and identification raise additional policy and regulatory concerns beyond ordinary scene understanding. A beginner vision tutorial should not imply that any model’s ability to describe a face establishes permission to identify a real person.
Accuracy concerns also depend on who and what appears in the dataset. A model tested only on well-lit photographs may perform poorly on dark scenes, unusual camera angles or equipment from a different supplier. A safety-oriented application needs representative tests and a controlled response when confidence is insufficient. Inclusive design considers users who cannot easily capture high-quality photos or who need text alternatives to image-only feedback. Transparency means explaining that AI is interpreting the image, not claiming that an instrument measured something it did not.
Generated artwork has its own risks. Users should know when an image is synthetic, and the application should not imply that a generated depiction documents a real event. Copyright, representation and false-context risks need review against the actual intended use. For multimodal applications, technical issues such as latency, usage costs, image sizes and model availability are meaningful design factors, but they must be verified for the specific selected service rather than generalized from another deployment.
Use an output contract to decide which visual service belongs
Take three final scenarios. A retailer needs to read package tracking numbers: first consider OCR or structured extraction with validation. An inspector needs a readable description of visible corrosion: consider image understanding, with human confirmation for safety decisions. A marketer needs a new conceptual illustration: consider an image-generation model and review the visual result against the creative brief. For each case, identify what goes in, what should come out, what might go wrong, and how to tell whether the output met the task.
Now imagine the retailer wants a summary of a video showing packages moving along a conveyor. That adds a temporal dimension and may require specialized multimodal analysis or extraction; a single still-image classification is not enough. The more advanced multimodal AI-103 scenarios go deeper into such systems. At the fundamentals level, recognize when an image, sequence, text document or audio recording has changed the required model capability.
A useful AI-901 outcome is the ability to justify why a selected service is appropriate instead of referring vaguely to “an AI image API.” Describe the input, the expected output, the model capability, the client’s responsibility and the failure test. That method applies whether the application is reading a blurry sign, generating a poster or answering a question about a photograph.