Ngân hàng đề — Microsoft Azure AI Engineer
Tìm thấy 267 câu.
You are required to make synchronous API calls to various Azure AI-Language features in your application.
Please refer to the table below for the appropriate features and endpoints and map them in the correct order.

-
A
F11 > E24; F12 > E25; F13 > E22 ; F14 > E21; F15 > E23
-
B
F11 > E24; F12 > E25; F13 > E22 ; F14 > E23; F15 > E21
-
C
F11 > E24; F12 > E25; F13 > E21 ; F14 > E23; F15 > E22
-
D
F11 > E24; F12 > E23; F13 > E22 ; F14 > E25; F15 > E21
Xem giải thích
Đáp án
B — F11→E24, F12→E25, F13→E22, F14→E23, F15→E21
Vì sao đúng
Cách làm nhanh nhất là đọc đoạn cuối của đường dẫn, vì mỗi tính năng có endpoint mang đúng tên của nó:
| Tính năng | Endpoint | Đoạn nhận ra ngay |
|---|---|---|
| Key Phrase Extraction (F11) | E24 | /keyPhrases |
| Sentiment Analysis (F12) | E25 | /sentiment |
| Language Detection (F13) | E22 | /languages |
| Named Entity Recognition (F14) | E23 | /entities/recognition/ |
| Entity Linking (F15) | E21 | /entities/linking |
Chỗ duy nhất dễ nhầm là hai endpoint cùng bắt đầu bằng /entities/: recognition là nhận dạng thực thể trong câu, còn linking là nối thực thể đó tới một mục tri thức bên ngoài (ví dụ trang Wikipedia tương ứng).
Vì sao các phương án khác sai
- A và C — đảo hai endpoint
entities/recognitionvàentities/linkingcho nhau. - D — gán
/sentimentcho nhận dạng thực thể.
Review the statement given below and state if it is true or false:
To translate text, you have set up a Translator service in Azure. While reviewing the input documents, you have noticed that the source language of certain text is missing. To identify the language of the source text, you have utilized the language detection feature available in the Translator service. You have specified the 'from' parameter in the translation request to detect the language. However, the confidence score will not be provided.
-
A
True
-
B
False
Xem giải thích
Đáp án
B — Sai (False).
Vì sao đúng
⚠ Nhận định sai ở chỗ nào: | Đề khẳng định | Thực tế | |---|---| | ⚠ "chỉ định tham số from để nhận diện ngôn ngữ nguồn" | ⚠ NGƯỢC LẠI — muốn tự nhận diện thì phải BỎ from |
⚠ CÓ tham số from=en
⚠ "tôi KHẲNG ĐỊNH nguồn là tiếng Anh"
⚠ API KHÔNG nhận diện gì cả
↓
⚠ BỎ tham số from
⚠ API TỰ nhận diện ngôn ngữ nguồn
⚠ trả về trường detectedLanguage
⚠ Logic đơn giản: ⚠ khai from là nói cho API biết, ⚠ không khai mới là để API tự đoán.
Ghi nhớ
⚠ Tham số from của Translator — quy tắc: | Trường hợp | Hành vi | |---|---| | ⚠ CÓ from | ⚠ dùng đúng ngôn ngữ đó, KHÔNG nhận diện | | ⚠ KHÔNG có from | ⚠ tự nhận diện, trả về detectedLanguage | | ⚠ Trong phản hồi | ⚠ detectedLanguage: { language: "vi", score: 1.0 } |
Từ khoá nhận diện:
"tự nhận diện ngôn ngữ nguồn khi dịch" → ⚠ BỎ tham số
from"chỉ nhận diện, không dịch" → ⚠ gọi endpoint/detect"biết chắc ngôn ngữ nguồn" → ⚠ khaifromđể nhanh và chính xác hơn
| ⚠ Hai cách nhận diện ngôn ngữ | Cách |
|---|---|
⚠ Bỏ from khi gọi /translate |
⚠ nhận diện VÀ dịch trong một lời gọi |
⚠ Gọi endpoint /detect riêng |
⚠ CHỈ nhận diện, không dịch |
| ⚠ Chọn cách nào | ⚠ cần dịch luôn thì bỏ from; chỉ cần biết ngôn ngữ thì dùng /detect |
| ⚠ Hiệu quả hơn | ⚠ một lời gọi tốt hơn hai |
⚠ Vì sao nên khai from khi biết chắc |
Lý do |
|---|---|
| ⚠ Nhanh hơn | ⚠ bỏ qua bước nhận diện |
| ⚠ Chính xác hơn với văn bản NGẮN | ⚠ nhận diện dễ sai khi ít chữ |
| ⚠ Tránh nhầm giữa các ngôn ngữ gần nhau | |
⚠ Chỉ bỏ from khi |
⚠ thật sự không biết ngôn ngữ nguồn |
| ⚠ Mẹo làm câu Đúng/Sai | Mẹo |
|---|---|
| ⚠ Tìm khẳng định CỤ THỂ nhất trong nhận định | |
| ⚠ Kiểm tra logic có ngược không | ⚠ đề này bị ngược |
| ⚠ Một vế sai là cả nhận định sai | |
| ⚠ Sai lầm | ⚠ thấy phần đầu hợp lý rồi vội chọn True |
| ⚠ Giới hạn của nhận diện ngôn ngữ | Giới hạn |
|---|---|
| ⚠ Văn bản quá ngắn → độ tin cậy thấp | |
| ⚠ Văn bản hỗn hợp nhiều ngôn ngữ → chỉ trả về một | |
| ⚠ Ngôn ngữ gần nhau dễ nhầm | ⚠ tiếng Bồ Đào Nha và Tây Ban Nha |
| ⚠ Nên | ⚠ kiểm tra điểm tin cậy trước khi dùng kết quả |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có biết chắc ngôn ngữ nguồn không | ⚠ biết thì khai from | | Văn bản có đủ dài để nhận diện đáng tin không | | | Ứng dụng có xử lý trường hợp nhận diện sai không | |
Và cách nhớ gọn để không bao giờ nhầm tham số này: khai from là bạn TRẢ LỜI, bỏ from là bạn HỎI. Không thể vừa trả lời vừa hỏi cùng một lúc.
You mentioned that you are using the Speech service in Azure to transcribe large amounts of audio, and you plan to apply analytics to the transcribed text to gain insights or facilitate actions. Since the amount of audio is considerable, you use batch transcription. This process involves four operations, which are as follows:
-
Operation A (011): Create a new transcription
-
Operation B (012): Get the transcription
-
Operation C (013): Update the details of the transcription
-
Operation D (014): Delete the transcription
To perform these operations, you use REST API calls and methods, which are listed in the table below. Review the operations, methods, and API calls and map them in the correct order. Here are the API calls and their respective methods:
-
API Call A (A21): GET speechtotext/v3.O/transcriptions/{id}
-
API Call B (A22): POST speechtotext/v3.O/transcriptions
-
API Call C (A23): DELETE speechtotext/v3.O/transcriptions/{id}
-
API Call D (A24): PATCH speechtotext/v3.O/transcriptions/{id}
-
A
011 > A21; 012 > A22; 013 > A24; 014 > A23
-
B
011 > A21; 012 > A22; 013 > A23; 014 > A24
-
C
011 > A22; 012 > A21; 013 > A24; 014 > A23
-
D
011 > A22; 012 > A21; 013 > A23; 014 > A24
Xem giải thích
Đáp án
C — O11→A22, O12→A21, O13→A24, O14→A23
Vì sao đúng
Bốn thao tác ứng với bốn phương thức HTTP theo đúng quy ước REST:
| Thao tác | Phương thức và đường dẫn | Vì sao |
|---|---|---|
| Tạo bản ghi mới (O11) | POST /transcriptions (A22) |
POST lên tập hợp để tạo phần tử mới; chưa có id nên đường dẫn không kèm id |
| Lấy bản ghi (O12) | GET /transcriptions/{id} (A21) |
Đọc một phần tử cụ thể |
| Cập nhật chi tiết (O13) | PATCH /transcriptions/{id} (A24) |
PATCH sửa một phần; PUT thì thay toàn bộ |
| Xoá (O14) | DELETE /transcriptions/{id} (A23) |
Dấu hiệu nhận ra nhanh nhất: thao tác tạo là cái duy nhất không có {id} trong đường dẫn, vì id chỉ tồn tại sau khi bản ghi được tạo.
Vì sao các phương án khác sai
- A và B — gán GET cho thao tác tạo và POST cho thao tác đọc, tức là đảo ngược hoàn toàn.
- D — đảo PATCH với DELETE, nghĩa là muốn cập nhật thì lại xoá mất bản ghi.
You have been assigned to fine-tune the text-to-speech using the core features of the Speech service in Azure. The goal is to manage specific aspects of the speech output, such as tweaking the pitch or adding pauses, in order to enhance the quality of the synthesized content. Additionally, you need to create your lexicons and switch between different speaking styles as per the requirement.
Which core feature of text-to-speech service would you utilize in this case?
-
A
Asynchronous Synthesis of Long Audio
-
B
Neural Voices
-
C
Visemes
-
D
Speech Synthesis Markup Language
Xem giải thích
Đáp án
D — Speech Synthesis Markup Language (SSML)
Vì sao đúng
SSML là ngôn ngữ đánh dấu dựng riêng để điều khiển chi tiết đầu ra giọng nói: cách phát âm một từ cụ thể (thẻ phoneme hoặc sub), âm lượng, tốc độ, cao độ, quãng nghỉ, nhấn giọng, và cả việc đổi giọng đọc giữa chừng. Đây đúng là "tinh chỉnh các khía cạnh cụ thể của đầu ra" mà đề nói tới.
Vì sao các phương án khác sai
- B. Neural Voices — là tập giọng đọc có sẵn, chất lượng tự nhiên; bạn chọn giọng chứ không điều khiển được từng khía cạnh của nó.
- C. Visemes — dữ liệu mô tả hình miệng tương ứng với âm thanh, dùng để đồng bộ hoạt hình nhân vật; không thay đổi bản thân âm thanh.
- A. Tổng hợp âm thanh dài bất đồng bộ — cơ chế xử lý văn bản rất dài theo lô, liên quan tới quy mô chứ không tới cách đọc.
Your application assists in identifying various entities within a given text. To accomplish this, you use the Text Analytics API in Azure to classify these entities into pre-defined categories.
Review the endpoint options provided below and select the one that is specifically used for Named Entity Recognition.
-
A
https://uksouth.cognitiveservices.azure.com/text/analytics/v3.1/entities/recognition/general -
B
https://uksouth.cognitiveservices.azure.com/text/analytics/v3.1/entities/recognition/pii -
C
https://uksouth.cognitiveservices.azure.com/text/analytics/v3.1/entities/recognition/pii?domain=phi -
D
https://uksouth.cognitiveservices.azure.com/text/analytics/v3.1/entities/linking
Xem giải thích
Đáp án
A — .../v3.1/entities/recognition/general
Vì sao đúng
Nhận dạng thực thể có tên (NER) phân loại các thực thể trong câu vào những nhóm chung — người, địa điểm, tổ chức, ngày tháng, số lượng. Đoạn recognition/general trong đường dẫn nói đúng điều đó: nhận dạng ở phạm vi tổng quát.
Vì sao các phương án khác sai
- B.
recognition/pii— chỉ tìm thông tin định danh cá nhân: số điện thoại, email, số thẻ. Đây là tập con hẹp, không phải NER tổng quát. - C.
recognition/pii?domain=phi— hẹp hơn nữa, giới hạn vào thông tin y tế cá nhân. - D.
entities/linking— không phân loại mà nối thực thể tìm được tới một mục tri thức bên ngoài, ví dụ trang Wikipedia. Khác mục đích hoàn toàn.
The Image Analysis API in Azure is utilized to analyze the image, regardless of whether it's clip art or a line drawing. Examine the code provided below and choose the most suitable value for the clipArtType parameter.

-
A
Non-clip-art
-
B
Ambiguous
-
C
Normal-clip-art
-
D
Good-clip-art
Xem giải thích
Đáp án
C — Normal-clip-art
Vì sao đúng
Trong phản hồi, clipArtType có giá trị 2, và Image Analysis dùng thang bốn mức cố định:
| Giá trị | Ý nghĩa |
|---|---|
| 0 | Non-clip-art — không phải clip art |
| 1 | Ambiguous — không xác định được |
| 2 | Normal-clip-art |
| 3 | Good-clip-art — clip art rõ ràng, chất lượng cao |
Điểm cần nhớ: đây là thang mức độ tin cậy, không phải nhãn phân loại nhị phân. Càng lên cao nghĩa là hệ thống càng chắc ảnh đúng là clip art.
Vì sao các phương án khác sai
- A. Non-clip-art ứng với 0, B. Ambiguous ứng với 1, D. Good-clip-art ứng với 3 — cả ba đều không khớp giá trị trong đoạn mã.
You are developing an application using Azure OpenAl Service. What does the "n" parameter signify in the provided code for consuming the DALL-E model through the REST API when generating images from textual prompts?

-
A
Description of the image to be generated
-
B
Resolution of the image(s)
-
C
API version
-
D
Number of images to be generated
-
E
Any arbitrary number with no significance
Xem giải thích
Đáp án
D — Số lượng ảnh sẽ được sinh ra
Vì sao đúng
Trong lời gọi API sinh ảnh, "n": 1 khai số ảnh muốn nhận về cho cùng một prompt. Đặt n: 4 thì mô hình trả về bốn biến thể khác nhau của cùng mô tả — hữu ích khi muốn có nhiều lựa chọn để so.
Đây cũng là tham số ảnh hưởng trực tiếp tới chi phí và thời gian chờ, vì mỗi ảnh là một lần sinh riêng.
Vì sao các phương án khác sai
Ba tham số kia đều có mặt trong chính đoạn mã, ở những khoá khác:
- A. Mô tả ảnh — nằm ở
"prompt". - B. Độ phân giải — nằm ở
"size"(1024×1024). - C. Phiên bản API — nằm ở
api_versiontrong URL. - E. Con số tuỳ ý không có ý nghĩa — sai; nó có ý nghĩa rất cụ thể.
You have developed a web application that is hosted on an Azure Virtual Machine within an Azure Virtual Network. Your goal is to establish a direct connection between the web application and a newly created Azure Al Search service without relying on public internet routes.
To accomplish this, you plan to deploy the Azure Al Search and a public endpoint onto a new Azure Virtual Network. Then, you will set up Azure Private Link to achieve your objective. You need to determine whether this solution aligns with your goal.
-
A
True
-
B
False
Xem giải thích
Đáp án
B — Sai, giải pháp này không đạt mục tiêu
Vì sao đúng
Mục tiêu là kết nối không đi qua Internet công cộng, nhưng chính giải pháp lại nói triển khai một public endpoint. Đó là mâu thuẫn nội tại: còn public endpoint thì dịch vụ vẫn phơi ra ngoài, và mục tiêu không đạt.
Cách làm đúng là dựng private endpoint cho Azure AI Search trong mạng ảo, rồi tắt truy cập công khai, để đường riêng là lối vào duy nhất.
Ngoài ra còn một điểm sai về cách hiểu: Azure AI Search là dịch vụ PaaS, bạn không "triển khai nó vào" một mạng ảo. Cái được đặt trong mạng ảo là private endpoint — một giao diện mạng có IP riêng trỏ tới dịch vụ.
Vì sao phương án còn lại sai
- A. Đúng — chỉ đúng nếu bỏ hẳn phần public endpoint và dùng private endpoint thay thế.
You have created an Azure AI Search resource in Azure and have opted for the standard S1 tier. Due to organic growth, the index sizes have increased, which could lead to performance issues and difficulty in handling query load. There are two possible solutions to address this problem:
-
Option 1: Add additional search units (SU) to the Sl tier
-
Option 2: Upgrade to a standard S2 tier

Based on the scenario presented, Option 2 would be the selection.
Is this statement True or False?
-
A
True
-
B
False
Xem giải thích
Đáp án
A — Đúng, nên chọn phương án nâng lên bậc S2
Vì sao đúng
Điểm quyết định nằm ở kích thước tối đa của một phân vùng, không nằm ở số lượng đơn vị:
| Bậc | Kích cỡ mỗi phân vùng | Giá mỗi SU |
|---|---|---|
| Standard S1 | 25 GB | 250 |
| Standard S2 | 100 GB | 1000 |
Vấn đề đề nêu là kích thước chỉ mục tăng lên. Thêm search unit vào S1 chỉ cho bạn thêm phân vùng và thêm bản sao, nhưng mỗi phân vùng vẫn bị chặn ở 25 GB — nên chỉ mục lớn vẫn phải xé nhỏ ra nhiều mảnh, và điều đó làm truy vấn chậm đi vì phải gom kết quả từ nhiều phân vùng. Bậc S2 cho mỗi phân vùng gấp bốn lần dung lượng, giải đúng nguyên nhân.
Một điều cần biết thêm
Azure AI Search không cho đổi bậc tại chỗ. Nâng bậc nghĩa là tạo dịch vụ mới ở bậc S2 rồi dựng lại chỉ mục và nạp lại dữ liệu — nên đây là quyết định cần tính trước, không phải một cú bấm.
You upload the receipt images to the Form Recognizer API for analysis, and the API returns the following JSON.
"documentResults": [
{
"docType": "prebuilt:receipt",
"pageRange": [
1,
1
],
"fields": {
"ReceiptType": {
"type": "string",
"valueString": "Itemized",
"confidence": 0.672
},
"MerchantName": {
"type": "string",
"valueString": "Tailwind",
"text": "Tailwind",
"boundingBox": [],
"page": 1,
"confidence": 0.913,
"elements": [
"#/readResults/0/lines/0/words/0"
]
},
...
Which expression should you use to trigger a manual review of the extracted information by a member of the Consultant-Bookkeeper group?
- A documentResults.docType == "prebuilt:receipt"
- B documentResults.fields.*.confidence < 0.7
- C documentResults.fields.ReceiptType.confidence > 0.7
- D documentResults.fields.MerchantName.confidence < 0.7
Xem giải thích
🧩 Phân tích nội dung câu hỏi
Câu hỏi yêu cầu phát triển một giải pháp extract dữ liệu từ hình ảnh biên lai (receipt images) sử dụng Azure AI Document Intelligence (trước đây gọi là Form Recognizer API). Giải pháp phải đáp ứng các yêu cầu xử lý tài liệu và kỹ thuật, bao gồm việc kích hoạt xem xét thủ công (manual review) bởi nhóm Consultant-Bookkeeper khi dữ liệu extract có độ tin cậy thấp.
📄 Dữ liệu đầu vào: Hình ảnh biên lai được upload lên API, trả về JSON với cấu trúc documentResults:
docType: "prebuilt:receipt" (model prebuilt nhận diện biên lai).fields: Các trường dữ liệu như:ReceiptType:confidence = 0.672(thấp, dưới 0.7).MerchantName:confidence = 0.913(cao, trên 0.7).
🎯 Mục tiêu: Xác định expression (biểu thức) đúng để trigger manual review dựa trên độ tin cậy (confidence). Thường dùng trong Azure Logic Apps, Power Automate hoặc workflow tương tự để kiểm tra ngưỡng confidence (thường < 0.7 là thấp, cần review).
🛠️ Ngữ cảnh cập nhật (2026): Theo tài liệu Azure AI Document Intelligence v4.0+ (ra mắt 2023-2024, ổn định đến 2026), API trả confidence từ 0-1 cho từng field. Expression sử dụng JSONPath-like hoặc OData để kiểm tra động, hỗ trợ wildcard (*) cho tất cả fields.
📘 Tài liệu tham khảo:
- Azure AI Document Intelligence - Analyze receipts (cập nhật 2026).
- Confidence scores in Document Intelligence.
- Logic Apps expressions for JSON.
✅ Đáp án đúng và lý do
Đáp án đúng: documentResults.fields.*.confidence < 0.7
Lý do chọn 🏆:
- Biểu thức này kiểm tra tất cả các field (
*là wildcard) trongdocumentResults.fields. Nếu bất kỳ field nào cóconfidence < 0.7, sẽ trigger manual review. - Trong JSON mẫu:
ReceiptType.confidence = 0.672 < 0.7→ Trigger đúng (cần review vì độ tin cậy thấp). MerchantName.confidence = 0.913 > 0.7→ Không ảnh hưởng, vì chỉ cần một field thấp là đủ.- Phù hợp best practice: Review toàn bộ document nếu any field low confidence, tránh miss data quan trọng. Hỗ trợ wildcard trong Azure Logic Apps v2+ (2024+).
❌ Phân tích tất cả các phương án
-
documentResults.docType == "prebuilt:receipt
❌ Sai: Biểu thức chỉ kiểm tra loại document là "prebuilt:receipt" (luôn đúng với JSON mẫu). Không liên quan đến confidence → Không trigger review dựa trên chất lượng extract, chỉ filter loại tài liệu. Không đáp ứng yêu cầu review khi confidence thấp. -
documentResults.fields.*.confidence < 0.7
✅ Đúng: Như giải thích trên. Kiểm tra động toàn bộ fields với wildcard*, trigger nếu any confidence < 0.7 (phù hợp JSON: ReceiptType thấp). Linh hoạt, scalable cho nhiều fields. -
documentResults.fields.ReceiptType.confidence > 0.7
❌ Sai: Kiểm tra cụ thểReceiptType.confidence > 0.7. Trong JSON: 0.672 < 0.7 → Không trigger (nhưng thực tế cần review). Ngược logic (high confidence thì KHÔNG review), chỉ check 1 field cố định → Miss các field khác thấp. -
documentResults.fields.MerchantName.confidence < 0.7
❌ Sai: Kiểm tra cụ thểMerchantName.confidence < 0.7. Trong JSON: 0.913 > 0.7 → Không trigger. Bỏ quaReceiptTypethấp → Không review đầy đủ, chỉ check 1 field không đại diện toàn bộ document.
🧠 Kết luận: Sử dụng wildcard để check toàn diện là cách tối ưu, tránh hard-code từng field. Implement trong Logic Apps: Condition với expression này → Send approval to Consultant-Bookkeeper group! 🚀