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

Đáp án

D — Triển khai tính năng Redis Cluster và thêm shard thứ hai để nhân đôi bộ nhớ khả dụng.

Vì sao đúng

⚠ Redis Cluster chia dữ liệu qua nhiều shard, mỗi shard là một node:

⚠ Một shard: tối đa dung lượng của một node
        ↓ ⚠ bật clustering
⚠ Shard 1: 120 GB
⚠ Shard 2: 120 GB
⚠ ...
⚠ Tối đa 10 shard (mở rộng được)
        ↓
⚠ Tổng bộ nhớ = số shard × dung lượng mỗi shard

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

• C (tạo server thứ hai và tự phân mảnh trong ứng dụng) — ⚠ đúng về ý tưởng nhưng SAI cách làm: ⚠ đó là ⚠ sharding thủ công; ⚠ Redis Cluster làm việc đó ⚠ tự động.

• B (bật auto-scaling để tự thêm bớt node) — ⚠ Redis KHÔNG có auto-scale theo kiểu đó; ⚠ bạn phải chủ động thêm shard hoặc nâng bậc.

• A (nói rằng dùng hơn 120GB là sai thiết kế) — ⚠ không trả lời câu hỏi, và có những kịch bản cần đúng như vậy.

Ghi nhớ

⚠ Hai cách mở rộng Azure Cache for Redis: | Cách | Nội dung | |---|---| | ⚠ Scale UP | ⚠ nâng bậc, node lớn hơn | | ⚠ Scale OUT | ⚠ thêm SHARD qua clustering — chỉ Premium | | ⚠ Kết hợp cả hai | ⚠ cho dung lượng lớn nhất |

Từ khoá nhận diện:

"vượt giới hạn bộ nhớ một node" → ⚠ clustering, thêm shard "node lớn hơn" → ⚠ nâng bậc "tự phân mảnh trong mã" → ⚠ cách thủ công, không nên "bền vững dữ liệu" → ⚠ Premium, RDB hoặc AOF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bậc hiện tại có hỗ trợ clustering không | | | Lệnh nhiều khoá có bị ảnh hưởng không | | | Có cần Enterprise Flash cho dung lượng rất lớn không | |

Và chi tiết cần kiểm thử kỹ trước khi bật chế độ cụm cho Redis đang chạy: các lệnh thao tác nhiều khoá cùng lúc sẽ thất bại nếu những khoá đó rơi vào các shard khác nhau.

Đáp án

C — 3 bản sao.

Vì sao đúng

⚠ ZRS phân tán ba bản sao vào ba availability zone trong CÙNG một vùng:

⚠ Vùng (region)
   ⚠ Zone 1 → bản sao 1
   ⚠ Zone 2 → bản sao 2
   ⚠ Zone 3 → bản sao 3
        ↓
⚠ Mất một zone: vẫn còn hai bản
⚠ Mất cả vùng: MẤT HẾT

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

• B (3 bản trong MỖI zone) — ⚠ bẫy chính: ⚠ như vậy là 9 bản; ⚠ thực tế ⚠ mỗi zone MỘT bản.

• D (6 bản) — ⚠ là GRS hoặc GZRS.

• A (1 bản) — ⚠ không có mức nào chỉ giữ một bản.

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 #19512 ở lô 164, ⚠ nhưng ⚠ THỨ TỰ PHƯƠNG ÁN ĐÃ BỊ XÁO.

⚠ Bốn mức nhân bản — bảng chốt: | Mức | Bản sao | Chịu được | |---|---|---| | ⚠ LRS | ⚠ 3 | ⚠ hỏng ổ, hỏng rack | | ⚠ ZRS | ⚠ 3 | ⚠ mất một zone | | ⚠ GRS | ⚠ 6 | ⚠ mất cả vùng | | ⚠ GZRS | ⚠ 6 | ⚠ mất zone VÀ vùng | | ⚠ Mẹo nhớ | ⚠ có chữ G là 6 bản, không có G là 3 bản |

Từ khoá nhận diện:

"3 bản, ba zone" → ⚠ ZRS "3 bản, một trung tâm dữ liệu" → ⚠ LRS "6 bản, hai vùng" → ⚠ GRS "đọc được ở vùng phụ" → ⚠ RA-GRS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng đang dùng có availability zone không | | | Cần chịu mất zone hay mất cả vùng | | | Đã có soft delete và versioning chưa | |

Và điều lô này nhắc lại rõ nhất qua năm câu trùng lặp: bộ đề dùng chung câu hỏi giữa các chứng chỉ và xáo thứ tự phương án. Học thuộc chữ cái đáp án là cách ôn thi chắc chắn thất bại.

Đáp án

D — Azure Container Registry (ACR).

Vì sao đúng

⚠ ACR là registry riêng tư cho ảnh container: | Năng lực | Nội dung | |---|---| | ⚠ Lưu ảnh Docker và OCI | | | ⚠ Riêng tư, có xác thực | | | ⚠ ACR Tasks tự build ảnh | | | ⚠ Geo-replication | ⚠ bậc Premium | | ⚠ Quét lỗ hổng | ⚠ Defender for Containers | | ⚠ Lưu cả Helm chart | |

⚠ ACR = nơi LƯU ảnh
        ↓
⚠ AKS, Container Instances, App Service
   ⚠ KÉO ảnh từ đó về CHẠY

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

• A (Container Instances) — ⚠ CHẠY container, không lưu ảnh.

• B (Kubernetes Service) — ⚠ điều phối container, không phải registry.

• C (Web Apps for Containers) — ⚠ chạy ứng dụng web trong container.

⚠ Ba phương án sai đều là nơi CHẠY container, ⚠ chỉ ACR là nơi LƯU.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh chùm năm câu về ACR qua hai lô.

⚠ Hệ sinh thái container trên Azure: | Dịch vụ | Vai trò | |---|---| | ⚠ ACR | ⚠ LƯU ảnh | | ⚠ Container Instances (ACI) | ⚠ chạy container đơn lẻ, nhanh | | ⚠ Container Apps | ⚠ microservice không quản lý cụm | | ⚠ AKS | ⚠ Kubernetes đầy đủ | | ⚠ App Service for Containers | ⚠ web app trong container |

Từ khoá nhận diện:

"lưu ảnh riêng tư" → ⚠ ACR "chạy một container nhanh, không quản hạ tầng" → ⚠ ACI "microservice có co giãn về 0" → ⚠ Container Apps "cần toàn quyền Kubernetes" → ⚠ AKS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đây là nơi lưu hay nơi chạy container | | | AKS đã gắn ACR chưa | ⚠ nguyên nhân ImagePullBackOff phổ biến nhất | | Ảnh có được quét lỗ hổng không | |

Và lỗi phổ biến nhất khi lần đầu triển khai lên AKS, dễ chẩn đoán khi biết chỗ nhìn: ImagePullBackOff vì cụm chưa được cấp quyền kéo ảnh từ registry của bạn.

Đáp án

B — Đặt giá trị hết hạn (expiration) cho các khoá.

Vì sao đúng

⚠ TTL cho phép Redis xoá khoá CHỦ ĐỘNG thay vì đợi tới lúc đầy bộ nhớ:

⚠ Không có TTL
   ⚠ khoá nằm mãi
        ↓ ⚠ bộ nhớ đầy
⚠ Redis phải ÉP xoá theo chính sách eviction
   ⚠ có thể xoá nhầm khoá đang cần
        ↓
⚠ Có TTL
   ⚠ khoá tự biến mất đúng lúc nên biến mất

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

• C (tự lưu thời gian truy cập rồi định kỳ dọn) — ⚠ làm lại bằng tay thứ Redis đã có sẵn, tốn công và dễ sai.

• A (định kỳ xoá sạch cache) — ⚠ quá thô bạo: ⚠ xoá cả khoá đang được dùng, gây đợt tải dồn xuống CSDL.

• D (đặt dung lượng tối đa thấp) — ⚠ làm vấn đề TỆ HƠN: ⚠ ép Redis phải xoá thường xuyên hơn.

Ghi nhớ

⚠ Chính sách eviction của Redis — khi bộ nhớ đầy: | Chính sách | Nội dung | |---|---| | ⚠ volatile-lru | ⚠ xoá khoá CÓ TTL, ít dùng gần đây nhất | | ⚠ allkeys-lru | ⚠ xoá bất kỳ khoá nào, ít dùng nhất | | ⚠ volatile-ttl | ⚠ xoá khoá sắp hết hạn nhất | | ⚠ noeviction | ⚠ từ chối ghi mới — báo lỗi | | ⚠ Mặc định Azure | ⚠ volatile-lru | | ⚠ Hệ quả | ⚠ khoá KHÔNG có TTL sẽ không bị xoá — và có thể chiếm hết bộ nhớ |

Từ khoá nhận diện:

"xoá chủ động, tự hết hạn" → ⚠ TTL / EXPIRE "khi bộ nhớ đầy thì xoá gì" → ⚠ eviction policy "cache không bao giờ hết hạn" → ⚠ thiết kế nguy hiểm "dọn thủ công định kỳ" → ⚠ làm lại việc Redis đã có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có khoá nào không đặt TTL không | ⚠ chúng sẽ không bao giờ bị dọn | | TTL có bị hết hạn đồng loạt không | | | Ứng dụng có chạy được khi cache trống không | |

Và thói quen nên áp dụng cho mọi khoá ghi vào Redis, đơn giản nhưng ngăn được phần lớn rắc rối về sau: luôn đặt thời gian hết hạn ngay lúc ghi. Một khoá không có TTL là một khoá sẽ nằm đó mãi mãi.

Đáp án

B — Ảnh Docker, ảnh OCI, OCI artifact và Helm chart.

Vì sao đúng

⚠ ACR không chỉ lưu ảnh Docker: | Định dạng | Nội dung | |---|---| | ⚠ Docker image | ⚠ định dạng phổ biến nhất | | ⚠ OCI image | ⚠ chuẩn mở, tương thích Docker | | ⚠ OCI artifact | ⚠ bất kỳ tệp nào theo chuẩn OCI | | ⚠ Helm chart | ⚠ gói triển khai Kubernetes |

⚠ OCI = Open Container Initiative
   ⚠ chuẩn mở do Docker và cộng đồng lập ra
        ↓
⚠ ACR lưu được mọi thứ đóng gói theo chuẩn đó
   ⚠ kể cả chính sách, mô hình ML, tệp cấu hình

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

• D (chỉ ảnh Docker) — ⚠ thiếu OCI artifact và Helm chart.

• A (tệp ZIP) và C (ảnh ISO) — ⚠ không phải định dạng container.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21436 trong cùng lô — ⚠ #21436 hỏi dịch vụ nào lưu ảnh, ⚠ câu này hỏi lưu được định dạng gì.

⚠ Vì sao Helm chart trong ACR lại hữu ích: | Lý do | Nội dung | |---|---| | ⚠ Ảnh VÀ chart cùng một nơi | | | ⚠ Cùng cơ chế xác thực và phân quyền | | | ⚠ Cùng chính sách geo-replication | | | ⚠ Không cần dựng Helm repository riêng | | | ⚠ Dùng bằng | ⚠ helm push và helm pull với ACR |

Từ khoá nhận diện:

"OCI artifact, Helm chart" → ⚠ ACR lưu được "ZIP, ISO" → ⚠ không phải định dạng container "chuẩn mở cho container" → ⚠ OCI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có đang lưu Helm chart ở nơi riêng không | ⚠ gộp về ACR gọn hơn | | Bậc hiện tại có đủ tính năng cần không | | | Ảnh có được ký và quét lỗ hổng không | |

Và điều làm ACR hữu ích hơn một kho ảnh đơn thuần: nó phân phối được mọi thứ đóng gói theo chuẩn OCI, nên bạn dùng chung một hệ thống xác thực và phân phối cho ảnh, chart và cả các tạo phẩm khác.

Đáp án

B — Bạn không phải lo về THỨ TỰ tạo tài nguyên và các phụ thuộc; Azure tự lo việc tạo chúng theo đúng trình tự.

Vì sao đúng

⚠ Khai báo nghĩa là bạn mô tả KẾT QUẢ, hệ thống lo cách đạt được:

⚠ Cách MỆNH LỆNH (script)
   ⚠ 1. Tạo VNet
   ⚠ 2. Chờ xong
   ⚠ 3. Tạo subnet
   ⚠ 4. Chờ xong
   ⚠ 5. Tạo VM
        ↓ ⚠ bạn phải viết đúng thứ tự

⚠ Cách KHAI BÁO (ARM)
   ⚠ Mô tả cả ba tài nguyên
   ⚠ Khai `dependsOn` nếu cần
        ↓
⚠ Azure TỰ phân tích đồ thị phụ thuộc
⚠ Tự tạo SONG SONG những gì độc lập

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

• C (hỗ trợ vòng lặp, biến, tham số) — ⚠ ARM CÓ những thứ đó, ⚠ nhưng script mệnh lệnh cũng có; ⚠ không phải điểm phân biệt.

• D (hỗ trợ quản lý mã nguồn) — ⚠ script cũng đưa vào Git được.

• A (chỉ cần sửa nhỏ trước mỗi lần triển khai) — ⚠ NGƯỢC với tinh thần idempotent.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bộ ba về cách cấp phát cùng #19513, #19630, #19638.

⚠ Quản lý phụ thuộc trong ARM: | Cách | Nội dung | |---|---| | ⚠ dependsOn tường minh | ⚠ khai rõ tài nguyên nào phải có trước | | ⚠ Phụ thuộc NGẦM | ⚠ dùng reference() hoặc resourceId() là tự tạo phụ thuộc | | ⚠ Azure dựng | ⚠ đồ thị phụ thuộc rồi tạo theo đúng thứ tự | | ⚠ Sai lầm | ⚠ khai dependsOn thừa làm triển khai chậm vì mất song song |

Từ khoá nhận diện:

"không phải lo thứ tự" → ⚠ khai báo "mô tả từng bước" → ⚠ mệnh lệnh "chạy lại vẫn cho cùng kết quả" → ⚠ idempotent, đặc trưng khai báo "trạng thái mong muốn" → ⚠ khai báo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dependsOn nào thừa không | ⚠ làm mất khả năng tạo song song | | Template chạy lại có an toàn không | | | Đang dùng incremental hay complete mode | |

Và lợi ích của cú pháp khai báo thể hiện rõ nhất vào lúc mọi thứ không suôn sẻ: triển khai thất bại ở tài nguyên thứ mười, bạn sửa rồi chạy lại từ đầu mà không lo chín tài nguyên trước bị tạo trùng.

Đáp án

C — Custom Handlers.

Vì sao đúng

⚠ Custom Handler cho phép chạy ngôn ngữ mà Functions không hỗ trợ sẵn:

⚠ Functions host nhận trigger
        ↓ ⚠ gửi HTTP request tới
⚠ Tiến trình Go của bạn
   ⚠ chạy như một web server nhỏ
        ↓ ⚠ trả HTTP response
⚠ Functions host xử lý output binding

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

• A (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ữ.

• D (Premium Functions) — ⚠ là GÓI LƯU TRỮ: ⚠ giải quyết cold start và VNet, không mở rộng ngôn ngữ.

• B (Function Orchestration) — ⚠ là khái niệm của Durable Functions, không phải tính năng riêng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #21422 ở lô trước.

⚠ Ngôn ngữ Azure Functions: | Hỗ trợ sẵn | Qua Custom Handler | |---|---| | ⚠ C#, F# | ⚠ Go | | ⚠ JavaScript, TypeScript | ⚠ Rust | | ⚠ Python | ⚠ PHP | | ⚠ Java | ⚠ R | | ⚠ PowerShell | ⚠ bất kỳ ngôn ngữ nào |

Từ khoá nhận diện:

"ngôn ngữ không hỗ trợ sẵn" → ⚠ Custom Handlers "quy trình có trạng thái" → ⚠ Durable Functions "không muốn cold start, cần VNet" → ⚠ Premium plan "chạy container tuỳ ý" → ⚠ Container Apps

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 binding của Functions không | ⚠ không cần thì Container Apps đơn giản hơn | | Cold start có chấp nhận được không | |

Và lựa chọn thay thế đáng cân nhắc khi ngôn ngữ không được hỗ trợ sẵn, ngoài Custom Handler: đóng gói thành container và chạy trên Container Apps. Nó cũng co giãn về không và không ràng buộc bạn vào một runtime nào.

Đáp án

B — ASP.NET Core.

Vì sao đúng

⚠ ASP.NET Core được viết lại từ đầu để chạy đa nền tảng: | Nền tảng | ASP.NET Core | ASP.NET 4 | |---|---|---| | ⚠ Windows | ⚠ CÓ | ⚠ CÓ | | ⚠ Linux | ⚠ CÓ | ⚠ KHÔNG | | ⚠ macOS | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Container | ⚠ CÓ | ⚠ hạn chế |

⚠ ASP.NET 4.x
   ⚠ gắn chặt với .NET Framework
   ⚠ .NET Framework CHỈ chạy Windows
        ↓
⚠ ASP.NET Core
   ⚠ chạy trên .NET (Core)
   ⚠ đa nền tảng từ thiết kế

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

• D (ASP.NET 4) — ⚠ chỉ chạy Windows: ⚠ phụ thuộc .NET Framework.

• A (Python) và C (Ruby) — ⚠ KHÔNG phải ngôn ngữ ASP.NET; ⚠ chúng chạy trên App Service nhưng không thuộc họ ASP.NET.

Ghi nhớ

⚠ Runtime của App Service theo nền tảng: | Runtime | Windows | Linux | |---|---|---| | ⚠ .NET (Core) | ⚠ CÓ | ⚠ CÓ | | ⚠ .NET Framework | ⚠ CÓ | ⚠ KHÔNG | | ⚠ Node.js | ⚠ CÓ | ⚠ CÓ | | ⚠ Java | ⚠ CÓ | ⚠ CÓ | | ⚠ Python | ⚠ KHÔNG | ⚠ CHỈ Linux | | ⚠ PHP | ⚠ KHÔNG (đã bỏ) | ⚠ CÓ | | ⚠ Ruby | ⚠ KHÔNG | ⚠ CÓ (qua container) |

Từ khoá nhận diện:

"đa nền tảng, Windows và Linux" → ⚠ ASP.NET Core ".NET Framework" → ⚠ chỉ Windows "Python trên App Service" → ⚠ chỉ Linux "ứng dụng cũ WCF, WebForms" → ⚠ chỉ Windows

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Runtime có chạy được trên Linux không | | | Có phụ thuộc thư viện Windows nào không | | | Đã cân nhắc chi phí giữa hai nền tảng chưa | |

Và quyết định cần chốt trước khi tạo App Service Plan, vì sau đó không đổi được: chọn hệ điều hành Windows hay Linux. Đổi ý nghĩa là tạo plan mới và di chuyển toàn bộ ứng dụng sang.

Đáp án

B — Bạn tiết kiệm được nhiều tiền nếu KHÔNG dùng tài nguyên thường xuyên, so với việc để nó sẵn sàng 24/7.

Vì sao đúng

⚠ Mô hình theo mức dùng chỉ tính tiền khi thật sự có việc:

⚠ Trả theo GIỜ
   ⚠ 24 giờ × 30 ngày = 720 giờ tính tiền
   ⚠ dù chỉ dùng 2 giờ

⚠ Trả theo MỨC DÙNG
   ⚠ chỉ tính 2 giờ đó
        ↓
⚠ Tiết kiệm rất lớn với tải THƯA

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

• C (luôn rẻ hơn trả theo giờ) — ⚠ SAI: ⚠ với tải CAO và ĐỀU, ⚠ trả theo giờ hoặc reserved instance ⚠ rẻ hơn nhiều.

• D (dễ dự đoán chi phí tương lai) — ⚠ NGƯỢC: ⚠ chi phí theo mức dùng ⚠ khó dự đoán hơn.

• A (mô hình đơn giản dễ hiểu hơn) — ⚠ cũng ngược: ⚠ tính theo lượt gọi và thời gian chạy ⚠ phức tạp hơn giá theo giờ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chủ đề với #19645 ở lô trước, ⚠ và cùng có một phương án bẫy kiểu "luôn rẻ hơn".

⚠ Chọn mô hình giá theo HÌNH DẠNG TẢI: | Hình dạng tải | Chọn | |---|---| | ⚠ Thưa, thất thường | ⚠ theo mức dùng | | ⚠ Đều, dự đoán được | ⚠ theo giờ hoặc reserved | | ⚠ Cao và liên tục nhiều năm | ⚠ reserved instance, tiết kiệm tới 70% | | ⚠ Đột biến không lường trước | ⚠ theo mức dùng hoặc autoscale |

Từ khoá nhận diện:

"ít dùng, thất thường" → ⚠ trả theo mức dùng "chạy liên tục nhiều năm" → ⚠ reserved instance "luôn rẻ hơn" → ⚠ phương án SAI "dự đoán chi phí" → ⚠ ưu điểm của giá cố định

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải thật sự là thưa hay đều | ⚠ đo, đừng đoán | | Đã đặt cảnh báo ngân sách chưa | | | Có giới hạn số instance tối đa chưa | |

Và biện pháp phòng ngừa bắt buộc khi dùng mô hình trả theo mức dùng: đặt cảnh báo ngân sách và giới hạn co giãn tối đa. Một vòng lặp vô hạn trong mã có thể biến ưu điểm chi phí thành hoá đơn gây choáng.

Đáp án

D — Đúng nửa đêm ngày 1 tháng 1, mỗi năm một lần.

Vì sao đúng

⚠ Phân tích sáu trường của NCRONTAB:

⚠ {giây} {phút} {giờ} {ngày} {tháng} {thứ}
⚠    0     0     0     1      1      *
⚠    │     │     │     │      │      │
⚠    │     │     │     │      │      └── mọi thứ
⚠    │     │     │     │      └───────── tháng 1
⚠    │     │     │     └──────────────── ngày 1
⚠    │     │     └────────────────────── giờ 0
⚠    │     └──────────────────────────── phút 0
⚠    └────────────────────────────────── giây 0
        ↓
⚠ 00:00:00 ngày 1 tháng 1 — MỖI NĂM MỘT LẦN

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

• B (12:01 sáng mỗi ngày) và C (1:01 sáng mỗi ngày) — ⚠ bỏ qua hai trường ngày và tháng: ⚠ chúng là 1 và 1, không phải *.

• A (mỗi thứ Hai lúc 1 giờ sáng) — ⚠ hiểu sai vị trí các trường.

Ghi nhớ

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

⚠ NCRONTAB — sáu trường, nhắc lại: | Vị trí | Trường | |---|---| | ⚠ 1 | ⚠ giây | | ⚠ 2 | ⚠ phút | | ⚠ 3 | ⚠ giờ | | ⚠ 4 | ⚠ ngày trong tháng | | ⚠ 5 | ⚠ tháng | | ⚠ 6 | ⚠ thứ trong tuần |

⚠ Cách đọc một biểu thức lạ: | Bước | Cách | |---|---| | ⚠ 1. ĐẾM số trường | ⚠ sáu là NCRONTAB, năm là cron Linux | | ⚠ 2. Đọc từ PHẢI sang TRÁI | ⚠ thứ, tháng, ngày, giờ, phút, giây | | ⚠ 3. Trường nào là * thì bỏ qua | | | ⚠ 4. Trường nào là số thì đó là ràng buộc | | | ⚠ Ở đây | ⚠ ràng buộc tháng 1, ngày 1, giờ 0 → mỗi năm một lần |

Từ khoá nhận diện:

"sáu trường" → ⚠ Azure Functions NCRONTAB "số ở trường tháng" → ⚠ chỉ tháng đó "* ở mọi trường sau giây" → ⚠ chạy rất thường xuyên "múi giờ" → ⚠ mặc định UTC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm đủ sáu trường chưa | | | Múi giờ đã cấu hình chưa | | | Lịch thưa có cách kiểm thử thủ công không | |

Và rủi ro riêng của những hàm chạy theo lịch rất thưa: nếu nó hỏng, bạn chỉ phát hiện ra sau một năm. Luôn tách phần logic ra để gọi và kiểm thử được bất cứ lúc nào.