Free AI-102 Practice Test Questions 2026

Explanation:
A data analyst is responsible for collecting, processing, and performing statistical analyses on data. Their primary role includes creating visualizations (charts, graphs, dashboards) and reports to communicate insights that help businesses make data-driven decisions. They bridge the gap between raw data and business stakeholders.

Correct Option:

A data analyst
Data analysts specialize in exploratory data analysis, creating visual representations (e.g., bar charts, line graphs, heatmaps, dashboards in Power BI or Tableau), and presenting findings to management. Their core deliverable is actionable insights through visuals, directly matching the description of "creating visuals and charts that help a company make informed decisions."

Incorrect Options:

A data engineer –
Data engineers build and maintain data pipelines, ETL processes, and data infrastructure (e.g., Azure Data Factory, SQL databases, data lakes). They focus on data ingestion, transformation, and storage, not on creating visuals or decision-making charts.

A data scientist –
Data scientists build predictive models using machine learning, perform advanced statistical analysis, and create algorithms. While they may create some visuals (e.g., for model evaluation), their primary focus is on prediction, classification, and inference, not routine business reporting visuals.

A database administrator (DBA) –
DBAs focus on database performance, backup/recovery, security, indexing, and query optimization. They manage the database system itself, not the analysis or visualization of data for business decisions.

Reference:
Microsoft Learn documentation: "Data analyst roles and responsibilities", "Difference between data analyst, data engineer, and data scientist", and "Azure Data Factory – Role definitions"

Explanation:
To find photos of a person based on a sample image, you first detect faces in the sample to get a faceId, then call the identify endpoint. This matches the sample faceId against faces stored in a LargeFaceList. You specify the list ID, candidate count, and optionally confidence threshold. The identify operation returns matching faces from the list.

Correct Options:

Endpoint: identify
The /identify endpoint takes a detected faceId (from a sample image) and searches for matching faces within a specified FaceList or LargeFaceList. This is the correct operation for "find photos of a person" when you have a reference image and a pre-existing face list.

Request Body: "faceId":"c5c24a82-6845-4031-9d5d-978df9175426" – This is the faceId obtained from detecting a face in the sample image. It is required as the query face.

Request Body: "largeFaceListId":"sample_list" – This specifies the target LargeFaceList containing previously stored faces to search against. This is required for identifying matches.

Request Body: "maxNumOfCandidatesReturned":10 – This optional parameter limits the number of candidate matches returned (default is 10). It helps control response size.

Request Body: "mode": "matchPerson" – While not explicitly in the image values, the mode parameter (not shown as a value option) would be matchPerson for person identification. However, based on visible values, the primary needed fields are faceId, largeFaceListId, and maxNumOfCandidatesReturned.

Incorrect Options (from visible values):

Endpoint: detect – The /detect endpoint finds faces in an image and returns faceIds and face rectangles. It does not find matching photos of a person. Detection is a prerequisite step before identification, not the solution itself.

Endpoint: findsimilars – The /findsimilars endpoint searches for similar-looking faces based solely on visual similarity, not person identification. It does not use FaceList/LargeFaceList. It is used for "find similar looking faces" scenarios, not identifying a specific person.

Endpoint: group – The /group endpoint divides unknown faces into groups based on visual similarity. It does not identify a specific person from a sample. It is used for clustering faces, not person matching.

Endpoint: verify – The /verify endpoint checks whether two faces belong to the same person (returns true/false). It is for one-to-one verification, not finding multiple matching photos from a list.

Request Body: "matchFace" / "matchPerson" – These are values for the mode parameter in the /findsimilars endpoint, not for /identify. The identify endpoint uses largeFaceListId and does not have a mode parameter.

Reference:
Microsoft Learn documentation: "Face API – Identify endpoint", "Identify faces in a LargeFaceList", and "Face detection vs identification vs verification"

Statement 1: Going to http://localhost:5000/status will query the Azure endpoint to verify whether the API key used to start the container is valid.

Answer: No

Explanation:
The /status endpoint on the local container checks the container's internal health (e.g., whether it is running properly). It does not query the Azure cloud endpoint to validate the API key. API key validation occurs when the container first attempts to bill to Azure. The /status endpoint is for local liveness probes only.

Statement 2: The container logging provider will write log data.

Answer: Yes

Explanation:
By default, Docker containers capture stdout and stderr output, which includes logs from the running container. The container's logging provider (e.g., json-file, journald, or other configured driver) will write these logs. You can view them using docker logs . Logging is enabled unless explicitly disabled.

Statement 3: Going to http://localhost:5000/swagger will provide the details to access the documentation for the available endpoints.

Answer: Yes

Explanation:
Azure Cognitive Services containers expose a Swagger UI (OpenAPI documentation) at the /swagger endpoint. This provides interactive documentation for all available REST API endpoints (e.g., /text/analytics/v3.0/sentiment). This is a standard feature of these containers to help developers test and integrate locally.

Reference:
Microsoft Learn documentation: "Azure Cognitive Services containers – Swagger documentation", "Container health endpoints (/status)", and "Docker container logging providers"

a table projection

Explanation:
To analyze extracted information in Power BI with minimal development effort, you need structured tabular data. Table projections write enrichment output directly to Azure Table Storage or Azure SQL Database. Power BI can then connect directly to these tables without additional transformation, making it the lowest-effort solution for analysis and reporting.

Correct Option:

A. a table projection
Table projections store enriched data in row/column format in Azure Table Storage or Azure SQL Database. Power BI has native connectors to both, allowing direct import of structured data for visualization and analysis. This requires no custom code or intermediate processing, minimizing development effort.

Incorrect Options:

B. a projection group –
A projection group is a container that holds multiple projections (tables, objects, files). It is not a specific projection type. Adding a projection group without defining table projections does not create queryable data for Power BI. This is a structural concept, not a solution.

C. an object projection –
Object projections store data as JSON files in Azure Blob Storage. While Power BI can read JSON, it requires additional parsing and transformation (e.g., Power Query logic). This increases development effort compared to direct table connections, so it does not minimize effort.

D. a file projection –
File projections store images or binary files in blob storage. These are not suitable for direct analysis in Power BI without extensive preprocessing. Power BI is designed for structured/tabular data, not raw files. This does not meet the requirement.

Reference:
Microsoft Learn documentation: "Table projections for Azure Cognitive Search", "Power BI integration with Cognitive Search knowledge store", and "Minimize development effort with table projections"

No

Explanation:
The issue is that users ask semantically equivalent questions ("What is the price of X?" vs. "How much does X cost?"). Creating an entity for "cost" does not solve this because entities extract values (e.g., "$50"), but the chatbot fails to recognize that the second question asks for the same information. The solution requires adding alternative phrasing (aliases) or synonyms to the question answering model, not entities.

Correct Option:

B. No
Entities are used to extract specific data points (like product names, prices, dates) from user queries. They do not help the model understand that two different phrasings ("price of" vs. "how much does") have the same intent. To handle multiple phrasings, you need to add similar questions (alternate wordings) to the QnA pair during authoring.

Incorrect Option:

A. Yes
This would be incorrect because entities are not designed to map different natural language expressions to the same answer. Even with an entity for "cost," the model still needs to recognize that "How much does" maps to the same QnA pair as "What is the price of." This requires manual addition of alternate phrasing, not entity creation.

Reference:
Microsoft Learn documentation: "Question answering – Add alternative phrasing", "Entities vs. synonyms in Cognitive Service for Language", and "Improve response accuracy with similar questions"

No

Explanation:
Throttling in Azure Cognitive Search occurs when query volume exceeds the capacity (replicas, partitions, query units) of the current service tier. Customer-managed key (CMK) encryption is a security feature for encrypting indexes and data at rest. It has no impact on query processing capacity, throughput, or throttling behavior.

Correct Option:

B. No
CMK encryption adds an additional layer of security by allowing you to manage your own encryption keys in Azure Key Vault. It does not increase the number of replicas, improve query response times, or raise any service limits. Throttling is a performance/capacity issue, not a security issue, so CMK does not address it.

Incorrect Option:

A. Yes
This would be incorrect because enabling CMK encryption does not affect query throughput or service capacity. To reduce throttling, you need to scale out (add replicas), scale up (higher tier), optimize queries, or distribute load. CMK encryption is unrelated to performance or throttling mitigation.

Reference:
Microsoft Learn documentation: "Customer-managed keys for Cognitive Search encryption", "Cognitive Search throttling causes and solutions", and "Scale replicas and partitions to handle query volume"

Explanation:
This scenario requires analyzing both video and audio streams to determine presence, attention, and speaking activity. Azure Cognitive Services provides specialized APIs: Face API for detecting faces and facial attributes, and Speech service for analyzing audio. Choosing the right service depends on the type of input (video vs audio) and the required insight (presence, attention, or speech detection).Correct Option:

From a learner’s video feed, verify whether the learner is present – Face
The Face service can detect whether a human face exists in the video frame. It can also identify individuals using face recognition features. This makes it ideal for confirming learner presence and identity with minimal development effort by leveraging built-in detection and identification capabilities.

From a learner’s facial expression in the video feed, verify whether the learner is paying attention – Face
The Face API provides facial attributes such as head pose, eye direction, and emotions. These attributes can be used to infer attention levels (e.g., looking at screen vs away). This avoids building custom ML models and uses prebuilt capabilities for analyzing engagement.

From a learner’s audio feed, detect whether the learner is talking – Speech
The Speech service can process audio streams to detect speech activity. It supports speech-to-text and speech detection, making it suitable for identifying whether a learner is speaking. This is more appropriate than other services because it is specifically designed for audio processing.

Incorrect Option:

Speech (for video-based tasks) – Incorrect
Speech service only processes audio input and cannot analyze video or facial expressions. It cannot detect presence or attention from visual data.

Text Analytics – Incorrect
Text Analytics works on written text input for sentiment analysis, key phrases, and language detection. It does not process video or audio directly, making it unsuitable for presence detection, facial analysis, or speech detection tasks.

Reference:
Microsoft Learn – Azure Cognitive Services (Face API for face detection and attributes, Speech service for audio processing)

Explanation:
Azure Synapse Analytics (formerly SQL Data Warehouse) uses a massively parallel processing (MPP) architecture. The MPP engine distributes query processing across multiple compute nodes that work in parallel. Each compute node handles a subset of data, and the control node coordinates the work. This enables high-performance queries on large datasets.

Correct Option:

distributes processing across compute nodes.
In Synapse's MPP architecture, the control node receives queries, optimizes them, and distributes the workload to multiple compute nodes. These compute nodes process their assigned data partitions in parallel, then return results to the control node for final aggregation. This is the core of MPP distribution.

Incorrect Options:

distributes processing across control nodes. – There is typically only one control node per Synapse SQL pool. Processing is distributed to compute nodes, not across multiple control nodes. The control node coordinates but does not perform distributed processing itself.

redirects client connections across compute nodes. – Client connections go to the control node, not directly to compute nodes. Compute nodes are not directly accessible by clients. Redirection is not part of the MPP engine's function.

redirects client connections across control nodes. – There is only one control node per SQL pool. Clients connect to the control node endpoint, and connections are not redirected across multiple control nodes.

Reference:
Microsoft Learn documentation: "Azure Synapse Analytics MPP architecture", "Control node vs compute nodes in Synapse", and "Distributed query processing"

Explanation:
The list contains 60,000 images, which exceeds the limit of a regular faceList (1 million faces). A LargeFaceList supports up to 1 million faces, so largeFaceListId is required. The findSimilar API uses matchFace mode to return similar faces based on visual similarity. matchPerson is for person identification using FaceList/LargeFaceList with confidence thresholds.

Correct Options:

"largeFaceListId": "employeefaces"
With 60,000 images, you must use a LargeFaceList (supports up to 1 million faces) rather than a regular faceList (limited to 1,000 faces). The largeFaceListId property references the existing list named employeefaces. This is required for large-scale face collections.

"mode": "matchFace"
The mode parameter determines the matching behavior. matchFace finds faces that are visually similar to the target faceId, regardless of person identity. This is appropriate for general "find similar faces" scenarios. matchPerson is used when you have person grouping and need to identify a specific individual.

Incorrect Options:

"faceListId" – This property is for regular faceList objects, which have a maximum capacity of 1,000 faces. Since employeefaces contains 60,000 images, using faceListId would be invalid or result in an error. largeFaceListId is the correct choice for large-scale face lists.

"mode": "matchPerson" – The matchPerson mode is used with faceListId or largeFaceListId to match faces to persons (using person group or large person group). For simple visual similarity matching without person grouping, matchFace is the appropriate mode. The question asks to "find similar faces," not identify a specific person.

Reference:
Microsoft Learn documentation: "Face API – Find Similar operation", "LargeFaceList vs FaceList limits", and "matchFace vs matchPerson modes"

a free (Limited enrichments) Cognitive Services resource

Explanation:
Azure Cognitive Search allows attaching a Cognitive Services resource for billable skills (OCR, text analytics). To minimize costs, you can use the free (Limited enrichments) option, which provides 20 documents per indexer per day at no charge. For 50,000 scanned documents, you can process over time or mix free with paid, but the free option minimizes cost.

Correct Option:

B. a free (Limited enrichments) Cognitive Services resource
When creating an enrichment pipeline in Cognitive Search, you can select "Free (Limited enrichments)" as the Cognitive Services attachment. This allows up to 20 free document enrichments per indexer per day. For 50,000 documents, this may take many days, but it incurs zero cost, which is the absolute minimum. This is the correct choice for cost minimization.

Incorrect Options:

A. a new Computer Vision resource –
While Computer Vision provides OCR, attaching a dedicated Computer Vision resource incurs costs per transaction (e.g., $1 per 1,000 images). This is not cost-minimizing compared to the free option. The question asks for minimum costs, so a paid resource is incorrect.

C. an Azure Machine Learning pipeline –
AML pipelines are for custom machine learning models and are not required for standard OCR and text analytics. Running AML pipelines incurs compute costs (e.g., Azure ML compute clusters). This is expensive and overkill for the requirement, not cost-minimizing.

D. a new Cognitive Services resource that uses the S0 pricing tier –
The S0 tier is a paid, multi-service Cognitive Services resource. It incurs costs per transaction. While functional, it does not minimize costs. The free (Limited enrichments) option provides the same OCR and text analytics capabilities at zero cost (up to 20 docs/day).

Reference:
Microsoft Learn documentation: "Attach a Cognitive Services resource to a skillset", "Free (Limited enrichments) option in Azure Cognitive Search", and "Cognitive Services pricing tiers for enrichment"

Scenario 1: Data for a product catalog will be loaded every 12 hours to a data warehouse.

Match: Batch

Explanation:
Batch processing handles large volumes of data at scheduled intervals (e.g., every 12 hours, daily, weekly). It is suitable for scenarios where real-time updates are not required. Loading a product catalog twice a day is a classic batch workload, as the data does not change continuously and can be processed in bulk.

Scenario 2: Thousands of data sets per second for online purchases will be loaded into a data warehouse in real time.

Match: Streaming

Explanation:
Streaming processing handles continuous, high-velocity data as it arrives, with low latency (milliseconds to seconds). Processing thousands of online purchase events per second in real time requires streaming technologies like Azure Stream Analytics, Kafka, or Event Hubs. Batch processing would introduce unacceptable delays.

Scenario 3: Updates to inventory data will be loaded to a data warehouse every 1 million transactions.

Match: Batch

Explanation:
Although "every 1 million transactions" could be triggered by a count, this is still a batch-oriented approach (processing after accumulating a threshold). True streaming processes each transaction individually in real time. Loading after accumulating 1 million transactions means data is processed in chunks, not continuously, making this a batch workload.

Reference:
Microsoft Learn documentation: "Batch vs streaming data processing", "Azure Data Factory for batch workloads", and "Azure Stream Analytics for real-time streaming"