Computer Vision practice questions

You must have at least 5 tags defined in the project.

Why it fails: Object detection training requires a minimum of 15 images per tag, and 50 images spread across several tags can leave individual tags below that threshold. It is tempting because tag counts do matter in classification projects, but the failing constraint here is per-tag image quantity, not the number of tags.

You must use multi-class classification instead of object detection for manufacturing defects.

Why it fails: Object detection is the correct project type for locating defects within an image; multi-class classification only assigns one label per image and cannot return bounding boxes. It is tempting because classification suits whole-image defect sorting, but the stem's requirement to identify defect locations rules it out.

Training images must be smaller than 256x256 pixels.

Why it fails: Custom Vision accepts images far larger than 256x256; the actual training failure stems from too few tagged images per label (50 total across defect classes) or missing regions, since object detection needs roughly 15+ examples per tag. The 256x256 figure is tempting because it resembles the small-image requirement for some other vision models, but it is not a Custom Vision constraint.

features=safety

Why it fails: Azure AI Vision exposes adult, racy and gore classification through the adult visual feature, not a safety feature name. It is tempting because 'safety' sounds like content moderation, but that naming belongs to Azure AI Content Safety, a separate service.

features=moderation

Why it fails: The moderation feature name does not exist in the Image Analysis feature list; adult content detection is requested via the adult feature. It is tempting because 'moderation' describes the pipeline's purpose, but Azure AI Content Safety is the separate service providing that capability.

features=image-analysis safety check

Why it fails: Azure AI Vision's image-analysis feature returns captions, tags and objects; it has no adult, racy or gore classifier, so it cannot flag that content. The dedicated Content Moderator or Azure AI Content Safety image API performs this detection, and would be the right choice when screening user uploads for explicit material.

ComputerVisionClient

Why it fails: ComputerVisionClient belongs to the older azure-cognitiveservices-vision-computervision package, which Microsoft has deprecated in favour of the ImageAnalysisClient in the azure-ai-vision-imageanalysis package. It is tempting because tutorials and legacy samples still reference it, and it would work for existing codebases pinned to that SDK version, but new scripts should instantiate ImageAnalysisClient.

VisionServiceClient

Why it fails: VisionServiceClient does not exist in the Azure AI Vision SDK; it is a fabricated class name. It is tempting because it sounds like a generic service client, and a similarly named class appears in some other Azure SDKs, but no such type is importable from azure-ai-vision-imageanalysis, so instantiation fails immediately.

CustomVisionPredictionClient

Why it fails: CustomVisionPredictionClient targets a trained Custom Vision project's prediction endpoint, not the general Azure AI Vision analysis service. It is tempting because it also analyses images and lives in an Azure AI package, and it would be correct when calling a published Custom Vision model, but it cannot perform dense captions or object detection on arbitrary images.

features=objects

Why it fails: The objects feature returns bounding boxes for detected objects and does not return person coordinates as required. It is tempting because it detects things in images, but it is intended for object detection scenarios such as locating products or vehicles, not people.

features=faces

Why it fails: The faces feature returns face bounding boxes and attributes, not the coordinates of detected people as whole figures. It is tempting because faces belong to people, but it is intended for face detection, identification, and verification scenarios rather than locating people in a scene.

features=tags

Why it fails: The tags feature returns content labels with confidence scores and no positional data, so it cannot supply coordinates. It is tempting because tagging describes image content, but it is intended for categorising scenes, such as identifying whether an image shows outdoors or food.

Switch from object detection to multiclass classification.

Why it fails: Changing problem types changes the output format entirely and does not fix low confidence for bounding boxes.

Decrease the image resolution setting in project properties.

Why it fails: Lowering resolution degrades detail and harms object detection performance.

Disable data augmentation.

Why it fails: Data augmentation generally helps generalization rather than hurting it.

Configure Custom Vision training iterations export.

Why it fails: Exporting Custom Vision training iterations captures model artefacts, not API request payloads or images, so no audit trail is produced. It is tempting because it is a genuine Custom Vision capability, and would be correct when you need to back up or migrate trained model iterations between projects.

Enable Azure Bastion session recording.

Why it fails: Azure Bastion session recording captures RDP and SSH sessions to virtual machines, not API request payloads, so it cannot log Vision API images. It is tempting because it provides auditable session evidence, and would be correct when you need to record administrative VM access for compliance.

Configure Azure Traffic Manager with logging rules.

Why it fails: Traffic Manager distributes and logs DNS-level routing decisions, not HTTP request bodies or images sent to Azure AI Vision. It is tempting because it offers logging and sits in front of services, and would be correct for routing traffic across regional endpoints by priority or performance.

dimensions

Why it fails: Azure AI Vision 4.0 returns width and height inside the metadata object, not a top-level dimensions property, so reading dimensions yields nothing. The name is tempting because it describes the concept, but the actual fields are metadata.width and metadata.height.

modelVersion

Why it fails: modelVersion identifies which model revision produced the analysis, supporting reproducibility and auditing. It is tempting because version metadata feels central to a response, yet it holds no spatial data; width and height live under the metadata object instead.

requestId

Why it fails: requestId is a correlation identifier for tracing a call through logs and support tickets. It is tempting because it appears in every response and looks authoritative, but it carries no image geometry; the width and height values sit in the metadata object.

/status

Why it fails: /status returns the container's model and API version metadata, not a liveness signal. The health endpoint is /health, which reports readiness for traffic. /status tempts because it confirms the service responds, and would be correct for verifying which model version a running container hosts.

/ping

Why it fails: Custom Vision containers expose /ping specifically as the liveness probe, returning a simple status payload; /health is not a documented endpoint on that image, so a load balancer pinging it would receive 404 and mark the container unhealthy. It is tempting because /health is the conventional Kubernetes probe path for many other container images.

/health

Why it fails: The Custom Vision container image does not expose /health; its documented liveness endpoint is /ping, so pinging /health returns 404 and the load balancer would treat a running container as unhealthy. It is tempting because /health is the standard probe path for many other container images and frameworks.

Authorization: Bearer

Why it fails: Custom Vision prediction keys are passed in the Prediction-Key header, not as a bearer token, so the endpoint rejects this request. It tempts because Authorization: Bearer is the standard scheme for OAuth 2.0 tokens; it would be correct when authenticating with a Microsoft Entra ID access token instead of an API key.

X-Auth-Token

Why it fails: X-Auth-Token is not a recognised Custom Vision header, so the prediction endpoint returns 401. It tempts because similar custom token headers appear in other APIs; it would be correct only where that specific service documents it, not for Custom Vision key authentication.

Vision-Api-Key

Why it fails: The required header is Prediction-Key; Vision-Api-Key is not read by the Custom Vision endpoint, so authentication fails. It tempts because the name mirrors the API-key concept and resembles headers used by other Azure AI services; it would be correct only for services that document that exact header name.

dominantColors

Why it fails: dominantColors belongs to the Image Analysis visual-features response, not the Read OCR result, so it contains no text lines or confidence scores. It tempts because it is a genuine Azure AI Vision response property; it would be correct when extracting colour information from an image.

adultScore

Why it fails: adultScore is an Image Analysis content-moderation property, absent from Read OCR results, so it yields no text lines or confidence values. It tempts because it appears in Azure AI Vision responses; it would be correct when filtering images for adult content rather than reading text.

smartCrops

Why it fails: smartCrops is an Image Analysis thumbnail-generation property, so it holds no recognised text or confidence data. It tempts because it is a real Azure AI Vision response field; it would be correct when producing cropped thumbnails around salient image regions.

Expect synchronous JSON responses containing all extracted text directly on the initial POST call.

Why it fails: Read is asynchronous and returns 202 Accepted, not immediate synchronous text payloads on the initial POST.

Configure the API to store extracted text permanently in local memory without pagination.

Why it fails: The cloud service does not manage local client memory storage.

Use Azure Logic Apps with a synchronous batch loop.

Why it fails: Logic Apps batch loops still execute synchronously within a single workflow run, so the 500 high-resolution images would be processed serially and risk the same timeout. Logic Apps suits orchestrating connectors and approvals, not parallelising compute-bound image processing.

Trigger a single synchronous Azure Function that loops through all 500 images sequentially within a single HTTP request.

Why it fails: Sequential processing of 500 images in a single function invocation will exceed execution time limits (timeouts).

Configure an Azure Event Grid subscription to directly invoke Azure AI Vision REST endpoints without compute logic.

Why it fails: Event Grid delivers event notifications only; it cannot invoke Azure AI Vision REST endpoints or transform image payloads without a subscriber running compute. Event Grid is correct for reactive routing of events to handlers, not for executing the vision inference itself.

Dense Captions feature to describe the sign content in natural language.

Why it fails: Dense Captions generates descriptive sentences about image regions but does not extract the actual text or identify its language. It cannot provide the textual content of the sign or per-line language information. Therefore, it is not suitable for OCR tasks, especially for multilingual text extraction.

OCR feature with a custom model trained on English and French text.

Why it fails: Azure AI Vision Image Analysis 4.0 does not offer a separate OCR feature with custom model training for multiple languages. The Read feature is the OCR capability, and it does not support custom training. This option describes a non-existent feature, so it cannot be used to achieve the requirement.

Read feature with the language parameter set to a specific language code.

Why it fails: Setting the language parameter to a single language code forces the OCR engine to use that language model, which may misrecognize text in the other language. The Read feature supports automatic language detection, so specifying a single language is unnecessary and can reduce accuracy for multilingual content. This approach would not ensure correct language identification for each line.

Recreate the Image Analysis resource inside the same virtual network as the storage account and retry the original blob URL

Why it fails: Placing the AI resource in the same virtual network does not grant it permission to read a blob whose public access is disabled. The service still needs an authenticated URL or a private endpoint with proper DNS, so recreating the resource alone leaves the HTTP 400 error unresolved.

Enable public network access on the storage account and restrict access with the storage firewall to the Image Analysis service tag

Why it fails: Re-enabling public network access weakens the private-only posture the company requires and may violate their security policy. Although a service tag rule limits exposure, it changes the account's network configuration rather than solving the URL authentication problem, and the service tag may not cover all regional endpoints.

Download each blob to the application's local disk and submit the image bytes in the request body of the analyze call

Why it fails: This approach works technically because the application already has network access to storage, but it adds download code, temporary disk usage, and extra latency for every image. It requires substantially more development effort than appending a SAS token to the URL, so it does not meet the least-effort requirement.

Request the objects feature and alert when any object is detected in the frame

Why it fails: The objects feature detects common categories such as vehicles and signs, so alerting on any object would fire constantly on parked cars and signage. It also does not provide a dedicated person class with the same reliability as the people feature, making it unsuitable for this restricted-door scenario.

Request the tags feature and treat any tag containing person as an alert condition

Why it fails: Tags describe overall image content and do not localize people to the restricted door. A distant person near the door may not generate a person tag at all, and unrelated people elsewhere in the garage could trigger the tag, so this approach is unreliable for the stated monitoring goal.

Request the read feature and alert when any text is detected near the door

Why it fails: The read feature extracts characters from text in the image, such as signs or license plates. It provides no person detection whatsoever, so it cannot indicate whether someone is standing near the restricted door and would generate alerts only when readable text is present.

Switch to synchronous Read API endpoint.

Why it fails: A 202 means the Read operation was accepted asynchronously; you must poll the Operation-Location URL until it reports succeeded. Switching to the synchronous endpoint abandons that job and breaks the high-throughput batch model, though synchronous reads suit single, latency-tolerant images.

Parse the response body directly for the extracted text results.

Why it fails: The 202 body carries only the operation-location header, not results; text appears later at the polling endpoint once status is succeeded. Parsing it directly is tempting because successful synchronous calls return text in the body, but asynchronous submission returns no extracted content yet.

Immediately retry the POST request with an increased timeout value.

Why it fails: Retrying the POST resubmits the same image and creates duplicate operations rather than retrieving the pending result; you must poll the Operation-Location URL from the 202 headers. Retrying is tempting because it helps with transient 429 or 503 errors, not with a successfully accepted job.

Retail

Why it fails: Retail is a domain-specific model tuned for shopping imagery, and domain-specific projects cannot be exported to ONNX. Export requires a compact domain. Retail tempts because it targets a real vertical, and would be right for classifying retail product images in the cloud.

Food (compact) for edge deployment

Why it fails: Food (compact) is a compact domain, but its export formats are limited to CoreML, TensorFlow and ONNX for classification — however the question's required domain is General (compact), which supports ONNX export. Food compact tempts because it is a compact domain, and would suit food image classification on edge devices.

General

Why it fails: General (not compact) cannot be exported to ONNX; only compact domains support export. General tempts because it is the default, most flexible domain for broad classification, and would be correct for cloud-hosted models where export to edge hardware is not required.

POST /vision/v3.2/ocr

Why it fails: The v3.2 OCR endpoint belongs to the earlier Read/OCR generation and does not match the Azure AI Vision 4.0 asynchronous flow. It is tempting because it performs OCR and returns bounding boxes, so it would fit a legacy v3.2 integration, but the scenario specifies the 4.0 Image Analysis submit operation.

POST /vision/v2.1/recognizeText

Why it fails: The v2.1 recognizeText endpoint is a retired generation and does not initiate the Azure AI Vision 4.0 asynchronous OCR process. It is tempting because recognizeText returns bounding boxes asynchronously, which suits older applications, but the 4.0 Image Analysis submit endpoint is required here.

POST /customvision/v3.3/Prediction

Why it fails: The Custom Vision prediction endpoint classifies or detects objects in images using a trained custom model; it does not perform OCR or return text bounding boxes. It is tempting because it is an asynchronous-style vision POST, but it would be correct only for custom image classification or object detection.

features=read

Why it fails: features=read runs Optical Character Recognition, returning extracted text rather than natural-language descriptions, so no captions are produced. It tempts because OCR is a common Vision feature, and read would be correct when the goal is transcribing text from scanned documents or signage instead of describing image content.

features=smartCrops

Why it fails: features=smartCrops returns suggested crop rectangles and aspect-ratio coordinates, not descriptive text, so no caption is generated. It tempts because smartCrops is genuinely useful for automated image thumbnailing and resizing pipelines, but it yields bounding boxes rather than the natural-language description this scenario requires.

features=objects

Why it fails: features=objects returns detected object names with bounding-box coordinates, not a grammatical sentence describing the whole image. It tempts because object detection is a Vision capability, and it would be correct when the requirement is locating and labelling individual items within an image rather than producing captions.

features=denseCaptions

Why it fails: DenseCaptions returns multiple region-level captions with bounding boxes, not colour statistics. It is tempting because it extracts rich per-region descriptive text, which suits scenarios needing granular image description, such as generating accessible alt text or searchable metadata. However, the stem requires the Color feature, which reports dominant colours and the black-and-white flag.

features=people

Why it fails: The people feature returns bounding boxes for detected human figures, providing no colour information. It is correct for scenarios such as counting or locating people in an image, not for determining dominant colours or black-and-white classification.

features=tags

Why it fails: Tags return a list of content descriptors, not the colour analysis the stem requires. The colour feature returns dominant foreground/background colours and the black-and-white flag. Tags are tempting because they do describe image content broadly, and would suit scenarios needing searchable keywords rather than colour properties.