Ngân hàng đề Microsoft Azure Developer

Câu 11 Azure Functions

Azure Functions store their configuration settings in which file?

A default.js
B index.js
C function.json
D web.config

Xem giải thích

Đáp án

C — function.json

Vì sao đúng

⚠ Mỗi hàm có một thư mục riêng, và function.json mô tả cấu hình của nó:

⚠ MyFunctionApp/
⚠   host.json           ← cấu hình CHUNG cho cả app
⚠   local.settings.json ← cấu hình khi chạy cục bộ
⚠   HamCuaToi/
⚠     function.json     ← binding của RIÊNG hàm này
⚠     index.js          ← mã nguồn

Nội dung `function.json`	Nội dung
⚠ Danh sách binding	⚠ trigger, input, output
⚠ Hướng của mỗi binding	⚠ in hoặc out
⚠ Tên biến trong mã
⚠ Đường dẫn tới mã nguồn	⚠ scriptFile
⚠ Bật tắt hàm	⚠ disabled

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

B (index.js) — ⚠ là MÃ NGUỒN của hàm (với JavaScript), không phải cấu hình.
D (web.config) — ⚠ là cấu hình của IIS và ASP.NET, không dùng cho Functions.
A (default.js) — ⚠ không phải tệp chuẩn nào của Azure Functions.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21406 trong cùng lô — ⚠ #21406 hỏi số lượng binding, ⚠ câu này hỏi chúng được khai ở đâu.

⚠ Các tệp cấu hình của Azure Functions: | Tệp | Phạm vi | Nội dung | |---|---|---| | ⚠ function.json | ⚠ MỘT hàm | ⚠ binding | | ⚠ host.json | ⚠ CẢ app | ⚠ timeout, logging, retry, concurrency | | ⚠ local.settings.json | ⚠ chỉ khi chạy cục bộ | ⚠ chuỗi kết nối để dev | | ⚠ Application settings | ⚠ trên Azure | ⚠ biến môi trường thật |

Từ khoá nhận diện:

"binding của một hàm" → ⚠ function.json "cấu hình chung, timeout, retry" → ⚠ host.json "chuỗi kết nối khi chạy máy mình" → ⚠ local.settings.json "biến môi trường trên Azure" → ⚠ Application settings

⚠ Mô hình BIÊN DỊCH thì khác	Khác biệt
⚠ C# và Java dùng ATTRIBUTE trong mã	⚠ `[BlobTrigger]`, `[QueueOutput]`
⚠ `function.json` được SINH RA khi build
⚠ Không sửa tay tệp đó
⚠ JavaScript, Python, PowerShell	⚠ viết `function.json` trực tiếp
⚠ Python model mới (v2)	⚠ cũng dùng decorator trong mã

⚠ Cảnh báo bảo mật quan trọng	Cảnh báo
⚠ `local.settings.json` chứa chuỗi kết nối THẬT
⚠ KHÔNG BAO GIỜ commit tệp này vào Git
⚠ Mặc định nằm trong `.gitignore` — đừng gỡ ra
⚠ Trên Azure	⚠ dùng Application settings hoặc Key Vault reference

⚠ host.json — điều đáng cấu hình	Điều
⚠ `functionTimeout`	⚠ thời gian tối đa một lần chạy
⚠ Số lượng xử lý đồng thời	⚠ batchSize cho queue
⚠ Chính sách thử lại
⚠ Mức ghi log và lấy mẫu	⚠ ảnh hưởng chi phí Application Insights

Ba việc kiểm chứng: | Việc | Cách | |---|---| | local.settings.json có bị commit không | ⚠ kiểm tra ngay | | Bí mật lấy từ Key Vault hay ghi thẳng | | | functionTimeout có đủ cho tác vụ dài không | |

Và tệp cần kiểm tra ngay trong bất kỳ kho mã Azure Functions nào: local.settings.json có bị commit lên Git không. Nó chứa chuỗi kết nối thật, và đó là một trong những cách rò rỉ bí mật phổ biến nhất.

Câu 12 Containers

You are tasked with deploying a containerized application using Azure Container Instances (ACI). You want to ensure that your ACI instance has access to a specific Azure Storage account for persistent data storage. Which of the following configurations will allow your container to access the Azure Storage account when deployed?

A
Use a volume mount to mount an Azure File share from the Azure Storage account to the container when creating the ACI instance.
B
Create a new ACI instance with the `--cpu` and `--memory` parameters, and specify the storage account connection string in the container environment variables.
C
Deploy the ACI instance with the `--restart-policy` set to `Always`, and the storage account connection string provided as a command-line argument.
D
Create the ACI instance with the Azure Storage account's access key as a secret in the Azure Key Vault and configure the ACI instance to pull the secret at runtime.

Xem giải thích

Đáp án

A — Dùng volume mount để gắn một Azure File share từ tài khoản lưu trữ

Vì sao đúng

Container Instances hỗ trợ gắn Azure File share làm volume, và đó là cách chuẩn để container đọc ghi dữ liệu bền vững. Điểm quan trọng: container vốn là tạm thời — mọi thứ ghi vào hệ tệp bên trong nó biến mất khi container dừng. Volume mount là cách duy nhất để dữ liệu sống lâu hơn container.

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

D. Đưa khoá tài khoản lưu trữ vào dưới dạng secret — cho container thông tin đăng nhập để tự gọi API lưu trữ, nhưng ứng dụng phải tự viết mã gọi API; volume mount thì ứng dụng chỉ cần đọc ghi theo đường dẫn tệp như bình thường.
B. Khai --cpu và --memory — cấp phát tài nguyên tính toán, không liên quan tới lưu trữ.
C. Đặt --restart-policy thành Always — quyết định container có tự khởi động lại hay không.

Câu 13 Azure App Service

You are configuring diagnostics logging for an Azure Web App. You want to ensure that all application logs, including trace logs and IIS logs, are stored in a centralized location for long-term retention and analysis. Which of the following Azure services should you use to achieve this?

A
Azure Application Insights
B
Azure Storage Account
C
Azure Event Hubs
D
Azure Log Analytics

Xem giải thích

Đáp án

B — Azure Storage Account

Vì sao đúng

Trong phần diagnostics logging của App Service, Storage Account là đích duy nhất nhận được cả hai loại mà đề yêu cầu: application log (bao gồm trace) và web server log của IIS. Log được ghi thành tệp trong blob container, giữ lâu tuỳ chính sách bạn đặt và chi phí rất thấp.

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

A. Application Insights — công cụ rất mạnh cho telemetry ứng dụng, nhưng nó không phải nơi nhận log thô của máy chủ IIS theo cấu hình diagnostics; nó tập trung vào dữ liệu do SDK gửi lên.
D. Log Analytics — nhận được log qua diagnostic settings, nhưng chi phí nạp dữ liệu cao hơn hẳn khi mục đích chỉ là lưu trữ tập trung như đề nêu.
C. Event Hubs — là kênh truyền để đẩy log sang hệ thống khác, không phải nơi lưu trữ.

Câu 14 Container Registry

You have a docker image in your local repository that you'd like to share with the Azure Container Register. Your local repository image is named myimage, and your ACR is named myacr.azurecr.io. What is the command to get the image from your local into ACR?

A docker build myacr.azurecr.io/myimage
B docker save myimage
C docker push azurecr.io/myacr/myimage
D docker push myacr.azurecr.io/myimage

Xem giải thích

Đáp án

D — docker push myacr.azurecr.io/myimage

Vì sao đúng

⚠ Docker quyết định đẩy ảnh đi ĐÂU dựa trên chính TÊN của ảnh:

⚠ Tên ảnh có dạng
   ⚠ <registry>/<repository>:<tag>
        ↓
⚠ myacr.azurecr.io/myimage
   ⚠ registry = myacr.azurecr.io
   ⚠ repository = myimage
        ↓
⚠ docker push đọc phần registry và đẩy tới đó

⚠ Quy trình đầy đủ: | Bước | Lệnh | |---|---| | ⚠ 1. Đăng nhập | ⚠ az acr login --name myacr | | ⚠ 2. Gắn thẻ lại | ⚠ docker tag myimage myacr.azurecr.io/myimage | | ⚠ 3. Đẩy lên | ⚠ docker push myacr.azurecr.io/myimage |

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

C (docker push azurecr.io/myacr/myimage) — ⚠ SAI THỨ TỰ: ⚠ tên registry là ⚠ myacr.azurecr.io, ⚠ không phải azurecr.io/myacr.
A (docker build myacr.azurecr.io/myimage) — ⚠ build không đẩy ảnh đi, và cú pháp cũng thiếu.
B (docker save myimage) — ⚠ xuất ảnh ra tệp tar, không liên quan tới registry.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21410 trong cùng lô.

Câu	Hỏi gì	Khoá
⚠ #21410	⚠ `az acr build` làm gì	⚠ build trên đám mây rồi đẩy
⚠ #21417 (câu này)	⚠ đẩy ảnh cục bộ lên ACR thế nào	⚠ tag rồi push với tên đầy đủ
⚠ Hai cách	⚠ build cục bộ rồi push, hoặc để ACR build hộ

⚠ Cấu trúc tên ảnh Docker: | Thành phần | Ví dụ | |---|---| | ⚠ Registry | ⚠ myacr.azurecr.io | | ⚠ Repository | ⚠ myimage hoặc team/myimage | | ⚠ Tag | ⚠ v1, latest | | ⚠ Đầy đủ | ⚠ myacr.azurecr.io/team/myimage:v1 | | ⚠ Không có registry | ⚠ Docker mặc định là Docker Hub |

Từ khoá nhận diện:

"đẩy lên ACR" → ⚠ tag theo <acr>.azurecr.io/... rồi push "build trên đám mây" → ⚠ az acr build "xuất ra tệp" → ⚠ docker save "kéo về" → ⚠ docker pull

⚠ Vì sao phải tag lại trước khi push	Lý do
⚠ Docker KHÔNG có tham số chỉ định đích
⚠ Đích được suy ra từ TÊN ảnh
⚠ Ảnh tên `myimage` sẽ bị đẩy lên Docker Hub
⚠ Đó là	⚠ lỗi hay gặp nhất khi mới dùng registry riêng
⚠ Nguy hiểm nếu	⚠ ảnh chứa mã nội bộ mà bị đẩy nhầm lên registry công khai

⚠ Thực hành tốt với thẻ ảnh	Thực hành
⚠ Tránh dùng `latest` cho môi trường thật	⚠ không biết đang chạy bản nào
⚠ Dùng số phiên bản hoặc mã commit
⚠ Bật content trust nếu cần ký ảnh	⚠ bậc Premium
⚠ Quét lỗ hổng ảnh	⚠ Defender for Containers

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh đã tag đúng tên registry chưa | ⚠ tránh đẩy nhầm lên Docker Hub | | Có dùng latest trong môi trường thật không | | | Ảnh đã được quét lỗ hổng chưa | |

Và lỗi nguy hiểm nhất khi làm việc với registry riêng, xuất phát từ chính cách Docker hoạt động: quên gắn thẻ tên registry và vô tình đẩy ảnh nội bộ lên Docker Hub công khai.

Câu 15 Non-relational DB

Which CosmosDB API format works best with document (JSON) data?

A Graph API
B Core SQL
C MongoDB API
D Cassandra API

Xem giải thích

Đáp án

B — Core SQL.

Vì sao đúng

⚠ Core (SQL) là API GỐC của Cosmos DB, thiết kế cho tài liệu JSON: | Đặc điểm | Nội dung | |---|---| | ⚠ Lưu tài liệu JSON | | | ⚠ Truy vấn bằng cú pháp giống SQL | | | ⚠ Được cập nhật tính năng SỚM NHẤT | | | ⚠ Hỗ trợ đầy đủ nhất | ⚠ change feed, stored procedure, trigger |

⚠ Ứng dụng MỚI với JSON
        ↓
⚠ Core SQL API là lựa chọn mặc định

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

C (MongoDB API) — ⚠ cũng là CSDL tài liệu, ⚠ nhưng dành cho ⚠ DI CHUYỂN ứng dụng Mongo sẵn có.
D (Cassandra API) — ⚠ cột rộng.
A (Graph API) — ⚠ Gremlin, cho đồ thị.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ TRÙNG HOÀN TOÀN với #19566 ở lô trước, ⚠ nhưng ⚠ THỨ TỰ PHƯƠNG ÁN ĐÃ BỊ XÁO.

Câu	Chứng chỉ	Vị trí đáp án
⚠ #19566	⚠ Azure Data Fundamentals	⚠ A — Core SQL
⚠ #21418 (câu này)	⚠ Azure Developer	⚠ B — Core SQL
⚠ Đề bài	⚠ giống nhau TỪNG CHỮ
⚠ Phương án	⚠ cùng bốn lựa chọn, xáo thứ tự
⚠ Bài học	⚠ ĐỪNG học thuộc CHỮ CÁI đáp án — hãy nhớ NỘI DUNG
⚠ Nhận xét	⚠ bộ đề dùng chung câu hỏi giữa các chứng chỉ khác nhau

⚠ Cũng lưu ý: ⚠ tên "Core (SQL) API" là ⚠ tên CŨ; ⚠ nay Microsoft gọi là ⚠ "Azure Cosmos DB for NoSQL".

⚠ Năm API — tên cũ và tên mới: | Tên cũ | Tên mới | Mô hình | |---|---|---| | ⚠ Core (SQL) | ⚠ for NoSQL | ⚠ tài liệu | | ⚠ MongoDB | ⚠ for MongoDB | ⚠ tài liệu | | ⚠ Cassandra | ⚠ for Apache Cassandra | ⚠ cột rộng | | ⚠ Gremlin | ⚠ for Apache Gremlin | ⚠ đồ thị | | ⚠ Table | ⚠ for Table | ⚠ khoá-giá trị |

Từ khoá nhận diện:

"JSON, ứng dụng mới" → ⚠ Core SQL / for NoSQL "di chuyển từ MongoDB" → ⚠ for MongoDB "khoá-giá trị" → ⚠ for Table "đồ thị" → ⚠ for Gremlin

⚠ Vì sao chọn API gốc cho ứng dụng mới	Lý do
⚠ Tính năng mới ra ở đây TRƯỚC
⚠ Hỗ trợ đầy đủ nhất
⚠ Tích hợp tốt nhất với Synapse Link và vector search
⚠ API tương thích	⚠ luôn chậm hơn một nhịp

⚠ Nhắc lại quyết định vĩnh viễn	Quyết định
⚠ API chọn lúc TẠO TÀI KHOẢN, không đổi được
⚠ Partition key chọn lúc tạo container, không đổi được
⚠ Vì vậy	⚠ giai đoạn thiết kế rất quan trọng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng mới hay đang di chuyển | | | Đang đọc tài liệu dùng tên cũ hay mới | | | Partition key đã theo mẫu truy vấn chưa | |

Và điều câu hỏi trùng lặp này nhắc nhở rõ nhất về cách ôn thi: nhớ NỘI DUNG đáp án chứ đừng nhớ chữ cái. Cùng một câu hỏi xuất hiện ở hai chứng chỉ với thứ tự phương án khác nhau.

Câu 16 Monitoring

You would like to receive an email every time a new Azure Container Registry is created. Which of the following steps would accomplish that goal?

A Azure Service Health can monitor your Azure account and Alert you when new resources are created on your account.
B Create an Azure Automation Runbook that checks your Account every 15 minutes for new resources and alerts you as new ones are created.
C Using Azure Event Grid, you can connect into the Azure subscription to receive alerts for resources created. The Event Grid can filter those events to only Azure Container Registry, and call a Function.
D Go into Azure Monitor. Go into Alerts. Select the Subscription scope. Select the Create or Update Container Registry signal. Add the action group that emails you. Give it a name and click save.

Xem giải thích

Đáp án

D — Vào Azure Monitor → Alerts, chọn phạm vi Subscription, chọn tín hiệu "Create or Update Container Registry", thêm action group gửi email.

Vì sao đúng

⚠ Đây là cách dùng cảnh báo Activity Log của Azure Monitor:

⚠ Ai đó tạo ACR mới
        ↓
⚠ Sự kiện ghi vào ACTIVITY LOG
        ↓ ⚠ Alert rule khớp tín hiệu
⚠ Action group được kích hoạt
        ↓
⚠ Email, SMS, webhook, Logic App

Thành phần	Vai trò
⚠ Scope	⚠ subscription, resource group, hoặc tài nguyên
⚠ Signal	⚠ thao tác cần theo dõi
⚠ Condition	⚠ lọc thêm nếu cần
⚠ Action group	⚠ làm gì khi khớp

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

B (Automation Runbook quét mỗi 15 phút) — ⚠ giải pháp thủ công, kém hiệu quả: ⚠ có độ trễ, tốn chi phí, phải tự viết và bảo trì.
A (Azure Service Health) — ⚠ theo dõi SỰ CỐ của chính dịch vụ Azure, ⚠ không phải thao tác của bạn.
C (Event Grid) — ⚠ xem mục chất lượng câu hỏi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án C ⚠ cũng là một cách làm hợp lệ.

Phương án	Thực tế
⚠ C — Event Grid	⚠ Event Grid CÓ nguồn sự kiện cấp subscription
⚠ Đăng ký sự kiện tạo tài nguyên được	⚠ `Microsoft.Resources.ResourceWriteSuccess`
⚠ Lọc theo loại tài nguyên được
⚠ D (khoá) — Azure Monitor Alert	⚠ cách ĐƠN GIẢN và trực tiếp hơn cho việc gửi email
⚠ Vì sao bộ đề chọn D	⚠ Monitor Alert có sẵn action group gửi email, không phải viết mã
⚠ Event Grid	⚠ cần thêm một handler để gửi email — Logic App hoặc Function
⚠ Giữ nguyên khoá	⚠ D theo bộ đề gốc

⚠ Ba loại cảnh báo của Azure Monitor: | Loại | Nguồn | |---|---| | ⚠ Metric alert | ⚠ số liệu: CPU, độ trễ | | ⚠ Log alert | ⚠ truy vấn KQL trên Log Analytics | | ⚠ Activity log alert | ⚠ thao tác trên tài nguyên — câu này |

Từ khoá nhận diện:

"ai tạo, sửa, xoá tài nguyên" → ⚠ Activity log alert "CPU vượt ngưỡng" → ⚠ metric alert "tìm mẫu trong log" → ⚠ log alert "phản ứng bằng mã khi có sự kiện" → ⚠ Event Grid

⚠ Monitor Alert và Event Grid — khi nào dùng cái nào	Khi nào
⚠ Chỉ cần THÔNG BÁO cho người	⚠ Monitor Alert
⚠ Cần TỰ ĐỘNG XỬ LÝ bằng mã	⚠ Event Grid
⚠ Cần định tuyến sự kiện tới nhiều hệ thống	⚠ Event Grid
⚠ Ranh giới	⚠ thông báo hay hành động

⚠ Action group — làm được gì	Làm được
⚠ Email, SMS, thông báo đẩy
⚠ Gọi webhook
⚠ Kích hoạt Logic App, Function, Runbook
⚠ Tạo ticket trong ITSM
⚠ Tái dùng được	⚠ một action group cho nhiều alert rule

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần thông báo hay cần xử lý tự động | | | Ai nhận cảnh báo và có ai đọc không | | | Có bị cảnh báo nhiễu quá nhiều không | |

Và ranh giới thực dụng giữa hai cách tiếp cận, đúng cho hầu hết tình huống giám sát: cần báo cho người thì dùng cảnh báo, cần máy xử lý thì dùng sự kiện.

Câu 17 Container Registry

You have an Azure Container Registry named 'contoso.azurecr.io'. There are several departments in your company that need to push images to the registry, and you want to keep them organized. You decide to use repository namespaces to separate out 'sales', 'marketing', 'technology' and 'customerservice'. How do you pull down the container image for the 'website' project located in the marketing namespace?

A docker pull marketing.contoso.azurecr.io/website
B docker pull contoso.azurecr.io -path marketing -project website
C docker pull contoso.azurecr.io/marketing/website
D docker pull contoso.azurecr.io -location marketing/website

Xem giải thích

Đáp án

C — docker pull contoso.azurecr.io/marketing/website

Vì sao đúng

⚠ Namespace trong ACR chỉ đơn giản là DẤU GẠCH CHÉO trong tên repository:

⚠ contoso.azurecr.io/marketing/website
⚠ └── registry ──┘ └─ ns ─┘└─ tên ─┘
        ↓
⚠ Registry: contoso.azurecr.io
⚠ Repository: marketing/website

Tổ chức bằng namespace	Ví dụ
⚠ Theo phòng ban	⚠ sales/, marketing/, technology/
⚠ Theo môi trường	⚠ dev/, prod/
⚠ Theo nhóm sản phẩm
⚠ Lồng nhiều tầng được	⚠ `marketing/web/frontend`

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

A (marketing.contoso.azurecr.io/website) — ⚠ sai: ⚠ namespace ⚠ không phải tên miền con; ⚠ registry vẫn là contoso.azurecr.io.
B và D (-path, -location) — ⚠ không có tham số nào như vậy trong docker pull.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #21410, #21417, #21425 về ACR trong lô.

Câu	Hỏi gì	Khoá
⚠ #21410	⚠ `az acr build` làm gì	⚠ build trên đám mây rồi đẩy
⚠ #21417	⚠ đẩy ảnh cục bộ lên ACR	⚠ tag đầy đủ rồi push
⚠ #21420 (câu này)	⚠ kéo ảnh trong namespace	⚠ registry/namespace/tên
⚠ Điểm chung	⚠ mọi thứ nằm trong TÊN ảnh, không có tham số riêng

⚠ Cấu trúc tên ảnh — chốt lại: | Phần | Ví dụ | |---|---| | ⚠ Registry | ⚠ contoso.azurecr.io | | ⚠ Namespace | ⚠ marketing | | ⚠ Repository | ⚠ website | | ⚠ Tag | ⚠ :v1 | | ⚠ Đầy đủ | ⚠ contoso.azurecr.io/marketing/website:v1 |

Từ khoá nhận diện:

"namespace" → ⚠ chỉ là dấu gạch chéo trong tên repository "tên miền con" → ⚠ KHÔNG phải cách ACR hoạt động "tham số -path, -location" → ⚠ không tồn tại

⚠ Phân quyền theo namespace	Nội dung
⚠ ACR hỗ trợ repository-scoped token
⚠ Cấp quyền cho từng namespace riêng
⚠ Nhóm marketing chỉ đẩy được vào `marketing/`
⚠ Có ở bậc	⚠ Premium
⚠ Không có tính năng đó	⚠ thì quyền là toàn registry

⚠ Quản lý dung lượng ACR	Quản lý
⚠ Ảnh cũ tích tụ rất nhanh
⚠ Đặt chính sách xoá tự động	⚠ retention policy cho manifest chưa gắn thẻ
⚠ `az acr run` với purge task
⚠ Không dọn	⚠ hoá đơn lưu trữ tăng đều mà không ai để ý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Namespace có phản ánh cách tổ chức đội không | | | Có phân quyền theo namespace không | | | Có chính sách dọn ảnh cũ chưa | |

Và điều cần hiểu đúng về namespace trong registry Docker: nó không phải một thực thể riêng biệt nào cả, chỉ là quy ước đặt tên có dấu gạch chéo. Toàn bộ sức mạnh tổ chức đến từ việc bạn dùng quy ước đó nhất quán.

Câu 18 Azure Storage

You are developing an Azure application that stores images in Azure Blob Storage. You need to set custom metadata on a blob to track the image's resolution and color profile. Which of the following code snippets correctly sets the metadata for a blob in C#?

A

// csharp
await blobClient.SetMetadataAsync(new Dictionary<string, string>
{
    { "Resolution", "1920x1080" },
    { "ColorProfile", "sRGB" }
});

B

// csharp
await blobClient.UploadAsync(fileStream);
blobClient.Metadata["Resolution"] = "1920x1080";
blobClient.Metadata["ColorProfile"] = "sRGB";
await blobClient.SetMetadataAsync();

C

// csharp
await blobClient.SetPropertiesAsync(new BlobHttpHeaders
{
    ContentType = "image/jpeg"
});

D

// csharp
var metadata = new Dictionary<string, string>
{
    { "Resolution", "1920x1080" },
    { "ColorProfile", "sRGB" }
};
await blobClient.UploadAsync(fileStream, new BlobHttpHeaders(), metadata);

Xem giải thích

Đáp án

A — await blobClient.SetMetadataAsync(new Dictionary<string, string> { ... });

Vì sao đúng

SetMetadataAsync là phương thức đúng để gán siêu dữ liệu tuỳ chỉnh cho blob, và nó nhận thẳng một Dictionary<string, string>. Lời gọi này gửi một yêu cầu riêng tới dịch vụ để cập nhật siêu dữ liệu, tách biệt với việc tải nội dung lên.

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

B. Gán vào blobClient.Metadata[...] rồi gọi SetMetadataAsync() không tham số — BlobClient không có thuộc tính Metadata để gán như vậy; siêu dữ liệu phải truyền vào lời gọi. Đây là phương án nhiễu gần nhất vì cách viết đó quen thuộc từ thư viện thế hệ cũ.
C. SetPropertiesAsync với BlobHttpHeaders — đặt thuộc tính hệ thống như ContentType hay CacheControl, hoàn toàn khác với siêu dữ liệu tuỳ chỉnh. Đây là cặp khái niệm hay bị lẫn.
D. Truyền metadata vào UploadAsync — sai thứ tự tham số và sai chữ ký phương thức.

Câu 19 Function Apps

Which feature of Azure functions allow you to use a runtime not currently supported natively by Azure?

A Serverless Functions
B Custom Handlers
C SignalR
D Durable Functions

Xem giải thích

Đáp án

B — Custom Handlers.

Vì sao đúng

⚠ Custom Handler cho phép chạy BẤT KỲ ngôn ngữ nào trên Azure Functions:

⚠ Functions host nhận trigger
        ↓ ⚠ gửi HTTP request tới
⚠ TIẾN TRÌNH của bạn (web server nhỏ)
   ⚠ viết bằng Go, Rust, PHP, R...
        ↓ ⚠ trả HTTP response
⚠ Functions host xử lý output binding

Yêu cầu	Nội dung
⚠ Chương trình phải là một HTTP server nhỏ
⚠ Khai trong `host.json`	⚠ `customHandler.description.defaultExecutablePath`
⚠ Vẫn dùng được trigger và binding bình thường

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

D (Durable Functions) — ⚠ cho quy trình nhiều bước CÓ TRẠNG THÁI, ⚠ không liên quan tới ngôn ngữ.
C (SignalR) — ⚠ dịch vụ giao tiếp thời gian thực với client.
A (Serverless Functions) — ⚠ là tên gọi chung, không phải một tính năng cụ thể.

Ghi nhớ

⚠ Ngôn ngữ được Azure Functions hỗ trợ sẵn: | Hỗ trợ sẵn | Qua Custom Handler | |---|---| | ⚠ C# | ⚠ Go | | ⚠ JavaScript, TypeScript | ⚠ Rust | | ⚠ Python | ⚠ PHP | | ⚠ Java | ⚠ R | | ⚠ PowerShell | ⚠ bất kỳ thứ gì chạy được HTTP server |

Từ khoá nhận diện:

"ngôn ngữ không được hỗ trợ sẵn" → ⚠ Custom Handlers "quy trình nhiều bước có trạng thái" → ⚠ Durable Functions "đẩy dữ liệu tới trình duyệt" → ⚠ SignalR "chạy container tuỳ ý" → ⚠ Container Apps hoặc Functions trong container

⚠ Durable Functions — nên biết luôn	Mẫu
⚠ Function chaining	⚠ chạy tuần tự nhiều bước
⚠ Fan-out / fan-in	⚠ chạy song song rồi gộp kết quả
⚠ Async HTTP API	⚠ trả về ngay, client hỏi trạng thái sau
⚠ Monitor	⚠ kiểm tra định kỳ tới khi điều kiện thoả
⚠ Human interaction	⚠ chờ người phê duyệt
⚠ Giải quyết	⚠ hạn chế "hàm không nhớ gì" của serverless

⚠ Khi nào KHÔNG nên dùng Custom Handler	Khi nào
⚠ Ngôn ngữ đã được hỗ trợ sẵn	⚠ dùng bản gốc tốt hơn
⚠ Cần tối ưu cold start	⚠ thêm một lớp trung gian
⚠ Cần các tính năng nâng cao của SDK
⚠ Thay thế đáng cân nhắc	⚠ Container Apps nếu chỉ cần chạy container

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngôn ngữ có được hỗ trợ sẵn không | | | Có cần trạng thái giữa các bước không | ⚠ thì dùng Durable | | Cold start có chấp nhận được không | |

Và giá trị của Custom Handler nằm ở chỗ nó mở rộng nền tảng mà không phá vỡ mô hình: bạn vẫn dùng đúng những trigger và binding quen thuộc, chỉ thay phần thực thi bằng ngôn ngữ mình muốn.

Câu 20 Non-Relational DB

Which Azure service allows you to extend Azure File Shares from the cloud to on-premises by creating a local cache of the files?

A Azure AD Connect
B Azure Service Bus
C azcopy
D Azure File Sync

Xem giải thích

Đáp án

D — Azure File Sync.

Vì sao đúng

⚠ File Sync mở rộng file share trên đám mây xuống máy chủ tại chỗ:

⚠ Azure File Share (nguồn sự thật)
        ↓ ⚠ Azure File Sync agent
⚠ Máy chủ Windows tại chỗ
   ⚠ giữ BẢN CACHE cục bộ
        ↓
⚠ Người dùng truy cập NHANH tại chỗ
⚠ Dữ liệu vẫn đồng bộ lên đám mây

Tính năng	Nội dung
⚠ Cloud tiering	⚠ tệp ít dùng chỉ giữ CON TRỎ trên máy chủ
⚠ Máy chủ chi nhánh chỉ cần đĩa nhỏ
⚠ Mở tệp cũ thì tự kéo về	⚠ người dùng không thấy khác biệt
⚠ Nhiều máy chủ đồng bộ chung một share
⚠ Khôi phục nhanh	⚠ dựng máy mới và đồng bộ metadata trước

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

C (azcopy) — ⚠ công cụ SAO CHÉP một chiều theo lệnh, ⚠ không đồng bộ liên tục và không có cache.
B (Service Bus) — ⚠ hàng đợi tin nhắn.
A (Azure AD Connect) — ⚠ đồng bộ DANH TÍNH giữa AD tại chỗ và Entra ID, không phải tệp.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #19105, #19593, #19599, #19641 về Azure Files.

Câu	Hỏi gì	Khoá
⚠ #19105	⚠ file server nhiều chi nhánh	⚠ File share + File Sync + GRS
⚠ #19599	⚠ dịch vụ nào mount SMB	⚠ Azure Files
⚠ #21423 (câu này)	⚠ dịch vụ nào tạo cache cục bộ	⚠ File Sync
⚠ Năm câu	⚠ vẽ trọn chủ đề Azure Files qua ba lô

⚠ Cloud tiering — cơ chế đáng nhớ: | Cơ chế | Nội dung | |---|---| | ⚠ Đặt ngưỡng dung lượng trống trên máy chủ | | | ⚠ Tệp ít dùng nhất bị đẩy lên đám mây | | | ⚠ Chỉ để lại con trỏ, hiện vẫn như tệp bình thường | | | ⚠ Mở tệp thì tự tải về | ⚠ có độ trễ lần đầu | | ⚠ Kết quả | ⚠ máy chủ 1TB phục vụ được 10TB dữ liệu |

Từ khoá nhận diện:

"cache cục bộ, đồng bộ hai chiều" → ⚠ File Sync "sao chép một lần" → ⚠ azcopy "đồng bộ danh tính" → ⚠ Entra Connect "phân tầng tệp ít dùng" → ⚠ cloud tiering

⚠ Cảnh báo: đồng bộ KHÔNG phải sao lưu	Cảnh báo
⚠ Xoá ở một nơi sẽ lan ra mọi nơi
⚠ Mã độc mã hoá tệp cũng lan theo
⚠ Vẫn cần Azure Backup cho file share
⚠ Đây là	⚠ hiểu lầm nguy hiểm nhất về File Sync

⚠ Kịch bản dùng File Sync	Kịch bản
⚠ Nhiều chi nhánh cần truy cập chung
⚠ Thay thế máy chủ tệp cũ mà không đổi thói quen
⚠ Giảm dung lượng đĩa máy chủ chi nhánh
⚠ Có bản sao đám mây để khôi phục thảm hoạ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã có sao lưu riêng cho file share chưa | ⚠ File Sync không thay thế được | | Ngưỡng cloud tiering đặt bao nhiêu | | | Băng thông đồng bộ có bị giới hạn không | |

Và hiểu lầm nguy hiểm nhất về Azure File Sync, có thể dẫn tới mất dữ liệu thật: nó là công cụ đồng bộ, không phải công cụ sao lưu. Một lệnh xoá nhầm ở chi nhánh sẽ lan tới mọi máy chủ khác trong vài phút.

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

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

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