Ngân hàng đề — Microsoft Azure Developer

Tìm thấy 409 câu.

Câu 371
Case study -

This is a case study. Case studies are not timed separately. You can use as much exam time as you would like to complete each case. However, there may be additional case studies and sections on this exam. You must manage your time to ensure that you are able to complete all questions included on this exam in the time provided.

To answer the questions included in a case study, you will need to reference information that is provided in the case study. Case studies might contain exhibits and other resources that provide more information about the scenario that is described in the case study. Each question is independent of the other questions in this case study.

At the end of this case study, a review screen will appear. This screen allows you to review your answers and to make changes before you move to the next section of the exam. After you begin a new section, you cannot return to this section.


To start the case study -
To display the first question in this case study, click the Next button. Use the buttons in the left pane to explore the content of the case study before you answer the questions. Clicking these buttons displays information such as business requirements, existing environment, and problem statements. When you are ready to answer a question, click the Question button to return to the question.


Background -

Fourth Coffee is a global coffeehouse chain and coffee company recognized as one of the world’s most influential coffee brands. The company is renowned for its specialty coffee beverages, including a wide range of espresso-based drinks, teas, and other beverages. Fourth Coffee operates thousands of stores worldwide.


Current environment -

The company is developing cloud-native applications hosted in Azure.


Corporate website -
The company hosts a public website located at http://www.fourthcoffee.com/. The website is used to place orders as well as view and update inventory items.


Inventory items -
In addition to its core coffee offerings, Fourth Coffee recently expanded its menu to include inventory items such as lunch items, snacks, and merchandise. Corporate team members constantly update inventory. Users can customize items. Corporate team members configure inventory items and associated images on the website.


Orders -
Associates in the store serve customized beverages and items to customers. Orders are placed on the website for pickup.

The application components process data as follows:

1. Azure Traffic Manager routes a user order request to the corporate website hosted in Azure App Service.
2. Azure Content Delivery Network serves static images and content to the user.
3. The user signs in to the application through a Microsoft Entra ID for customers tenant.
4. Users search for items and place an order on the website as item images are pulled from Azure Blob Storage.
5. Item customizations are placed in an Azure Service Bus queue message.
6. Azure Functions processes item customizations and saves the customized items to Azure Cosmos DB.
7. The website saves order details to Azure SQL Database.
8. SQL Database query results are cached in Azure Cache for Redis to improve performance.

The application consists of the following Azure services:




Requirements -

The application components must meet the following requirements:

•Azure Cosmos DB development must use a native API that receives the latest updates and stores data in a document format.
•Costs must be minimized for all Azure services.
•Developers must test Azure Blob Storage integrations locally before deployment to Azure. Testing must support the latest versions of the Azure Storage APIs.


Corporate website -
•User authentication and authorization must allow one-time passcode sign-in methods and social identity providers (Google or Facebook).
•Static web content must be stored closest to end users to reduce network latency.


Inventory items -
•Customized items read from Azure Cosmos DB must maximize throughput while ensuring data is accurate for the current user on the website.
•Processing of inventory item updates must automatically scale and enable updates across an entire Azure Cosmos DB container.
•Inventory items must be processed in the order they were placed in the queue.
•Inventory item images must be stored as JPEG files in their native format to include exchangeable image file format (data) stored with the blob data upon upload of the image file.
•The Inventory Items API must securely access the Azure Cosmos DB data.


Orders -
•Orders must receive inventory item changes automatically after inventory items are updated or saved.


Issues -

•Developers are storing the Azure Cosmos DB credentials in an insecure clear text manner within the Inventory Items API code.
•Production Azure Cache for Redis maintenance has negatively affected application performance.


You need to implement the processing of enqueue inventory items.

Which message value should you use?
  1. A Sequence number
  2. B Timestamp
  3. C Session identifier
  4. D Partition key
Xem giải thích

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

📖 Tóm tắt case study:
Case study mô tả công ty Fourth Coffee đang xây dựng ứng dụng cloud-native trên Azure, với website công khai (fourthcoffee.com) dùng để đặt hàng, xem và cập nhật hàng tồn kho (inventory items như đồ ăn nhẹ, hàng hóa). Ứng dụng sử dụng các dịch vụ Azure như Traffic Manager, CDN, Entra ID (xác thực), Service Bus (queue cho item customizations), Functions (xử lý API Inventory Items), Cosmos DB (lưu inventory), SQL Database (orders), Cache for Redis, và Blob Storage (hình ảnh).

🔄 Luồng xử lý chính (từ mô tả và hình ảnh):
Hình ảnh minh họa kiến trúc rõ ràng:

  • Web Browser → Traffic Manager → Corporate Website (App Service) và CDN (static content).
  • Website kết nối Entra ID (xác thực external identities).
  • User tùy chỉnh items → Azure Service Bus Queue (Inventory Items Queue) nhận message chứa customizations.
  • Azure Functions (Inventory Items API) đọc queue, xử lý và lưu vào Azure Cosmos DB (Inventory Items).
  • Orders lưu vào SQL DB, cache ở Redis, images ở Blob Storage.

🎯 Câu hỏi cụ thể:
"You need to implement the processing of enqueue inventory items. Which message value should you use?"

  • Dịch nghĩa: Bạn cần triển khai xử lý các inventory items đã được enqueue (đưa vào queue). Giá trị message nào nên sử dụng?
  • Ngữ cảnh quan trọng từ Requirements: "Inventory items must be processed in the order they were placed in the queue" (Xử lý items theo đúng thứ tự chúng được đặt vào queue). Đây là yêu cầu FIFO (First-In-First-Out) cho các items liên quan, thường dùng cho customizations từ cùng user/session (ví dụ: nhiều tùy chỉnh liên tiếp từ một order).
  • Vấn đề liên quan: Developers lưu credentials Cosmos DB không an toàn, và Redis maintenance ảnh hưởng performance, nhưng câu hỏi tập trung vào Service Bus Queue processing.

🛠️ Phiên bản mới nhất (đến 2026): Azure Service Bus hỗ trợ Sessions (từ phiên bản Standard/Premium) để đảm bảo ordered delivery trong cùng session. Không có thay đổi lớn ở AZ-204 exam đến 2026, vẫn ưu tiên Sessions cho ordered processing queues.

✅ Đáp án đúng: Session identifier

Lý do chọn (chi tiết):

  • Trong Azure Service Bus, để xử lý messages theo đúng thứ tự enqueue (ordered processing), phải kích hoạt Sessions trên queue. Mỗi message cần gắn Session identifier (SessionId) để nhóm các messages liên quan (ví dụ: tất cả customizations từ cùng user/session/order).
  • Service Bus đảm bảo messages trong cùng SessionId được xử lý tuần tự (sequentially) theo SequenceNumber nội bộ, lock session cho receiver duy nhất, tránh out-of-order.
  • Phù hợp hoàn hảo: Customizations từ website (per user) cần order chính xác, tránh mất dữ liệu inventory. Không dùng Sessions thì queue chỉ FIFO cơ bản, không group được.
  • Từ hình ảnh: Queue "Inventory Items Queue" → Functions API → Cosmos DB, cần order để "maximize throughput while ensuring data is accurate for the current user".

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

  • ❌ Sequence number
    Sai vì SequenceNumber là thuộc tính tự động của mỗi message (toàn cục, tăng dần), dùng để theo dõi chứ không dùng để group hoặc enable ordered processing. Không thể set thủ công khi enqueue, và không đảm bảo FIFO per group (chỉ per queue nếu không partition). Không giải quyết yêu cầu order theo "they were placed".

  • ❌ Timestamp
    Sai vì Timestamp (EnqueuedTimeUtc/ScheduledEnqueueTimeUtc) chỉ ghi thời gian enqueue, không đảm bảo thứ tự xử lý. Có thể duplicate timestamp, network delay gây out-of-order, hoặc multi-receiver cạnh tranh. Không hỗ trợ Sessions/FIFO grouping.

  • ✅ Session identifier
    Đúng như giải thích trên: Giá trị chính để enable Sessions, group messages (ví dụ: SessionId = userId/orderId), xử lý ordered theo SequenceNumber trong session. Tối ưu cho throughput cao, scale tự động, phù hợp Cosmos DB container updates.

  • ❌ Partition key
    Sai vì PartitionKey dùng cho Service Bus Topics/Subscriptions partitioned (không phải Queues), hoặc Cosmos DB partitioning. Trong Queues, không liên quan đến ordering; chỉ phân tán messages, có thể phá vỡ thứ tự toàn cục. Không dùng cho "process in the order placed".

📘 Tài liệu tham khảo

💡 Lời khuyên: Khi implement, set message.SessionId = userSessionId lúc enqueue từ website, enable RequiresSession = true trên queue. Test local với Azurite hoặc Storage Emulator (hỗ trợ latest APIs như yêu cầu).

Câu 372
You have an Azure Service Bus namespace with a partitioned queue named queue1.

You plan to send a large number of messages through queue1 over the next few weeks. The order of messages will be random. You must minimize the possibility of message transmission interruption by transient failures of individual partitions.

You need to use the optimal configuration of the partition key in the messages.

Which configuration should you use?
  1. A Set the partition key of messages to the message ID value.
  2. B Enable sessions. Set the partition key of messages to the session ID value.
  3. C Enable sessions. Ensure that the partition key is different from the session ID value.
  4. D Leave the partition key value as null.
Xem giải thích

🧩 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 xoay quanh việc cấu hình partition key tối ưu cho một Azure Service Bus namespace chứa partitioned queue có tên queue1. Bạn dự định gửi số lượng lớn messages qua queue này trong vài tuần tới, với thứ tự messages ngẫu nhiên. Mục tiêu là giảm thiểu tối đa khả năng gián đoạn truyền messages do lỗi tạm thời (transient failures) của các partition riêng lẻ.

  • Partitioned queue trong Azure Service Bus tự động phân phối messages qua nhiều messaging store partitions (mặc định 16 partitions ở Standard tier, nhiều hơn ở Premium) để tăng throughput, availability và resiliency.
  • Partition key quyết định messages có cùng key sẽ được gửi đến cùng một partition (đảm bảo thứ tự xử lý), nhưng nếu key giống nhau cho nhiều messages, sẽ tập trung traffic vào một partition → dễ bị gián đoạn nếu partition đó fail tạm thời.
  • Với số lượng lớn messages và thứ tự ngẫu nhiên, cần phân phối messages đều qua tất cả partitions để một partition fail chỉ ảnh hưởng phần nhỏ messages, giảm thiểu gián đoạn tổng thể.
    ✅ Yêu cầu chính: Chọn cấu hình partition key giúp phân phối đều nhất, không tập trung vào ít partitions.

✅ Đáp án đúng:
Leave the partition key value as null.
Lý do chọn (chi tiết):
Khi partition key = null (hoặc empty), Azure Service Bus tự động sử dụng hash của MessageId làm cơ sở phân vùng messages. Điều này đảm bảo phân phối đều qua tất cả partitions nếu MessageId có tính ngẫu nhiên tốt (random algorithmic). Với large volume messages và random order, cách này tối ưu nhất để minimize interruption từ transient partition failures, vì lỗi một partition chỉ ảnh hưởng ~1/16 (hoặc ít hơn) traffic. Không cần sessions vì không yêu cầu ordered processing theo group. Đây là best practice theo docs mới nhất (2024-2026, áp dụng cho Standard/Premium tiers).
🛠️ Lợi ích: Tăng resiliency cao nhất, throughput tối đa mà không cần can thiệp thủ công.

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

  • Set the partition key of messages to the message ID value.
    ❌ Sai. Phương án này gần giống null (vì hash(PartitionKey = MessageId) tương đương hash(MessageId) khi null), nhưng không optimal vì: (1) Thêm overhead set key không cần thiết; (2) Nếu MessageId không hoàn toàn random (ví dụ duplicate hoặc pattern), phân phối có thể không đều bằng null tự động; (3) Docs recommend leave null cho random distribution để tránh confusion và tận dụng hash built-in. Không giảm thiểu gián đoạn tốt hơn null.

  • Enable sessions. Set the partition key of messages to the session ID value.
    ❌ Sai. Sessions dùng cho ordered processing theo group (messages cùng SessionId được lock và process sequential trong cùng partition). Set PartitionKey = SessionId là bắt buộc cho sessions (per docs), nhưng với random order và large volume, sẽ tập trung messages theo session groups → nhiều messages/group có thể overload một vài partitions → tăng rủi ro gián đoạn nếu partition fail. Không phù hợp khi không cần ordering.

  • Enable sessions. Ensure that the partition key is different from the session ID value.
    ❌ Sai nghiêm trọng. Sessions yêu cầu PartitionKey PHẢI BẰNG SessionId để messages của session ở cùng partition (enforced by Service Bus). Nếu khác, messages sẽ không group đúng, dẫn đến loss of session semantics, unordered processing, và có thể fail validation hoặc phân phối không mong muốn. Thêm sessions không cần thiết làm phức tạp, tăng rủi ro gián đoạn với random order.

  • Leave the partition key value as null.
    ✅ Đúng (như đã giải thích ở trên). Phân phối đều tự động, resiliency cao nhất cho scenario.

📘 Tài liệu tham khảo (cập nhật mới nhất 2024-2026)

🛠️ Lời khuyên từ Azure Developer: Trong production, luôn test với Azure Service Bus Explorer hoặc SDK (.NET/Java/Python) để verify distribution. Sử dụng MessageId GUID random để tối ưu hash!

Câu 373
You manage an Azure Cosmos DB for a NoSQL API account named account1. The account contains a database named db1, which contains a container named container1. You configure account1 with a session consistency level.

You plan to develop an application named App1 that will access container1. Individual instances of App1 must perform reads and writes. App1 must allow multiple nodes to participate in the same session.

You need to configure an object to share the session token between the nodes.

Which object should you use?
  1. A Document response
  2. B Request options
  3. C Feed options
  4. D Connection policy
Xem giải thích

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

Câu hỏi tập trung vào Azure Cosmos DB for NoSQL API, một dịch vụ cơ sở dữ liệu NoSQL đa mô hình của Microsoft Azure. Bạn đang quản lý tài khoản account1 với cơ sở dữ liệu db1 và container container1, được cấu hình ở mức session consistency (tính nhất quán phiên).

Ứng dụng App1 sẽ truy cập container1, hỗ trợ đọc và ghi từ các instance riêng lẻ, và cho phép nhiều nodes (nút) tham gia cùng một session. Vấn đề chính: Cần cấu hình một object để chia sẻ session token giữa các nodes, đảm bảo tính nhất quán session (các reads sau commit của writes trước đó trong cùng session, nhưng có thể khác nhau giữa các session).

Mục tiêu: Xác định object phù hợp để truyền session token (một chuỗi token từ response của request trước) đến các request tiếp theo trên nhiều nodes, giúp duy trì session consistency mà không cần multi-master replication phức tạp. Điều này dựa trên SDK của Azure Cosmos DB (phiên bản mới nhất đến 2026, như .NET SDK v3.x hoặc tương đương, hỗ trợ ItemRequestOptions hoặc QueryRequestOptions cho session token).

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

✅ Đáp án đúng: Request options

Lý do lựa chọn:

  • Trong Azure Cosmos DB SDK (NoSQL API), Request options (cụ thể là RequestOptions.SessionToken hoặc ItemRequestOptions.SessionToken trong SDK mới nhất) là object chính để chèn session token vào các request đọc/ghi.
  • Nó cho phép chia sẻ token giữa các nodes bằng cách extract token từ response trước (qua headers) và set vào options cho request sau.
  • Điều này đảm bảo tất cả nodes trong cùng session thấy cùng view dữ liệu, phù hợp với yêu cầu "multiple nodes participate in the same session". Không cần thay đổi connection policy, chỉ per-request. 🛠️ Hoàn hảo cho App1!

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

  • ❌ Document response
    Sai vì: Document response chỉ chứa session token trong headers (như x-session-token) sau một request thành công, dùng để trích xuất token chứ không phải object để cấu hình chia sẻ. Bạn phải lấy token từ response rồi truyền thủ công sang object khác (như Request options). Không hỗ trợ trực tiếp multi-node sharing mà không code thêm.

  • ✅ Request options (Đã giải thích ở trên – đúng và lý tưởng).

  • ❌ Feed options
    Sai vì: Feed options (nay là QueryRequestOptions hoặc FeedIteratorOptions trong SDK mới) dùng cho query feed (như đọc nhiều items qua continuation token), tập trung vào pagination (MaxItemCount, ResponseContinuationToken). Nó không hỗ trợ session token trực tiếp cho session consistency giữa reads/writes trên multi-nodes. Chỉ phù hợp query lớn, không phải chia sẻ session.

  • ❌ Connection policy
    Sai vì: Connection policy cấu hình ở mức client connection (như ConnectionMode, RetryInterval), ảnh hưởng toàn bộ kết nối đến Cosmos DB endpoint. Nó không xử lý session token per-request/session, nên không chia sẻ được giữa nodes trong cùng session. Dùng cho global settings, không linh hoạt cho App1.

🧠 Lưu ý bổ sung: Với SDK 2026 (v3.5x+), ưu tiên CosmosClient với ItemRequestOptions để set SessionToken. Test trên emulator để verify! Nếu cần code sample, tham khảo GitHub Azure SDK repo.

Câu 374 Chọn nhiều đáp án
You are developing several microservices to deploy to a new Azure Kubernetes Service cluster. The microservices manage data stored in Azure Cosmos DB and Azure Blob storage. The data is secured by using customer-managed keys stored in Azure Key Vault.

You must automate key rotation for all Azure Key Vault keys and allow for manual key rotation. Keys must rotate every three months. Notifications of expiring keys must be sent before key expiry.

You need to configure key rotation and enable key expiry notifications.

Which two actions should you perform? Each correct answer presents part of the solution.

NOTE: Each correct selection is worth one point.
  1. A Create and configure a new Azure Event Grid instance.
  2. B Configure Azure Key Vault alerts.
  3. C Create and assign an Azure Key Vault access policy.
  4. D Create and configure a key rotation policy during key creation.
Xem giải thích

🧩 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 mô tả tình huống bạn đang phát triển nhiều microservices triển khai trên Azure Kubernetes Service (AKS) cluster mới. Các microservices quản lý dữ liệu lưu trữ trong Azure Cosmos DB và Azure Blob Storage, với dữ liệu được bảo mật bằng customer-managed keys (CMKs) lưu trữ trong Azure Key Vault.

Yêu cầu chính:

  • Tự động hóa xoay khóa (key rotation) cho tất cả khóa trong Azure Key Vault.
  • Hỗ trợ xoay khóa thủ công.
  • Khóa phải xoay mỗi 3 tháng.
  • Gửi thông báo về khóa sắp hết hạn trước khi hết hạn.

Nhiệm vụ: Cấu hình key rotation và thông báo hết hạn khóa. Đây là câu hỏi chọn nhiều đáp án đúng (mỗi đáp án đúng chiếm 1 điểm), cần chọn hai hành động phù hợp.

🎯 Đáp án đúng:
Hai lựa chọn đúng là:
✅ Create and configure a new Azure Event Grid instance.
✅ Create and configure a key rotation policy during key creation.

Lý do chọn đáp án đúng (theo tài liệu Azure mới nhất đến 2026):

  • Azure Key Vault hỗ trợ Key Rotation Policies (tính năng ra mắt từ 2021 và cập nhật liên tục đến phiên bản 2024-2026), cho phép tự động xoay khóa định kỳ (ví dụ: mỗi 3 tháng), hỗ trợ xoay thủ công, và áp dụng lúc tạo khóa.
  • Azure Event Grid dùng để subscribe sự kiện KeyNearExpiry hoặc KeyExpired từ Key Vault, tự động gửi thông báo (qua email, webhook, hoặc Logic Apps) trước khi khóa hết hạn. Đây là cách chuẩn để enable notifications.
    (Nguồn: Azure Key Vault Key Rotation và Key Vault Events with Event Grid, cập nhật tháng 10/2024).

🛠️ Giải thích chi tiết từng phương án

Dưới đây là phân tích tất cả các phương án (giữ nguyên văn bản gốc tiếng Anh). Mỗi phương án được đánh giá đúng/sai kèm lý do cụ thể bằng tiếng Việt:

  • ✅ Create and configure a new Azure Event Grid instance.
    Đúng! Phương án này cần thiết để kích hoạt thông báo hết hạn khóa. Azure Event Grid cho phép subscribe các sự kiện từ Key Vault như Microsoft.KeyVault.KeyNearExpiry (gửi trước 30 ngày) hoặc tùy chỉnh thời gian. Bạn tạo Event Grid topic, liên kết với Key Vault, rồi định tuyến thông báo đến endpoint (như Azure Monitor, email). Không có Event Grid, không thể tự động notify trước expiry.

  • ❌ Configure Azure Key Vault alerts.
    Sai! Azure Key Vault không hỗ trợ alerts trực tiếp cho key expiry theo cách yêu cầu (tự động rotation + notify). Alerts trong Key Vault chủ yếu dùng cho vault-level metrics (như CPU, access denied) qua Azure Monitor, không phải key-specific events. Để notify key expiry, phải dùng Event Grid thay vì alerts thuần túy.

  • ❌ Create and assign an Azure Key Vault access policy.
    Sai! Access policy chỉ dùng để quản lý quyền truy cập (RBAC hoặc policy-based) vào Key Vault (ví dụ: cho phép app đọc/giấy phép khóa). Nó không liên quan đến rotation tự động hay thông báo expiry. Rotation policy và Event Grid độc lập với access policy.

  • ✅ Create and configure a key rotation policy during key creation.
    Đúng! Đây là bước cốt lõi cho tự động hóa rotation. Khi tạo khóa trong Key Vault, bạn attach rotation policy với lịch trình (hành động mỗi 3 tháng), hỗ trợ manual trigger, và thời gian gần expiry để notify. Policy này áp dụng cho CMKs dùng trong Cosmos DB/Blob, đảm bảo xoay khóa an toàn mà không gián đoạn dịch vụ.

💡 Lưu ý bổ sung:

  • Giải pháp đầy đủ: Tạo key với rotation policy → Enable Event Grid subscription cho events → Test rotation thủ công.
  • Không vi phạm best practices Azure (zero-downtime rotation cho services).
    (Tài liệu tham khảo chính: Azure Key Vault Rotation Best Practices và Event Grid Key Vault Integration, phiên bản cập nhật 2025).
Câu 375
You develop an ASP. Net Core application by integrating the Application Insights SDK into your solution.

The application sends a very high rate of telemetry in a short time interval. You observe a reduced number of events, traces, and metrics being recorded and increased error rates for telemetry ingestion.

You need to reduce telemetry traffic, data costs, and storage costs while preserving a statistically correct analysis of application telemetry data. Your solution must ensure that you will be able to correlate HTTP request and response data.

What should you do?
  1. A Configure a Log Analytics workspace data collection rule (DCR). Use a Kusto Query Language (KQL) statement to filter incoming data.
  2. B Disable adaptive sampling. Enable and configure the fixed-rate sampling module.
  3. C Set a daily cap on the Log Analytics workspace. Create an Activity log alert rule.
  4. D Configure the TelemetryConfiguration object in the instrumented code. Increase the metric aggregation interval to 15 minutes.
Xem giải thích

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

📖 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả tình huống bạn đang phát triển một ứng dụng ASP.NET Core và tích hợp Application Insights SDK (một phần của Azure Monitor). Ứng dụng gửi lượng telemetry (dữ liệu theo dõi như events, traces, metrics) rất cao trong khoảng thời gian ngắn, dẫn đến:

  • Số lượng events, traces, metrics được ghi nhận giảm (do throttling hoặc quota).
  • Tỷ lệ lỗi ingestion (tiếp nhận dữ liệu) tăng cao.

🎯 Mục tiêu giải quyết:

  • Giảm lưu lượng telemetry, chi phí dữ liệu và lưu trữ.
  • Giữ nguyên phân tích thống kê chính xác (statistically correct analysis).
  • Đảm bảo khả năng correlate (liên kết) dữ liệu HTTP request và response (ví dụ: trace request với dependencies).

Vấn đề cốt lõi là sampling (lấy mẫu dữ liệu): Cần một cơ chế lấy mẫu thông minh để giữ tỷ lệ đại diện thống kê và duy trì correlation giữa các item telemetry liên quan (như request ID).

✅ Đáp án đúng:
Disable adaptive sampling. Enable and configure the fixed-rate sampling module.

🛠️ Lý do chọn đáp án này (dựa trên phiên bản Azure Monitor/Application Insights mới nhất 2024-2026):

  • Adaptive sampling tự động điều chỉnh tỷ lệ lấy mẫu dựa trên volume dữ liệu, nhưng nó không đảm bảo tỷ lệ cố định, dẫn đến phân tích thống kê không ổn định (ví dụ: một số request bị drop ngẫu nhiên, mất correlation).
  • Fixed-rate sampling (tỷ lệ lấy mẫu cố định, ví dụ 50%) áp dụng nhất quán trên toàn bộ telemetry stream, bao gồm requests, dependencies, traces → giữ nguyên correlation qua operation ID.
  • Giảm volume dữ liệu lên đến 90% mà vẫn statistically correct (dữ liệu đại diện đúng tỷ lệ thực tế).
  • Cấu hình qua TelemetryConfiguration.SetSamplingPercentage() hoặc module riêng, hiệu quả ngay từ SDK client-side, giảm costs ingestion/storage.
    (Nguồn: Azure Monitor docs - Sampling in Application Insights - Cập nhật 2024, vẫn áp dụng đến 2026).

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

  • ❌ [SAI] Configure a Log Analytics workspace data collection rule (DCR). Use a Kusto Query Language (KQL) statement to filter incoming data.
    Phương án này dùng DCR (data collection rules) ở Log Analytics workspace để filter dữ liệu bằng KQL trước khi lưu trữ. Tuy nhiên:

    • Filter diễn ra sau ingestion (dữ liệu đã gửi đến Azure rồi mới filter), nên không giảm traffic ban đầu → vẫn tốn costs ingestion và gặp lỗi throttling.
    • KQL phức tạp cho real-time filtering, không đảm bảo statistically correct (có thể drop dữ liệu không ngẫu nhiên).
    • Không giữ correlation HTTP vì filter có thể drop dependencies riêng lẻ.
      (Không khuyến nghị cho high-volume telemetry; Nguồn: DCR docs).

  • ✅ [ĐÚNG] Disable adaptive sampling. Enable and configure the fixed-rate sampling module.
    (Đã giải thích chi tiết ở trên – Đây là giải pháp chuẩn của Microsoft cho vấn đề này).

  • ❌ [SAI] Set a daily cap on the Log Analytics workspace. Create an Activity log alert rule.
    Daily cap giới hạn tổng volume dữ liệu/ngày ở workspace, kết hợp alert qua Activity log. Vấn đề:

    • Chỉ ngăn chặn khi vượt quota, không giảm traffic real-time → vẫn lỗi ingestion cao.
    • Drop dữ liệu đột ngột khi đạt cap, làm phân tích không statistically correct (mất dữ liệu cuối ngày).
    • Không hỗ trợ correlation vì drop toàn bộ sau ingestion.
      (Nguồn: Log Analytics quota docs).

  • ❌ [SAI] Configure the TelemetryConfiguration object in the instrumented code. Increase the metric aggregation interval to 15 minutes.
    Tăng aggregation interval metrics lên 15 phút qua TelemetryConfiguration. Hạn chế:

    • Chỉ ảnh hưởng metrics (không giảm events/traces cao).
    • Aggregation làm mất granularity (chi tiết thời gian), không giải quyết high-rate telemetry tổng thể.
    • Không đảm bảo statistically correct analysis cho traces/events, và correlation HTTP vẫn bị ảnh hưởng nếu volume cao.
      (Phù hợp bổ sung, nhưng không phải giải pháp chính; Nguồn: Telemetry config docs).

🔍 Kết luận & Lời khuyên:
Sử dụng fixed-rate sampling là best practice cho ASP.NET Core với Application Insights (phiên bản SDK 2.21+). Test ở dev với SamplingPercentage = 10-50%. Theo dõi qua Azure Portal → Application Insights → Failures/Performance để verify correlation. (Tài liệu tổng hợp: Application Insights best practices).

Câu 376
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.

After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear on the review screen.

You are developing an application that needs to react to events from multiple Azure services, such as Azure Blob Storage and Azure Resource Manager, in near-real time.

The application must meet the following requirements:

•Handle a high volume of events without manual intervention.
•Receive only specific events relevant to your application, based on event types or resource patterns.
•Ensure that no events are missed, even if the processing application is temporarily unavailable.
•Use Azure Functions for processing events without managing any infrastructure.
•Minimize the amount of custom code required for event routing and handling.

You need to develop the solution.

Solution: Deploy an Azure Service Bus namespace. Configure the Azure services to send events to the Service Bus. Implement Azure Functions with Service Bus triggers to process the events. Use Service Bus sessions and message deferral to manage event ordering and reliability.

Does the solution meet the goal?
  1. A Yes
  2. B No
Xem giải thích

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

Câu hỏi thuộc dạng case study (phân tích tình huống) trong kỳ thi chứng chỉ Azure, nơi bạn phải đánh giá xem giải pháp đề xuất có đáp ứng đầy đủ các yêu cầu kinh doanh hay không. Tình huống cụ thể:
Bạn đang phát triển một ứng dụng cần phản ứng gần thời gian thực (near-real time) với các sự kiện (events) từ nhiều dịch vụ Azure như Azure Blob Storage và Azure Resource Manager (ARM).

Các yêu cầu chính (requirements) phải được đáp ứng:

  • 📈 Xử lý khối lượng sự kiện lớn mà không cần can thiệp thủ công.
  • 🔍 Chỉ nhận sự kiện cụ thể liên quan, dựa trên loại sự kiện (event types) hoặc mẫu tài nguyên (resource patterns).
  • ✅ Không bỏ lỡ bất kỳ sự kiện nào, ngay cả khi ứng dụng xử lý tạm thời không khả dụng.
  • 🛠️ Sử dụng Azure Functions để xử lý sự kiện mà không quản lý hạ tầng.
  • 💻 Giảm thiểu mã tùy chỉnh cho việc định tuyến (routing) và xử lý sự kiện.

Giải pháp đề xuất (Solution):
Triển khai Azure Service Bus namespace. Cấu hình các dịch vụ Azure gửi sự kiện đến Service Bus. Triển khai Azure Functions với Service Bus triggers để xử lý. Sử dụng Service Bus sessions và message deferral để quản lý thứ tự và độ tin cậy của sự kiện.

Câu hỏi: Giải pháp này có đáp ứng mục tiêu (meet the goal) không?

(Lưu ý: Đây là câu hỏi một chiều, không quay lại được sau khi trả lời, theo phong cách kỳ thi thực tế của Microsoft.)

✅ Đáp án đúng: No

Lý do lựa chọn:
Giải pháp sử dụng Azure Service Bus không đáp ứng đầy đủ các yêu cầu, đặc biệt là:

  • 🛑 Các dịch vụ Azure như Blob Storage và ARM không hỗ trợ gửi sự kiện trực tiếp (natively) đến Service Bus. Chúng chủ yếu publish events qua Azure Event Grid (hoặc Event Hubs/Storage Queues), đòi hỏi mã tùy chỉnh để forward events – vi phạm yêu cầu "minimize custom code" và "Azure services to send events".
  • ⏱️ Service Bus phù hợp cho messaging đáng tin cậy (queues/topics), nhưng không phải lựa chọn tối ưu cho near-real time events từ nhiều nguồn Azure, thiếu filtering tự động dựa trên event types/patterns mà không code thêm.
  • 🔄 Sessions/deferral giúp ordering/reliability, nhưng phức tạp hóa code và không đảm bảo "no events missed" một cách native như Event Grid (với dead-lettering và retry tự động).
  • 🛠️ Azure Functions với Service Bus triggers là serverless OK, nhưng tổng thể giải pháp không "handle high volume without manual intervention" hiệu quả bằng Event Grid + Functions triggers.

Giải pháp đúng nên là: Sử dụng Azure Event Grid làm event router trung tâm (hỗ trợ >100 sources như Blob/ARM), với Event Grid triggers trên Functions, filtering topics/domains, và dead-letter storage để không miss events. Điều này minimize code và meet tất cả reqs (cập nhật đến 2026: Event Grid v2 với improved reliability và schema registry).

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

  • Yes ❌ SAI: Phương án này sai vì giải pháp Service Bus không native hỗ trợ events từ Blob Storage/ARM (cần custom forwarder), tăng code tùy chỉnh và không optimize cho near-real time filtering/reliability từ multiple Azure services. Service Bus mạnh về ordered messaging nhưng không phải "eventing hub" chuẩn của Azure – dẫn đến vi phạm nhiều reqs như minimize code và no-miss events mà không manual setup.

  • No ✅ ĐÚNG: Phương án này đúng vì như phân tích trên, Service Bus không meet the goal toàn diện. Event Grid mới là dịch vụ lý tưởng cho scenario này (push model, fan-out, filtering built-in), tích hợp seamless với Functions mà không infra management.

📘 Tài liệu tham khảo (cập nhật mới nhất 2026)

Hy vọng phân tích giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm case study Azure, hỏi nhé!

Câu 377 Chọn nhiều đáp án
You are developing a web application that uses the Microsoft identity platform to authenticate users and resources. The web application calls several REST APIs.

The APIs require an access token from the Microsoft identity platform.

You need to request a token.

Which three properties should you use? Each correct answer presents part of the solution.

NOTE: Each correct selection is worth one point.
  1. A Redirect URI/URL
  2. B Application ID
  3. C Application name
  4. D Application secret
  5. E Supported account type
Xem giải thích

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

Câu hỏi này thuộc chủ đề Microsoft identity platform (trước đây gọi là Azure Active Directory - Azure AD, nay là Entra ID), không liên quan trực tiếp đến AWS như mô tả ban đầu (có thể là nhầm lẫn). Nội dung tập trung vào việc phát triển một web application sử dụng nền tảng xác thực của Microsoft để xác thực người dùng (users) và tài nguyên (resources). Ứng dụng này cần gọi nhiều REST APIs yêu cầu access token từ Microsoft identity platform.

Chi tiết quy trình:

  • Web app là confidential client (ứng dụng bảo mật, như web server-side), thường sử dụng Authorization Code Flow với PKCE hoặc Client Credentials Flow để lấy token.
  • Để request access token, bạn phải cung cấp các thông tin xác thực cơ bản từ App Registration trong Azure portal (Entra ID).
  • Câu hỏi yêu cầu chọn ba thuộc tính (properties) cần thiết để thực hiện request token. Đây là câu multi-select (mỗi lựa chọn đúng đáng 1 điểm).

Bối cảnh kỹ thuật (cập nhật đến 2026): Theo tài liệu Microsoft mới nhất (MSAL.js/MSAL.NET v2.x, Entra ID), khi sử dụng thư viện MSAL (Microsoft Authentication Library) hoặc gọi trực tiếp /token endpoint (OAuth 2.0/OpenID Connect), các thuộc tính chính bao gồm client_id, client_secret (cho confidential clients), và redirect_uri để hoàn tất flow authorization code.

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

✅ Đáp án đúng (3 lựa chọn)

Các thuộc tính bắt buộc để request token trong web app confidential client là:

  • Redirect URI/URL ✅
  • Application ID ✅ (hay còn gọi là Client ID)
  • Application secret ✅ (Client Secret)

Lý do lựa chọn:

  • Trong Authorization Code Flow (phù hợp cho web app authenticate users), bạn cần redirect_uri để Microsoft identity platform redirect code về app sau khi user login. Application ID (client_id) xác định app, và Application secret (client_secret) chứng minh quyền sở hữu app (confidential client). Không có 3 cái này, request token sẽ thất bại (lỗi invalid_client hoặc redirect_uri_mismatch).
  • Đây là tiêu chuẩn OAuth 2.0 của Microsoft (RFC 6749), áp dụng cho cả MSAL và direct HTTP POST đến /token endpoint.

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

  • Redirect URI/URL ✅
    Đúng: Đây là địa chỉ callback mà Microsoft identity platform sử dụng để gửi authorization code sau khi user xác thực. Phải khớp chính xác với cấu hình trong App Registration (Azure portal > Authentication > Redirect URIs). Thiếu nó, flow sẽ lỗi invalid_request hoặc redirect_uri_mismatch. Bắt buộc trong Authorization Code Flow.

  • Application ID ✅
    Đúng: Còn gọi là Client ID (ứng dụng ID URI), là định danh duy nhất của app trong Entra ID. Dùng làm client_id trong mọi token request (POST đến /token). Không có nó, Microsoft không biết app nào đang request token.

  • Application name ❌
    Sai: Tên ứng dụng (Display Name) chỉ dùng cho mục đích hiển thị trong Azure portal hoặc consent screen, không tham gia vào token request. Nó không phải tham số OAuth, chỉ là metadata. Sử dụng sẽ gây lỗi invalid_client.

  • Application secret ✅
    Đúng: Là Client Secret (hoặc certificate/private key), dùng để chứng thực app trong token exchange (code-to-token). Bắt buộc cho confidential clients như web apps (public clients như SPA không cần). Lưu ý: Secret phải được tạo và gia hạn định kỳ qua Azure portal.

  • Supported account type ❌
    Sai: Đây là tùy chọn cấu hình trong App Registration (Accounts in this org / multi-tenant / personal Microsoft), quyết định phạm vi xác thực (single-tenant hay multi-tenant). Nó ảnh hưởng đến audience claim trong token nhưng không phải tham số trực tiếp trong request token. Chỉ là setting metadata, không gửi trong /token call.

Lưu ý cuối: Để implement thực tế, dùng MSAL library (ví dụ: ConfidentialClientApplication trong .NET) với các params này. Test qua Azure Token Playground. Nếu dùng Client Credentials Flow (không user), vẫn cần Application ID + Secret (không redirect_uri). 🚀

Câu 378
Note: This question is part of a series of questions that present the same scenario. Each question in the series contains a unique solution that might meet the stated goals. Some question sets might have more than one correct solution, while others might not have a correct solution.

After you answer a question in this section, you will NOT be able to return to it. As a result, these questions will not appear on the review screen.

You are developing an application that needs to react to events from multiple Azure services, such as Azure Blob Storage and Azure Resource Manager, in near-real time.

The application must meet the following requirements:

•Handle a high volume of events without manual intervention.
•Receive only specific events relevant to your application, based on event types or resource patterns.
•Ensure that no events are missed, even if the processing application is temporarily unavailable.
•Use Azure Functions for processing events without managing any infrastructure.
•Minimize the amount of custom code required for event routing and handling.

You need to develop the solution.

Solution: Set up Azure Event Hubs to receive events from the Azure services. Develop a custom application using Azure Functions with Event Hub triggers to process the events. Implement custom filtering logic within the functions to select relevant events.

Does the solution meet the goal?
  1. A Yes
  2. B No
Xem giải thích

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

Câu hỏi thuộc dạng case study trong kỳ thi chứng chỉ AWS (có lẽ là AWS Certified Developer Associate hoặc tương tự, nhưng thực tế nội dung tập trung vào Azure services như Azure Blob Storage, Azure Resource Manager, Azure Functions, và Azure Event Hubs). Đây là phần câu hỏi liên quan đến một tình huống phát triển ứng dụng cần xử lý sự kiện (events) từ nhiều dịch vụ Azure khác nhau theo thời gian thực gần (near-real time).

Yêu cầu chính của ứng dụng (goals):

  • Xử lý lượng sự kiện lớn mà không cần can thiệp thủ công (high volume, no manual intervention) 🛡️️.
  • Chỉ nhận sự kiện cụ thể liên quan, dựa trên loại sự kiện (event types) hoặc mẫu tài nguyên (resource patterns) 🔍.
  • Đảm bảo không bỏ lỡ bất kỳ sự kiện nào, ngay cả khi ứng dụng xử lý tạm thời không khả dụng 📥.
  • Sử dụng Azure Functions để xử lý mà không quản lý hạ tầng (serverless) ☁️.
  • Giảm thiểu tối đa mã code tùy chỉnh cho việc định tuyến và xử lý sự kiện (minimize custom code) 💻.

Giải pháp được đề xuất (Solution):

  • Thiết lập Azure Event Hubs để nhận sự kiện từ các dịch vụ Azure.
  • Phát triển ứng dụng tùy chỉnh bằng Azure Functions với trigger từ Event Hubs.
  • Triển khai logic lọc tùy chỉnh bên trong Functions để chọn sự kiện phù hợp.

Câu hỏi chính: Giải pháp này có đáp ứng được mục tiêu không? (Does the solution meet the goal?)
(Lưu ý: Đây là câu hỏi kiểu "Yes/No" trong series, không thể quay lại sau khi trả lời).

✅ Đáp án đúng: No

Lý do lựa chọn đáp án đúng (bằng kiến thức Azure cập nhật đến 2026):
Giải pháp KHÔNG đáp ứng đầy đủ các yêu cầu vì Azure Event Hubs không phải là dịch vụ tối ưu cho việc nhận sự kiện từ các dịch vụ Azure Fabric như Blob Storage hay Resource Manager. Event Hubs dành cho streaming dữ liệu cao throughput (như telemetry, logs), nhưng để tích hợp native với Azure events cần setup phức tạp (custom publishers).

Thay vào đó, Azure Event Grid (phiên bản mới nhất 2026 hỗ trợ Event Grid Schema Registry, Domains, Topics với advanced filtering và hybrid events) mới là lựa chọn chuẩn:

  • Tích hợp trực tiếp với Blob Storage (BlobCreated events) và ARM (resource changes).
  • Built-in filtering theo event types/subject patterns, giảm custom code 👌.
  • At-least-once delivery với dead-letter queues, retry policies tự động → không miss events ngay cả khi Functions down.
  • Event Grid Triggers cho Functions: serverless, zero infra, minimize code (chỉ cần bind topic).

Event Hubs yêu cầu custom filtering trong Functions (vi phạm minimize code), và custom ingestion từ Azure services (không near-real time native, dễ miss nếu publisher fail). Theo docs Azure 2026, Event Grid là recommended cho "reactive apps to Azure events".

Dẫn nguồn tham khảo:

🔍 Giải thích tất cả các phương án (giữ nguyên văn bản gốc bằng tiếng Anh)

  • Yes ❌ SAI
    Phương án này sai vì giải pháp sử dụng Event Hubs không đáp ứng các yêu cầu cốt lõi. Cụ thể:

    • Không có tích hợp native với Blob Storage/ARM → cần custom code để push events vào Event Hubs (tăng code, không minimize).
    • Custom filtering trong Functions làm phức tạp hóa, không tận dụng built-in filters.
    • Dễ miss events nếu Functions unavailable (Event Hubs checkpoints yêu cầu custom consumer groups, không tự động như Event Grid).
    • Không "near-real time" mượt mà cho Azure events, và vi phạm high volume without manual intervention (cần scale manually partitions).

  • No ✅ ĐÚNG
    Phương án này đúng vì giải pháp KHÔNG meet the goal như phân tích trên. Giải pháp đúng phải dùng Azure Event Grid với:

    • Topics/Domains để subscribe events từ Blob/ARM.
    • Event subscriptions với filters (type, subject, data fields).
    • Azure Functions Event Grid trigger → serverless, retry/dead-letter tự động, no custom code for routing.
    • Đảm bảo 99.99% availability, no miss events (updated SLA 2026). 🛠️
Câu 379
A large retail company operates online and physical stores. The company tracks inventory levels in real time to manage stock efficiently across all locations. You develop an Azure Event Grid solution to handle events generated by the inventory management system deployed to Azure.

You need to implement a subscription filter that dynamically adjusts to seasonal changes in product demand.

Which event filter should you use?
  1. A An advanced filter using a Boolean condition that evaluates multiple data fields, including a season field within the event data
  2. B A prefix filter on the event type field that matches the current season's name
  3. C A subscription filter that uses label filter to include events tagged with seasonal promotional codes
  4. D A static subject filter that targets events with a subject ending in “/seasonal/inventory”
Xem giải thích

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

Câu hỏi mô tả một công ty bán lẻ lớn hoạt động cả trực tuyến và cửa hàng vật lý, theo dõi mức tồn kho thời gian thực để quản lý hàng hóa hiệu quả trên tất cả các địa điểm. Bạn đang phát triển giải pháp Azure Event Grid để xử lý các sự kiện từ hệ thống quản lý tồn kho được triển khai trên Azure.

📌 Yêu cầu chính: Triển khai một subscription filter (bộ lọc đăng ký) có khả năng điều chỉnh động (dynamically adjusts) theo sự thay đổi nhu cầu sản phẩm theo mùa (seasonal changes in product demand).

🛠️ Bối cảnh kỹ thuật: Azure Event Grid cho phép lọc sự kiện tại thời điểm đăng ký (subscription level) để chỉ nhận các sự kiện phù hợp. Các bộ lọc cần linh hoạt để xử lý dữ liệu mùa vụ, chẳng hạn như tăng/giảm tồn kho dựa trên mùa (ví dụ: mùa hè, Giáng sinh), mà không cần thay đổi cấu hình thủ công thường xuyên. Kiến thức cập nhật đến năm 2026: Azure Event Grid hỗ trợ Advanced Filters (bộ lọc nâng cao) từ phiên bản 2021 và được cải tiến thêm với hỗ trợ boolean logic phức tạp hơn trong Event Grid Schema v2020-04-01-preview (vẫn là chuẩn mới nhất).

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

Đáp án đúng: An advanced filter using a Boolean condition that evaluates multiple data fields, including a season field within the event data

Lý do:
🧠 Bộ lọc Advanced Filter (bộ lọc nâng cao) của Azure Event Grid cho phép sử dụng Boolean conditions (điều kiện logic AND/OR/NOT) để đánh giá nhiều trường dữ liệu (data fields) trong payload của sự kiện, bao gồm trường tùy chỉnh như "season" (mùa vụ). Điều này động (dynamic) vì có thể điều chỉnh logic lọc dựa trên giá trị mùa vụ thực tế trong event data (ví dụ: if season == "summer" AND demand > threshold), tự động thích ứng với thay đổi theo mùa mà không cần chỉnh sửa subscription thủ công. Đây là giải pháp linh hoạt nhất theo tài liệu chính thức AWS... à không, Azure (lưu ý: câu hỏi thuộc Azure, không phải AWS).

📘 Nguồn tham khảo:

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

  • An advanced filter using a Boolean condition that evaluates multiple data fields, including a season field within the event data
    ✅ Đúng 🏆: Như đã giải thích, advanced filter hỗ trợ boolean logic trên nhiều data fields (string, number, bool, arrays), lý tưởng cho việc lọc động dựa trên trường "season" trong event data. Ví dụ: data.season eq 'winter' and data.demand gt 100. Linh hoạt cao, không giới hạn ở subject/eventType.

  • A prefix filter on the event type field that matches the current season's name
    ❌ Sai 🚫: Prefix filter chỉ áp dụng cho eventType (bắt đầu bằng prefix, ví dụ: "inventory.season.summer."), là bộ lọc cơ bản (simple filter), không động vì phải thay đổi prefix thủ công khi mùa thay đổi (ví dụ: từ "summer" sang "winter"). Không hỗ trợ đánh giá data fields phức tạp.

  • A subscription filter that uses label filter to include events tagged with seasonal promotional codes
    ❌ Sai ⚠️: Label filter dùng để tách biệt routing (multi-tenant), lọc dựa trên labels (tags) trong metadata, không phải filter chính cho data fields. Không dynamic cho seasonal changes vì labels phải được gán thủ công lúc publish event, và không hỗ trợ boolean trên multiple fields. Phù hợp hơn cho phân loại promotion, không phải inventory demand.

  • A static subject filter that targets events with a subject ending in “/seasonal/inventory”
    ❌ Sai 🔒: Subject filter (ends with, begins with, equal to) là static (cố định), chỉ lọc đường dẫn subject (ví dụ: "/inventory/seasonal/inventory"). Không động vì không thể thay đổi theo mùa (luôn fixed "/seasonal/inventory"), bỏ lỡ các sự kiện khác nếu subject thay đổi theo mùa thực tế.

Tóm tắt nhanh 🎯: Chỉ advanced filter mới đáp ứng yêu cầu "dynamically adjusts" nhờ boolean trên data fields. Các phương án khác đều static hoặc hạn chế! Nếu triển khai, dùng Azure Portal/CLI để config advanced filter cho subscription.

Câu 380
You have an Azure subscription that contains an Application Insights resource named AI1 and an Azure App Service web app named App1.

You create a Standard availability test in AI1. You set its URL to point to App1.

You need to ensure that any failed tests generate email notifications to the owners of the subscription.

What should you do?
  1. A Create an action group.
  2. B Create an alert rule.
  3. C Enable the test.
  4. D Enable the alert.
Xem giải thích

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

Câu hỏi mô tả một tình huống trong Microsoft Azure, cụ thể là với tài nguyên Application Insights (AI1) và Azure App Service web app (App1) trong một Azure subscription. Bạn đã tạo một Standard availability test (kiểm tra tính sẵn sàng tiêu chuẩn, đa vị trí) trong AI1, với URL trỏ đến App1.

Mục tiêu: Đảm bảo rằng bất kỳ test thất bại nào (failed tests) cũng tự động gửi email thông báo đến các owners (chủ sở hữu) của subscription.

🛠️ Chi tiết kỹ thuật:

  • Standard availability test là loại kiểm tra ping HTTP/HTTPS từ nhiều vị trí địa lý toàn cầu (lên đến 10 vị trí mặc định), đo lường tính sẵn sàng (availability), thời gian phản hồi (response time), và phát hiện lỗi test.
  • Test này tạo ra các metrics trong Azure Monitor như "Availability", "Test Duration", "Test Failed" (số test thất bại).
  • Để gửi email notifications cho failed tests đến subscription owners, cần sử dụng Azure Monitor Alerts kết hợp Action Groups. Action Groups định nghĩa hành động gửi email (hỗ trợ gửi đến Azure RBAC roles như Owner, Contributor).
  • Kiến thức cập nhật đến 2026 (Azure Monitor phiên bản mới nhất): Không có thay đổi lớn, availability tests vẫn yêu cầu cấu hình thủ công alert rules và action groups (không tự động gửi email). Tính năng "Email to subscription owners" qua Action Group > "Email Azure Resource Manager role".

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

✅ Đáp án đúng: Create an action group

Lý do lựa chọn: Action Group là thành phần cốt lõi để thực hiện các hành động thông báo (như gửi email) khi alert được kích hoạt từ failed tests. Trong Azure Monitor, availability test chỉ tạo metrics, nhưng để gửi email cụ thể đến owners của subscription, bạn phải tạo Action Group với hành động "Email Azure Resource Manager role (owners, contributors, readers)". Sau đó, liên kết Action Group này với alert rule của test (alert rule có thể được tạo riêng hoặc dựa trên metric sẵn có). Đây là bước bắt buộc và trực tiếp giải quyết yêu cầu "generate email notifications to the owners". Không có Action Group, alert chỉ log mà không notify.

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

  • Create an action group. ✅
    Đúng vì Action Group định nghĩa hành động gửi email đến subscription owners qua RBAC roles (Owner). Availability test đã tạo metrics (như "Test Failed > 0"), chỉ cần Action Group để trigger email khi failed. Bước này hoàn tất cấu hình notify mà không cần thay đổi test khác. (Phiên bản 2026: Hỗ trợ thêm ITSM connectors nhưng email role-based vẫn chuẩn).

  • Create an alert rule. ❌
    Sai vì chỉ tạo alert rule (dựa trên metric "Availability < 95%" hoặc "Test Failed") sẽ chỉ kích hoạt trạng thái alert (log/firing), nhưng không gửi email nếu thiếu Action Group. Alert rule cần Action Group để thực hiện notify đến owners. Đây là bước hỗ trợ nhưng không đủ cho yêu cầu email.

  • Enable the test. ❌
    Sai vì test đã được tạo (implied enabled sau create), và "Enable the test" chỉ kích hoạt chạy test (từ Disabled sang Enabled). Không liên quan đến notifications – test chạy rồi vẫn cần alert + action để gửi email khi failed.

  • Enable the alert. ❌
    Sai vì không có alert mặc định cần "enable" cho Standard availability test (test chỉ tạo metrics, không auto tạo/enable alert rule). "Enable the alert" giả định alert tồn tại nhưng ở đây chưa có, và dù enable cũng thiếu Action Group để gửi email đến owners.

🛡️ Lưu ý từ Azure Developer: Trong thực tế triển khai, quy trình đầy đủ là: Tạo Action Group → Tạo Alert Rule → Assign Action Group vào rule. Nhưng câu hỏi tập trung vào "email notifications", nên Action Group là đáp án chính xác nhất theo logic exam (AZ-204/AZ-305). Test ngay trên portal để verify!