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

Đáp án

C — Bị THU HỒI (eviction).

Vì sao đúng

⚠ Thu hồi là rủi ro định nghĩa nên bản chất của Spot VM:

⚠ Azure cần lại năng lực đó
        ↓ ⚠ hoặc giá vượt mức bạn đặt
⚠ Thông báo trước 30 GIÂY
        ↓
⚠ VM bị DỪNG hoặc XOÁ
   ⚠ tuỳ chính sách bạn chọn

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

• D (không có SLA) — ⚠ cũng ĐÚNG: ⚠ xem mục chất lượng câu hỏi.

• A (có thể đắt hơn VM thường) — ⚠ SAI: ⚠ bạn đặt được ⚠ giá tối đa, không bao giờ vượt giá VM thường.

• B (giới hạn số lượng spot instance) — ⚠ có hạn mức quota nhưng ⚠ không phải rủi ro chính.

Ghi nhớ

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

⚠ Đối chiếu #21431 trong cùng lô — ⚠ câu đó hỏi ⚠ ƯU điểm (rẻ), ⚠ câu này hỏi ⚠ NHƯỢC điểm (bị thu hồi); ⚠ hai mặt của cùng một đánh đổi.

⚠ Sống chung với eviction — thiết kế: | Thiết kế | Nội dung | |---|---| | ⚠ Công việc phải CHẠY LẠI ĐƯỢC | | | ⚠ Lưu điểm kiểm tra thường xuyên | | | ⚠ Nghe Scheduled Events API | ⚠ có 30 giây để dọn dẹp | | ⚠ Trộn Spot và node thường trong AKS | | | ⚠ Phân tán qua nhiều loại VM | ⚠ giảm khả năng bị thu hồi cùng lúc |

Từ khoá nhận diện:

"bị thu hồi, ngắt giữa chừng" → ⚠ rủi ro Spot "rẻ hơn nhiều" → ⚠ ưu điểm Spot "cam kết dài hạn, giảm giá" → ⚠ Reserved Instance "tải ổn định" → ⚠ không nên dùng Spot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Công việc chịu được ngắt giữa chừng không | | | Có xử lý sự kiện thu hồi chưa | | | Chính sách thu hồi là deallocate hay delete | |

Và cách nghĩ đúng về Spot VM, giúp thiết kế hệ thống dùng được nó: coi việc bị thu hồi là hành vi BÌNH THƯỜNG cần xử lý, không phải sự cố cần tránh.

Đáp án

C — az acr build

Vì sao đúng

⚠ az acr build gộp hai bước build và push thành một, chạy trên đám mây:

⚠ az acr build --registry myacr --image app:v1 .
        ↓
⚠ 1. Nén mã nguồn và tải lên ACR
⚠ 2. ACR Tasks build ảnh
⚠ 3. Đẩy ảnh vào registry
        ↓
⚠ KHÔNG cần Docker trên máy bạn

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

• D (docker push) — ⚠ chỉ ĐẨY ảnh đã build sẵn, không tạo ảnh.

• A (az acr create) — ⚠ tạo TÀI NGUYÊN registry, không build ảnh.

• B (docker compose up) — ⚠ chạy nhiều container cục bộ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ hai về az acr build trong hai lô, ⚠ và câu #21467 trong cùng lô cũng hỏi về nó.

⚠ Nhóm lệnh ACR — phân biệt: | Lệnh | Việc | Thuộc ACR Tasks | |---|---|---| | ⚠ az acr create | ⚠ tạo registry | ⚠ KHÔNG | | ⚠ az acr build | ⚠ build ảnh trên đám mây | ⚠ CÓ | | ⚠ az acr import | ⚠ sao chép ảnh từ nơi khác | ⚠ KHÔNG | | ⚠ az acr task | ⚠ quản lý task tự động | ⚠ CÓ | | ⚠ az acr run | ⚠ chạy task đa bước | ⚠ CÓ | | ⚠ az acr login | ⚠ xác thực | ⚠ KHÔNG |

Từ khoá nhận diện:

"build và tự đẩy" → ⚠ az acr build "chỉ đẩy ảnh có sẵn" → ⚠ docker push "tạo registry" → ⚠ az acr create "sao chép từ Docker Hub" → ⚠ az acr import

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần Docker trên máy build không | | | Băng thông đẩy ảnh có phải vấn đề không | | | Có nên dùng ACR Task tự động thay vì build thủ công | |

Và lợi ích thực tế lớn nhất của việc build ảnh trên đám mây, cảm nhận rõ khi mạng chậm: bạn chỉ tải lên vài megabyte mã nguồn thay vì đẩy lên vài gigabyte ảnh đã build.

Đáp án

D — Resource Group.

Vì sao đúng

⚠ Resource group là vùng chứa BẮT BUỘC của mọi tài nguyên Azure:

⚠ Management Group
   ⚠ Subscription
      ⚠ Resource Group  ← MỌI tài nguyên phải thuộc đúng MỘT
         ⚠ Cosmos DB
         ⚠ SQL Database
         ⚠ Redis Cache

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

• A (Virtual Network) — ⚠ nhiều dịch vụ PaaS không nằm trong VNet nào: ⚠ Cosmos DB, Redis bậc thấp.

• B (Availability Zone) — ⚠ là tuỳ chọn, nhiều dịch vụ không dùng zone.

• C (Azure AD Group) — ⚠ nhóm NGƯỜI DÙNG, không chứa tài nguyên.

Ghi nhớ

⚠ Bốn cấp phạm vi trên Azure — bảng phải thuộc: | Cấp | Nội dung | |---|---| | ⚠ Management Group | ⚠ nhóm nhiều subscription | | ⚠ Subscription | ⚠ đơn vị thanh toán và hạn mức | | ⚠ Resource Group | ⚠ nhóm logic các tài nguyên | | ⚠ Resource | ⚠ tài nguyên cụ thể | | ⚠ RBAC và Policy | ⚠ gán được ở MỌI cấp, và KẾ THỪA xuống dưới |

Từ khoá nhận diện:

"mọi tài nguyên phải thuộc về" → ⚠ resource group "đơn vị thanh toán" → ⚠ subscription "áp chính sách cho nhiều subscription" → ⚠ management group "nhóm người dùng" → ⚠ Entra ID group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RG có nhóm theo vòng đời không | | | RG production đã có resource lock chưa | | | Có tài nguyên prod nằm chung RG với dev không | |

Và biện pháp bảo vệ đơn giản nhất chống lại sự cố nghiêm trọng nhất trên Azure: đặt khoá CanNotDelete cho các resource group của môi trường thật. Một lệnh xoá resource group nhầm sẽ mang theo mọi thứ bên trong.

Đáp án

A — Eventual

Vì sao đúng

Trong Cosmos DB, nhất quán và sẵn sàng là hai đầu của một đánh đổi. Năm mức xếp theo thứ tự giảm dần độ chặt: Strong, Bounded Staleness, Session, Consistent Prefix, Eventual.

Càng đi về phía Eventual thì:

• Tính sẵn sàng càng cao — không phải chờ xác nhận từ khu vực khác, nên sự cố ở một nơi ít ảnh hưởng hơn.
• Độ trễ càng thấp và thông lượng càng cao với cùng mức RU.

Đổi lại là đọc có thể ra dữ liệu cũ trong một khoảng thời gian ngắn. Khi đề đặt tính sẵn sàng lên hàng đầu, Eventual là mức phù hợp.

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

• D. Strong — chặt nhất nên sẵn sàng thấp nhất, và không dùng được với ghi đa vùng.
• C. Bounded Staleness và B. Session — nằm ở giữa; chúng là lựa chọn tốt cho phần lớn ứng dụng thật, nhưng không tối đa hoá tính sẵn sàng như câu hỏi yêu cầu.

Đáp án

C — Đặt source thành EventGrid

Vì sao đúng

Blob trigger có hai chế độ hoạt động, và chúng khác nhau về bản chất:

Đề yêu cầu mỗi blob chỉ được xử lý một lần dù bị cập nhật nhiều lần, và chế độ Event Grid cho sự kiện rời rạc theo từng thao tác nên đáp ứng tốt hơn hẳn.

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

• A. dataType thành binary — quyết định dữ liệu được truyền vào hàm dưới dạng gì.
• B. blobPath là tên container — khai nơi theo dõi, không đổi cách phát hiện.
• D. connection là chuỗi kết nối — bắt buộc phải có, nhưng không liên quan tới việc xử lý trùng.

Đáp án

B — Azure Monitor.

Vì sao đúng

⚠ Azure Monitor là nền tảng giám sát hợp nhất của Azure: | Năng lực | Nội dung | |---|---| | ⚠ Thu thập log và metric | ⚠ từ mọi tài nguyên | | ⚠ Truy vấn bằng KQL | ⚠ qua Log Analytics | | ⚠ Vẽ biểu đồ và dashboard | ⚠ Workbooks | | ⚠ Cảnh báo | ⚠ metric, log, activity log | | ⚠ Application Insights | ⚠ giám sát ứng dụng | | ⚠ Container và VM Insights | |

⚠ Mọi tài nguyên Azure
        ↓ ⚠ diagnostic settings
⚠ Log Analytics Workspace
        ↓ ⚠ KQL
⚠ Truy vấn, biểu đồ, cảnh báo

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

• C (Storage Account hoặc Event Hub) — ⚠ là ĐÍCH lưu log, ⚠ không có khả năng truy vấn và cảnh báo.

• A (Azure Security Center) — ⚠ nay là Defender for Cloud: ⚠ tập trung vào bảo mật và tuân thủ.

• D (Azure Portal Dashboard) — ⚠ chỉ là màn hình hiển thị, không thu thập hay truy vấn log.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chùm với #19048 và #19095 qua ba lô.

⚠ Các thành phần của Azure Monitor: | Thành phần | Vai trò | |---|---| | ⚠ Metrics | ⚠ số liệu theo thời gian, độ trễ thấp | | ⚠ Logs (Log Analytics) | ⚠ dữ liệu chi tiết, truy vấn KQL | | ⚠ Application Insights | ⚠ APM cho ứng dụng | | ⚠ Alerts | ⚠ cảnh báo | | ⚠ Workbooks | ⚠ báo cáo tương tác | | ⚠ Action Groups | ⚠ hành động khi cảnh báo |

Từ khoá nhận diện:

"gom log tập trung, truy vấn, cảnh báo" → ⚠ Azure Monitor "kho lưu và truy vấn KQL" → ⚠ Log Analytics workspace "bảo mật và tuân thủ" → ⚠ Defender for Cloud "chỉ hiển thị" → ⚠ dashboard

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Diagnostic settings đã bật cho tài nguyên quan trọng chưa | ⚠ mặc định TẮT | | Đang nạp bao nhiêu GB log mỗi ngày | | | Cảnh báo có ai đọc và xử lý không | |

Và điều dễ bị bỏ sót nhất khi thiết lập giám sát trên Azure: diagnostic settings mặc định TẮT cho hầu hết tài nguyên. Không bật thì log chi tiết đơn giản là không tồn tại, kể cả khi sự cố đã xảy ra.

Đáp án

D — Log Analytics Workspace.

Vì sao đúng

⚠ Log Analytics Workspace là kho chứa và truy vấn của Azure Monitor:

⚠ Tài nguyên Azure
        ↓ ⚠ diagnostic settings
⚠ Log Analytics Workspace
   ⚠ dữ liệu tổ chức thành BẢNG
        ↓ ⚠ truy vấn KQL
⚠ AzureDiagnostics, Heartbeat, Perf, AppRequests...

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

• C (Append Blob Storage) — ⚠ lưu được log nhưng KHÔNG truy vấn được: ⚠ chỉ là nơi lưu trữ nguội, giá rẻ.

• B (Azure Monitor account) — ⚠ không phải tên tài nguyên thật.

• A (Managed Storage) — ⚠ không phải khái niệm của Azure Monitor.

Ghi nhớ

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

⚠ Ba đích gửi log — chọn theo mục đích: | Đích | Dùng khi | |---|---| | ⚠ Log Analytics Workspace | ⚠ cần TRUY VẤN và cảnh báo | | ⚠ Storage Account | ⚠ lưu trữ dài hạn, rẻ, tuân thủ | | ⚠ Event Hub | ⚠ chuyển sang hệ thống SIEM bên ngoài | | ⚠ Gửi được | ⚠ cả ba cùng lúc |

Từ khoá nhận diện:

"truy vấn KQL, phân tích" → ⚠ Log Analytics Workspace "lưu trữ rẻ và lâu" → ⚠ Storage Account "chuyển ra hệ thống ngoài" → ⚠ Event Hub "nền tảng giám sát" → ⚠ Azure Monitor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu workspace và có cần thế không | | | Thời gian lưu giữ đặt bao nhiêu | ⚠ ảnh hưởng chi phí | | Có gửi song song ra Storage cho lưu trữ dài hạn không | |

Và cách kiểm soát chi phí giám sát hiệu quả nhất, thay vì giảm mức log: giữ ngắn ở Log Analytics để truy vấn, đồng thời gửi bản sao sang Storage Account cho lưu trữ dài hạn giá rẻ.

Đáp án

B — Chuyển hàng đợi sang chế độ giao nhận "at-most-once".

Vì sao đúng

⚠ Service Bus có hai chế độ nhận tin nhắn, mỗi chế độ một rủi ro: | Chế độ | Cơ chế | Rủi ro | |---|---|---| | ⚠ Peek-Lock (mặc định) | ⚠ khoá, xử lý, rồi mới xoá | ⚠ có thể xử lý TRÙNG | | ⚠ Receive-and-Delete | ⚠ xoá NGAY khi nhận | ⚠ có thể MẤT tin nhắn |

⚠ Peek-Lock
   ⚠ Nhận → xử lý → Complete
        ↓ ⚠ nếu sập TRƯỚC khi Complete
⚠ Khoá hết hạn → tin nhắn quay lại hàng đợi
        ↓
⚠ Một ứng dụng khác nhận và XỬ LÝ LẠI
        ↓
⚠ Đó chính là vấn đề đề mô tả

⚠ Receive-and-Delete = at-most-once: ⚠ tin nhắn ⚠ không bao giờ được xử lý hai lần, ⚠ đổi lại có thể mất nếu tiến trình sập.

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

• D (lưu số thứ tự tin nhắn vào bảng và kiểm tra) — ⚠ hướng đi đúng về idempotency nhưng ⚠ tự làm lại thứ Service Bus đã có; ⚠ và mô tả trong phương án là cách làm thủ công dễ sai.

• A (chỉ dùng một ứng dụng xử lý) — ⚠ KHÔNG giải quyết được: ⚠ một tiến trình sập giữa chừng vẫn gây xử lý lại.

• C (thêm mã kiểm tra lỗi và nhắn tin cho lập trình viên) — ⚠ không sửa nguyên nhân, chỉ thông báo.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án D ⚠ đáng bàn thêm.

⚠ Ba mức bảo đảm giao nhận: | Mức | Nghĩa | |---|---| | ⚠ At-most-once | ⚠ tối đa một lần — có thể MẤT | | ⚠ At-least-once | ⚠ ít nhất một lần — có thể TRÙNG | | ⚠ Exactly-once | ⚠ đúng một lần — rất khó, thường phải tự làm | | ⚠ Service Bus mặc định | ⚠ at-least-once (peek-lock) |

Từ khoá nhận diện:

"xử lý trùng" → ⚠ at-least-once, cần idempotent "mất tin nhắn" → ⚠ at-most-once "không được mất, không được trùng" → ⚠ cần xử lý idempotent ở phía ứng dụng "duplicate detection" → ⚠ Service Bus chống trùng khi GỬI, không phải khi xử lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mất một tin nhắn hay xử lý trùng thì tệ hơn | ⚠ quyết định chế độ | | Việc xử lý có idempotent không | | | Có theo dõi dead-letter queue không | |

Và câu hỏi phải trả lời trước khi chọn chế độ giao nhận, vì không có lựa chọn nào hoàn hảo: mất một tin nhắn hay xử lý nó hai lần — cái nào gây thiệt hại lớn hơn cho nghiệp vụ của bạn?

Đáp án

C — Triển khai liên tục bằng Azure DevOps

Vì sao đúng

Từ khoá là "tự động cập nhật khi bạn đẩy thay đổi". Triển khai liên tục dựng cho đúng vòng lặp đó: đẩy mã lên kích hoạt build ảnh container, đưa ảnh vào registry, rồi App Service tự lấy bản mới. Không ai phải nhớ bấm gì.

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

• D. Triển khai thủ công bằng Azure CLI — có chữ "thủ công", tức là ngược hẳn yêu cầu.
• A. Tải lên tệp ZIP từ máy — cũng là thao tác tay, và không hợp với ứng dụng đóng gói container.
• B. Triển khai bằng ARM template — mô tả hạ tầng, không phải cơ chế phát hành phiên bản ứng dụng mới; và tự nó cũng không tự động chạy khi mã thay đổi.

Đáp án

B — Gremlin API.

Vì sao đúng

⚠ Gremlin là ngôn ngữ duyệt đồ thị, và đó là API đồ thị của Cosmos DB:

⚠ Dữ liệu đồ thị
   ⚠ ĐỈNH: người, sản phẩm, địa điểm
   ⚠ CẠNH: quan hệ có hướng
        ↓ ⚠ truy vấn Gremlin
⚠ g.V().has('ten','An').out('banBe')
        ↓
⚠ Đi theo cạnh, không cần JOIN

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

• D (Core SQL API) — ⚠ cho tài liệu JSON.

• A (Table API) — ⚠ cho khoá-giá trị.

• C (Cassandra API) — ⚠ cho cột rộng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ TRÙNG với #19602 ở lô 166, ⚠ với ⚠ HAI khác biệt đáng chú ý.

⚠ Năm API Cosmos DB — tên cũ và 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:

"đỉnh, cạnh, quan hệ" → ⚠ Gremlin "JSON, truy vấn nhiều trường" → ⚠ NoSQL "khoá-giá trị" → ⚠ Table "cột rộng, ghi rất nhiều" → ⚠ Cassandra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn đi qua mấy tầng quan hệ | | | Có nhầm chữ cái đáp án từ lần gặp trước không | | | Đã cân nhắc API kỹ chưa | ⚠ không đổi được |

Và điều lô này lặp lại nhiều nhất, qua năm câu trùng lặp: cùng một câu hỏi xuất hiện ở nhiều chứng chỉ với thứ tự phương án khác nhau. Ghi nhớ chữ cái là cách ôn thi chắc chắn sai.