Ngân hàng đề Microsoft Azure Developer

Câu 91 Azure App Service

What type of App Service log files store the web server logs?

A AllMetrics
B AppServiceAuditLogs
C AppServiceAppLogs
D AppServiceHTTPLogs

Xem giải thích

Đáp án

D — AppServiceHTTPLogs

Vì sao đúng

⚠ Mỗi loại log của App Service có một BẢNG riêng trong Log Analytics: | Bảng | Nội dung | |---|---| | ⚠ AppServiceHTTPLogs | ⚠ log web server: request, status code, thời gian | | ⚠ AppServiceAppLogs | ⚠ log do MÃ ứng dụng ghi | | ⚠ AppServiceAuditLogs | ⚠ ai đăng nhập vào FTP hay Kudu | | ⚠ AppServiceConsoleLogs | ⚠ đầu ra console và stdout | | ⚠ AppServicePlatformLogs | ⚠ nền tảng, khởi động container | | ⚠ AllMetrics | ⚠ số liệu, KHÔNG phải log |

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

C (AppServiceAppLogs) — ⚠ bẫy gần nhất: ⚠ đó là log của ⚠ mã ứng dụng, không phải web server.
B (AppServiceAuditLogs) — ⚠ ghi việc đăng nhập quản trị.
A (AllMetrics) — ⚠ là SỐ LIỆU, không phải log.

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ề log App Service qua hai lô.

Câu	Hỏi gì	Khoá
⚠ #21426	⚠ tải log về đĩa	⚠ az webapp log download
⚠ #21430	⚠ log ghi ra đâu được	⚠ file system và blob
⚠ #21481	⚠ xem log trực tiếp	⚠ az webapp log tail
⚠ #21494 (câu này)	⚠ bảng nào chứa log web server	⚠ AppServiceHTTPLogs
⚠ Bốn câu	⚠ từ cách lấy log tới cấu trúc bảng log

⚠ Truy vấn KQL mẫu cho AppServiceHTTPLogs:

⚠ AppServiceHTTPLogs
⚠ | where TimeGenerated > ago(1h)
⚠ | where ScStatus >= 500
⚠ | summarize count() by CsUriStem
⚠ | order by count_ desc

Cột hữu ích	Nội dung
⚠ `ScStatus`	⚠ mã trạng thái HTTP
⚠ `CsUriStem`	⚠ đường dẫn
⚠ `TimeTaken`	⚠ thời gian xử lý
⚠ `CIp`	⚠ IP client
⚠ `CsHost`	⚠ tên miền

Từ khoá nhận diện:

"request, status code, thời gian phản hồi" → ⚠ AppServiceHTTPLogs "log do mã ghi ra" → ⚠ AppServiceAppLogs "ai đăng nhập FTP hay Kudu" → ⚠ AppServiceAuditLogs "CPU, bộ nhớ, số request" → ⚠ AllMetrics

⚠ Điều kiện để có các bảng này	Điều kiện
⚠ Phải bật DIAGNOSTIC SETTINGS
⚠ Chọn loại log và gửi tới Log Analytics workspace
⚠ Mặc định TẮT	⚠ điểm rất hay bị quên
⚠ Không bật	⚠ bảng rỗng, không truy vấn được gì

⚠ Chi phí — cân nhắc thực tế	Cân nhắc
⚠ HTTPLogs sinh RẤT NHIỀU dòng	⚠ mỗi request một dòng
⚠ Tính tiền theo GB nạp vào
⚠ Với site lưu lượng cao thì rất tốn
⚠ Cân nhắc	⚠ chỉ bật khi cần điều tra, hoặc lọc bớt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Diagnostic settings đã bật chưa | ⚠ mặc định tắt | | Đang nạp bao nhiêu GB log mỗi ngày | | | Cần bảng log ứng dụng hay log web server | |

Và điều cần cân nhắc trước khi bật đầy đủ log HTTP cho một site lưu lượng cao: mỗi request sinh một dòng log, và bạn trả tiền theo dung lượng nạp vào. Với site nhiều triệu lượt truy cập, đó là khoản đáng kể.

Câu 92 Azure Functions

Your function uses the following code. You want to add a message to the log when the function starts late. What code belongs in the missing line? [FunctionName("TimerTriggerCSharp")] public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, ILogger log) { >>>>> LINE MISSING HERE <<<<< { log.LogInformation("Timer is running late!"); } log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");}

A if (TimerTrigger.IsLate)
B if (myTimer.TriggerTime < DateTime.Now)
C if (myTimer.IsLate)
D if (myTimer.IsPastDue)

Xem giải thích

Đáp án

D — if (myTimer.IsPastDue)

Vì sao đúng

⚠ TimerInfo có thuộc tính IsPastDue cho biết lần chạy này có bị TRỄ không:

⚠ [FunctionName("TimerTriggerCSharp")]
⚠ public static void Run(
⚠     [TimerTrigger("0 */5 * * * *")] TimerInfo myTimer,
⚠     ILogger log)
⚠ {
⚠     if (myTimer.IsPastDue)
⚠     {
⚠         log.LogInformation("Hàm chạy TRỄ hơn lịch");
⚠     }
⚠ }

Khi nào `IsPastDue` là true	Trường hợp
⚠ Function app vừa khởi động lại
⚠ Đã bỏ lỡ một hoặc nhiều lần chạy
⚠ Function app bị dỡ tải rồi bật lại
⚠ Hữu ích để	⚠ quyết định có nên chạy bù hay bỏ qua

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

C (myTimer.IsLate) — ⚠ bẫy chính: ⚠ tên nghe rất hợp lý nhưng ⚠ thuộc tính đó không tồn tại.
B (myTimer.TriggerTime < DateTime.Now) — ⚠ luôn đúng: ⚠ thời điểm kích hoạt luôn ở quá khứ so với lúc chạy, ⚠ nên điều kiện này vô nghĩa.
A (TimerTrigger.IsLate) — ⚠ sai cả tên lớp lẫn tên thuộc tính.

Ghi nhớ

⚠ Thuộc tính của TimerInfo: | Thuộc tính | Nội dung | |---|---| | ⚠ IsPastDue | ⚠ lần chạy này có bị trễ không | | ⚠ Schedule | ⚠ thông tin lịch | | ⚠ ScheduleStatus.Last | ⚠ lần chạy trước | | ⚠ ScheduleStatus.Next | ⚠ lần chạy kế tiếp | | ⚠ ScheduleStatus.LastUpdated | |

Từ khoá nhận diện:

"chạy trễ" → ⚠ IsPastDue "lần chạy kế tiếp" → ⚠ ScheduleStatus.Next "IsLate" → ⚠ KHÔNG tồn tại — bẫy "chạy lại khi khởi động" → ⚠ runOnStartup

⚠ Vì sao Timer Trigger có thể bị trễ	Lý do
⚠ Gói Consumption: function app có thể ngủ
⚠ Triển khai lại làm khởi động lại app
⚠ Bảo trì nền tảng
⚠ Lần chạy trước quá lâu chưa xong
⚠ Với gói App Service	⚠ phải bật Always On, nếu không timer rất không đáng tin

⚠ Xử lý khi bị trễ — hai hướng	Hướng
⚠ Chạy bù	⚠ nếu công việc bỏ lỡ gây hậu quả
⚠ Bỏ qua và chờ lần sau	⚠ nếu công việc lặp lại được
⚠ Ghi log	⚠ luôn nên ghi lại để biết tần suất bị trễ
⚠ Nếu trễ thường xuyên	⚠ dấu hiệu cần nâng gói hoặc xem lại thiết kế

⚠ Trạng thái lịch lưu ở đâu	Nơi
⚠ Trong Storage Account của function app
⚠ Bảng `AzureWebJobsHostLogs` hoặc blob `timers`
⚠ Nghĩa là	⚠ nhiều instance không chạy trùng cùng một lịch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có xử lý trường hợp bị trễ không | | | Always On đã bật chưa nếu dùng App Service Plan | | | Có ghi log khi bị trễ để theo dõi không | |

Và tình huống mà IsPastDue giúp bạn xử lý đúng đắn, thường bị bỏ qua khi viết Timer Trigger: hàm vừa khởi động lại sau một thời gian ngừng và đã bỏ lỡ vài lần chạy. Chạy bù hay bỏ qua là quyết định nghiệp vụ, và bạn cần biết mình đang ở tình huống nào.

Câu 93 Azure App Service

Azure App Service has options to scale up and scale out. What does scaling up an app do?

A Increases the number of VM instances that run your app.
B It moves your App Service plan to a higher pricing tier, giving you more CPU, memory, disk space and extra features.
C Switches the VM type your App Service runs on, to one with more vCPUs and more memory.
D Deploys another instance of your app to a different region to ensure better performance for global customers.

Xem giải thích

Đáp án

B — Chuyển App Service Plan lên BẬC GIÁ CAO HƠN, cho nhiều CPU, bộ nhớ, dung lượng đĩa và tính năng bổ sung.

Vì sao đúng

⚠ Scale up là mở rộng theo chiều DỌC:

⚠ Bậc B1 → S1 → P1v3
        ↓
⚠ Nhiều CPU hơn
⚠ Nhiều RAM hơn
⚠ Nhiều đĩa hơn
⚠ Mở khoá TÍNH NĂNG mới

Tính năng mở khoá theo bậc	Bậc
⚠ Always On	⚠ từ Basic
⚠ Deployment slot	⚠ từ Standard
⚠ Autoscale	⚠ từ Standard
⚠ Sao lưu tự động	⚠ từ Standard
⚠ Traffic Manager tích hợp	⚠ từ Standard
⚠ Vì vậy	⚠ scale up không chỉ là thêm sức mạnh, mà còn mở tính năng

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

A (tăng số instance) — ⚠ đó là scale OUT.
C (đổi sang loại VM khác có nhiều vCPU hơn) — ⚠ mô tả nghe đúng nhưng thiếu: ⚠ trên App Service bạn không chọn loại VM trực tiếp mà ⚠ chọn BẬC; ⚠ và bậc còn mở thêm tính năng.
D (triển khai sang vùng khác) — ⚠ mở rộng địa lý.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp ĐỐI XỨNG với #21479 ở lô trước.

Câu	Hỏi gì	Khoá
⚠ #21479	⚠ scale OUT làm gì	⚠ tăng số instance
⚠ #21496 (câu này)	⚠ scale UP làm gì	⚠ lên bậc giá cao hơn
⚠ Cặp đối xứng	⚠ dùng chung bộ phương án, hoán đổi khoá
⚠ Cùng với #21493	⚠ ba câu về mở rộng App Service

⚠ Scale up và scale out — bảng chốt: | Tiêu chí | Scale UP | Scale OUT | |---|---|---| | ⚠ Hướng | ⚠ dọc | ⚠ ngang | | ⚠ Thay đổi | ⚠ bậc plan | ⚠ số instance | | ⚠ Mở khoá tính năng | ⚠ CÓ | ⚠ không | | ⚠ Có trần | ⚠ CÓ — bậc cao nhất | ⚠ cao hơn nhiều | | ⚠ Yêu cầu ứng dụng | ⚠ không đặc biệt | ⚠ phải STATELESS |

Từ khoá nhận diện:

"bậc cao hơn, S1 lên S2" → ⚠ scale up "nhiều instance hơn" → ⚠ scale out "sang vùng khác" → ⚠ mở rộng địa lý "tự động theo tải" → ⚠ autoscale, thuộc scale out

⚠ Khi nào scale up là lựa chọn đúng	Khi nào
⚠ Cần tính năng chỉ có ở bậc cao	⚠ slot, autoscale
⚠ Ứng dụng cần nhiều RAM cho MỘT tiến trình
⚠ Ứng dụng chưa stateless nên chưa scale out được
⚠ Hạn chế	⚠ có trần, và một instance vẫn là điểm hỏng đơn lẻ

⚠ Thứ tự nên cân nhắc	Thứ tự
⚠ 1. Tối ưu mã và truy vấn	⚠ rẻ nhất
⚠ 2. Thêm cache
⚠ 3. Scale out nếu ứng dụng stateless
⚠ 4. Scale up
⚠ Sai lầm	⚠ nâng bậc ngay khi thấy chậm mà chưa tìm nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguyên nhân chậm là CPU, RAM, hay truy vấn CSDL | ⚠ nâng bậc không chữa được truy vấn chậm | | Ứng dụng có stateless để scale out không | | | Bậc hiện tại có thiếu tính năng nào cần không | |

Và sai lầm tốn kém phổ biến khi ứng dụng chậm: nâng bậc ngay mà chưa tìm nguyên nhân. Nếu nút thắt nằm ở một truy vấn cơ sở dữ liệu thiếu chỉ mục, máy chủ mạnh gấp đôi cũng không giúp gì.

Câu 94 Azure App Service

Your Azure Web App is currently throwing a 500 server error when viewed. You'd like to see more detail on the error. In order to accomplish this, what app setting do you need to set, and to what value?

A DEBUG="TRUE"
B ASPNETCORE_ENVIRONMENT="Development"
C ENVIRONMENT="Development"
D LOGGING="DEBUG"

Xem giải thích

Đáp án

B — ASPNETCORE_ENVIRONMENT="Development"

Vì sao đúng

⚠ ASP.NET Core chỉ hiện trang lỗi chi tiết khi ở môi trường Development:

⚠ if (app.Environment.IsDevelopment())
⚠ {
⚠     app.UseDeveloperExceptionPage();
⚠ }
⚠ else
⚠ {
⚠     app.UseExceptionHandler("/Error");
⚠ }

Môi trường	Trang lỗi
⚠ Development	⚠ chi tiết: stack trace, dòng mã, biến
⚠ Staging, Production	⚠ trang lỗi chung, không lộ gì
⚠ Đặt bằng	⚠ biến môi trường `ASPNETCORE_ENVIRONMENT`
⚠ Trên App Service	⚠ thêm vào Application Settings

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

C (ENVIRONMENT) — ⚠ sai tên biến: ⚠ thiếu tiền tố ASPNETCORE_.
A (DEBUG="TRUE") và D (LOGGING="DEBUG") — ⚠ không phải biến chuẩn của ASP.NET Core.

Ghi nhớ

⚠ CẢNH BÁO BẢO MẬT quan trọng nhất của câu này: | Cảnh báo | Nội dung | |---|---| | ⚠ Trang lỗi chi tiết LỘ rất nhiều thông tin | | | ⚠ Đường dẫn tệp trên máy chủ | | | ⚠ Mã nguồn và stack trace | | | ⚠ Đôi khi cả chuỗi kết nối | | | ⚠ TUYỆT ĐỐI | ⚠ TẮT lại ngay sau khi gỡ lỗi xong | | ⚠ Không bao giờ | ⚠ để Development trên môi trường thật lâu dài |

⚠ Ba môi trường chuẩn của ASP.NET Core: | Môi trường | Dùng khi | |---|---| | ⚠ Development | ⚠ máy lập trình viên | | ⚠ Staging | ⚠ kiểm thử trước khi phát hành | | ⚠ Production | ⚠ mặc định nếu không đặt gì | | ⚠ Tự đặt tên khác được | ⚠ và đọc bằng app.Environment.EnvironmentName |

Từ khoá nhận diện:

"thấy chi tiết lỗi" → ⚠ ASPNETCORE_ENVIRONMENT=Development "cấu hình theo môi trường" → ⚠ appsettings.{Environment}.json "ASP.NET Framework cũ" → ⚠ web.config, customErrors "không lộ lỗi ra ngoài" → ⚠ Production

⚠ Cách an toàn hơn để điều tra lỗi	Cách
⚠ Application Insights	⚠ thấy stack trace mà KHÔNG lộ ra người dùng
⚠ Log ứng dụng ghi ra Log Analytics
⚠ Bật Development ở SLOT staging thay vì production
⚠ Đây là	⚠ cách nên làm thay vì bật Development trên site thật

⚠ Cấu hình theo môi trường	Cơ chế
⚠ `appsettings.json`	⚠ chung
⚠ `appsettings.Development.json`	⚠ ghi đè khi ở Development
⚠ `appsettings.Production.json`
⚠ Application Settings trên Azure	⚠ ghi đè cao nhất
⚠ Thứ tự ưu tiên	⚠ biến môi trường thắng tệp cấu hình

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có site production nào đang ở Development không | ⚠ kiểm tra ngay | | Có Application Insights để điều tra lỗi không | | | Slot staging có dùng cấu hình riêng không | |

Và rủi ro bảo mật cụ thể của việc quên tắt chế độ Development trên môi trường thật: trang lỗi chi tiết công khai đường dẫn máy chủ, mã nguồn và đôi khi cả chuỗi kết nối cơ sở dữ liệu cho bất kỳ ai gây được lỗi.

Câu 95 Azure App Service

You are deploying a web application to Azure App Service and want to ensure that the application can handle high traffic loads without downtime. You decide to configure autoscaling for the App Service Plan. Which of the following metrics can you use to trigger autoscaling based on application performance?

A
Memory Percentage
B
CPU Percentage
C
Disk Queue Length
D
HTTP Queue Length

Xem giải thích

Đáp án

B — CPU Percentage

Vì sao đúng

CPU là tín hiệu co giãn mặc định và đáng tin nhất cho ứng dụng web: nó có sẵn không phải dựng gì, phản ánh trực tiếp lượng công việc đang xử lý, và tăng giảm theo cả hai chiều nên co lên và co xuống đều hoạt động.

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

A. Memory Percentage — bộ nhớ là tín hiệu tệ cho ứng dụng web vì nó không giảm khi tải giảm: bộ đệm và cơ chế thu gom rác giữ lại, nên hệ thống co lên rồi không bao giờ co xuống.
D. HTTP Queue Length — là tín hiệu có ý nghĩa và dùng được, nhưng nó chỉ tăng khi ứng dụng đã quá tải, tức là phản ứng muộn hơn CPU.
C. Disk Queue Length — hiếm khi là nút thắt của ứng dụng web.

Câu 96 Azure Key Vault

You are developing an application that needs to access a secret stored in Azure Key Vault. You have implemented the Azure SDK for .NET in your application. Which of the following code snippets correctly retrieves a secret named "MySecret" from Azure Key Vault?

A

// csharp
var client = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(...));
var secret = client.GetSecretAsync("https://<YourKeyVaultName>.vault.azure.net/secrets/MySecret").Result;

B

// csharp
var client = new SecretClient(new Uri("https://<YourKeyVaultName>.vault.azure.net/"), new DefaultAzureCredential());
KeyVaultSecret secret = client.GetSecret("MySecret");

C

// csharp
var secret = new SecretClient("<YourKeyVaultName>", new DefaultAzureCredential()).GetSecret("MySecret").Value;

D

// csharp
var secretClient = new SecretClient(new Uri("<YourKeyVaultName>"), new DefaultAzureCredential());
var secret = secretClient.GetSecretAsync("MySecret").GetAwaiter().GetResult();

Xem giải thích

Đáp án

D — Khởi tạo SecretClient với DefaultAzureCredential rồi gọi GetSecretAsync

Vì sao đúng theo khoá đáp án

Hai thành phần chính đều đúng:

SecretClient — lớp của thư viện hiện hành Azure.Security.KeyVault.Secrets.
DefaultAzureCredential — chuỗi xác thực tự thử nhiều nguồn theo thứ tự: biến môi trường, managed identity, Azure CLI. Nhờ vậy cùng một đoạn mã chạy được cả trên máy lập trình viên lẫn trên Azure mà không cần đổi gì.

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

A. Dùng KeyVaultClient với AuthenticationCallback — đó là thư viện thế hệ cũ (Microsoft.Azure.KeyVault), đã được thay bằng bộ Azure.*.
C. Truyền tên vault dạng chuỗi thay vì Uri — SecretClient nhận Uri, không nhận string.

Ghi chú về chất lượng câu hỏi

Phương án B thực ra viết địa chỉ vault đúng chuẩn — https://<tên>.vault.azure.net/ — trong khi phương án được chọn lại truyền new Uri("<YourKeyVaultName>"), một chuỗi không phải URI hợp lệ. Nếu chấm theo mã chạy được thật thì B mới đúng. Phần đáng nhớ ở đây là cặp SecretClient + DefaultAzureCredential và dạng đầy đủ của địa chỉ vault.

Câu 97 Virtual Machines

What advantage does the Compute-Optimized (Fsv2) instance family have over the General Purpose (Dsv4) instance family?

A F-series VMs allow you to scale to much more powerful machine sizes than D-series
B F-series VMs provide higher performance (ACU) per virtual CPU compared to D-series
C F-series VMs are budget series, being much cheaper than D-series VMs
D They provide more temporary disk space than D-series VMs

Xem giải thích

Đáp án

B — Máy F-series cho HIỆU NĂNG (ACU) trên mỗi vCPU cao hơn so với D-series.

Vì sao đúng

⚠ ACU (Azure Compute Unit) là thước đo hiệu năng chuẩn hoá của Microsoft: | Dòng | Định vị | ACU mỗi vCPU | |---|---|---| | ⚠ Dsv4 (General Purpose) | ⚠ cân bằng CPU và RAM | ⚠ thấp hơn | | ⚠ Fsv2 (Compute Optimized) | ⚠ thiên về CPU | ⚠ CAO HƠN |

⚠ F-series
   ⚠ CPU nhanh hơn trên mỗi lõi
   ⚠ Tỉ lệ RAM trên vCPU THẤP hơn
        ↓
⚠ Hợp với tải nặng về TÍNH TOÁN
   ⚠ xử lý theo lô, máy chủ web, phân tích

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

C (dòng ngân sách, rẻ hơn nhiều) — ⚠ đó là B-series.
D (nhiều đĩa tạm hơn) — ⚠ thực tế F-series thường ít RAM và đĩa tạm hơn trên mỗi vCPU.
A (mở rộng tới cấu hình mạnh hơn D-series) — ⚠ D-series có các kích thước rất lớn; ⚠ đây không phải điểm phân biệt.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21431 ở lô trước về các dòng máy ảo.

Câu	Hỏi gì	Khoá
⚠ #21431	⚠ ưu điểm Spot VM	⚠ rẻ hơn nhiều
⚠ #21500 (câu này)	⚠ F-series hơn D-series ở đâu	⚠ ACU mỗi vCPU cao hơn
⚠ Bổ sung nhau	⚠ một hỏi mô hình giá, một hỏi dòng phần cứng

⚠ Các dòng máy ảo Azure — bảng phải thuộc: | Dòng | Tối ưu cho | Đặc điểm | |---|---|---| | ⚠ B | ⚠ burstable | ⚠ tích luỹ credit CPU, rẻ | | ⚠ D | ⚠ mục đích chung | ⚠ cân bằng | | ⚠ E | ⚠ bộ nhớ | ⚠ nhiều RAM trên mỗi vCPU | | ⚠ F | ⚠ tính toán | ⚠ CPU nhanh, ít RAM | | ⚠ L | ⚠ lưu trữ | ⚠ đĩa NVMe cục bộ lớn | | ⚠ M | ⚠ bộ nhớ rất lớn | ⚠ cho SAP HANA | | ⚠ N | ⚠ GPU | ⚠ học sâu, đồ hoạ | | ⚠ H | ⚠ HPC | ⚠ tính toán hiệu năng cao |

Từ khoá nhận diện:

"CPU nhanh, ACU cao" → ⚠ F-series "nhiều RAM cho CSDL" → ⚠ E-series hoặc M-series "rẻ, tải thấp không đều" → ⚠ B-series "GPU" → ⚠ N-series

⚠ ACU — cách đọc con số	Nội dung
⚠ Chuẩn hoá theo một mốc tham chiếu
⚠ Cho phép SO SÁNH hiệu năng giữa các dòng
⚠ ACU cao hơn = mỗi vCPU mạnh hơn
⚠ Lưu ý	⚠ ACU chỉ đo CPU, không đo RAM, đĩa hay mạng

⚠ B-series — cơ chế credit đáng biết	Cơ chế
⚠ Chạy dưới mức cơ sở thì TÍCH LUỸ credit
⚠ Cần bùng nổ thì TIÊU credit
⚠ Hết credit thì bị giới hạn về mức cơ sở
⚠ Rất tiết kiệm cho	⚠ máy chủ dev, site lưu lượng thấp
⚠ Không hợp cho	⚠ tải cao liên tục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nút thắt là CPU hay RAM | ⚠ quyết định chọn F hay E | | Tải có đều không | ⚠ không đều thì B-series tiết kiệm | | Có cần GPU thật không | ⚠ N-series đắt hơn nhiều |

Và bước cần làm trước khi chọn dòng máy ảo, thay vì chọn theo cảm tính: đo xem nút thắt thật sự nằm ở CPU, bộ nhớ hay đĩa. Chọn nhầm trục tối ưu là trả tiền cho thứ không giải quyết vấn đề.

Câu 98 Azure App Service

What is the URL for the Azure App Service Kudu companion app?

A https://(app-name).azurewebsites.net
B ftp://(app-name).azurewebsites.net
C https://(app-name).scm.azurewebsites.net
D https://(app-name).kudu.azurewebsites.net

Xem giải thích

Đáp án

C — https://(app-name).scm.azurewebsites.net

Vì sao đúng

⚠ Kudu là công cụ quản trị đi kèm mọi App Service, ở tên miền con scm:

⚠ Ứng dụng:  https://myapp.azurewebsites.net
⚠ Kudu:      https://myapp.scm.azurewebsites.net
        ↓
⚠ scm = Source Control Management

Kudu làm được gì	Nội dung
⚠ Duyệt và sửa tệp trên máy chủ
⚠ Console và PowerShell
⚠ Xem log triển khai
⚠ Tải xuống bộ nhớ và crash dump
⚠ Xem biến môi trường
⚠ Cài extension
⚠ Xem tiến trình đang chạy

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

D (kudu.azurewebsites.net) — ⚠ bẫy hợp lý nhất: ⚠ tên đúng nhưng ⚠ tên miền con là scm, không phải kudu.
A (chính địa chỉ ứng dụng) — ⚠ đó là site của bạn.
B (ftp://...) — ⚠ là điểm cuối FTP, một dịch vụ khác.

Ghi nhớ

⚠ Cách truy cập Kudu: | Cách | Nội dung | |---|---| | ⚠ Gõ thẳng URL scm | | | ⚠ Từ Portal: Advanced Tools → Go | | | ⚠ Đăng nhập bằng chính tài khoản Azure | | | ⚠ Trên Linux App Service | ⚠ Kudu có ÍT tính năng hơn Windows |

Từ khoá nhận diện:

"scm.azurewebsites.net" → ⚠ Kudu "Advanced Tools" → ⚠ lối vào Kudu từ Portal "azurewebsites.net" → ⚠ ứng dụng "tải log, xem tệp trên server" → ⚠ Kudu

⚠ CẢNH BÁO bảo mật về Kudu	Cảnh báo
⚠ Kudu cho quyền RẤT RỘNG	⚠ đọc mọi tệp, xem biến môi trường
⚠ Biến môi trường có thể chứa chuỗi kết nối
⚠ Ai vào được Kudu gần như kiểm soát được ứng dụng
⚠ Nên	⚠ giới hạn quyền truy cập, tắt SCM basic auth
⚠ Cấu hình	⚠ `SCM Basic Auth Publishing Credentials` nên TẮT

⚠ Kudu trong quy trình triển khai	Vai trò
⚠ Zip deploy đi qua Kudu
⚠ Git deploy cũng vậy
⚠ Log triển khai xem ở đây
⚠ Khi triển khai lỗi	⚠ Kudu là nơi đầu tiên nên nhìn

⚠ Vài đường dẫn hữu ích trong Kudu	Đường dẫn
⚠ `/api/settings`	⚠ xem cấu hình
⚠ `/DebugConsole`	⚠ console duyệt tệp
⚠ `/api/logs/docker`	⚠ log container trên Linux
⚠ `/api/deployments`	⚠ lịch sử triển khai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCM basic auth đã tắt chưa | ⚠ nên tắt | | Ai có quyền truy cập Kudu | | | Có dùng Kudu để xem log triển khai khi lỗi không | |

Và điều cần siết lại trên mọi App Service chạy thật, vì Kudu cho quyền rất rộng: tắt xác thực cơ bản cho SCM và chỉ cho phép truy cập qua danh tính Entra ID. Ai vào được Kudu là đọc được toàn bộ biến môi trường của ứng dụng.

Câu 99 Container Registry

What does the Azure Container Registry endpoint look like?

A azurecr.io/myprivateacr
B myprivateacr.azurecr.io
C registry.azure.com
D myprivateacr.eastus.azurecr.io

Xem giải thích

Đáp án

B — myprivateacr.azurecr.io

Vì sao đúng

⚠ Endpoint của ACR là tên registry cộng với hậu tố cố định:

⚠ <tên registry>.azurecr.io
        ↓
⚠ myprivateacr.azurecr.io
        ↓
⚠ Tên registry phải DUY NHẤT TOÀN CẦU

So sánh với dịch vụ khác	Mẫu
⚠ ACR	⚠ `<tên>.azurecr.io`
⚠ App Service	⚠ `<tên>.azurewebsites.net`
⚠ Storage blob	⚠ `<tên>.blob.core.windows.net`
⚠ Container Instances	⚠ `<nhãn>.<VÙNG>.azurecontainer.io`

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

D (myprivateacr.eastus.azurecr.io) — ⚠ bẫy tinh vi: ⚠ thêm VÙNG vào giữa; ⚠ đó là mẫu của ⚠ Container Instances, không phải ACR.
A (azurecr.io/myprivateacr) — ⚠ sai cấu trúc: ⚠ tên registry là tên miền con, không phải đường dẫn.
C (registry.azure.com) — ⚠ không phải tên miền của ACR.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là bài kiểm tra ngược của #21450 ở lô trước.

Câu	Dịch vụ	Có vùng trong tên miền
⚠ #21450	⚠ Container Instances	⚠ CÓ — `<nhãn>.<vùng>.azurecontainer.io`
⚠ #21502 (câu này)	⚠ Container Registry	⚠ KHÔNG — `<tên>.azurecr.io`
⚠ Lý do khác nhau	⚠ tên ACR duy nhất TOÀN CẦU, nhãn ACI chỉ duy nhất trong VÙNG
⚠ Bẫy	⚠ mỗi câu đều có phương án mang mẫu của câu kia

⚠ Quy tắc chung về tên miền Azure: | Nguyên tắc | Nội dung | |---|---| | ⚠ Tên duy nhất TOÀN CẦU | ⚠ không cần vùng trong tên miền | | ⚠ Tên duy nhất trong VÙNG | ⚠ phải có vùng trong tên miền | | ⚠ Ví dụ toàn cầu | ⚠ ACR, Storage, App Service, Key Vault | | ⚠ Ví dụ theo vùng | ⚠ Container Instances |

Từ khoá nhận diện:

"azurecr.io" → ⚠ Container Registry "azurecontainer.io có vùng" → ⚠ Container Instances "azurewebsites.net" → ⚠ App Service "vault.azure.net" → ⚠ Key Vault

⚠ Vì sao tên miền quan trọng trong thực tế	Lý do
⚠ Cấu hình private endpoint cần đúng tên miền
⚠ Cấu hình DNS riêng
⚠ Danh sách cho phép trên tường lửa
⚠ Private endpoint của ACR	⚠ dùng `privatelink.azurecr.io`

⚠ Geo-replication ảnh hưởng tên miền thế nào	Nội dung
⚠ Tên miền KHÔNG đổi
⚠ Azure tự định tuyến tới bản sao gần nhất
⚠ Client không cần biết gì
⚠ Có ở bậc	⚠ Premium

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tên registry có duy nhất toàn cầu không | | | Có cần private endpoint không | | | Có nhầm mẫu tên miền của dịch vụ khác không | |

Và quy tắc suy ra được mẫu tên miền của hầu hết dịch vụ Azure: tên duy nhất toàn cầu thì không cần vùng, tên chỉ duy nhất trong vùng thì phải có vùng.

Câu 100 API Management

Your company uses Azure API Management as the public front-end to its APIs, to control access. You'd like to implement certificate authentication to ensure that only authorized clients are calling the API. In which policy section do you add the <authentication-certificate> policy?

A Outbound
B Backend
C On-Error
D Inbound

Xem giải thích

Đáp án

D — Mục Inbound.

Vì sao đúng

⚠ Policy authentication-certificate được đặt ở phần inbound (hoặc backend) để đính chứng chỉ khi gọi tiếp:

⚠ <policies>
⚠   <inbound>
⚠     <base />
⚠     <authentication-certificate thumbprint="..." />
⚠   </inbound>
⚠   ...
⚠ </policies>

Bốn mục policy	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

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

B (Backend) — ⚠ policy này CŨNG dùng được ở backend, ⚠ nhưng đề hỏi một đáp án và bộ đề chọn inbound.
A (Outbound) — ⚠ quá muộn: ⚠ backend đã được gọi xong rồi.
C (On-Error) — ⚠ chỉ chạy khi có lỗi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đề bài và policy trong khoá ⚠ hơi lệch nhau.

Vấn đề	Thực tế
⚠ Đề nói: xác thực để chỉ CLIENT được phép mới gọi được API
⚠ Nhưng `authentication-certificate` là để APIM đính chứng chỉ khi gọi BACKEND
⚠ Để kiểm tra chứng chỉ CLIENT thì dùng `validate-client-certificate`	⚠ hoặc kiểm `context.Request.Certificate`
⚠ Cả hai	⚠ đều đặt ở mục INBOUND
⚠ Nên khoá	⚠ D vẫn ĐÚNG về vị trí
⚠ Giữ nguyên khoá	⚠ D theo bộ đề gốc
⚠ Đối chiếu	⚠ #21433 ở lô trước về policy nói chung

⚠ Policy xác thực trong API Management: | Policy | Việc | |---|---| | ⚠ validate-client-certificate | ⚠ kiểm chứng chỉ CLIENT gửi lên | | ⚠ authentication-certificate | ⚠ APIM đính chứng chỉ khi gọi BACKEND | | ⚠ validate-jwt | ⚠ kiểm token JWT | | ⚠ authentication-basic | ⚠ basic auth tới backend | | ⚠ authentication-managed-identity | ⚠ dùng managed identity gọi backend |

Từ khoá nhận diện:

"kiểm chứng chỉ client" → ⚠ validate-client-certificate, ở inbound "APIM gọi backend bằng chứng chỉ" → ⚠ authentication-certificate "kiểm token" → ⚠ validate-jwt, ở inbound "sửa response" → ⚠ outbound

⚠ Quy tắc chung về vị trí policy	Quy tắc
⚠ Kiểm tra và từ chối SỚM → inbound
⚠ Xác thực với backend → backend hoặc inbound
⚠ Biến đổi hoặc che dữ liệu trả về → outbound
⚠ Xử lý lỗi → on-error
⚠ Nguyên tắc	⚠ từ chối càng sớm càng tiết kiệm tài nguyên

⚠ Đừng quên thẻ `<base />`	Nhắc lại
⚠ Thiếu nó thì policy cấp trên KHÔNG được áp dụng
⚠ Lỗi phổ biến nhất khi viết policy
⚠ Vị trí của `<base />`	⚠ quyết định policy cha chạy trước hay sau policy con

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang xác thực CLIENT hay xác thực với BACKEND | ⚠ hai policy khác nhau | | Policy có <base /> không | | | Có từ chối được sớm ở inbound không | |

Và nguyên tắc thiết kế policy trong API Management giúp tiết kiệm tài nguyên rõ rệt: từ chối request không hợp lệ ngay ở mục inbound, trước khi tốn một lời gọi tới backend.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Đáp án

Vì sao đúng theo khoá đáp án

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

Ghi chú về chất lượng câu hỏi

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ