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

Đáp án

D — Cấu hình Application Insights và dùng TelemetryClient để gửi sự kiện tuỳ chỉnh

Vì sao đúng

Application Insights là cách ghi log được khuyến nghị cho Azure Functions, vì nó lo sẵn ba thứ mà các cách khác thiếu: gom log từ mọi lần chạy kể cả khi hàm co giãn ra hàng trăm bản, liên kết log với từng lời gọi cụ thể, và cho truy vấn bằng KQL để lọc và tổng hợp.

TelemetryClient cho gửi sự kiện và số đo tuỳ chỉnh kèm thuộc tính riêng của nghiệp vụ, nên gỡ lỗi không chỉ dừng ở "có ngoại lệ" mà biết được ngoại lệ đó xảy ra với dữ liệu đầu vào nào.

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

• A. Console.WriteLine — hoạt động nhưng đầu ra không có cấu trúc và khó tra cứu; ở môi trường sản xuất thì gần như vô dụng.
• B. Tự ghi tệp log lên Blob Storage — tự dựng lại thứ đã có sẵn, kèm việc phải tự xoay vòng và tự tra cứu.
• C. Đặt mức log thành Verbose trong host.json — có ích và nên làm, nhưng đó chỉ là chỉnh mức chi tiết; nó không tự tạo ra nơi thu thập và tra cứu log.

Đáp án

C — [resourceGroup().location]

Vì sao đúng

⚠ Hàm resourceGroup() trả về đối tượng mô tả resource group đang triển khai:

⚠ "location": "[resourceGroup().location]"
        ↓
⚠ Tài nguyên được tạo ở CÙNG VÙNG với resource group

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

• B (subscription().location) — ⚠ KHÔNG tồn tại: ⚠ subscription ⚠ không có thuộc tính location; ⚠ đây là bẫy đáng chú ý.

• D (parameters('location')) — ⚠ đọc THAM SỐ do người triển khai truyền vào; ⚠ nó thường ⚠ có defaultValue là [resourceGroup().location], ⚠ nhưng bản thân nó không tự lấy vị trí RG.

• A (environment()) — ⚠ trả về endpoint của môi trường (Azure Public, Azure China...), ⚠ không phải vị trí.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp bổ sung hoàn hảo với #18376 ở lô 164.

⚠ Hàm ARM template hay dùng: | Hàm | Việc | |---|---| | ⚠ parameters() | ⚠ đọc tham số | | ⚠ variables() | ⚠ đọc biến | | ⚠ resourceGroup() | ⚠ thông tin RG | | ⚠ subscription() | ⚠ thông tin subscription | | ⚠ reference() | ⚠ thuộc tính runtime của tài nguyên khác | | ⚠ resourceId() | ⚠ dựng id đầy đủ của tài nguyên | | ⚠ concat(), uniqueString() | ⚠ ghép chuỗi, sinh hậu tố duy nhất |

Từ khoá nhận diện:

"vị trí của resource group" → ⚠ resourceGroup().location "giá trị truyền vào lúc deploy" → ⚠ parameters() "thuộc tính của tài nguyên vừa tạo" → ⚠ reference() "tên duy nhất toàn cầu" → ⚠ uniqueString()

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng có nên cố định hay theo RG | | | Tên tài nguyên cần duy nhất toàn cầu có dùng uniqueString chưa | | | Đã chạy what-if trước khi deploy chưa | |

Và mẫu viết template được dùng trong hầu hết ví dụ chính thức của Microsoft, kết hợp cả hai câu hỏi này: khai một tham số location với giá trị mặc định là vị trí của resource group. Vừa linh hoạt, vừa không bắt người dùng nhập gì khi không cần.

Đáp án

A — Bao nhiêu cũng được, hoặc không có cái nào.

Vì sao đúng

⚠ Azure Functions có ba loại binding với quy tắc số lượng khác nhau: | Loại | Số lượng | |---|---| | ⚠ Trigger | ⚠ BẮT BUỘC đúng MỘT | | ⚠ Input binding | ⚠ BAO NHIÊU CŨNG ĐƯỢC, kể cả 0 | | ⚠ Output binding | ⚠ bao nhiêu cũng được, kể cả 0 |

⚠ {
⚠   "bindings": [
⚠     { "type": "httpTrigger",  "direction": "in" },
⚠     { "type": "blob",         "direction": "in" },
⚠     { "type": "table",        "direction": "in" },
⚠     { "type": "queue",        "direction": "out" }
⚠   ]
⚠ }

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

• D (0 hoặc 1) và C (đúng 1) — ⚠ là quy tắc của TRIGGER, không phải input binding.

• B (1 trở lên) — ⚠ SAI: ⚠ hàm hoàn toàn có thể ⚠ không có input binding nào, ⚠ chỉ có trigger.

Ghi nhớ

⚠ Ba loại binding — bảng phải thuộc: | Loại | Vai trò | Số lượng | |---|---|---| | ⚠ Trigger | ⚠ KHỞI ĐỘNG hàm | ⚠ đúng 1 | | ⚠ Input | ⚠ lấy thêm dữ liệu vào | ⚠ 0 tới nhiều | | ⚠ Output | ⚠ ghi kết quả ra | ⚠ 0 tới nhiều |

Từ khoá nhận diện:

"đúng một, bắt buộc" → ⚠ trigger "bao nhiêu cũng được" → ⚠ input và output binding "function.json" → ⚠ nơi khai binding "host.json" → ⚠ cấu hình chung cho cả function app

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có đúng một trigger chưa | | | Có dùng binding thay cho mã kết nối không | | | Chuỗi kết nối có nằm trong cấu hình chứ không phải mã không | |

Và quy tắc duy nhất cần nhớ chắc về binding của Azure Functions: trigger thì đúng một, còn input và output thì bao nhiêu tuỳ ý.

Đáp án

B — Tạo cho họ một Shared Access Signature (SAS).

Vì sao đúng

⚠ SAS cấp quyền HẸP và CÓ HẠN mà không lộ khoá tài khoản:

⚠ Khoá tài khoản
   ⚠ = quyền TOÀN PHẦN trên MỌI thứ
        ↓ ⚠ không bao giờ đưa ra ngoài
⚠ SAS token
   ⚠ chỉ container này
   ⚠ chỉ quyền đọc
   ⚠ hết hạn sau N giờ
   ⚠ giới hạn dải IP

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

• D (đổi container thành công khai) — ⚠ NGUY HIỂM: ⚠ cho ⚠ cả thế giới truy cập, không chỉ người kia.

• A (cấp vai trò Contributor trên storage account) — ⚠ quá rộng: ⚠ cho quyền trên ⚠ toàn bộ tài khoản, ⚠ và Contributor còn ⚠ đọc được khoá.

• C (đưa một khoá rồi tạo lại khoá sau) — ⚠ vẫn lộ quyền toàn phần trong khoảng thời gian đó.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #19495 và #19578 về quản lý khoá.

⚠ Ba loại SAS — phải phân biệt: | Loại | Ký bằng | Thu hồi được | |---|---|---| | ⚠ Service SAS | ⚠ khoá tài khoản | ⚠ khó — phải đổi khoá | | ⚠ Account SAS | ⚠ khoá tài khoản | ⚠ khó | | ⚠ User delegation SAS | ⚠ Entra ID | ⚠ DỄ — thu hồi danh tính | | ⚠ Khuyến nghị | ⚠ user delegation SAS |

Từ khoá nhận diện:

"cấp quyền tạm thời, phạm vi hẹp" → ⚠ SAS "ứng dụng truy cập không cần bí mật" → ⚠ managed identity "cho cả thế giới" → ⚠ public access — hầu như luôn sai "thu hồi dễ dàng" → ⚠ user delegation SAS hoặc RBAC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SAS đang phát hành có hạn bao lâu | | | Có dùng stored access policy để thu hồi được không | | | Có container nào đang ở chế độ công khai không | |

Và điểm yếu cố hữu của SAS mà stored access policy sinh ra để khắc phục: một token đã phát ra thì không gọi lại được. Gắn nó vào một chính sách có thể sửa là cách duy nhất để giữ quyền thu hồi.

Đáp án

C — Lúc 00:15, 00:30 và 00:45 — chỉ ba lần mỗi ngày.

Vì sao đúng

⚠ NCRONTAB của Azure Functions có SÁU trường, không phải năm:

⚠ {giây} {phút} {giờ} {ngày} {tháng} {thứ}
⚠    0   15,30,45   0     *      *     *
⚠    │      │       │
⚠    │      │       └── giờ 0 (nửa đêm)
⚠    │      └────────── phút 15, 30, 45
⚠    └───────────────── giây 0
        ↓
⚠ 00:15:00, 00:30:00, 00:45:00
⚠ → BA lần mỗi ngày

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

• B (15, 30, 45 phút của MỌI giờ) — ⚠ bẫy chính: ⚠ sẽ đúng nếu trường giờ là *; ⚠ nhưng ở đây là ⚠ 0 nên chỉ giờ nửa đêm.

• D (mỗi 15 phút, mọi giờ) — ⚠ đó là 0 */15 * * * *.

• A (mỗi 15 giây) — ⚠ hiểu nhầm hoàn toàn vị trí các trường.

Ghi nhớ

⚠ NCRONTAB — sáu trường: | Vị trí | Trường | Khoảng | |---|---|---| | ⚠ 1 | ⚠ giây | ⚠ 0-59 | | ⚠ 2 | ⚠ phút | ⚠ 0-59 | | ⚠ 3 | ⚠ giờ | ⚠ 0-23 | | ⚠ 4 | ⚠ ngày trong tháng | ⚠ 1-31 | | ⚠ 5 | ⚠ tháng | ⚠ 1-12 | | ⚠ 6 | ⚠ thứ trong tuần | ⚠ 0-6, 0 là Chủ nhật | | ⚠ Khác cron Linux | ⚠ Linux chỉ có NĂM trường, không có giây |

⚠ Ví dụ hay gặp: | Biểu thức | Nghĩa | |---|---| | ⚠ 0 */5 * * * * | ⚠ mỗi 5 phút | | ⚠ 0 0 * * * * | ⚠ mỗi giờ đúng phút 0 | | ⚠ 0 0 9 * * * | ⚠ 9 giờ sáng mỗi ngày | | ⚠ 0 0 9 * * 1-5 | ⚠ 9 giờ sáng thứ Hai tới thứ Sáu | | ⚠ 0 30 2 1 * * | ⚠ 2:30 sáng ngày mùng 1 mỗi tháng |

Từ khoá nhận diện:

"sáu trường, có giây" → ⚠ NCRONTAB của Azure Functions "năm trường" → ⚠ cron Linux "* ở trường giờ" → ⚠ mọi giờ "số cụ thể ở trường giờ" → ⚠ chỉ giờ đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Biểu thức có sáu trường không | ⚠ đếm trước khi phân tích | | Múi giờ đã cấu hình chưa | | | Lỡ một lần chạy có sao không | |

Và sai lầm phổ biến nhất khi viết lịch cho Azure Functions: dùng biểu thức cron năm trường quen thuộc từ Linux. Trường đầu tiên ở đây là giây, và mọi thứ dịch đi một ô.

Đáp án

A — TrackEvent

Vì sao đúng

Application Insights có bốn phương thức chính, mỗi cái cho một loại dữ liệu khác nhau:

Đề nói rõ là sự kiện nghiệp vụ, nên TrackEvent là lựa chọn đúng. Nó còn cho gắn thuộc tính tuỳ ý (loại sản phẩm, giá trị đơn) để phân tích về sau.

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

• D. TrackMetric — nếu bạn muốn theo dõi giá trị đơn hàng thì dùng nó, nhưng "khi ai đó hoàn tất mua hàng" là một sự kiện, không phải một con số.
• C. TrackTrace và B. TrackException — thuộc về chẩn đoán kỹ thuật, không phải phân tích nghiệp vụ.

Đáp án

D — Thực hiện docker build rồi ĐẨY NGAY ảnh kết quả vào ACR.

Vì sao đúng

⚠ az acr build chạy toàn bộ quá trình TRÊN ĐÁM MÂY:

⚠ az acr build --registry $ACR_NAME \
⚠   --image helloacrtasks:v1 .
        ↓
⚠ 1. Nén thư mục hiện tại (dấu chấm) và tải lên ACR
⚠ 2. ACR Tasks BUILD ảnh trên máy chủ Azure
⚠ 3. Ảnh được ĐẨY thẳng vào registry
        ↓
⚠ KHÔNG cần Docker cài trên máy bạn

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

• B (build rồi giữ ảnh trên máy cục bộ) — ⚠ đó là docker build, không phải az acr build.

• A và C (tạo hoặc xoá tài nguyên ACR) — ⚠ đó là az acr create và az acr delete; ⚠ lệnh build ⚠ không tạo registry.

Ghi nhớ

⚠ Ba cách đưa ảnh vào ACR: | Cách | Nội dung | |---|---| | ⚠ docker build rồi docker push | ⚠ build cục bộ, cần Docker | | ⚠ az acr build | ⚠ build TRÊN ĐÁM MÂY, đẩy luôn | | ⚠ az acr import | ⚠ sao chép ảnh từ registry khác |

Từ khoá nhận diện:

"build trên đám mây, không cần Docker" → ⚠ az acr build "build cục bộ" → ⚠ docker build "sao chép từ Docker Hub" → ⚠ az acr import "tự build lại khi mã nguồn đổi" → ⚠ ACR Tasks

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần Docker trên máy build không | | | Ảnh cơ sở cập nhật thì ảnh của bạn có tự build lại không | | | AKS xác thực với ACR bằng gì | ⚠ nên là managed identity |

Và tính năng của ACR Tasks đáng bật nhất cho môi trường sản xuất, thường bị bỏ qua: tự động build lại khi ảnh cơ sở được vá lỗi bảo mật. Không có nó, ảnh của bạn mang lỗ hổng đã được vá từ nhiều tháng trước.

Đáp án

C — docker build -t myapp:v1 .

Vì sao đúng

docker build là lệnh dựng ảnh từ Dockerfile. Ba phần trong lệnh:

• -t myapp:v1 — gắn thẻ cho ảnh: tên và phiên bản.
• . — build context, tức thư mục chứa Dockerfile và các tệp cần chép vào ảnh. Dấu chấm rất hay bị quên và khi thiếu thì lệnh báo lỗi.

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

• B. docker image build -t myapp:v1 . — đây là cú pháp mới của cùng lệnh, và nó cũng chạy được. Đây là phương án nhiễu gần nhất; docker build là dạng rút gọn phổ biến hơn và là cách được hỏi tới trong hầu hết tài liệu.
• A. docker create — tạo container từ một ảnh đã có, không dựng ảnh.
• D. docker run — tạo và khởi chạy container từ ảnh đã có.

Đáp án

A — 1 MB mỗi giây HOẶC 1.000 sự kiện mỗi giây, tuỳ cái nào tới trước.

Vì sao đúng

⚠ Throughput unit của Event Hub giới hạn theo HAI chiều: | Chiều | Giới hạn mỗi TU | |---|---| | ⚠ Ingress (vào) | ⚠ 1 MB/giây HOẶC 1.000 sự kiện/giây | | ⚠ Egress (ra) | ⚠ 2 MB/giây hoặc 4.096 sự kiện/giây |

⚠ Gửi 1.500 sự kiện nhỏ mỗi giây
   ⚠ dù tổng chỉ 200 KB
        ↓
⚠ VẪN vượt giới hạn 1.000 sự kiện
        ↓
⚠ Bị điều tiết

⚠ Điểm mấu chốt: ⚠ chạm ⚠ BẤT KỲ giới hạn nào cũng bị điều tiết, ⚠ không phải cả hai.

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

• C (1.000 sự kiện mỗi giây) — ⚠ thiếu vế dung lượng: ⚠ 500 sự kiện mỗi cái 5KB đã vượt 1MB.

• B (1 GB mỗi giây) — ⚠ quá lớn, không đúng con số.

• D (một sự kiện mỗi giây) — ⚠ quá nhỏ.

Ghi nhớ

⚠ Con số Event Hub cần nhớ: | Chỉ số | Giá trị | |---|---| | ⚠ Ingress mỗi TU | ⚠ 1 MB/s hoặc 1.000 sự kiện/s | | ⚠ Egress mỗi TU | ⚠ 2 MB/s hoặc 4.096 sự kiện/s | | ⚠ Số TU (Standard) | ⚠ 1 tới 20, xin thêm được | | ⚠ Kích thước sự kiện tối đa | ⚠ 1 MB | | ⚠ Thời gian giữ (Standard) | ⚠ 1 tới 7 ngày | | ⚠ Số partition | ⚠ chọn lúc tạo, ảnh hưởng song song |

Từ khoá nhận diện:

"1 MB/s hoặc 1.000 sự kiện/s" → ⚠ throughput unit "tự tăng TU khi cần" → ⚠ Auto-inflate "partition" → ⚠ đơn vị song song khi ĐỌC "consumer group" → ⚠ nhiều ứng dụng đọc độc lập cùng dòng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang chạm giới hạn dung lượng hay số sự kiện | ⚠ hai chiều khác nhau | | Số partition có đủ cho số consumer không | | | Auto-inflate đã bật chưa và có ai hạ lại không | |

Và chi tiết dễ gây bất ngờ nhất về Event Hub: rất nhiều sự kiện nhỏ có thể chạm trần trước khi tổng dung lượng gần tới giới hạn. Một triệu tin nhắn một kilobyte vượt hạn mức sự kiện từ lâu trước khi vượt hạn mức megabyte.

Đáp án

A — Không, blob sẽ TỰ ĐỘNG bị chuyển lại về Cool vào ngày hôm sau.

Vì sao đúng

⚠ Chính sách lifecycle dựa trên lastModified, và đổi tầng KHÔNG cập nhật mốc đó:

⚠ Blob sửa lần cuối: 60 ngày trước
        ↓ ⚠ policy: chưa sửa trong 30 ngày → Cool
⚠ Blob bị chuyển sang Cool
        ↓ ⚠ bạn chuyển tay về Hot
⚠ lastModified VẪN là 60 ngày trước
        ↓ ⚠ policy chạy lại ngày hôm sau
⚠ Điều kiện VẪN thoả → chuyển về Cool
        ↓
⚠ Vòng lặp vô ích, và mỗi lần đổi tầng đều TỐN TIỀN

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

• B (Có, blob sẽ ở lại Hot) — ⚠ SAI: ⚠ chính sách sẽ đưa nó về lại.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là ứng dụng sâu của kiến thức ở #19528.

⚠ Cách xử lý ĐÚNG khi có tệp cần ở Hot: | Cách | Nội dung | |---|---| | ⚠ Sửa policy để LOẠI TRỪ tệp đó | ⚠ theo tiền tố đường dẫn | | ⚠ Dùng blob index tag để lọc | ⚠ linh hoạt nhất | | ⚠ Đổi điều kiện sang lastAccessTime | ⚠ cần bật access tracking | | ⚠ Chuyển tệp sang container khác không áp policy | |

Từ khoá nhận diện:

"lifecycle policy đảo lại thao tác tay" → ⚠ phải sửa policy "theo thời gian truy cập cuối" → ⚠ lastAccessTime, cần bật tracking "lọc theo thẻ" → ⚠ blob index tags "loại trừ một thư mục" → ⚠ prefixMatch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Policy dựa trên lastModified hay lastAccessTime | | | Có tệp nào đang bị chuyển tầng qua lại không | ⚠ kiểm tra metrics | | Có cần loại trừ thư mục nào khỏi policy không | |

Và bài học chung từ mọi hệ thống tự động hoá, thể hiện rất rõ ở câu hỏi này: thao tác tay không thắng được chính sách tự động — muốn thay đổi kết quả thì phải sửa chính sách.