Ngân hàng đề Microsoft Azure Developer

Câu 41 Non-Relational Data Management

You are developing an Azure application that needs to interact with Azure Blob Storage to upload files. You want to ensure that you are using the Azure SDK for .NET correctly. Which of the following code snippets properly uploads a file to Azure Blob Storage using the Azure.Storage.Blobs library?

A

// csharp
BlobClient blobClient = new BlobClient(connectionString, "my-container", "myfile.txt");
using FileStream uploadFileStream = File.OpenRead("path/to/myfile.txt");
blobClient.Upload(uploadFileStream, overwrite: true);

B

// csharp
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionString);
CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
CloudBlobContainer container = blobClient.GetContainerReference("my-container");
CloudBlockBlob blockBlob = container.GetBlockBlobReference("myfile.txt");
using (var fileStream = File.OpenRead("path/to/myfile.txt"))
{
    blockBlob.UploadFromStream(fileStream);
}

C

// csharp
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobContainerClient containerClient = blobServiceClient.GetBlobContainerClient("my-container");
BlobClient blobClient = containerClient.GetBlobClient("myfile.txt");
using FileStream uploadFileStream = File.OpenRead("path/to/myfile.txt");
blobClient.Upload(uploadFileStream);

D

// csharp
BlobServiceClient blobServiceClient = new BlobServiceClient(connectionString);
BlobContainerClient containerClient = blobServiceClient.GetBlobContainerClient("my-container");
BlobClient blobClient = containerClient.GetBlobClient("myfile.txt");
blobClient.UploadAsync(uploadFileStream, true);

Xem giải thích

Đáp án

A — Khởi tạo BlobClient trực tiếp và gọi Upload(stream, overwrite: true)

Vì sao đúng

Đoạn mã này đúng ở mọi chi tiết:

Dùng đúng thư viện Azure.Storage.Blobs mà đề yêu cầu.
Mở luồng bằng using, nên tệp được đóng đúng cách.
Truyền overwrite: true, nên chạy lại nhiều lần vẫn được.

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

**C. Cùng thư viện, dựng client theo tầng, nhưng gọi Upload(stream) không có overwrite — đây là phương án nhiễu gần nhất và nó chạy được đúng một lần: lần thứ hai sẽ ném ngoại lệ vì blob đã tồn tại. Một lỗi chỉ lộ ra ở lần chạy thứ hai.
**D. Gọi UploadAsync(...) mà không await — phương thức trả về Task bị bỏ rơi, nên chương trình chạy tiếp trong khi việc tải lên chưa xong và không ai biết nếu nó thất bại. Ngoài ra uploadFileStream chưa hề được khai báo.
B. Dùng CloudStorageAccount và CloudBlockBlob — đó là thư viện thế hệ cũ (Microsoft.WindowsAzure.Storage), không phải Azure.Storage.Blobs như đề yêu cầu.

Câu 42 Azure App Services

In ASP.NET, how do you write a message to the application diagnostics log that only shows up when the user has enabled warning level messages?

A Trace.WriteLine("message");
B Trace.TraceInformation("message");
C Trace.TraceWarning("message");
D Console.WriteLine("message");

Xem giải thích

Đáp án

C — Trace.TraceWarning("message");

Vì sao đúng

⚠ Lớp Trace của .NET Framework có phương thức riêng cho từng MỨC: | Phương thức | Mức log | |---|---| | ⚠ Trace.TraceError() | ⚠ Error | | ⚠ Trace.TraceWarning() | ⚠ Warning | | ⚠ Trace.TraceInformation() | ⚠ Information | | ⚠ Trace.WriteLine() | ⚠ Verbose |

⚠ App Service đặt mức log = Warning
        ↓
⚠ Ghi nhận: Error, Warning
⚠ Bỏ qua: Information, Verbose
        ↓
⚠ Chỉ TraceWarning và TraceError hiện ra

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

B (Trace.TraceInformation) — ⚠ mức Information: ⚠ ⚠ THẤP hơn Warning nên bị lọc bỏ.
A (Trace.WriteLine) — ⚠ mức Verbose, thấp nhất.
D (Console.WriteLine) — ⚠ không đi qua hệ thống diagnostics của App Service.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp song song với #21451 trong cùng lô.

Câu	Nền tảng	Khoá
⚠ #21445 (câu này)	⚠ ASP.NET (Framework)	⚠ Trace.TraceWarning
⚠ #21451	⚠ ASP.NET Core	⚠ logger.LogWarning
⚠ Cùng bài toán	⚠ ghi log mức Warning
⚠ Khác API	⚠ Trace cũ so với ILogger mới
⚠ Mẹo	⚠ nhận ra nền tảng trong đề rồi chọn API tương ứng

⚠ Thứ tự mức log — từ cao xuống thấp: | Mức | Ghi nhận khi đặt ngưỡng | |---|---| | ⚠ Critical / Error | ⚠ luôn ghi | | ⚠ Warning | ⚠ ghi nếu ngưỡng là Warning trở xuống | | ⚠ Information | ⚠ ghi nếu ngưỡng là Information trở xuống | | ⚠ Verbose / Debug / Trace | ⚠ chỉ ghi khi ngưỡng thấp nhất | | ⚠ Nguyên tắc | ⚠ đặt ngưỡng nào thì ghi mức đó TRỞ LÊN |

Từ khoá nhận diện:

"Trace.TraceXxx" → ⚠ ASP.NET Framework "logger.LogXxx" → ⚠ ASP.NET Core "Console.WriteLine" → ⚠ không vào diagnostics của App Service "mức cảnh báo" → ⚠ Warning

⚠ Chọn mức log cho môi trường thật	Chọn
⚠ Production: Warning hoặc Error	⚠ giảm khối lượng và chi phí
⚠ Gỡ lỗi tạm: Information hoặc Verbose
⚠ Nhớ hạ lại sau khi gỡ xong
⚠ Verbose trong production	⚠ rất tốn tiền lưu trữ và làm chậm ứng dụng

⚠ Ghi log gì và không ghi gì	Nguyên tắc
⚠ NÊN: mã lỗi, id tương quan, bước nghiệp vụ quan trọng
⚠ KHÔNG: mật khẩu, token, số thẻ, dữ liệu cá nhân
⚠ Rất hay vi phạm	⚠ log cả request body chứa thông tin nhạy cảm
⚠ Log là dữ liệu	⚠ và cũng cần được bảo vệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức log trên production đặt bao nhiêu | | | Log có chứa dữ liệu nhạy cảm không | | | Có id tương quan để lần theo một request không | |

Và lỗi bảo mật âm thầm nhất trong ghi log ứng dụng, thường chỉ phát hiện khi kiểm toán: log cả nội dung request chứa mật khẩu hoặc token. Nhật ký cũng là dữ liệu, và nó thường được sao chép đi nhiều nơi.

Câu 43 Azure App Service

You are deploying a web application to Azure App Service and want to ensure that the application automatically scales out during periods of high traffic. You configure the App Service Plan to use autoscaling based on CPU usage. However, you notice that the scaling operation is delayed, causing performance degradation during traffic spikes. Which of the following features should you enable to improve the responsiveness of autoscaling?

A
Auto Heal
B
Predictive Autoscale
C
Always On
D
Deployment Slots

Xem giải thích

Đáp án

B — Predictive Autoscale

Vì sao đúng

Predictive autoscale dùng học máy trên dữ liệu lịch sử của chính ứng dụng để dự đoán đợt tăng tải và co giãn trước khi nó xảy ra. Đây là điểm khác biệt thật so với tự co giãn thông thường: co giãn phản ứng luôn chậm một nhịp — tải tăng, chỉ số vượt ngưỡng, rồi mới thêm bản chạy, và người dùng chịu độ trễ trong khoảng thời gian đó.

Với ứng dụng có mẫu tải lặp lại theo ngày hoặc theo tuần thì cách này hiệu quả rõ rệt.

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

C. Always On — giữ ứng dụng không bị ngủ khi không có yêu cầu; giải bài toán khởi động lạnh, không phải bài toán co giãn.
A. Auto Heal — tự khởi động lại ứng dụng khi gặp điều kiện xấu (bộ nhớ cao, nhiều yêu cầu chậm); là cơ chế phục hồi, không thêm năng lực.
D. Deployment Slots — dùng cho phát hành không gián đoạn.

Câu 44 Container Registry

You are preparing to publish a Docker image to Azure Container Registry (ACR). Which of the following commands is used to log in to your Azure Container Registry from your local development environment before you push the image?

A
az acr push <your-acr-name>
B
docker push <your-acr-name>.azurecr.io/<your-image-name>:<tag>
C
docker login <your-acr-name>.azurecr.io
D
az acr login --name <your-acr-name>

Xem giải thích

Đáp án

C — docker login <your-acr-name>.azurecr.io

Vì sao đúng

Đây là lệnh Docker tiêu chuẩn để xác thực với một registry, và với ACR thì địa chỉ registry có dạng <tên>.azurecr.io. Sau khi đăng nhập, Docker lưu thông tin xác thực cục bộ và các lệnh docker push hay docker pull về registry đó hoạt động bình thường.

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

B. docker push — đẩy ảnh lên, và nó chỉ chạy được sau khi đã đăng nhập.
A. az acr push — không phải lệnh có thật; việc đẩy ảnh do Docker làm.

Một điểm cần nói thẳng

Phương án D — az acr login --name <tên> cũng đăng nhập được, và trên thực tế đây là cách thường được khuyến nghị hơn: nó dùng danh tính Azure bạn đang đăng nhập để lấy token, nên không phải nhập tên người dùng và mật khẩu của registry. Về bản chất nó là lớp bọc gọi tới chính docker login. Khoá đáp án của nguồn chọn C; điều đáng nhớ là cả hai đều dùng được, và az acr login tiện hơn khi bạn đã đăng nhập Azure CLI.

Câu 45 Azure App Service

What is an App Service Plan?

A A set of compute resources for a web app to run.
B An isolated physical environment including network available to your applications and no other Azure customer.
C A serverless environment in which App Services and Functions can run.
D A container running inside a VM.

Xem giải thích

Đáp án

A — Một tập tài nguyên tính toán để web app chạy trên đó.

Vì sao đúng

⚠ App Service Plan quyết định HẠ TẦNG và CHI PHÍ: | Plan quyết định | Nội dung | |---|---| | ⚠ Vùng | | | ⚠ Số instance | ⚠ quy mô ngang | | ⚠ Kích thước instance | ⚠ CPU, RAM — quy mô dọc | | ⚠ Bậc giá | ⚠ Free tới Isolated | | ⚠ Hệ điều hành | ⚠ Windows hoặc Linux |

⚠ App Service Plan (hạ tầng)
   ⚠ Web App 1
   ⚠ Web App 2
   ⚠ Function App
        ↓
⚠ TẤT CẢ dùng chung tài nguyên của plan
⚠ Trả tiền cho PLAN, không phải cho từng app

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

B (môi trường vật lý cách ly, không chia sẻ với khách hàng khác) — ⚠ đó là App Service ENVIRONMENT (ASE), ⚠ một khái niệm khác và đắt hơn nhiều.
C (môi trường serverless cho App Service và Functions) — ⚠ mô tả gói Consumption của Functions, không phải plan.
D (một container chạy trong VM) — ⚠ quá thu hẹp và không chính xác.

Ghi nhớ

⚠ Các bậc App Service Plan: | Bậc | Đặc điểm | |---|---| | ⚠ Free, Shared | ⚠ dùng chung, KHÔNG SLA, có hạn mức CPU | | ⚠ Basic | ⚠ máy riêng, có scale thủ công | | ⚠ Standard | ⚠ autoscale, slot triển khai, sao lưu | | ⚠ Premium | ⚠ hiệu năng cao hơn, nhiều slot hơn | | ⚠ Isolated | ⚠ chạy trong ASE, mạng cách ly |

Từ khoá nhận diện:

"tập tài nguyên tính toán" → ⚠ App Service Plan "môi trường cách ly hoàn toàn" → ⚠ App Service Environment "deployment slot" → ⚠ từ bậc Standard "autoscale" → ⚠ từ bậc Standard

⚠ Hệ quả của việc dùng chung plan	Hệ quả
⚠ Nhiều app trên một plan CHIA NHAU CPU và RAM
⚠ Một app ngốn tài nguyên làm chậm app khác
⚠ Nhưng tiết kiệm hơn nhiều plan riêng
⚠ Cân nhắc	⚠ tách plan riêng cho app quan trọng

⚠ Deployment slot — tính năng đáng giá nhất	Nội dung
⚠ Môi trường staging song song với production
⚠ Triển khai lên slot, kiểm thử, rồi SWAP
⚠ Swap là đổi chỗ, gần như không gián đoạn
⚠ Lỗi thì swap ngược lại ngay
⚠ Warm-up trước khi swap	⚠ tránh request đầu bị chậm
⚠ Có từ bậc	⚠ Standard

⚠ Cấu hình theo slot	Nội dung
⚠ Một số setting ĐI THEO slot khi swap
⚠ Một số setting Ở LẠI slot	⚠ đánh dấu "deployment slot setting"
⚠ Ví dụ	⚠ chuỗi kết nối CSDL nên ở lại slot
⚠ Quên đánh dấu	⚠ staging swap lên production mang theo cấu hình test

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu app dùng chung một plan | | | Có dùng deployment slot chưa | | | Setting nào cần đánh dấu ở lại slot | ⚠ tránh mang cấu hình test lên production |

Và tính năng của App Service đáng dùng nhất mà nhiều đội bỏ qua: deployment slot với thao tác swap. Nó biến việc triển khai thành một thao tác gần như không gián đoạn và quay lui được trong vài giây.

Câu 46 Cosmos DB

You are developing an application that uses Azure Cosmos DB as its database. The application requires low-latency reads and writes, and you need to ensure that the data is always available even in the event of a regional outage. Which of the following configurations should you implement in Cosmos DB to meet these requirements?

A
Enable Multi-Region Writes and set the Consistency Level to Strong
B
Enable Single-Region Writes and set the Consistency Level to Eventual
C
Enable Single-Region Writes and set the Consistency Level to Bounded Staleness
D
Enable Multi-Region Writes and set the Consistency Level to Session

Xem giải thích

Đáp án

D — Bật ghi đa vùng (multi-region writes) và đặt mức nhất quán là Session

Vì sao đúng

Ba yêu cầu của đề được thoả bởi hai lựa chọn:

Ghi đa vùng — ứng dụng ghi vào khu vực gần nó nhất thay vì phải đi tới một khu vực chính duy nhất, nên độ trễ ghi thấp; và mất một khu vực thì khu vực khác vẫn nhận ghi được.
Mức nhất quán Session — đây là điểm cân bằng thực dụng nhất: nó bảo đảm mỗi người dùng luôn đọc được thứ chính họ vừa ghi, mà không phải trả giá đồng bộ toàn cầu như mức Strong.

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

A. Ghi đa vùng cộng mức Strong — đây là bẫy chính, và nó không cấu hình được: Cosmos DB không cho dùng mức Strong cùng với ghi đa vùng, vì đồng bộ chặt trên phạm vi toàn cầu sẽ phá hỏng cam kết độ trễ.
B và C. Ghi một vùng — mọi thao tác ghi phải đi tới một khu vực duy nhất, nên độ trễ ghi cao với người dùng ở xa, và mất khu vực đó là không ghi được nữa.

Câu 47 Azure Container Instances

You have an Azure Container Instance with the DNS label "mycontainer". What is the public Fully-Qualified Domain Name (FQDN) for that instance?

A mycontainer.container.azure.com
B azurecontainer.io/mycontainer
C mycontainer.(azureregion).azurecontainer.io
D mycontainer.azurecontainer.io

Xem giải thích

Đáp án

C — mycontainer.(azureregion).azurecontainer.io

Vì sao đúng

⚠ FQDN của Azure Container Instance luôn có VÙNG ở giữa:

⚠ <nhãn DNS>.<vùng>.azurecontainer.io
        ↓
⚠ mycontainer.eastus.azurecontainer.io
⚠ mycontainer.southeastasia.azurecontainer.io

Vì sao có vùng ở giữa	Lý do
⚠ Nhãn DNS chỉ cần duy nhất TRONG một vùng
⚠ Không phải duy nhất toàn cầu
⚠ Hai người có thể cùng đặt "mycontainer" ở hai vùng khác nhau

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

D (mycontainer.azurecontainer.io) — ⚠ thiếu VÙNG: ⚠ đây là bẫy chính vì trông rất hợp lý.
A (mycontainer.container.azure.com) — ⚠ sai tên miền.
B (azurecontainer.io/mycontainer) — ⚠ sai cấu trúc: ⚠ đó là đường dẫn, không phải tên miền.

Ghi nhớ

⚠ Mẫu tên miền của các dịch vụ Azure — bảng đáng thuộc: | Dịch vụ | Mẫu FQDN | |---|---| | ⚠ Container Instances | ⚠ <nhãn>.<vùng>.azurecontainer.io | | ⚠ App Service | ⚠ <tên>.azurewebsites.net | | ⚠ Storage blob | ⚠ <tên>.blob.core.windows.net | | ⚠ Azure SQL | ⚠ <tên>.database.windows.net | | ⚠ Cosmos DB | ⚠ <tên>.documents.azure.com | | ⚠ Container Registry | ⚠ <tên>.azurecr.io | | ⚠ Key Vault | ⚠ <tên>.vault.azure.net |

Từ khoá nhận diện:

"có vùng ở giữa" → ⚠ Container Instances "azurewebsites.net" → ⚠ App Service "azurecr.io" → ⚠ Container Registry "core.windows.net" → ⚠ Storage

⚠ Vì sao mẫu tên miền quan trọng	Lý do
⚠ Cấu hình private endpoint cần đúng tên miền
⚠ Cấu hình tường lửa và DNS
⚠ Nhận diện dịch vụ khi đọc log
⚠ Với private endpoint	⚠ có tên miền riêng như `privatelink.blob.core.windows.net`

⚠ ACI — đặc điểm cần nhớ	Đặc điểm
⚠ Chạy container KHÔNG cần quản lý VM hay cụm
⚠ Khởi động trong vài giây
⚠ Tính tiền theo GIÂY
⚠ Hợp cho tác vụ ngắn, xử lý theo lô
⚠ Hạn chế	⚠ không tự co giãn, không cân bằng tải sẵn

⚠ Khi nào dùng ACI thay vì AKS	Khi nào
⚠ Tác vụ đơn lẻ, chạy rồi thoát
⚠ Không cần điều phối phức tạp
⚠ Cần khởi động cực nhanh
⚠ Kết hợp	⚠ AKS dùng Virtual Nodes để đẩy pod sang ACI khi cần bùng nổ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhãn DNS có duy nhất trong vùng không | | | Container có cần chạy liên tục không | ⚠ có thì cân nhắc Container Apps | | Có cần cân bằng tải không | ⚠ ACI không có sẵn |

Và điều cần nhớ về nhãn DNS của Container Instances, khác với nhiều dịch vụ khác: nó chỉ cần duy nhất trong phạm vi một vùng, không phải toàn cầu — và đó chính là lý do tên vùng xuất hiện trong tên miền.

Câu 48 Azure App Service

In ASP.NET Core, using the logger factory class, how do you write a message to the application diagnostics log that only shows up with the user has enabled warning level messages?

A logger.LogCritical("Message");
B logger.LogWarning("message");
C logger.LogError("Message");
D logger.LogDebug("Message");

Xem giải thích

Đáp án

B — logger.LogWarning("message");

Vì sao đúng

⚠ ASP.NET Core dùng giao diện ILogger với một phương thức cho mỗi mức: | Phương thức | Mức | |---|---| | ⚠ LogCritical | ⚠ nghiêm trọng nhất | | ⚠ LogError | ⚠ lỗi | | ⚠ LogWarning | ⚠ cảnh báo — đề này | | ⚠ LogInformation | ⚠ thông tin | | ⚠ LogDebug | ⚠ gỡ lỗi | | ⚠ LogTrace | ⚠ chi tiết nhất |

⚠ Ngưỡng đặt = Warning
        ↓
⚠ Ghi: Critical, Error, Warning
⚠ Bỏ: Information, Debug, Trace

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

C (LogError) và A (LogCritical) — ⚠ mức CAO HƠN Warning: ⚠ chúng sẽ hiện ra, ⚠ nhưng đề hỏi mức ⚠ chỉ hiện khi bật cảnh báo — ⚠ tức là đúng mức Warning.
D (LogDebug) — ⚠ mức THẤP hơn, bị lọc bỏ khi ngưỡng là Warning.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp song song với #21445 trong cùng lô.

Câu	Nền tảng	API	Khoá
⚠ #21445	⚠ ASP.NET Framework	⚠ Trace	⚠ Trace.TraceWarning
⚠ #21451 (câu này)	⚠ ASP.NET Core	⚠ ILogger	⚠ logger.LogWarning
⚠ Cùng bài toán	⚠ ghi log mức Warning
⚠ Cách làm bài	⚠ nhận ra nền tảng TRƯỚC, rồi chọn API tương ứng

⚠ Sáu mức log của ASP.NET Core — theo thứ tự: | Mức | Giá trị số | Dùng khi | |---|---|---| | ⚠ Trace | ⚠ 0 | ⚠ chi tiết nhất, có thể lộ dữ liệu | | ⚠ Debug | ⚠ 1 | ⚠ gỡ lỗi khi phát triển | | ⚠ Information | ⚠ 2 | ⚠ luồng chạy bình thường | | ⚠ Warning | ⚠ 3 | ⚠ bất thường nhưng chưa lỗi | | ⚠ Error | ⚠ 4 | ⚠ thất bại của một thao tác | | ⚠ Critical | ⚠ 5 | ⚠ hệ thống không dùng được |

Từ khoá nhận diện:

"ILogger, LogXxx" → ⚠ ASP.NET Core "Trace.TraceXxx" → ⚠ ASP.NET Framework "mức cảnh báo" → ⚠ Warning "cấu hình mức log" → ⚠ appsettings.json, mục Logging

⚠ Structured logging — điểm mạnh của ILogger	Nội dung
⚠ `logger.LogWarning("Đơn {OrderId} chậm {Ms}ms", id, ms)`
⚠ Tham số được lưu thành TRƯỜNG riêng
⚠ Truy vấn được: "tìm mọi đơn chậm hơn 500ms"
⚠ Đừng	⚠ nối chuỗi bằng dấu cộng — mất khả năng truy vấn
⚠ Đây là	⚠ khác biệt lớn nhất so với ghi log kiểu cũ

⚠ Cấu hình mức log theo namespace	Nội dung
⚠ Đặt mức khác nhau cho từng namespace
⚠ Ví dụ: mã của bạn ở Information, thư viện ở Warning
⚠ Cấu hình trong `appsettings.json`
⚠ Lợi ích	⚠ giảm nhiễu mà vẫn thấy được luồng ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dùng structured logging không | ⚠ hay nối chuỗi | | Mức log của thư viện bên thứ ba đặt bao nhiêu | | | Log có chứa dữ liệu nhạy cảm không | |

Và khác biệt lớn nhất giữa ghi log hiện đại và ghi log kiểu cũ, quyết định việc log có dùng được để điều tra hay không: tham số là TRƯỜNG DỮ LIỆU truy vấn được, chứ không phải chuỗi đã nối sẵn.

Câu 49 Virtual Machines

What does the PowerShell command 'Get-AzVMImageSku -Location "EastUS" -PublisherName "MicrosoftWindowsServer" -Offer "WindowsServer"' return?

A A list of available custom VM images in your Shared Image Gallery
B A list of publicly available Windows Server OS images in the EastUS region.
C A list of running virtual machines on your subscription

Xem giải thích

Đáp án

B — Danh sách các ảnh hệ điều hành Windows Server công khai ở vùng EastUS.

Vì sao đúng

⚠ Ảnh máy ảo trên Azure Marketplace được định danh bằng BỐN phần: | Phần | Ví dụ | |---|---| | ⚠ Location | ⚠ EastUS | | ⚠ Publisher | ⚠ MicrosoftWindowsServer | | ⚠ Offer | ⚠ WindowsServer | | ⚠ SKU | ⚠ 2022-Datacenter, 2019-Datacenter | | ⚠ Version | ⚠ latest hoặc số cụ thể |

⚠ Get-AzVMImagePublisher  → liệt kê PUBLISHER
⚠ Get-AzVMImageOffer      → liệt kê OFFER
⚠ Get-AzVMImageSku        → liệt kê SKU
⚠ Get-AzVMImage           → liệt kê VERSION
        ↓
⚠ Đi từ rộng tới hẹp

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

A (ảnh tuỳ chỉnh trong Shared Image Gallery) — ⚠ đó là Get-AzGalleryImageDefinition; ⚠ lệnh trong đề tìm ảnh ⚠ công khai trên Marketplace.
C (danh sách máy ảo đang chạy) — ⚠ đó là Get-AzVM.

Ghi nhớ

⚠ Chuỗi bốn lệnh tìm ảnh — nhớ theo thứ tự: | Lệnh | Trả về | |---|---| | ⚠ Get-AzVMImagePublisher -Location | ⚠ ai phát hành | | ⚠ Get-AzVMImageOffer -PublisherName | ⚠ dòng sản phẩm | | ⚠ Get-AzVMImageSku -Offer | ⚠ phiên bản cụ thể | | ⚠ Get-AzVMImage -Skus | ⚠ số hiệu bản dựng | | ⚠ Mỗi lệnh | ⚠ cần kết quả của lệnh trước làm tham số |

Từ khoá nhận diện:

"ảnh công khai trên Marketplace" → ⚠ Get-AzVMImage* "ảnh tuỳ chỉnh của tôi" → ⚠ Shared Image Gallery / Azure Compute Gallery "máy ảo đang chạy" → ⚠ Get-AzVM "URN" → ⚠ publisher:offer:sku:version

⚠ URN — cách viết gọn khi tạo VM	Nội dung
⚠ `MicrosoftWindowsServer:WindowsServer:2022-Datacenter:latest`
⚠ Bốn phần ngăn bằng dấu hai chấm
⚠ Dùng trong `az vm create --image`
⚠ `latest`	⚠ tiện nhưng KHÔNG lặp lại được — bản dựng thay đổi theo thời gian

⚠ Azure Compute Gallery — cho ảnh riêng	Nội dung
⚠ Tên cũ: Shared Image Gallery
⚠ Lưu ảnh tuỳ chỉnh của tổ chức
⚠ Nhân bản sang nhiều vùng
⚠ Quản lý phiên bản ảnh
⚠ Dùng khi	⚠ có ảnh chuẩn của công ty đã cài sẵn phần mềm và cấu hình

⚠ Vì sao nên ghim phiên bản ảnh	Lý do
⚠ `latest` đổi nội dung theo thời gian
⚠ Máy tạo hôm nay khác máy tạo tháng trước
⚠ Khó tái tạo môi trường y hệt
⚠ Với môi trường thật	⚠ ghim số phiên bản cụ thể

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang tìm ảnh công khai hay ảnh riêng | | | Có ghim phiên bản ảnh không | | | Có nên dùng Compute Gallery cho ảnh chuẩn không | |

Và lý do nên ghim số phiên bản ảnh thay vì dùng latest trong template hạ tầng: hai lần triển khai cách nhau vài tháng sẽ cho ra hai máy ảo khác nhau, và đó là kiểu khác biệt rất khó lần ra khi gỡ lỗi.

Câu 50 Azure Redis Cache

What is it that makes a caching system like Redis Cache faster than a traditional data store like Azure SQL Database?

A Stores data in memory
B Uses premium solid state disks
C Runs on the most powerful servers
D The Redis service runs on the same physical hardware as your application

Xem giải thích

Đáp án

A — Lưu dữ liệu TRONG BỘ NHỚ.

Vì sao đúng

⚠ Khác biệt căn bản nằm ở nơi dữ liệu nằm:

⚠ Azure SQL Database
   ⚠ dữ liệu trên ĐĨA
   ⚠ đọc đĩa: mili giây
        ↓
⚠ Redis
   ⚠ dữ liệu trong RAM
   ⚠ đọc RAM: micro giây
        ↓
⚠ Nhanh hơn hàng trăm tới hàng nghìn lần

Vì sao RAM nhanh hơn đĩa	Lý do
⚠ Không có chuyển động cơ học
⚠ Truy cập ngẫu nhiên tức thì
⚠ Không qua hệ thống tệp và bộ đệm
⚠ Kèm theo	⚠ cấu trúc dữ liệu đơn giản, không có JOIN hay giao dịch phức tạp

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

B (dùng đĩa SSD cao cấp) — ⚠ SSD nhanh hơn HDD nhưng ⚠ vẫn chậm hơn RAM rất nhiều.
C (chạy trên máy chủ mạnh nhất) — ⚠ không phải lý do: ⚠ CSDL quan hệ cũng chạy trên máy mạnh.
D (chạy cùng phần cứng vật lý với ứng dụng) — ⚠ SAI: ⚠ Redis là dịch vụ riêng, ⚠ và độ trễ mạng vẫn tồn tại.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #19504 và #21434, #21437 về Redis.

Câu	Hỏi gì	Khoá
⚠ #19504	⚠ chi phí Redis phụ thuộc gì	⚠ vùng, bậc, số giờ
⚠ #21434	⚠ vượt giới hạn bộ nhớ	⚠ Redis Cluster, thêm shard
⚠ #21437	⚠ xoá khoá chủ động	⚠ đặt TTL
⚠ #21453 (câu này)	⚠ vì sao Redis nhanh	⚠ lưu trong bộ nhớ
⚠ Bốn câu	⚠ vẽ trọn chủ đề Redis qua hai lô

⚠ Cái giá của việc lưu trong bộ nhớ: | Cái giá | Nội dung | |---|---| | ⚠ RAM ĐẮT hơn đĩa nhiều lần | | | ⚠ Dung lượng hạn chế hơn | | | ⚠ Mất điện là mất dữ liệu | ⚠ trừ khi bật bền vững | | ⚠ Không có truy vấn phức tạp | | | ⚠ Vì vậy | ⚠ Redis là CACHE, không phải kho lưu trữ chính |

Từ khoá nhận diện:

"trong bộ nhớ, micro giây" → ⚠ Redis "trên đĩa, có giao dịch" → ⚠ CSDL quan hệ "cache tăng tốc đọc" → ⚠ Redis "nguồn sự thật" → ⚠ CSDL, không phải cache

⚠ Bền vững dữ liệu trong Redis	Cơ chế
⚠ RDB	⚠ chụp ảnh định kỳ
⚠ AOF	⚠ ghi lại mọi lệnh ghi
⚠ Có ở bậc Premium
⚠ Nhưng	⚠ vẫn không nên coi Redis là kho lưu trữ chính

⚠ Ngoài cache, Redis còn dùng làm gì	Dùng làm
⚠ Lưu session	⚠ bỏ được session affinity ở load balancer
⚠ Bảng xếp hạng	⚠ sorted set
⚠ Hàng đợi nhẹ và pub/sub
⚠ Khoá phân tán
⚠ Đếm và giới hạn tần suất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có chạy được khi cache trống không | ⚠ nguyên tắc quan trọng nhất | | Dữ liệu trong Redis có phải nguồn sự thật không | ⚠ không nên | | Tỉ lệ trúng cache là bao nhiêu | |

Và ranh giới không nên vượt qua khi dùng Redis, dù nó có tính năng bền vững dữ liệu: nó là bản sao tăng tốc, không phải nơi cất giữ duy nhất của bất kỳ dữ liệu nào.

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

Đáp án

Vì sao đúng

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

Đá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

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

Một điểm cần nói thẳng

Đá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

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ớ