Part 6 Full Quiz

B is correct. TAGS returns category labels for the whole image without location information — exactly requirement (1). OBJECTS returns specific detected items with bounding box coordinates (x, y, width, height as fractions) — requirement (2). CAPTION returns a single natural-language descriptive sentence — requirement (3). DENSE_CAPTIONS (option C) generates multiple captions for different regions — not what was asked. READ extracts text (OCR) — not needed. PEOPLE detects human figures — not the same as general object detection. All three correct features can be requested in one analyze() call, which is more efficient than making separate requests.

C is correct. The READ visual feature is the OCR capability of Image Analysis 4.0. It extracts text from both printed and handwritten sources and returns a hierarchical structure: Pages → Lines → Words. Each Word object has: the recognised text, a confidence score, and a bounding polygon (list of vertex coordinates — not just a rectangle, but the actual polygon boundary of the word in the image). This enables precise layout reconstruction. TAGS (A) returns content category labels, not text content. CAPTION (B) writes a description sentence about the image, not the actual text within it. OBJECTS (D) detects things like "car" or "bottle" — not text content.

B is correct. Microsoft's Responsible AI policy distinguishes between detection and identification. Face detection (finding that faces exist, counting them, getting their location and basic attributes like estimated age) is available without approval — it's low privacy risk. Face identification (matching a detected face to a specific known person) creates biometric recognition capabilities and carries significant privacy implications, so it requires Microsoft Limited Access approval before use. This distinction appears frequently in the exam — the key question is always whether you need to know WHO the face belongs to (identification → approval needed) or just that faces exist (detection → no approval).

C is correct. Image Analysis bounding boxes use normalised coordinates (0.0–1.0 as fractions of the image). x=0.15 and y=0.30 are the top-left corner as fractions. width=0.40 and height=0.25 are the box dimensions as fractions. To convert: top-left pixel = (x × img_width, y × img_height) = (0.15 × 1200, 0.30 × 800) = (180, 240). Bottom-right pixel = ((x + width) × img_width, (y + height) × img_height) = (0.55 × 1200, 0.55 × 800) = (660, 440). Option B makes the mistake of using x and width directly without adding them together for bottom-right, and doesn't multiply by image dimensions correctly.

C is correct. Smart Cropping is designed exactly for this use case — automatic crop suggestion at multiple aspect ratios. You request SMART_CROPS as a visual feature and specify the desired aspect ratios. The service uses saliency detection to identify the most visually interesting and important part of the image and returns crop rectangle suggestions that preserve that area at each ratio. DENSE_CAPTIONS (A) describes regions in text, not crop coordinates. Background Removal (B) is useful for subject isolation but doesn't handle aspect-ratio cropping. OBJECTS (D) finds item boundaries — not the same as finding the best compositional crop for the image.

C is correct. The key requirement is "each photo can include multiple categories simultaneously" — this is the definition of multi-label classification. Multi-label classification assigns multiple tags to a single image where categories are NOT mutually exclusive. Multi-class classification (A/D) assigns exactly ONE tag per image — categories are mutually exclusive. It cannot assign "Fast Food" AND "Beverage" to the same image. Object Detection (B) would find where each item is in the image with bounding boxes — overkill for this use case, which only needs whole-image category labels, not locations. No location information is needed for the search filter requirement.

C is correct. The problem is 71% Recall — 29% of real defects are being missed. In a safety/quality critical scenario, missing true positives (false negatives) is the primary concern. Lowering the probability threshold makes the model report detections at lower confidence levels — it will now flag more potential defects, including real ones it was previously too uncertain to report. This increases Recall at the cost of more false positives (boards flagged as defective that are actually fine) — acceptable because those can be manually reviewed. Raising the threshold (A) does the opposite — it becomes even more conservative, missing even more defects. Switching to classification (B) is the wrong tool — you lose the location information. Reducing training data (D) would make everything worse.

B is correct. Custom Vision has TWO completely separate key pairs and endpoints: (1) Training endpoint + Training Key → authenticates the CustomVisionTrainingClient for all project management operations: creating tags, uploading images, training models, evaluating metrics, publishing iterations. (2) Prediction endpoint + Prediction Key → authenticates the CustomVisionPredictionClient for making predictions against published models. Using the Prediction Key with the Training Client will fail authentication — they are separate credentials, not interchangeable. This separation is intentional: production apps only need prediction access, not the ability to modify the training project.

C is correct. Custom Vision bounding boxes use normalised coordinates (0.0–1.0). Top-left pixel: (left × img_width, top × img_height) = (0.10 × 640, 0.20 × 480) = (64, 96). Bottom-right pixel: ((left + width) × img_width, (top + height) × img_height) = (0.40 × 640, 0.35 × 480) = (256, 168). Option B has the bottom-right calculation wrong — it uses raw width/height values instead of adding them to the position first. Option A and D are wrong because these are normalised fractions — they MUST be multiplied by the image dimensions to get pixel coordinates before drawing on an image.

C is correct. mAP (Mean Average Precision) is NOT the arithmetic mean of Precision and Recall. The reported Precision (88%) and Recall (82%) are evaluated at a single probability threshold (typically 50%). mAP is a much more comprehensive metric: it calculates Average Precision (AP) by computing the area under the precision-recall curve across ALL probability thresholds, then averages that across ALL object classes. Additionally, for object detection, correct detections require the predicted bounding box to sufficiently overlap the ground truth box (measured by IoU — Intersection over Union, typically IoU ≥ 0.5). This bounding box accuracy requirement means mAP can be significantly lower than the point-in-time Precision and Recall. mAP is specifically the standard for object detection (not AUC, which is for classification ROC curves).

C is correct. Three requirements force the ARM-Connected account: (1) Data residency — the firm's content must stay in their own Azure subscription and EU West region. Trial accounts store data under Microsoft's control, not in the customer's subscription. (2) Scale — 500 hours far exceeds the Trial limit (40 hours via API). (3) Custom person model — identifying specific expert witnesses by face requires training a custom person model, which is only available on ARM-Connected accounts (and also requires Limited Access approval for face identification). Trial accounts (A/B) have none of these capabilities. All three requirements independently make Trial unsuitable.

C is correct. Scenario (a) is pure NLP — the transcript text mentions "Bill Gates" as a string, and Named Entity Recognition (NER) identifies it as a person entity from the text, exactly like Azure AI Language's entity recognition. No biometric processing involved, no Limited Access required. Scenario (b) involves face identification — visually matching a face in video frames to a specific known person. This is biometric recognition and requires Microsoft Limited Access approval. This distinction is important: what someone SAYS about a person vs recognising a person's FACE are entirely different processes with different privacy implications and different access requirements.

B is correct. (A) The food court is a zone and the requirement is to count people within that zone — personcountingzone is designed for counting within a defined polygon area with configurable threshold alerts. personcount counts the whole camera frame, not a specific zone. (B) The entrance requires directional counting — people going IN vs people going OUT — personcrossingline tracks crossing events with direction (A→B or B→A), enabling separate entry vs exit counts. personcrossingpolygon tracks zone entry/exit but is better for dwell-time analysis. (C) Measuring the physical gap between people is exactly what persondistance does — it measures real-world distance in metres (requires camera calibration) and fires events when distance drops below the threshold.

C is correct. The correct workflow is: (1) Use the Management API key to request a video-level access token from the Auth endpoint: GET /Auth/{location}/Accounts/{accountId}/Videos/{videoId}/AccessToken?allowEdit=false. The video-level token is scoped to one specific video — even if it's exposed in a web page, it cannot access other videos or perform account-level management. (2) Call GET /Videos/{videoId}/InsightsWidget?accessToken={videoToken} to get the embeddable iframe URL. (3) Embed the returned URL as an iframe. Using the Management API key directly in a public web page (A) would expose full account management access — a serious security risk. An account-level token (B) provides access to all videos, which violates the "scoped to one video" requirement.

C is correct. (1) Azure AI Vision READ / OCR — extracts printed text from scanned forms. No Limited Access needed (just general text, no biometrics). (2) Face API identification — detecting whether specific known personnel appear in CCTV images requires face identification (matching faces to known persons), which requires Limited Access. Face detection alone (bounding boxes, count) would not need approval. (3) Spatial Analysis — real-time counting from live CCTV feeds via personcountingzone (capacity alert at 50) and personcrossingline (hourly directional count). The entire Spatial Analysis service requires Limited Access. (4) Custom Vision object detection — trains a custom model to locate objects with bounding boxes in X-ray images. No Limited Access required for custom vision models. Options A misses both Limited Access requirements. Option D misidentifies (3) as Custom Vision (wrong — real-time camera analysis is Spatial Analysis) and (2) as Video Indexer (wrong — single images, not video files).