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

Tìm thấy 409 câu.

Câu 21 Microsoft Graph
Which of the following statements describes the type of data that can be retrieved using Microsoft Graph?
  1. A Document data, such as JSON or XML
  2. B All of the data contained in Microsoft 365, including documents, calendar, email, Teams, and people.
  3. C Columnar data, such as a spreadsheet or relational data table
  4. D All of your Azure resources and resource groups, including deployment history and activity logs
Xem giải thích

Đáp án

B — Toàn bộ dữ liệu trong Microsoft 365, gồm tài liệu, lịch, email, Teams và thông tin người dùng.

Vì sao đúng

⚠ Microsoft Graph là API HỢP NHẤT cho toàn bộ hệ sinh thái Microsoft 365:

⚠ https://graph.microsoft.com/v1.0/me
⚠ https://graph.microsoft.com/v1.0/me/messages
⚠ https://graph.microsoft.com/v1.0/me/events
⚠ https://graph.microsoft.com/v1.0/me/drive
        ↓
⚠ MỘT endpoint, MỘT cơ chế xác thực
⚠ cho MỌI dịch vụ Microsoft 365
Truy cập được Nội dung
⚠ Người dùng và nhóm ⚠ Entra ID
⚠ Email và lịch ⚠ Exchange
⚠ Tệp và thư mục ⚠ OneDrive, SharePoint
⚠ Chat, kênh, cuộc họp ⚠ Teams
⚠ Thiết bị và chính sách ⚠ Intune
⚠ Thông tin bảo mật ⚠ Defender

Vì sao các phương án khác sai

  • D (mọi tài nguyên Azure và nhật ký hoạt động) — ⚠ bẫy đáng chú ý: ⚠ đó là ⚠ Azure Resource Manager API, ⚠ một API hoàn toàn khác.

  • A (dữ liệu tài liệu như JSON, XML) và C (dữ liệu dạng cột) — ⚠ mô tả LOẠI DỮ LIỆU, ⚠ không phải phạm vi của Graph.

Ghi nhớ

⚠ Hai API lớn của Microsoft — đừng lẫn: | API | Phạm vi | |---|---| | ⚠ Microsoft Graph | ⚠ dữ liệu Microsoft 365: người, email, tệp, Teams | | ⚠ Azure Resource Manager | ⚠ tài nguyên Azure: VM, storage, network | | ⚠ Điểm chung | ⚠ cùng dùng Entra ID để xác thực | | ⚠ Nhầm lẫn | ⚠ rất phổ biến vì cả hai đều là "API của Microsoft" |

Từ khoá nhận diện:

"email, lịch, Teams, OneDrive" → ⚠ Microsoft Graph "máy ảo, storage, resource group" → ⚠ ARM API "người dùng và nhóm" → ⚠ Graph (Entra ID) "nhật ký hoạt động Azure" → ⚠ ARM / Azure Monitor

⚠ Xác thực với Microsoft Graph Cách
⚠ Đăng ký ứng dụng trong Entra ID
⚠ Xin quyền (scope) phù hợp
⚠ Hai loại quyền ⚠ delegated (thay mặt người dùng) và application (chạy nền)
⚠ Quyền application cần admin consent
⚠ Nguyên tắc ⚠ xin quyền TỐI THIỂU — Graph có rất nhiều scope
⚠ Delegated và Application permission Phân biệt
⚠ Delegated: hành động THAY MẶT người dùng đang đăng nhập ⚠ giới hạn bởi quyền của chính họ
⚠ Application: chạy NỀN, không có người dùng ⚠ quyền rộng hơn nhiều, nguy hiểm hơn
⚠ Ví dụ ⚠ Mail.Read delegated đọc mail của người đó; application đọc mail của MỌI người
⚠ Rất cẩn thận ⚠ với quyền application
⚠ Graph Explorer — công cụ hữu ích Nội dung
⚠ Thử API ngay trên trình duyệt
⚠ Xem quyền cần thiết cho từng endpoint
⚠ Sinh mã mẫu nhiều ngôn ngữ
⚠ Nên dùng ⚠ trước khi viết dòng mã đầu tiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần dữ liệu Microsoft 365 hay tài nguyên Azure | ⚠ quyết định API | | Quyền là delegated hay application | ⚠ ảnh hưởng phạm vi rất lớn | | Có xin quyền rộng hơn mức cần không | |

Và điều cần cân nhắc kỹ nhất khi tích hợp với Microsoft Graph: quyền kiểu application cho ứng dụng truy cập dữ liệu của TOÀN BỘ tổ chức, không chỉ của người đang dùng. Một scope xin thừa ở đó là một rủi ro rất lớn.

Câu 22 Azure Container Registry
If your Azure solution relies on third-party public images, some risks are added to your process. Microsoft recommends keeping a private copy of public images and deploying from there, instead of deploying directly from public image locations like DockerHub. Which CLI command is able to copy a public image into Azure Container Registry?
  1. A docker compose
  2. B az acr import
  3. C git clone
  4. D az acr copy
Xem giải thích

Đáp án

B — az acr import

Vì sao đúng

⚠ az acr import sao chép ảnh từ registry khác vào ACR của bạn:

⚠ az acr import \
⚠   --name myacr \
⚠   --source docker.io/library/nginx:latest \
⚠   --image nginx:latest
        ↓
⚠ Sao chép TRỰC TIẾP giữa hai registry
⚠ KHÔNG qua máy của bạn
⚠ KHÔNG cần Docker cài sẵn
Vì sao Microsoft khuyến nghị giữ bản sao riêng Lý do
⚠ Ảnh công khai có thể bị XOÁ hoặc ĐỔI
⚠ Docker Hub có giới hạn số lần kéo ⚠ rate limit
⚠ Triển khai không phụ thuộc mạng ngoài
⚠ Quét lỗ hổng trên bản của mình
⚠ Biết chắc ảnh đang chạy là ảnh nào

Vì sao các phương án khác sai

  • D (az acr copy) — ⚠ KHÔNG tồn tại lệnh này.

  • A (docker compose) — ⚠ chạy nhiều container cùng lúc, không sao chép ảnh.

  • C (git clone) — ⚠ sao chép kho MÃ NGUỒN, không liên quan tới ảnh container.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh chùm bốn câu về ACR trong lô.

Câu Hỏi gì Khoá
⚠ #21410 ⚠ az acr build ⚠ build trên đám mây rồi đẩy
⚠ #21417 ⚠ đẩy ảnh cục bộ lên ⚠ tag đầy đủ rồi push
⚠ #21420 ⚠ kéo ảnh trong namespace ⚠ registry/namespace/tên
⚠ #21425 (câu này) ⚠ sao chép ảnh công khai vào ACR ⚠ az acr import
⚠ Bốn câu ⚠ vẽ trọn vòng đời ảnh container trên Azure

⚠ Ba lệnh ACR — bảng chốt: | Lệnh | Việc | |---|---| | ⚠ az acr build | ⚠ build từ mã nguồn TRÊN đám mây | | ⚠ az acr import | ⚠ sao chép ảnh từ registry khác | | ⚠ docker push | ⚠ đẩy ảnh đã build cục bộ |

Từ khoá nhận diện:

"sao chép ảnh công khai vào registry riêng" → ⚠ az acr import "build từ Dockerfile trên đám mây" → ⚠ az acr build "đẩy ảnh từ máy mình" → ⚠ docker push "kéo ảnh về" → ⚠ docker pull

⚠ Vì sao phụ thuộc ảnh công khai là rủi ro Rủi ro
⚠ Ảnh bị xoá khỏi Docker Hub ⚠ đã xảy ra trong thực tế
⚠ Thẻ latest đổi nội dung bất ngờ
⚠ Giới hạn số lần kéo làm triển khai thất bại
⚠ Ảnh bị chèn mã độc ⚠ tấn công chuỗi cung ứng
⚠ Giữ bản sao riêng ⚠ loại bỏ gần hết các rủi ro trên
⚠ Quy trình chuẩn cho ảnh bên thứ ba Quy trình
⚠ Import vào ACR riêng
⚠ Quét lỗ hổng ⚠ Defender for Containers
⚠ Gắn thẻ phiên bản CỤ THỂ, không dùng latest
⚠ Triển khai TỪ ACR của mình
⚠ Định kỳ import bản mới và quét lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có triển khai thẳng từ Docker Hub không | ⚠ rủi ro chuỗi cung ứng | | Ảnh có được quét lỗ hổng không | | | Có dùng thẻ latest trong môi trường thật không | |

Và rủi ro chuỗi cung ứng cụ thể nhất trong thế giới container, đã xảy ra nhiều lần trong thực tế: một ảnh công khai bạn đang phụ thuộc bị xoá hoặc bị thay đổi nội dung. Giữ bản sao trong registry của mình là cách phòng ngừa rẻ nhất.

Câu 23 Azure App Service
What is the Azure CLI command to download application log files to the local disk?
  1. A az log download
  2. B az webapp log
  3. C az webapp log tail
  4. D az webapp log download
Xem giải thích

Đáp án

D — az webapp log download

Vì sao đúng

⚠ Nhóm lệnh az webapp log có bốn lệnh con, mỗi lệnh một việc: | Lệnh | Việc | |---|---| | ⚠ az webapp log download | ⚠ TẢI log về đĩa dưới dạng ZIP | | ⚠ az webapp log tail | ⚠ xem log TRỰC TIẾP theo dòng chảy | | ⚠ az webapp log config | ⚠ bật tắt và cấu hình mức log | | ⚠ az webapp log show | ⚠ xem cấu hình log hiện tại |

⚠ az webapp log download \
⚠   --name myapp \
⚠   --resource-group myrg \
⚠   --log-file logs.zip

Vì sao các phương án khác sai

  • C (az webapp log tail) — ⚠ bẫy gần nhất: ⚠ nó ⚠ hiển thị log theo thời gian thực trên terminal, ⚠ không tải tệp về.

  • B (az webapp log) — ⚠ thiếu lệnh con, không chạy được.

  • A (az log download) — ⚠ không tồn tại nhóm lệnh này.

Ghi nhớ

⚠ Ba cách xem log của App Service: | Cách | Dùng khi | |---|---| | ⚠ log tail | ⚠ gỡ lỗi TRỰC TIẾP, xem ngay | | ⚠ log download | ⚠ phân tích sau, gửi cho người khác | | ⚠ Log stream trên Portal | ⚠ giống tail nhưng trên trình duyệt | | ⚠ Application Insights | ⚠ giám sát dài hạn, truy vấn KQL |

Từ khoá nhận diện:

"tải về đĩa" → ⚠ log download "xem trực tiếp, theo dòng" → ⚠ log tail "bật ghi log" → ⚠ log config "truy vấn log lịch sử" → ⚠ Application Insights

⚠ Bật ghi log trước khi có log để xem Bước
⚠ az webapp log config --application-logging filesystem
⚠ Đặt mức: error, warning, information, verbose
⚠ Ghi ra file system chỉ giữ được 12 GIỜ ⚠ điểm rất hay bị quên
⚠ Muốn giữ lâu phải ghi ra BLOB
⚠ Triệu chứng ⚠ hôm sau vào xem thì log đã biến mất
⚠ Vì sao nên dùng Application Insights Lý do
⚠ Giữ log lâu dài, truy vấn được
⚠ Gắn log với request cụ thể ⚠ distributed tracing
⚠ Cảnh báo tự động khi có lỗi
⚠ Xem hiệu năng, phụ thuộc, ngoại lệ
⚠ log tail chỉ nên dùng ⚠ để gỡ lỗi tại chỗ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ghi log đã bật chưa | ⚠ mặc định TẮT | | Log ghi ra file system hay blob | ⚠ file system chỉ giữ 12 giờ | | Đã nối Application Insights chưa | |

Và điều gây bối rối nhất khi lần đầu gỡ lỗi App Service: log không có gì vì ghi log chưa được bật, hoặc đã bị xoá sau 12 giờ. Ghi ra blob hoặc Application Insights là cách duy nhất giữ được log lâu dài.

Câu 24 Non-Relational DB

You are developing an application that interacts with Azure Cosmos DB using the .NET SDK. You want to retrieve a specific item from a container based on its unique identifier. Which of the following methods should you use to achieve this?

  1. A

    ReadItemAsync<T>(string id, PartitionKey partitionKey)
  2. B

    QueryItemsAsync<T>(string query, QueryRequestOptions requestOptions)
  3. C

    GetItemQueryIterator<T>(string query)
  4. D

    GetItemAsync<T>(string id, PartitionKey partitionKey)
Xem giải thích

Đáp án

A — ReadItemAsync<T>(string id, PartitionKey partitionKey)

Vì sao đúng

Khi bạn biết cả id lẫn partition key, ReadItemAsync là cách rẻ nhất và nhanh nhất: nó là thao tác đọc theo điểm (point read), đi thẳng tới đúng bản ghi mà không cần công cụ truy vấn tham gia.

Khác biệt về chi phí rất đáng kể: một point read tốn khoảng 1 RU cho tài liệu 1 KB, trong khi truy vấn cùng bản ghi bằng SQL tốn nhiều hơn hẳn — và đây là loại tối ưu quan trọng nhất khi làm việc với Cosmos DB, vì hoá đơn tính theo RU.

Vì sao các phương án khác sai

  • C. GetItemQueryIterator<T> — phương thức có thật và dùng để chạy truy vấn SQL; nhưng khi đã biết id thì dùng nó là lãng phí RU.
  • D. GetItemAsync<T> — tên nghe rất hợp lý nhưng không tồn tại trong .NET SDK. Đây là bẫy chính của câu.
  • B. QueryItemsAsync<T> — cũng không phải tên phương thức có thật.
Câu 25 Managed Identity
Your company has several applications running on Azure App Services - App1, App2, App3 and App4. Each application is configured to use a system-managed identity to access resources. Your applications all store their secrets in a KeyVault named KV1. You are finding it difficult to manage the permissions for all these applications, and would like to move to a single managed identity for all applications instead of each application having their own. What action do you take to implement that?
  1. A Change the applications to the same user-managed identity
  2. B Change the applications to the same system-managed identity
  3. C Create one user in Azure Active Directory for all applications, and have the applications use that
  4. D Create one user in Azure Active Directory for each application, and have the applications use that
Xem giải thích

Đáp án

A — Đổi các ứng dụng sang dùng CHUNG một user-assigned managed identity.

Vì sao đúng

⚠ Hai loại managed identity khác nhau ở chỗ VÒNG ĐỜI và KHẢ NĂNG DÙNG CHUNG: | Loại | Đặc điểm | |---|---| | ⚠ System-assigned | ⚠ gắn CHẶT với MỘT tài nguyên, xoá tài nguyên là xoá luôn | | ⚠ User-assigned | ⚠ tài nguyên ĐỘC LẬP, gán cho NHIỀU tài nguyên |

⚠ Trước: 4 system identity
   ⚠ → 4 lần cấp quyền trên Key Vault
   ⚠ → thêm app thứ 5 lại phải cấp lại
        ↓
⚠ Sau: 1 user-assigned identity dùng chung
   ⚠ → cấp quyền MỘT lần
   ⚠ → app mới chỉ cần gán identity đó

Vì sao các phương án khác sai

  • B (dùng chung một system-assigned identity) — ⚠ BẤT KHẢ THI: ⚠ system-assigned identity ⚠ luôn thuộc về đúng một tài nguyên, không chia sẻ được.

  • C và D (tạo user trong Entra ID cho ứng dụng dùng) — ⚠ quay lại thời phải quản lý MẬT KHẨU; ⚠ đó chính là thứ managed identity sinh ra để xoá bỏ.

Ghi nhớ

⚠ System-assigned và User-assigned — bảng chọn: | Tiêu chí | System-assigned | User-assigned | |---|---|---| | ⚠ Vòng đời | ⚠ theo tài nguyên | ⚠ độc lập | | ⚠ Dùng chung | ⚠ KHÔNG | ⚠ CÓ, nhiều tài nguyên | | ⚠ Cấp quyền | ⚠ mỗi tài nguyên một lần | ⚠ một lần cho cả nhóm | | ⚠ Xoá tài nguyên | ⚠ identity mất theo | ⚠ identity còn | | ⚠ Chọn user-assigned khi | ⚠ nhiều tài nguyên cần CÙNG bộ quyền |

Từ khoá nhận diện:

"nhiều ứng dụng cùng bộ quyền" → ⚠ user-assigned "một tài nguyên duy nhất, đơn giản" → ⚠ system-assigned "không muốn quản lý mật khẩu" → ⚠ managed identity nói chung "tạo user cho ứng dụng" → ⚠ cách cũ, nên tránh

⚠ Vì sao managed identity tốt hơn service principal Lý do
⚠ KHÔNG có bí mật để lưu hay luân chuyển
⚠ Azure tự quản lý vòng đời thông tin đăng nhập
⚠ Không có gì để lộ trong mã nguồn
⚠ Cấp quyền bằng RBAC như người dùng thường
⚠ Đây là ⚠ cách xác thực được khuyến nghị trên Azure
⚠ Lưu ý khi có NHIỀU user-assigned identity trên một tài nguyên Lưu ý
⚠ Gán được nhiều identity cho một VM hay App Service
⚠ Nhưng khi lấy token phải CHỈ RÕ dùng identity nào ⚠ client id
⚠ Không chỉ rõ sẽ gặp lỗi mơ hồ
⚠ Đơn giản nhất ⚠ mỗi tài nguyên chỉ gán một identity

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhiều ứng dụng có cùng bộ quyền không | ⚠ thì gộp về user-assigned | | Còn ứng dụng nào dùng mật khẩu hay khoá không | | | Có tài nguyên nào gán nhiều identity không | |

Và lợi ích thực tế lớn nhất của user-assigned identity, chỉ thấy rõ khi hệ thống lớn dần: thêm ứng dụng thứ mười không cần cấp quyền lần thứ mười — chỉ cần gán đúng identity đã có sẵn.

Câu 26 Access Control

You are developing an Azure web application that requires user authentication. You decide to use Microsoft Entra ID for authentication purposes. Which of the following approaches should you use to implement user authentication in your application?

  1. A

    Use the Microsoft Entra External ID service (formerly Azure AD B2C) to create a custom policy for user authentication.
  2. B

    Use the Microsoft Graph API to directly validate user credentials at runtime.
  3. C

    Configure the application to use Microsoft Entra ID as an identity provider through OpenID Connect or OAuth 2.0.
  4. D

    Implement a self-hosted OpenID Connect provider for user authentication.
Xem giải thích

Đáp án

C — Cấu hình ứng dụng dùng Microsoft Entra ID làm nhà cung cấp danh tính

Vì sao đúng

Đây là cách tiêu chuẩn: ứng dụng được đăng ký trong Entra ID, rồi dùng OpenID Connect để chuyển người dùng sang trang đăng nhập của Microsoft. Ứng dụng không bao giờ nhìn thấy mật khẩu — nó chỉ nhận về token đã ký và kiểm tra token đó.

Nhờ vậy ứng dụng tự động hưởng mọi thứ Entra ID cung cấp: xác thực đa yếu tố, truy cập theo điều kiện, đăng nhập một lần, và phát hiện đăng nhập rủi ro.

Vì sao các phương án khác sai

  • B. Dùng Microsoft Graph API để tự kiểm tra thông tin đăng nhập — không làm được và không nên làm: ứng dụng sẽ phải nhận mật khẩu của người dùng, đúng thứ mà mô hình liên kết danh tính sinh ra để tránh.
  • D. Tự dựng một OpenID Connect provider — tự viết hạ tầng xác thực là việc rủi ro cao và hoàn toàn thừa.
  • A. Entra External ID (Azure AD B2C) — dịch vụ đúng nhưng cho khách hàng bên ngoài; đề nói về xác thực bằng Entra ID của tổ chức.
Câu 27 Azure App Service
For Windows App Services, where can you choose to have logging saved to?
  1. A File system, and blob storage
  2. B File system, blob storage, and SQL Database
  3. C File system only
  4. D File system, blob storage, and Windows Event Log
Xem giải thích

Đáp án

A — File system và blob storage.

Vì sao đúng

⚠ App Service trên Windows cho hai đích ghi log ứng dụng: | Đích | Đặc điểm | |---|---| | ⚠ File system | ⚠ bật nhanh, TỰ TẮT sau 12 giờ | | ⚠ Blob storage | ⚠ giữ lâu dài, đặt được thời gian lưu |

⚠ File system
   ⚠ dùng để gỡ lỗi NGAY
   ⚠ Azure tự tắt sau 12 giờ để bảo vệ đĩa
        ↓
⚠ Blob storage
   ⚠ dùng cho môi trường thật
   ⚠ giữ được nhiều ngày
Lưu ý theo nền tảng Nội dung
⚠ Windows ⚠ application log ghi được ra CẢ HAI
⚠ Linux ⚠ chỉ ghi ra file system
⚠ Web server log ⚠ chỉ có trên Windows

Vì sao các phương án khác sai

  • D (file system, blob và Windows Event Log) — ⚠ App Service KHÔNG ghi ra Event Log: ⚠ bạn không có quyền truy cập hệ điều hành ở mô hình PaaS.

  • B (thêm SQL Database) — ⚠ không phải đích log tích hợp.

  • C (chỉ file system) — ⚠ thiếu blob.

Ghi nhớ

⚠ Các loại log của App Service: | Loại | Nội dung | |---|---| | ⚠ Application logging | ⚠ log do MÃ của bạn ghi ra | | ⚠ Web server logging | ⚠ request HTTP, chỉ Windows | | ⚠ Detailed error messages | ⚠ trang lỗi đầy đủ | | ⚠ Failed request tracing | ⚠ truy vết request lỗi | | ⚠ Deployment logging | ⚠ quá trình triển khai |

Từ khoá nhận diện:

"giữ lâu dài" → ⚠ blob storage "gỡ lỗi ngay, tự tắt sau 12 giờ" → ⚠ file system "truy vấn và cảnh báo" → ⚠ Application Insights "Event Log" → ⚠ KHÔNG có ở PaaS

⚠ Vì sao file system tự tắt sau 12 giờ Lý do
⚠ Bảo vệ dung lượng đĩa của App Service
⚠ Log đầy đĩa sẽ làm ứng dụng dừng
⚠ Hệ quả ⚠ bật lúc gỡ lỗi rồi quên, hôm sau không có log
⚠ Với môi trường thật ⚠ luôn ghi ra blob hoặc Application Insights
⚠ Diagnostic settings — cách hiện đại hơn Nội dung
⚠ Gửi log tới Log Analytics workspace
⚠ Truy vấn bằng KQL
⚠ Đặt cảnh báo trên kết quả truy vấn
⚠ Gửi tới Event Hub cho hệ thống SIEM
⚠ Khuyến nghị ⚠ cho mọi ứng dụng chạy thật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log ghi ra đâu và giữ bao lâu | | | Có ai theo dõi log lỗi không | | | Ứng dụng chạy Windows hay Linux | ⚠ ảnh hưởng loại log có sẵn |

Và thiết lập cần đổi ngay khi ứng dụng chuyển từ thử nghiệm sang chạy thật: chuyển đích ghi log từ file system sang blob hoặc Log Analytics. Log tự xoá sau mười hai giờ là thứ chỉ chấp nhận được khi đang ngồi gỡ lỗi.

Câu 28 Virtual Machines
What advantage does a Spot VM provide over a regularly-provisioned VM?
  1. A Spot instances are significantly cheaper
  2. B Spot instances have a high CPU-to-memory ratio.
  3. C Spot instances are specialized virtual machines available with single, multiple, or fractional GPUs.
  4. D Provides burstable performance, ideal for workloads that do not need the full performance of the CPU continuously
Xem giải thích

Đáp án

A — Spot instance RẺ HƠN đáng kể.

Vì sao đúng

⚠ Spot VM dùng năng lực TỒN DƯ của Azure với giá rất thấp:

⚠ Azure còn máy trống
        ↓
⚠ Bán với giá giảm rất sâu
        ↓ ⚠ nhưng
⚠ Khi Azure CẦN lại năng lực đó
        ↓
⚠ VM của bạn bị THU HỒI
   ⚠ chỉ báo trước 30 giây
Đánh đổi Nội dung
⚠ Giảm giá rất sâu ⚠ có thể tới 80-90%
⚠ Có thể bị THU HỒI bất cứ lúc nào
⚠ KHÔNG có SLA
⚠ Đặt được giá tối đa chấp nhận

Vì sao các phương án khác sai

  • D (hiệu năng bùng nổ, hợp tải không cần CPU liên tục) — ⚠ đó là dòng B-series.

  • C (máy chuyên dụng có GPU) — ⚠ đó là dòng N-series.

  • B (tỉ lệ CPU trên bộ nhớ cao) — ⚠ đó là dòng F-series (compute optimized).

Ghi nhớ

⚠ Các dòng máy ảo Azure — bảng phải thuộc: | Dòng | Tối ưu cho | |---|---| | ⚠ B-series | ⚠ burstable, tải thấp không đều | | ⚠ D-series | ⚠ mục đích chung, cân bằng | | ⚠ E-series | ⚠ nhiều BỘ NHỚ | | ⚠ F-series | ⚠ nhiều CPU | | ⚠ L-series | ⚠ lưu trữ tối ưu, đĩa NVMe | | ⚠ N-series | ⚠ GPU | | ⚠ H-series | ⚠ tính toán hiệu năng cao |

Từ khoá nhận diện:

"rẻ, có thể bị thu hồi" → ⚠ Spot VM "burstable, credit CPU" → ⚠ B-series "GPU, học sâu, đồ hoạ" → ⚠ N-series "nhiều RAM cho CSDL" → ⚠ E-series

⚠ Khi nào dùng Spot VM Khi nào
⚠ Xử lý theo lô có thể chạy lại
⚠ Render hình ảnh, mô phỏng
⚠ Môi trường dev và test
⚠ Node phụ trong cụm AKS
⚠ KHÔNG dùng cho ⚠ ứng dụng cần chạy liên tục, CSDL, dịch vụ khách hàng
⚠ Thiết kế để sống được với Spot Thiết kế
⚠ Công việc phải CHẠY LẠI ĐƯỢC
⚠ Lưu điểm kiểm tra thường xuyên
⚠ Xử lý sự kiện thu hồi trong 30 giây ⚠ Scheduled Events API
⚠ Trộn Spot với node thường trong AKS
⚠ Nguyên tắc ⚠ coi việc bị thu hồi là chuyện BÌNH THƯỜNG, không phải sự cố
⚠ Cách khác để tiết kiệm chi phí VM Cách
⚠ Reserved Instance ⚠ cam kết 1-3 năm, giảm tới 70%
⚠ Savings Plan ⚠ linh hoạt hơn reservation
⚠ Azure Hybrid Benefit ⚠ dùng giấy phép Windows và SQL sẵn có
⚠ Tự tắt VM ngoài giờ ⚠ hiệu quả với dev/test

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công việc có chạy lại được không | ⚠ điều kiện tiên quyết cho Spot | | Có xử lý sự kiện thu hồi chưa | | | Đã cân nhắc reserved instance cho tải ổn định chưa | |

Và điều kiện duy nhất để Spot VM là lựa chọn đúng, không phải là giá mà là thiết kế: công việc của bạn phải chịu được việc bị ngắt giữa chừng bất cứ lúc nào.

Câu 29 Message Solutions
You are a developer for Acme Inc. Your company's flagship application is the Wind Monitoring software that Wind Energy farms use to monitor their equipment. At the end of each day, the Wind Collector sends a message that contains all of the days statistics in JSON format which needs to be read, processed, and posted to the database. Which Azure Service is best for processing this type of data?
  1. A Service Bus
  2. B IoT Hub
  3. C Event Hub
  4. D Storage Queues
Xem giải thích

Đáp án

A — Service Bus.

Vì sao đúng

⚠ Đề mô tả tin nhắn NGHIỆP VỤ cần xử lý đáng tin cậy, không phải dòng telemetry: | Đặc điểm trong đề | Service Bus | |---|---| | ⚠ MỘT tin nhắn cuối ngày | ⚠ khối lượng thấp, không phải dòng | | ⚠ Chứa dữ liệu quan trọng | ⚠ cần bảo đảm không mất | | ⚠ Cần đọc, xử lý, ghi vào CSDL | ⚠ cần xác nhận sau khi xử lý xong |

⚠ Service Bus
   ⚠ Bảo đảm giao nhận
   ⚠ Xử lý xong mới xoá tin nhắn
   ⚠ Thất bại thì tự thử lại
   ⚠ Quá số lần thì vào DEAD-LETTER queue
        ↓
⚠ Không tin nhắn nào bị mất âm thầm

Vì sao các phương án khác sai

  • C (Event Hub) — ⚠ cho DÒNG telemetry khối lượng RẤT LỚN: ⚠ hàng triệu sự kiện mỗi giây; ⚠ dùng cho một tin nhắn mỗi ngày là ⚠ sai công cụ.

  • B (IoT Hub) — ⚠ cho THIẾT BỊ IoT với giao tiếp hai chiều và quản lý thiết bị; ⚠ ở đây không có yêu cầu đó.

  • D (Storage Queue) — ⚠ đơn giản và rẻ, ⚠ nhưng ⚠ thiếu các bảo đảm nghiệp vụ: ⚠ không có dead-letter, không có phiên, không có giao dịch.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin — bảng phân biệt: | Dịch vụ | Dùng cho | |---|---| | ⚠ Service Bus | ⚠ tin nhắn NGHIỆP VỤ, cần bảo đảm | | ⚠ Event Hub | ⚠ DÒNG telemetry khối lượng lớn | | ⚠ Event Grid | ⚠ sự kiện rời rạc, phản ứng theo sự kiện | | ⚠ Storage Queue | ⚠ hàng đợi đơn giản, rẻ |

Từ khoá nhận diện:

"tin nhắn nghiệp vụ, không được mất" → ⚠ Service Bus "hàng triệu sự kiện mỗi giây" → ⚠ Event Hub "phản ứng khi có blob mới" → ⚠ Event Grid "hàng đợi đơn giản, hơn 80GB" → ⚠ Storage Queue

⚠ Tính năng riêng của Service Bus Tính năng
⚠ Dead-letter queue ⚠ tin nhắn xử lý thất bại không biến mất
⚠ Sessions ⚠ bảo đảm THỨ TỰ trong một nhóm
⚠ Duplicate detection ⚠ loại tin nhắn trùng
⚠ Scheduled delivery ⚠ hẹn giờ gửi
⚠ Transactions ⚠ gộp nhiều thao tác
⚠ Topic và subscription ⚠ một tin nhắn tới nhiều người nhận
⚠ Storage Queue và Service Bus — chọn cái nào Chọn
⚠ Cần đơn giản, rẻ, hơn 80GB hàng đợi ⚠ Storage Queue
⚠ Cần thứ tự, giao dịch, dead-letter, topic ⚠ Service Bus
⚠ Tin nhắn lớn hơn 64KB ⚠ Service Bus (tới 256KB hoặc 100MB)
⚠ Nguyên tắc ⚠ nghiệp vụ quan trọng thì chọn Service Bus
⚠ Peek-lock — cơ chế cốt lõi Nội dung
⚠ Nhận tin nhắn nhưng KHÔNG xoá ngay
⚠ Xử lý xong gọi Complete để xoá
⚠ Lỗi thì gọi Abandon để trả về hàng đợi
⚠ Quá thời gian khoá thì tự trả về
⚠ Bảo đảm ⚠ tin nhắn không mất khi tiến trình xử lý bị sập giữa chừng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mất một tin nhắn có gây hậu quả nghiệp vụ không | ⚠ có thì dùng Service Bus | | Có ai theo dõi dead-letter queue không | ⚠ rất hay bị bỏ quên | | Khối lượng là bao nhiêu tin mỗi giây | |

Và hàng đợi cần theo dõi mà gần như luôn bị bỏ quên trong mọi hệ thống nhắn tin: dead-letter queue. Tin nhắn vào đó nghĩa là một giao dịch nghiệp vụ đã thất bại, và nếu không ai nhìn thì nó nằm đó mãi.

Câu 30 API Gateways
The API Management Gateway includes a powerful feature called Policies. What is the main function of policies?
  1. A You can set rules as to who has access to an API and who does not.
  2. B Increase the security of your account by rejecting traffic coming in to the API by IP address
  3. C Policies allow you to modify the behavior of the API using configuration instead of code. A policy can change both the inbound request and the outbound response.
  4. D Policies allow you to direct the incoming traffic to several back-end APIs to help balance the load of the request.
Xem giải thích

Đáp án

C — Policy cho phép thay đổi HÀNH VI của API bằng CẤU HÌNH thay vì mã, tác động được lên cả request vào lẫn response ra.

Vì sao đúng

⚠ Policy là công cụ mạnh nhất của API Management:

⚠ <policies>
⚠   <inbound>   ← trước khi tới backend
⚠   <backend>   ← khi gọi backend
⚠   <outbound>  ← sau khi backend trả về
⚠   <on-error>  ← khi có lỗi
⚠ </policies>
Policy làm được gì Ví dụ
⚠ Giới hạn tần suất ⚠ rate-limit, quota
⚠ Xác thực ⚠ validate-jwt, kiểm tra subscription key
⚠ Chuyển đổi định dạng ⚠ XML sang JSON và ngược lại
⚠ Cache phản hồi
⚠ Viết lại URL và header
⚠ Che dữ liệu nhạy cảm trong response
⚠ Định tuyến theo điều kiện
⚠ Ghi log tới Event Hub

Vì sao các phương án khác sai

  • A (đặt luật ai được truy cập) và B (chặn theo IP) — ⚠ là MỘT SỐ policy cụ thể, ⚠ không phải chức năng chính của cả hệ thống policy.

  • D (cân bằng tải giữa nhiều backend) — ⚠ policy làm được, ⚠ nhưng cũng chỉ là một trường hợp dùng.

⚠ Ba phương án sai đều đúng một phần — ⚠ chúng là ⚠ ví dụ chứ không phải ⚠ định nghĩa.

Ghi nhớ

⚠ Bốn phần của policy — nhớ theo dòng chảy request: | Phần | Khi nào chạy | |---|---| | ⚠ inbound | ⚠ request tới, TRƯỚC khi gọi backend | | ⚠ backend | ⚠ lúc gọi backend | | ⚠ outbound | ⚠ response về, TRƯỚC khi trả cho client | | ⚠ on-error | ⚠ khi có lỗi ở bất kỳ phần nào |

Từ khoá nhận diện:

"đổi hành vi API bằng cấu hình" → ⚠ policy "giới hạn số lần gọi" → ⚠ rate-limit policy "kiểm tra token" → ⚠ validate-jwt policy "cache kết quả" → ⚠ cache-lookup và cache-store

⚠ Phạm vi áp dụng policy Phạm vi
⚠ Global ⚠ toàn bộ instance
⚠ Product ⚠ nhóm API bán cùng gói
⚠ API ⚠ một API
⚠ Operation ⚠ một endpoint cụ thể
⚠ Kế thừa bằng ⚠ thẻ <base />
⚠ Quên <base /> ⚠ policy cấp trên KHÔNG được áp dụng
⚠ Vì sao policy giá trị Lý do
⚠ Thêm tính năng mà KHÔNG sửa backend
⚠ Áp dụng nhất quán cho nhiều API
⚠ Đội API không phải viết lại logic chung
⚠ Ví dụ điển hình ⚠ thêm rate limit cho API cũ mà không đụng vào mã của nó
⚠ Ba tầng của API Management Tầng
⚠ Gateway ⚠ nơi policy chạy
⚠ Developer portal ⚠ tài liệu và đăng ký khoá
⚠ Management plane ⚠ cấu hình qua Portal, CLI, ARM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Policy có <base /> để kế thừa không | ⚠ lỗi hay gặp nhất | | Có rate limit cho API công khai chưa | | | Response có lộ thông tin nội bộ không | ⚠ dùng policy để che |

Và giá trị lớn nhất của policy trong API Management, thể hiện rõ khi phải bảo vệ một hệ thống cũ: thêm được xác thực, giới hạn tần suất và ghi log cho một API mà không cần chạm vào dòng mã nào của nó.