Ngân hàng đề — Microsoft Azure AI Engineer

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Azure Cognitive Services, cụ thể là dịch vụ QnA Maker (nay được tích hợp vào Azure AI Language services theo cập nhật mới nhất đến năm 2026). Nội dung câu hỏi mô tả tình huống:
Bạn đang lập kế hoạch triển khai (provision) một dịch vụ QnA Maker trong một resource group mới tên RG1. Trong RG1, bạn đã tạo sẵn một App Service plan tên AP1.
Câu hỏi yêu cầu xác định hai Azure resources nào được tự động tạo trong RG1 khi triển khai QnA Maker. Đây là câu hỏi trắc nghiệm multi-select (chọn nhiều đáp án đúng), mỗi lựa chọn đúng chiếm 1 điểm.

📘 Bối cảnh kỹ thuật: Khi provision QnA Maker qua Azure Portal hoặc CLI, dịch vụ này sẽ tự động tạo các tài nguyên phụ thuộc cần thiết để hoạt động, bao gồm indexing và hosting. Lưu ý rằng App Service plan AP1 đã tồn tại sẵn, nhưng QnA Maker vẫn cần một App Service instance riêng để chạy logic xử lý. Kiến thức dựa trên tài liệu Azure chính thức cập nhật đến năm 2026 (Azure AI Studio và Cognitive Services v4+).

✅ Đáp án đúng và lý do lựa chọn

Hai đáp án đúng là:
🟢 Azure Cognitive Search
🟢 Azure App Service

Lý do:

• Khi provision QnA Maker, Azure tự động tạo một Azure Cognitive Search (trước đây gọi là Azure Search) để lưu trữ và tìm kiếm knowledge base (cơ sở kiến thức Q&A). Đây là tài nguyên bắt buộc cho chức năng indexing và semantic search.
• Đồng thời, một Azure App Service (web app) được tạo tự động trong cùng resource group để host endpoint của QnA Maker, sử dụng App Service plan đã có (AP1). App Service plan chỉ là "kế hoạch giá", còn App Service là instance thực tế chạy ứng dụng.

🔍 Giải thích tất cả các phương án (đúng và sai)

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên nội dung văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng:

• Language Understanding
  ❌ Sai. Language Understanding (LUIS) là dịch vụ riêng biệt trong Azure Cognitive Services dùng cho NLU (Natural Language Understanding), không được QnA Maker tự động tạo. QnA Maker chỉ tập trung vào Q&A extraction và không phụ thuộc LUIS.

• Azure SQL Database
  ❌ Sai. QnA Maker không sử dụng Azure SQL Database làm backend lưu trữ chính. Thay vào đó, nó dùng Azure Cognitive Search cho metadata và knowledge base. SQL DB chỉ dùng nếu bạn tự tích hợp custom storage.

• Azure Storage
  ❌ Sai. Mặc dù Azure Storage có thể dùng để upload files cho knowledge base, nhưng QnA Maker không tự động tạo tài nguyên Storage mới trong RG1. Bạn phải tạo thủ công nếu cần import dữ liệu lớn.

• Azure Cognitive Search
  ✅ Đúng. Đây là tài nguyên cốt lõi được tự động provision để xử lý tìm kiếm full-text và semantic ranking cho QnA pairs. Theo docs Azure 2026, Cognitive Search là dependency bắt buộc (mức Basic trở lên).

• Azure App Service
  ✅ Đúng. QnA Maker tự động tạo một Web App (App Service) trong RG1, gắn với plan AP1 để expose REST API endpoint (như /generateAnswer). Không có App Service plan thì không deploy được.

📚 Tài liệu tham khảo

• Azure QnA Maker Documentation - Provisioning Resources (Cập nhật 2026: Phần "Automatically created resources").
• Azure AI Language - QnA Integration (Chi tiết về Cognitive Search và App Service dependencies).
• Azure Portal Quickstart (Thử nghiệm provision để verify resources tự động tạo).

🛠️ Lời khuyên: Trong thực tế triển khai, kiểm tra resource group sau provision để thấy chính xác các tài nguyên được tạo. Nếu dùng Azure AI Studio (mới 2025+), quy trình tương tự nhưng tích hợp hơn!

🧩 Phân tích nội dung câu hỏi

Câu hỏi yêu cầu xây dựng một giải pháp sử dụng Optical Character Recognition (OCR) từ Computer Vision API (thuộc Azure Cognitive Services) để quét các tài liệu nhạy cảm. Yêu cầu quan trọng nhất: Giải pháp KHÔNG được triển khai trên public cloud (tức là phải chạy on-premises, trên máy chủ nội bộ để đảm bảo bảo mật dữ liệu nhạy cảm).
📌 Mục tiêu chính: Tìm cách triển khai Computer Vision API cục bộ, tránh gửi dữ liệu ra cloud công khai, đồng thời vẫn sử dụng đầy đủ tính năng OCR của API này.
🛠️ Bối cảnh kỹ thuật: Computer Vision API hỗ trợ OCR để nhận diện văn bản từ hình ảnh/tài liệu. Theo tài liệu Azure mới nhất (cập nhật đến 2026), Azure cung cấp tùy chọn Docker containers cho các dịch vụ Cognitive Services, cho phép chạy on-premises mà không cần kết nối cloud.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Host the Computer Vision endpoint in a container on an on-premises server.
Lý do:

• Azure Cognitive Services (bao gồm Computer Vision) chính thức hỗ trợ Docker containers để triển khai on-premises. Bạn có thể pull image từ Microsoft Container Registry (MCR), chạy trên server nội bộ (như Kubernetes on-prem, Docker host), và expose endpoint API cục bộ.
• Điều này đảm bảo dữ liệu nhạy cảm không rời khỏi môi trường nội bộ, vẫn sử dụng đầy đủ tính năng OCR mà không cần public cloud.
• ✅ Ưu điểm: Hỗ trợ billing theo pay-as-you-go (dựa trên quota keys), tích hợp dễ dàng với các app on-premises.
  📘 Tài liệu tham khảo: Azure Cognitive Services Containers Documentation (cập nhật 2025-2026, hỗ trợ Vision 4.0+ với OCR cải tiến).

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên yêu cầu "NOT deployed to public cloud" và tính khả thi với Computer Vision API.

• ❌ Build an on-premises web app to query the Computer Vision endpoint.
  Sai vì: Web app on-premises chỉ là frontend, nhưng vẫn phải query endpoint của Computer Vision API trên cloud (Azure public endpoint). Dữ liệu nhạy cảm sẽ được gửi ra public cloud, vi phạm yêu cầu. Không giải quyết vấn đề triển khai cục bộ.

• ✅ Host the Computer Vision endpoint in a container on an on-premises server.
  Đúng vì: Như đã giải thích ở trên, đây là cách chính thức của Azure để chạy endpoint API đầy đủ (bao gồm OCR) trong container Docker trên server nội bộ. Không phụ thuộc cloud, dữ liệu an toàn 100%. Hỗ trợ các tính năng như Read API cho OCR tài liệu dài.

• ❌ Host an exported Open Neural Network Exchange (ONNX) model on an on-premises server.
  Sai vì: Computer Vision API không hỗ trợ export trực tiếp thành ONNX model cho OCR (ONNX dùng cho custom ML models như với ONNX Runtime). Bạn chỉ có model riêng lẻ, thiếu endpoint API đầy đủ và tích hợp dịch vụ Azure (như quota, billing). Không phải giải pháp chính thức cho Computer Vision.

• ❌ Build an Azure web app to query the Computer Vision endpoint.
  Sai vì: Azure Web App là dịch vụ public cloud (App Service trên Azure), query endpoint Computer Vision cũng trên cloud. Toàn bộ giải pháp chạy trên public cloud, hoàn toàn vi phạm yêu cầu "NOT be deployed to the public cloud".

🧠 Lưu ý bổ sung: Với kiến thức cập nhật 2026, Azure tiếp tục ưu tiên containers cho on-premises AI (tích hợp Azure Arc cho hybrid), thay vì các hack như ONNX. Nếu cần scale, dùng Azure Stack hoặc AKS on-prem!

🧩 Phân tích nội dung câu hỏi

Câu hỏi yêu cầu chọn mô hình Azure OpenAI phù hợp để xử lý 10.000 file ASCII trong một Azure subscription. Nhiệm vụ cụ thể là xác định các file chứa các cụm từ (phrases) nhất định, và bắt buộc phải sử dụng cosine similarity.

• Chi tiết vấn đề: Đây là bài toán tìm kiếm ngữ nghĩa (semantic search) trên dữ liệu văn bản lớn. Cosine similarity là kỹ thuật đo độ tương đồng vector (góc giữa hai vector embedding), thường dùng để so sánh độ giống nhau giữa các cụm từ tìm kiếm và nội dung file mà không cần khớp chính xác từ khóa.
• Yêu cầu kỹ thuật: Cần một embedding model để chuyển đổi văn bản thành vector số (embeddings), sau đó tính cosine similarity giữa vector của cụm từ tìm kiếm và vector của từng file (hoặc chunk file).
• Ngữ cảnh Azure OpenAI: Azure OpenAI cung cấp các mô hình từ OpenAI, bao gồm embedding models cho vector search và generation models cho chat/completion. (Kiến thức cập nhật đến 2026: text-embedding-ada-002 vẫn là mô hình embedding phổ biến và ổn định nhất cho các workload lớn như thế này, theo Azure OpenAI Service v2+).

📘 Nguồn tham khảo:

• Azure OpenAI Embeddings Documentation (cập nhật 2025).
• OpenAI Embeddings Guide (tích hợp Azure).

✅ Đáp án đúng: text-embedding-ada-002

Lý do chọn:

• Đây là mô hình embedding chuyên dụng của Azure OpenAI (dựa trên OpenAI's ada-002), được thiết kế để tạo vector embeddings 1536 chiều từ văn bản.
• Hoàn hảo cho cosine similarity vì embeddings của nó được tối ưu hóa cho semantic search: bạn embed cụm từ tìm kiếm, embed từng file (hoặc chunk), rồi tính similarity score để lọc file chứa phrases tương tự.
• Hiệu suất cao với 10.000 file: Chi phí thấp, tốc độ nhanh (hàng triệu tokens/giây), phù hợp quy mô lớn mà không cần generation.
• 🛠️ Cách triển khai ví dụ: Sử dụng Azure OpenAI SDK → client.embeddings.create(model="text-embedding-ada-002", input=text) → Tính cosine với thư viện như NumPy/FAISS.

📋 Giải thích tất cả các phương án

• ✅ text-embedding-ada-002
  Đúng vì đây là embedding model duy nhất trong danh sách hỗ trợ cosine similarity trực tiếp. Nó chuyển văn bản thành vector dense, lý tưởng cho tìm kiếm phrases trên file lớn. Không dùng cho generation, chỉ pure embedding. (Vẫn là lựa chọn hàng đầu đến 2026, dù có text-embedding-3 mới hơn cho một số use-case chuyên sâu).

• ❌ GPT-4
  Sai vì GPT-4 là mô hình generation/chat (completion model), chuyên tạo văn bản mới hoặc trả lời câu hỏi, không tạo embeddings. Không hỗ trợ cosine similarity native; nếu dùng, phải hack qua prompt (không hiệu quả, đắt đỏ cho 10k files).

• ❌ GPT-35 Turbo (GPT-3.5 Turbo)
  Sai vì tương tự GPT-4, đây là chat/completion model (gpt-3.5-turbo), tối ưu cho đối thoại nhanh/chí phí thấp. Không có chức năng embedding; dùng cho generation chứ không phải vector search. (Lưu ý: Tên chính xác là gpt-3.5-turbo-instruct hoặc turbo).

• ❌ GPT-4-32k
  Sai vì GPT-4-32k (GPT-4 với context window 32k tokens) là mô hình generation lớn, dùng cho nhiệm vụ phức tạp cần context dài. Không hỗ trợ embedding trực tiếp; tập trung vào reasoning/output text, không phù hợp cosine similarity trên quy mô file lớn (quá tốn kém và chậm).

🧠 Kết luận: Chọn embedding model là chìa khóa cho semantic search với cosine. Nếu cần scale lớn hơn, kết hợp với Azure AI Search hoặc Vector DB như Pinecone! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào dịch vụ Language Understanding (classic) (hay còn gọi là LUIS classic) trên nền tảng Azure Cognitive Services. Tình huống: Bạn đang xây dựng một mô hình ngôn ngữ bằng LUIS classic, đã tạo một Language Understanding (classic) resource mới. Bây giờ, bạn cần thêm các contributor (người đóng góp, có quyền chỉnh sửa mô hình như train, publish).
Mục tiêu chính: Xác định công cụ/cách thức đúng để quản lý quyền truy cập và thêm contributor cho tài nguyên này.
🛠️ Lưu ý quan trọng: LUIS classic phân biệt rõ hai loại tài nguyên:

• Authoring resource: Dùng để tạo, huấn luyện và quản lý mô hình (nơi cần contributor).
• Prediction resource: Chỉ dùng để dự đoán (query) mô hình, không quản lý contributor.
  Kiến thức cập nhật đến năm 2026: LUIS classic vẫn hỗ trợ quản lý quyền qua Azure RBAC (Role-Based Access Control) trên IAM, theo tài liệu Azure mới nhất (Azure AI services v2024+).

📘 Tài liệu tham khảo:

• Manage access to LUIS authoring resources - Azure AI Language
• Azure RBAC for Cognitive Services

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: the Access control (IAM) page for the authoring resources in the Azure portal
Lý do: Trong LUIS classic, contributor (quyền chỉnh sửa mô hình) chỉ được quản lý trên authoring resource qua trang Access control (IAM) trong Azure Portal. Đây là nơi áp dụng Azure RBAC để gán vai trò như Cognitive Services Contributor hoặc Owner, cho phép thêm user/group từ Azure AD. Prediction resource chỉ dùng cho endpoint query, không hỗ trợ contributor cho authoring tasks. ✅ Hoàn hảo cho việc scale team phát triển mô hình!

📋 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá rõ ràng với lý do dựa trên cơ chế Azure IAM và LUIS architecture:

• a conditional access policy in Azure Active Directory (Azure AD)
  ❌ Sai: Conditional Access Policy trong Azure AD dùng để kiểm soát truy cập dựa trên điều kiện (như vị trí, thiết bị, MFA), không phải để thêm contributor cụ thể cho một resource LUIS. Nó là chính sách toàn cục/tenant-level, không granular cho authoring tasks. Sử dụng sai sẽ không giải quyết được việc gán quyền RBAC trực tiếp cho resource.

• the Access control (IAM) page for the authoring resources in the Azure portal
  ✅ Đúng: Như đã giải thích ở trên, đây là nơi chính xác để thêm contributor. Truy cập Azure Portal > Chọn authoring resource > IAM > Add role assignment > Chọn role (ví dụ: Cognitive Services LUIS Contributor) và user/group. Hỗ trợ đầy đủ cho team collaboration trên mô hình ngôn ngữ. 🛠️ Đây là best practice từ docs Azure!

• the Access control (IAM) page for the prediction resources in the Azure portal
  ❌ Sai: Prediction resource chỉ quản lý quyền truy cập endpoint (query predictions), không hỗ trợ contributor cho authoring (train/publish). IAM trên prediction chỉ gán quyền như Reader/Contributor cho inference, không liên quan đến việc chỉnh sửa mô hình. Dùng nhầm sẽ không thêm được người đóng góp thực sự!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Azure AI Search (trước đây gọi là Azure Cognitive Search, cập nhật mới nhất đến năm 2026 theo tài liệu Microsoft). Tình huống: Bạn có một giải pháp Azure AI Search và bộ sưu tập thư viết tay được lưu trữ dưới dạng file JPEG (hình ảnh). Mục tiêu là index bộ sưu tập này để có thể thực hiện truy vấn (query) trên nội dung văn bản bên trong các bức thư.

Để đạt được điều này, bạn cần tạo một indexer kết hợp với skillset (bộ kỹ năng nhận thức - cognitive skills). Skillset là tập hợp các kỹ năng AI được tích hợp vào pipeline xử lý dữ liệu của Azure AI Search, giúp trích xuất và làm giàu dữ liệu từ nguồn đầu vào (ở đây là file JPEG).

Vấn đề cốt lõi: File JPEG chứa hình ảnh thư viết tay, nên cần một skill chuyên biệt để trích xuất văn bản (text) từ hình ảnh trước khi index và query. Đây không phải là xử lý văn bản thuần túy mà là xử lý hình ảnh chứa chữ viết tay (handwritten text).

📘 Tài liệu tham khảo chính:

• Azure AI Search Cognitive Skills - OCR Skill (hỗ trợ extract text từ ảnh, bao gồm handwritten với model mới nhất).
• Azure AI Search Indexer Skills Overview (cập nhật 2025-2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: optical character recognition (OCR)

Lý do: OCR là skill chuyên dụng trong Azure AI Search để trích xuất văn bản từ hình ảnh (image-based text extraction), hỗ trợ cả chữ in (printed text) và chữ viết tay (handwritten text) với độ chính xác cao nhờ tích hợp model AI từ Azure AI Vision (cập nhật mới nhất 2026 sử dụng multimodal models). Trong pipeline indexer, OCR sẽ quét file JPEG, detect vùng text, và output văn bản thuần túy để index và query. Không có OCR, nội dung thư viết tay sẽ không thể query được vì dữ liệu gốc chỉ là pixel hình ảnh, không phải text. 🛠️ Đây là bước đầu tiên bắt buộc trong skillset cho handwritten letters.

📋 Giải thích tất cả các phương án (đúng và sai)

• ❌ image analysis
  Sai vì: Skill "image analysis" (dựa trên Azure AI Vision) tập trung vào phân tích nội dung hình ảnh như phát hiện đối tượng (object detection), mô tả hình ảnh (image captioning), nhận diện khuôn mặt, hoặc tag hình ảnh (visual features). Nó không trích xuất văn bản cụ thể từ ảnh, đặc biệt không dành cho handwritten text. Nếu dùng skill này, bạn chỉ được metadata hình ảnh (ví dụ: "có người viết thư"), chứ không query được nội dung thư.

• ✅ optical character recognition (OCR)
  Đúng vì: Như đã giải thích ở trên, đây là skill cốt lõi để extract text từ JPEG handwritten letters. Nó output text đã normalize (với bounding box, confidence score), sẵn sàng cho các skill tiếp theo như key phrase extraction. Hỗ trợ ngôn ngữ đa dạng và handwritten với model cải tiến 2026 (tích hợp Azure Form Recognizer v4+).

• ❌ key phrase extraction
  Sai vì: Skill này trích xuất cụm từ khóa (key phrases) từ văn bản đã có sẵn (text input), sử dụng model NLP như Azure AI Language. Nó không xử lý hình ảnh JPEG, nên nếu dùng trực tiếp trên file thư viết tay, sẽ thất bại vì input không phải text. Phải dùng sau OCR mới hiệu quả.

• ❌ document extraction
  Sai vì: Không có skill chính thức tên "document extraction" trong Azure AI Search skillset (cập nhật 2026). Có thể nhầm với document cracking (phân tích cấu trúc file PDF/Word) hoặc entity extraction, nhưng chúng không dành cho JPEG handwritten images. Skillset không hỗ trợ extract text từ ảnh thuần túy mà không qua OCR.

🧩 Tóm tắt pipeline khuyến nghị: Source (JPEG) → OCR skill → Text output → Các skill khác (key phrase...) → Index → Query. Điều này đảm bảo giải pháp hoàn chỉnh! Nếu cần code mẫu indexer JSON, hãy hỏi thêm nhé! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc lĩnh vực Azure AI Document Intelligence (trước đây gọi là Azure Form Recognizer), một dịch vụ AI của Microsoft Azure dùng để trích xuất thông tin từ tài liệu quét (scanned documents).

• Yêu cầu cụ thể: Xây dựng ứng dụng App1 để trích xuất các dữ liệu sau từ tài liệu quét:

  • Shipping address (địa chỉ giao hàng)
  • Billing address (địa chỉ thanh toán)
  • Customer ID (mã khách hàng)
  • Amount due (số tiền phải trả)
  • Due date (ngày đến hạn)
  • Total tax (tổng thuế)
  • Subtotal (tổng phụ)

• Mục tiêu chính: Chọn model phù hợp để minimize development effort (giảm thiểu công sức phát triển), nghĩa là ưu tiên model có sẵn (prebuilt) thay vì phải tùy chỉnh hoặc huấn luyện từ đầu.

• Bối cảnh cập nhật 2026: Theo phiên bản mới nhất của Azure AI Document Intelligence (v4.0.0 và các bản cập nhật sau), dịch vụ cung cấp các prebuilt models chuyên biệt cho từng loại tài liệu phổ biến như hóa đơn (invoice), biên nhận (receipt), hợp đồng (contract), giúp trích xuất tự động mà không cần training dữ liệu. 📘 Nguồn tham khảo: Azure AI Document Intelligence - Prebuilt models và Concept - Models.

✅ Đáp án đúng: invoice

Lý do lựa chọn:

• Model prebuilt-invoice được thiết kế chuyên biệt để trích xuất chính xác các trường dữ liệu trong câu hỏi như: Customer ID, Billing Address, Shipping Address, Amount Due, Due Date, Total Tax, Subtotal.
• Nó hỗ trợ cả hóa đơn US/International, giảm thiểu công sức phát triển vì không cần training dữ liệu tùy chỉnh – chỉ cần gọi API là trích xuất ngay.
• Đây là lựa chọn tối ưu để minimize development effort theo yêu cầu. 🛠️ Xác nhận từ tài liệu: Model invoice hỗ trợ >90% các field phổ biến trên hóa đơn thực tế (cập nhật v4.0.0, 2024-2026).

📋 Giải thích tất cả các phương án (đúng/sai)

• invoice ✅
  Đúng vì: Như đã giải thích ở trên, model này khớp hoàn hảo với các field cần trích xuất từ hóa đơn (invoices), hỗ trợ tự động và chính xác cao mà không cần phát triển thêm. Tiết kiệm thời gian nhất!

• custom extraction model ❌
  Sai vì: Đây là model tùy chỉnh (custom), yêu cầu huấn luyện dữ liệu riêng (ít nhất 5 mẫu tài liệu + labeling), tăng công sức phát triển đáng kể. Không phù hợp khi có prebuilt model sẵn như invoice.

• contract ❌
  Sai vì: Model prebuilt-contract chuyên cho hợp đồng (contracts), trích xuất các field như Vendor Name, Customer Name, Contract Amount, nhưng không tối ưu cho invoice fields như Amount Due, Total Tax, Subtotal hay Shipping/Billing Address. Độ chính xác thấp hơn và không minimize effort cho trường hợp này.

• general document ❌
  Sai vì: Model prebuilt-layout (general document) chỉ trích xuất cấu trúc cơ bản như paragraphs, tables, key-value pairs chung chung, không chuyên sâu cho các field invoice cụ thể. Yêu cầu xử lý hậu kỳ nhiều hơn, không giảm thiểu development effort.

Kết luận: Chọn invoice là giải pháp nhanh chóng, hiệu quả nhất! 🚀 Nếu cần code mẫu, tham khảo Quickstart - Analyze invoice.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này tập trung vào quản lý quyền truy cập (Role-Based Access Control - RBAC) trong Azure OpenAI Service, một phần của Azure Cognitive Services. Cụ thể:

• Bạn có một Azure subscription chứa Azure OpenAI resource tên AI1 và một user tên User1.
• Yêu cầu: User1 cần thực hiện các hành động sau trong Azure OpenAI Studio (giao diện web để quản lý và sử dụng OpenAI models):
  • Identify resource endpoints: Xác định các endpoint (địa chỉ API) của resource để kết nối và gọi API.
  • View models that are available for deployment: Xem danh sách các models (như GPT-4, DALL-E) có sẵn để deploy (triển khai).
  • Generate text and images by using the deployed models: Tạo văn bản (text generation) và hình ảnh (image generation) bằng các models đã deploy.
• Nguyên tắc quan trọng: Least privilege (quyền hạn tối thiểu) – chỉ cấp quyền cần thiết, tránh cấp quyền quản lý hoặc chỉnh sửa resource để giảm rủi ro bảo mật. 📘

Mục tiêu là chọn role (vai trò) phù hợp nhất để assign cho User1 tại mức resource scope (Azure OpenAI resource AI1), đảm bảo user chỉ "sử dụng" mà không "quản lý" resource.

Kiến thức cập nhật: Theo tài liệu Azure mới nhất (tính đến 2026), Azure OpenAI sử dụng các built-in roles chuyên biệt cho OpenAI, được tinh chỉnh từ Cognitive Services roles. Không có thay đổi lớn từ 2023-2026.
Nguồn tham khảo:

• Azure OpenAI RBAC Documentation 🛠️
• Azure Built-in Roles for Cognitive Services ✅

✅ Đáp án đúng: Cognitive Services OpenAI User

Lý do lựa chọn (theo nguyên tắc least privilege):
Role này cấp quyền đọc (read) và sử dụng (invoke) chính xác cho các hành động yêu cầu:

• Xem endpoints và keys (Identify resource endpoints).
• Liệt kê models có sẵn (View models available for deployment).
• Gọi API để generate text/images từ deployments (Generate text and images).
  Nó không cho phép deploy mới, xóa, hoặc quản lý resource – hoàn hảo cho end-user. Assign role này tại Azure OpenAI resource scope để User1 truy cập Azure OpenAI Studio mà không cần quyền cao hơn. 🏆

📋 Giải thích tất cả các phương án (đúng/sai)

• ✅ Cognitive Services OpenAI User
  Đúng vì role này được thiết kế dành riêng cho Azure OpenAI end-users. Cấp quyền Microsoft.CognitiveServices/OpenAI/deployments/*/read, Microsoft.CognitiveServices/OpenAI/models/*/read, và Microsoft.CognitiveServices/accounts/listKeys/action để xem endpoints/models và generate content. Tuân thủ least privilege, không cho phép write/delete/deploy. Hoàn thành 100% yêu cầu mà không thừa quyền. 📈

• ❌ Cognitive Services Contributor
  Sai vì role này cấp quyền đầy đủ (full CRUD) cho tất cả Cognitive Services (không chỉ OpenAI), bao gồm tạo/xóa resource, deploy models, quản lý billing. Vi phạm least privilege vì User1 không cần quản lý, chỉ cần sử dụng. Quá rộng và rủi ro cao. 🚫

• ❌ Contributor
  Sai vì đây là RBAC role tổng quát cấp quyền full access trên toàn subscription/resource (tạo, xóa, quản lý VM, storage, etc.). Không chuyên biệt cho OpenAI, User1 có thể làm hỏng resource khác. Vi phạm nghiêm trọng least privilege – như cấp "admin" cho user thường. ⚠️

• ❌ Cognitive Services OpenAI Contributor
  Sai vì role này cấp quyền quản lý đầy đủ cho OpenAI cụ thể (deploy models mới, scale, xóa deployments). User1 chỉ cần "view" và "generate", không cần contribute/manage. Vượt quá least privilege, có thể dẫn đến thay đổi không mong muốn. 🔒

Kết luận: Sử dụng Azure Portal > AI1 resource > Access control (IAM) > Add role assignment > Chọn Cognitive Services OpenAI User cho User1. Kiểm tra bằng Azure OpenAI Studio sau khi assign! 🎯

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc dạng case study trong kỳ thi chứng chỉ Azure (có thể là AZ-400 hoặc AZ-204), nơi mô tả một tình huống thực tế và yêu cầu đánh giá giải pháp có đạt mục tiêu hay không. Tình huống cụ thể:

• Bạn đang quản lý một dịch vụ Azure Cognitive Search (nay được gọi là Azure AI Search theo cập nhật năm 2023-2026).
• Trong 12 tháng qua, khối lượng truy vấn (query volume) tăng dần đều.
• Một số yêu cầu truy vấn tìm kiếm (search query requests) bị throttled (bị giới hạn tốc độ, dẫn đến lỗi HTTP 429 Too Many Requests hoặc trì hoãn).
• Mục tiêu: Giảm khả năng (likelihood) các yêu cầu truy vấn bị throttled.
• Giải pháp đề xuất: Chuyển (migrate) sang dịch vụ Cognitive Search sử dụng tier cao hơn (higher tier, ví dụ từ Basic sang Standard S1/S2/S3 hoặc cao hơn).

🛠️ Lý do vấn đề xảy ra: Azure AI Search giới hạn tài nguyên dựa trên tier hiện tại (như số lượng Search Units - SU, QPS - Queries Per Second). Khi query volume tăng vượt ngưỡng (ví dụ: Basic tier chỉ hỗ trợ ~3 QPS/search replica), hệ thống sẽ throttle để bảo vệ dịch vụ. Giải pháp cần tăng capacity để xử lý tải cao hơn.

📘 Kiến thức cập nhật đến 2026: Theo tài liệu Microsoft mới nhất (Azure AI Search pricing tiers, cập nhật tháng 10/2025), các tier cao hơn cung cấp nhiều SU hơn (Standard S3: lên đến 36 SU/replica), hỗ trợ replicas và partitions scale-out/up, giảm throttling hiệu quả. Không có thay đổi lớn từ 2023 (rename từ Cognitive Search).

Nguồn tham khảo:

• Azure AI Search Limits & Quotas (Microsoft Docs, 2025).
• Pricing Tiers (Azure Pricing Calculator, 2026).
• Throttling Behavior.

✅ Đáp án đúng: Yes

Lý do lựa chọn:

• ✅ Giải pháp migrate to higher tier trực tiếp giải quyết vấn đề bằng cách tăng capacity (nhiều SU, replicas, QPS cao hơn). Ví dụ: Basic (1 SU) → Standard S1 (1-12 SU) → xử lý query volume lớn hơn 10-100 lần mà không throttle.
• ✅ Đây là giải pháp chuẩn theo best practices của Microsoft cho scaling vertical (tăng tier trước khi scale-out replicas).
• ✅ Đạt mục tiêu "reduce the likelihood" vì tier cao giảm xác suất vượt ngưỡng, ngay cả với query volume tăng.

📋 Giải thích tất cả các phương án

• Yes ✅:
  Đúng vì higher tier cung cấp tài nguyên lớn hơn (QPS cao hơn, ví dụ Standard S3 hỗ trợ 20+ QPS/replica so với Basic chỉ 2-3 QPS). Điều này trực tiếp giảm throttling khi query volume tăng. Microsoft khuyến nghị migrate tier cho tải production cao (theo docs 2025). Không cần thay đổi code, chỉ cấu hình Azure portal/CLI.

• No ❌:
  Sai vì giải pháp này hoàn toàn phù hợp và đạt mục tiêu. Không migrate tier sẽ không giải quyết gốc rễ (capacity limit), chỉ tạm thời bằng cách scale replicas (nhưng tier thấp vẫn giới hạn tổng SU). Đây không phải "afterthought" solution như cache hoặc optimize query.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc tích hợp các nguồn dữ liệu đa dạng vào Azure AI Search (trước đây gọi là Azure Cognitive Search) để có thể tìm kiếm toàn bộ dữ liệu thông qua Azure AI Search REST API. Các nguồn dữ liệu bao gồm:

• Finance: Cơ sở dữ liệu Microsoft SQL Server on-premises (chạy cục bộ, không phải trên cloud Azure).
• Sales: Azure Cosmos DB sử dụng Core (SQL) API.
• Logs: Azure Table Storage.
• HR: Azure SQL Database (dịch vụ SQL trên Azure cloud).

Mục tiêu chính: Đảm bảo tất cả dữ liệu từ 4 nguồn này có thể được index (lập chỉ mục) và tìm kiếm thống nhất qua REST API của Azure AI Search. Azure AI Search hỗ trợ indexer (công cụ tự động kéo dữ liệu) cho nhiều nguồn dữ liệu Azure native, nhưng không hỗ trợ trực tiếp cho cơ sở dữ liệu on-premises SQL Server. Do đó, cần xử lý nguồn Finance để đưa dữ liệu vào định dạng/hình thức mà Azure AI Search có thể index (như Blob Storage, Data Lake Storage Gen2, hoặc các nguồn đã hỗ trợ).

🛠️ Kiến thức cập nhật (tính đến 2026): Theo tài liệu Azure AI Search phiên bản mới nhất (v11+), indexer hỗ trợ trực tiếp Azure Cosmos DB (SQL API), Azure Table Storage, Azure SQL Database, và Azure Data Lake Storage Gen2 (hierarchical JSON/CSV). On-premises SQL cần export/migrate sang các kho lưu trữ được hỗ trợ để indexer hoạt động. (Nguồn: Azure AI Search Indexers Overview & Data sources gallery).

✅ Đáp án đúng: Export the data in Finance to Azure Data Lake Storage

Lý do chọn đáp án này:

• Nguồn Finance (on-premises SQL Server) là vấn đề duy nhất không được Azure AI Search hỗ trợ indexer trực tiếp.
• Export sang Azure Data Lake Storage (ADLS Gen2) cho phép indexer của Azure AI Search đọc dữ liệu hierarchical (JSON, CSV, Parquet) một cách hiệu quả, hỗ trợ change detection và incremental indexing.
• Các nguồn còn lại (Sales, Logs, HR) đã hỗ trợ indexer trực tiếp, nên không cần thay đổi. Việc export Finance sẽ hoàn thiện hệ thống tìm kiếm thống nhất qua REST API.
• Đây là giải pháp tối ưu, ít xâm lấn (không cần migrate toàn bộ, chỉ export dữ liệu cần thiết).

📋 Giải thích tất cả các phương án

• ❌ Migrate the data in HR to Azure Blob storage.
  Sai vì: HR đang dùng Azure SQL Database – nguồn này đã hỗ trợ indexer trực tiếp của Azure AI Search (full-text search và change tracking). Việc migrate sang Blob Storage là không cần thiết, tốn kém và làm phức tạp hóa hệ thống mà không giải quyết vấn đề cốt lõi (Finance on-premises).

• ❌ Migrate the data in HR to the on-premises SQL server.
  Sai vì: Di chuyển HR (Azure SQL) sang on-premises SQL Server sẽ làm HR mất hỗ trợ indexer trực tiếp, đồng thời tạo thêm 2 nguồn on-premises cần xử lý. Điều này trái ngược mục tiêu, vì on-premises không được hỗ trợ và làm hệ thống tệ hơn.

• ✅ Export the data in Finance to Azure Data Lake Storage.
  Đúng vì: Như giải thích ở trên, chỉ Finance cần xử lý. ADLS Gen2 là nguồn hỗ trợ indexer mạnh mẽ cho dữ liệu lớn, phân cấp, và tích hợp tốt với Azure AI Search (hỗ trợ skillsets cho AI enrichment). Giải pháp này đảm bảo tất cả dữ liệu có thể search qua REST API mà không ảnh hưởng các nguồn khác.

• ❌ Migrate the data in Sales to the MongoDB API.
  Sai vì: Sales dùng Cosmos DB Core (SQL) API – đã hỗ trợ indexer đầy đủ (query-based indexing). Chuyển sang MongoDB API có thể mất tính tương thích với indexer SQL-based, gây lỗi và không cần thiết. Cosmos DB Mongo API hỗ trợ hạn chế hơn cho Azure AI Search so với SQL API.

📘 Tài liệu tham khảo chính:

• Azure AI Search supported data sources
• Indexer for Azure Data Lake Storage Gen2
• Cosmos DB indexer

Giải pháp này đảm bảo hệ thống tìm kiếm semantic và vector search (tính năng mới 2024-2026) hoạt động mượt mà! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi yêu cầu thiết kế một giao diện hội thoại (conversational interface) cho ứng dụng xử lý yêu cầu nghỉ phép (vacation requests). Giao diện cần thu thập ba thông tin chính:

• Ngày bắt đầu nghỉ phép (start date).
• Ngày kết thúc nghỉ phép (end date).
• Số lượng ngày nghỉ có lương cần thiết (amount of required paid time off).

🛠️ Yêu cầu cốt lõi: Giải pháp phải giảm thiểu độ phức tạp của dialog (minimize dialog complexity). Nghĩa là cần chọn loại dialog đơn giản, dễ quản lý, xử lý các bước thu thập dữ liệu một cách tuyến tính, tránh các luồng phức tạp hoặc phân nhánh không cần thiết.

Câu hỏi này thuộc lĩnh vực Microsoft Bot Framework (không phải AWS thuần túy, dù người dùng đề cập liên quan AWS – có thể là ngữ cảnh so sánh dịch vụ bot như Amazon Lex vs. Azure Bot Service). Bot Framework hỗ trợ các loại dialog để xây dựng chatbot, và đây là kiến thức cập nhật đến phiên bản Bot Framework SDK v4+ (2023-2026), tích hợp với Azure Bot Service và Composer.

✅ Đáp án đúng: waterfall
Lý do chọn: Waterfall dialog là loại dialog tuần tự (sequential) lý tưởng cho việc thu thập dữ liệu theo từng bước một cách đơn giản. Nó sử dụng một chuỗi các bước (waterfall steps), mỗi bước xử lý một phần dữ liệu (ví dụ: hỏi ngày bắt đầu → ngày kết thúc → số ngày nghỉ), kiểm tra và validate ngay lập tức. Điều này giảm thiểu độ phức tạp vì không cần xử lý phân nhánh phức tạp, dễ debug và maintain. Trong Bot Framework, waterfall phù hợp nhất cho các form-filling scenarios như yêu cầu nghỉ phép.
(Nguồn: Microsoft Docs - Waterfall dialogs, cập nhật 2025).

🔍 Giải thích tất cả các phương án (đúng/sai)

• adaptive
  ❌ Sai. Adaptive dialog (dựa trên Adaptive Cards và Expression Language) được thiết kế cho các luồng phức tạp, động với điều kiện phân nhánh, input đa dạng (như form động hoặc decision trees). Nó tăng độ phức tạp vì yêu cầu scripting JSON phức tạp, không phù hợp để minimize dialog cho việc thu thập dữ liệu tuyến tính đơn giản. Phù hợp hơn cho scenarios có nhiều biến số không dự đoán được.

• skill
  ❌ Sai. Skill dialog dùng để gọi các bot con (skills) từ bot chính, như tích hợp Alexa Skills hoặc Virtual Assistant. Nó không tập trung vào thu thập dữ liệu nội bộ mà dành cho mở rộng hệ thống đa bot, dẫn đến độ phức tạp cao hơn (cần authentication, handover). Không minimize dialog cho một app đơn giản như vacation requests.

• waterfall
  ✅ Đúng. Như đã giải thích ở trên: Waterfall xử lý tuần tự các bước thu thập slot/data (start date → end date → PTO amount), với validation tự động và fallback đơn giản. Giảm complexity tối đa bằng cách tránh state management phức tạp. Ví dụ code đơn giản trong C#/JS: AddDialog(new WaterfallDialog("vacation", steps)).

• component
  ❌ Sai. Component dialog là dialog tái sử dụng (reusable) như một "black box" module (ví dụ: dialog xác thực chung). Nó hữu ích cho modular design nhưng vẫn cần orchestrate bên ngoài (thường kết hợp waterfall), không tự minimize complexity cho toàn bộ luồng thu thập dữ liệu tuyến tính. Tăng overhead nếu dùng riêng lẻ.

📘 Tài liệu tham khảo thêm:

• Bot Framework Dialogs Overview (2025).
• So sánh dialogs trong Azure Bot vs. AWS Lex (Lex dùng slots/waterfalls tương tự nhưng Bot Framework explicit hơn).
• Demo code GitHub: BotBuilder-Samples.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần code sample hoặc so sánh với AWS Lex, hãy hỏi thêm nhé!