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

Đáp án

C — Mỗi giờ một lần, vào phút thứ 5 sau giờ tròn.

Vì sao đúng

⚠ Phân tích sáu trường:

⚠ {giây} {phút} {giờ} {ngày} {tháng} {thứ}
⚠    0     5      *     *      *      *
⚠    │     │      │
⚠    │     │      └── mọi giờ
⚠    │     └───────── phút thứ 5 (KHÔNG phải mỗi 5 phút)
⚠    └─────────────── giây 0
        ↓
⚠ 00:05, 01:05, 02:05, ... 23:05
⚠ → 24 lần mỗi ngày

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

• A (mỗi 5 phút, mọi giờ) — ⚠ bẫy CHÍNH: ⚠ đó là ⚠ 0 */5 * * * *, có dấu */.

• D (mỗi ngày lúc 5 giờ sáng) — ⚠ đó là 0 0 5 * * *: ⚠ số 5 phải ở trường GIỜ.

• B (biểu thức không hợp lệ) — ⚠ SAI: ⚠ biểu thức hoàn toàn hợp lệ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về NCRONTAB qua hai lô, ⚠ và là câu ⚠ tinh tế nhất.

⚠ Bảng so sánh cực kỳ đáng nhớ: | Biểu thức | Nghĩa | Số lần mỗi ngày | |---|---|---| | ⚠ 0 5 * * * * | ⚠ phút thứ 5 mỗi giờ | ⚠ 24 | | ⚠ 0 */5 * * * * | ⚠ mỗi 5 phút | ⚠ 288 | | ⚠ 0 0 5 * * * | ⚠ 5 giờ sáng mỗi ngày | ⚠ 1 | | ⚠ 5 * * * * * | ⚠ giây thứ 5 mỗi phút | ⚠ 1.440 | | ⚠ Chênh lệch | ⚠ cùng con số 5 nhưng khác nhau tới hàng trăm lần chạy |

Từ khoá nhận diện:

"số trần" → ⚠ giá trị CỤ THỂ của trường đó "*/n" → ⚠ mỗi n đơn vị "*" → ⚠ mọi giá trị "vị trí quyết định đơn vị" → ⚠ giây, phút, giờ...

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dấu */ hay không | ⚠ khác biệt then chốt | | Số nằm ở trường nào | | | Portal báo lần chạy kế tiếp là khi nào | ⚠ cách kiểm chứng nhanh nhất |

Và cặp biểu thức đáng ghi nhớ nhất trong toàn bộ chủ đề lịch chạy: 0 5 * * * * chạy 24 lần mỗi ngày, còn 0 */5 * * * * chạy 288 lần. Chúng khác nhau đúng hai ký tự.

Đáp án

C — Không, mỗi tài khoản chỉ chứa được MỘT loại dữ liệu (một API).

Vì sao đúng

⚠ API được chọn ở cấp TÀI KHOẢN và không đổi được:

⚠ Cosmos DB Account
   ⚠ API: Core (SQL)  ← chọn lúc TẠO
        ↓
⚠ Mọi database và container bên trong
   ⚠ đều dùng API đó
        ↓
⚠ Cần Gremlin → phải tạo TÀI KHOẢN MỚI

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

• A (mỗi database dùng API khác nhau) — ⚠ SAI: ⚠ API ở cấp ⚠ tài khoản.

• B (dùng API nào cũng gọi được loại nào) — ⚠ SAI: ⚠ mỗi API có giao thức và mô hình riêng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ TRÙNG với #19581 ở lô 166, thứ tự phương án ⚠ bị xáo.

⚠ Ba quyết định vĩnh viễn của Cosmos DB: | Quyết định | Cấp | |---|---| | ⚠ API | ⚠ tài khoản — KHÔNG đổi | | ⚠ Partition key | ⚠ container — KHÔNG đổi | | ⚠ Vùng chính ban đầu | ⚠ đổi được nhưng phức tạp | | ⚠ Ý nghĩa | ⚠ giai đoạn thiết kế quan trọng hơn nhiều so với CSDL quan hệ |

Từ khoá nhận diện:

"đổi API sau khi tạo" → ⚠ KHÔNG được "nhiều API trong một tài khoản" → ⚠ KHÔNG được "nhiều database trong một tài khoản" → ⚠ ĐƯỢC, không giới hạn "đổi partition key" → ⚠ KHÔNG được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình dữ liệu đã chốt chưa | ⚠ trước khi tạo tài khoản | | Có phần dữ liệu nào cần mô hình khác không | | | Partition key đã theo mẫu truy vấn chưa | |

Và điểm khác biệt lớn nhất giữa thiết kế trên Cosmos DB và trên cơ sở dữ liệu quan hệ: những quyết định quan trọng nhất phải đúng ngay lần tạo đầu tiên — không có lệnh ALTER nào cho API hay partition key.

Đáp án

B — KEDA (Kubernetes Event-driven Autoscaling)

Vì sao đúng

Azure Container Apps dùng KEDA làm bộ máy co giãn, và điểm mạnh riêng của nó là co giãn theo sự kiện bên ngoài chứ không chỉ theo CPU: số thông điệp trong hàng đợi, số yêu cầu HTTP đang chờ, độ trễ của Kafka. Nhờ vậy ứng dụng co được về 0 khi không có việc, và bật lên ngay khi có thông điệp đầu tiên.

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

• A. Co giãn tĩnh và D. Co giãn thủ công — cố định số bản chạy, tức là không đáp ứng được tải biến động như đề yêu cầu.
• C. Azure Load Balancer — phân phối lưu lượng giữa các bản chạy đã có, nhưng không tạo thêm bản nào. Đây là cặp khái niệm hay bị lẫn: cân bằng tải chia việc, co giãn tạo năng lực.

Đáp án

A — Durable Functions.

Vì sao đúng

⚠ Durable Functions cho phép một hàm điều phối và gọi các hàm khác:

⚠ Orchestrator function
   ⚠ gọi Activity function 1
   ⚠ chờ kết quả
   ⚠ gọi Activity function 2
   ⚠ ...
        ↓
⚠ TRẠNG THÁI được lưu tự động
⚠ Chạy lại được sau khi tiến trình sập

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

• D (Extension Bundles) — ⚠ là cách quản lý PHỤ THUỘC binding cho ngôn ngữ script, không liên quan.

• B (Core Tools) — ⚠ công cụ dòng lệnh để phát triển cục bộ.

• C (Premium Tier Functions) — ⚠ là GÓI LƯU TRỮ, giải quyết cold start và VNet.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #21422 và #21440 về tính năng của Functions.

⚠ Năm mẫu của Durable Functions: | Mẫu | Nội dung | |---|---| | ⚠ Function chaining | ⚠ chạy tuần tự A → 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, có timeout |

Từ khoá nhận diện:

"hàm gọi hàm, quy trình nhiều bước" → ⚠ Durable Functions "ngôn ngữ lạ" → ⚠ Custom Handlers "không muốn cold start" → ⚠ Premium plan "phát triển cục bộ" → ⚠ Core Tools

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Orchestrator có mã bất định nào không | ⚠ lỗi khó chẩn đoán nhất | | Quy trình có cần chạy lâu hơn giới hạn hàm thường không | | | Có cần chờ người phê duyệt không | ⚠ mẫu human interaction |

Và ràng buộc quan trọng nhất khi viết orchestrator của Durable Functions, vi phạm là gây lỗi rất khó lần ra: mã phải tất định. Nó sẽ được chạy lại nhiều lần để dựng lại trạng thái, nên mọi giá trị ngẫu nhiên hay thời gian hiện tại đều phải lấy từ context.

Đáp án

D — Dùng HTTP Trigger và kiểm tra giờ hiện tại ngay trong thân hàm

Vì sao đúng

Điểm mấu chốt là hàm được kích hoạt bởi yêu cầu HTTP — nghĩa là nó chỉ chạy khi có người gọi, và bạn không kiểm soát được lúc nào họ gọi. Vì vậy điều kiện thời gian phải kiểm bên trong hàm, rồi trả về mã lỗi phù hợp nếu ngoài khung giờ.

Đây là cách đơn giản nhất, không thêm dịch vụ nào, và dễ kiểm thử.

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

• B. Dùng biểu thức CRON để hàm chỉ chạy trong khung giờ — CRON dùng cho Timer Trigger; nó không áp được lên HTTP Trigger, vì HTTP Trigger phản ứng theo yêu cầu chứ không theo lịch.
• C. Dùng Timer Trigger chạy mỗi giờ — đổi hẳn mô hình kích hoạt, nên hàm không còn phản hồi được yêu cầu HTTP nữa.
• A. Gọi dịch vụ bên ngoài để hỏi giờ — thêm một phụ thuộc mạng và một điểm hỏng cho việc mà một dòng mã trong hàm làm được.

Đáp án

C — Tăng SỐ LƯỢNG instance máy ảo chạy ứng dụng của bạn.

Vì sao đúng

⚠ Hai hướng mở rộng, đừng lẫn: | Hướng | Nội dung | |---|---| | ⚠ Scale UP (dọc) | ⚠ máy MẠNH hơn — S1 lên S2 | | ⚠ Scale OUT (ngang) | ⚠ NHIỀU máy hơn — 1 instance lên 5 |

⚠ Scale UP
   ⚠ [máy nhỏ] → [MÁY LỚN]

⚠ Scale OUT
   ⚠ [máy] → [máy][máy][máy][máy]
        ↓
⚠ Cần load balancer phân phối lưu lượng
⚠ App Service tự lo phần đó

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

• A (chuyển lên gói cao hơn, S1 lên S2) — ⚠ đó là scale UP.

• B (thêm bản chạy của app trên CÙNG instance) — ⚠ không phải cơ chế của App Service.

• D (triển khai sang vùng khác) — ⚠ đó là mở rộng ĐỊA LÝ, cần Traffic Manager hoặc Front Door.

Ghi nhớ

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

⚠ Điều kiện để scale out hoạt động: | Điều kiện | Nội dung | |---|---| | ⚠ Ứng dụng phải KHÔNG GIỮ TRẠNG THÁI | ⚠ stateless | | ⚠ Session lưu ra ngoài | ⚠ Redis, CSDL | | ⚠ Tệp tải lên lưu ở Blob, không lưu đĩa cục bộ | | | ⚠ Không phụ thuộc bộ nhớ cache trong tiến trình | | | ⚠ Không đáp ứng | ⚠ thêm instance sẽ gây lỗi khó hiểu cho người dùng |

Từ khoá nhận diện:

"tăng số instance" → ⚠ scale out "máy mạnh hơn, gói cao hơn" → ⚠ scale up "sang vùng khác" → ⚠ mở rộng địa lý "tự động theo tải" → ⚠ autoscale, từ bậc Standard

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có stateless không | ⚠ điều kiện tiên quyết để scale out | | Autoscale có quy tắc GIẢM không | | | Số instance tối đa đặt bao nhiêu | ⚠ giới hạn chi phí |

Và cấu hình autoscale bị thiếu nhiều nhất, chỉ phát hiện qua hoá đơn cuối tháng: quy tắc thu nhỏ trở lại. Hệ thống mở rộng lúc cao điểm rồi giữ nguyên số instance đó mãi mãi.

Đáp án

B — Tạo SAS bằng cách gắn với một stored access policy.

Vì sao đúng

⚠ Stored access policy tách phần "quyền và thời hạn" ra khỏi chính token:

⚠ SAS thường
   ⚠ quyền và hạn NHÚNG THẲNG vào token
        ↓ ⚠ đã phát ra thì không sửa được

⚠ SAS gắn stored access policy
   ⚠ token chỉ TRỎ TỚI tên policy
   ⚠ quyền và hạn nằm trong POLICY
        ↓
⚠ Sửa policy = mọi SAS gắn với nó ĐỔI THEO
⚠ Xoá policy = THU HỒI ngay lập tức

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

• A (cách duy nhất là tạo lại) — ⚠ đúng với SAS THƯỜNG, ⚠ nhưng sai khi có stored access policy.

• C (không sửa được bằng bất kỳ cách nào) — ⚠ SAI.

• D (sửa trong màn hình SAS của Storage Account) — ⚠ màn hình đó chỉ TẠO SAS mới, không sửa được token đã phát.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là câu tiếp nối trực tiếp của #21407 ở lô trước.

⚠ Ba loại SAS — nhắc lại: | Loại | Thu hồi thế nào | |---|---| | ⚠ Service SAS thường | ⚠ phải đổi khoá tài khoản | | ⚠ Service SAS + stored access policy | ⚠ sửa hoặc xoá policy | | ⚠ User delegation SAS | ⚠ thu hồi quyền của danh tính Entra ID | | ⚠ Khuyến nghị hiện nay | ⚠ user delegation SAS |

Từ khoá nhận diện:

"sửa hạn sau khi phát" → ⚠ stored access policy "thu hồi mà không đổi khoá" → ⚠ stored access policy hoặc user delegation SAS "ký bằng Entra ID" → ⚠ user delegation SAS "đổi khoá tài khoản" → ⚠ thu hồi mọi SAS thường cùng lúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có SAS nào hạn quá dài đang lưu hành không | | | Có cách thu hồi từng SAS riêng lẻ chưa | | | Có thể chuyển sang user delegation SAS 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 đi thì không gọi lại được. Gắn nó vào một chính sách sửa được là cách duy nhất giữ lại quyền thu hồi.

Đáp án

A — az webapp log tail

Vì sao đúng

⚠ tail là lệnh xem log TRỰC TIẾP theo dòng chảy:

⚠ az webapp log tail --name myapp --resource-group myrg
        ↓
⚠ Log hiện ra ngay trên terminal
⚠ Cập nhật liên tục khi có dòng mới
⚠ Ctrl+C để dừng

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

• B (az webapp download) — ⚠ không có lệnh này; ⚠ đúng phải là az webapp log download, ⚠ và nó ⚠ tải về chứ không xem trực tiếp.

• C (Get-AzAppServiceLog) — ⚠ không phải cmdlet chuẩn.

• D (az webapp log -all) — ⚠ cú pháp không hợp 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 #21426 trong cùng lô.

⚠ Bốn lệnh con của az webapp log: | Lệnh | Việc | |---|---| | ⚠ config | ⚠ bật tắt và đặt mức log | | ⚠ show | ⚠ xem cấu hình hiện tại | | ⚠ tail | ⚠ xem trực tiếp | | ⚠ download | ⚠ tải về dạng ZIP |

Từ khoá nhận diện:

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

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 | ⚠ tail chỉ đọc file system | | Có Application Insights cho điều tra sau không | |

Và lý do phổ biến nhất khiến lệnh xem log trực tiếp không hiện gì cả: ghi log chưa được bật, hoặc đã tự tắt sau mười hai giờ. Kiểm tra cấu hình trước khi nghi ngờ ứng dụng.

Đáp án

A — Bật thiết lập "Always On" trong trang General Settings.

Vì sao đúng

⚠ Mặc định App Service DỠ TẢI ứng dụng khi không có lưu lượng:

⚠ Không có request trong 20 phút
        ↓
⚠ App Service dỡ tải ứng dụng khỏi bộ nhớ
        ↓
⚠ WebJob chạy liên tục cũng BỊ DỪNG
⚠ Timer trigger có thể không chạy
        ↓ ⚠ bật Always On
⚠ App Service tự gửi request giữ ứng dụng luôn chạy

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

• B (nâng lên gói Standard) và D (nâng lên Premium) — ⚠ bẫy hợp lý: ⚠ Always On ⚠ CÓ yêu cầu từ gói Basic trở lên, ⚠ nhưng nâng gói ⚠ không tự bật nó; ⚠ vẫn phải bật thủ công.

• C (đặt Managed Pipeline version thành Integrated) — ⚠ liên quan tới cách IIS xử lý request, không giữ ứng dụng chạy.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21448 và #21484 về App Service.

⚠ Các thiết lập quan trọng ở General Settings: | Thiết lập | Việc | |---|---| | ⚠ Always On | ⚠ không dỡ tải ứng dụng | | ⚠ ARR Affinity | ⚠ giữ phiên ở cùng instance | | ⚠ HTTPS Only | ⚠ ép HTTPS | | ⚠ Minimum TLS Version | ⚠ nên đặt 1.2 trở lên | | ⚠ WebSockets | ⚠ bật nếu ứng dụng cần | | ⚠ FTP State | ⚠ nên tắt hoặc chỉ FTPS |

Từ khoá nhận diện:

"app bị dỡ tải khi vắng khách" → ⚠ Always On "phiên bị mất khi có nhiều instance" → ⚠ ARR Affinity "request đầu tiên rất chậm" → ⚠ cold start, bật Always On "WebJob dừng bất thường" → ⚠ Always On

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Always On đã bật chưa | ⚠ mặc định tắt | | Gói hiện tại có hỗ trợ Always On không | | | Có WebJob hoặc timer trigger nào không chạy đúng lịch không | |

Và nguyên nhân số một khiến tác vụ nền trên App Service dừng một cách bí ẩn: Always On chưa được bật. Ứng dụng bị dỡ tải khi vắng khách, và mọi thứ đang chạy ngầm dừng theo.

Đáp án

C — Azure Functions với Cosmos DB trigger

Vì sao đúng

Cosmos DB trigger được xây dựng trên chính change feed, nên nó là cách gọn nhất để phản ứng với thay đổi: hàm tự được gọi mỗi khi có item được thêm hoặc sửa, và runtime lo sẵn phần khó nhất — lưu vị trí đã đọc tới đâu (lease) và chia việc giữa nhiều bản chạy khi cần co giãn.

Không có nó thì bạn phải tự viết vòng lặp đọc change feed và tự quản lý con trỏ.

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

• D. Event Grid — Cosmos DB không phát sự kiện trực tiếp cho Event Grid theo cách dùng được ở đây; change feed là cơ chế riêng.
• A. Data Factory — điều phối dữ liệu theo lô, không phản ứng theo sự kiện.
• B. Logic Apps — có connector cho Cosmos DB nhưng thiên về hỏi vòng, kém hiệu quả hơn hẳn trigger dựa trên change feed.