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

Đáp án

B — LRS (Locally Redundant Storage)

Vì sao đúng

LRS giữ ba bản sao trong cùng một trung tâm dữ liệu, tức là phạm vi bảo vệ hẹp nhất — và vì thế rẻ nhất. Nó chống được hỏng ổ đĩa hay hỏng máy chủ, nhưng không chống được sự cố của cả cơ sở đó.

Xếp theo giá tăng dần: LRS → ZRS → GRS → GZRS, và mỗi bậc mở rộng phạm vi bảo vệ thêm một mức.

Khi nào LRS là lựa chọn đúng

• Dữ liệu dựng lại được từ nguồn khác.
• Môi trường phát triển và kiểm thử.
• Yêu cầu pháp lý cấm dữ liệu rời khỏi một khu vực cụ thể.

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

• D. ZRS — nhân bản qua ba availability zone, bền hơn và đắt hơn.
• C. GRS — thêm bản sao ở khu vực khác.
• A. GZRS — kết hợp cả hai, bảo vệ tốt nhất và đắt nhất.

Đáp án

B — Tự động co giãn số lượng máy ảo theo nhu cầu hoặc theo lịch

Vì sao đúng

Đây là năng lực định danh của scale set, và nó có hai cách kích hoạt:

• Theo chỉ số — CPU, bộ nhớ, hoặc số liệu tuỳ chọn vượt ngưỡng thì thêm máy.
• Theo lịch — biết trước cao điểm vào giờ nào hay thứ mấy thì chuẩn bị năng lực trước khi tải tới, thay vì phản ứng chậm một nhịp.

Kèm theo đó là tự thay máy hỏng và cập nhật cuốn chiếu.

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

• C. Cho phép tạo và quản lý từng máy ảo bằng tay — ngược hẳn ý tưởng của scale set: mọi máy sinh ra từ cùng một cấu hình và được quản lý như một khối.
• D. Giới hạn tối đa 10 máy — sai; scale set hỗ trợ tới hàng trăm, thậm chí hàng nghìn máy.
• A. Cung cấp giao diện đồ hoạ — đó là Azure Portal, không phải tính năng của scale set.

Đáp án

A — Đúng

Vì sao đúng

VNet peering nối được hai mạng ảo thuộc các subscription khác nhau, thậm chí các tenant khác nhau. Điều kiện là người thực hiện phải có quyền phù hợp ở cả hai phía, và peering phải được khai ở cả hai bên — chỉ một bên khai thì trạng thái vẫn là chờ kết nối.

Đây là cách phổ biến để nối môi trường của hai đơn vị kinh doanh, hoặc nối mạng của bạn với mạng của đối tác.

Ràng buộc thật sự — điều quan trọng cần nhớ

Thứ không vượt qua được không phải là ranh giới subscription mà là dải địa chỉ chồng lấn. Hai VNet dùng chung một dải IP thì peering không thiết lập được, và cách chữa duy nhất là đánh lại địa chỉ cho một bên.

Vì sao phương án còn lại sai

• B. Sai — nhầm ranh giới subscription với ranh giới kỹ thuật thật.

Đáp án

D — Một thực thể logic đại diện cho một tài nguyên trên đám mây

Vì sao đúng

Trong Azure, "resource" là bất kỳ thứ gì bạn tạo và quản lý qua Azure Resource Manager: máy ảo, tài khoản lưu trữ, mạng ảo, cơ sở dữ liệu, địa chỉ IP công khai. Mỗi cái có một định danh duy nhất (resource ID), thuộc về đúng một resource group, và nằm ở một khu vực cụ thể.

Chữ "logic" quan trọng: bạn thao tác với một đối tượng trừu tượng, còn việc nó ánh xạ xuống phần cứng nào là chuyện của Azure.

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

• C. Thiết bị vật lý trong trung tâm dữ liệu — chính là thứ mà lớp trừu tượng này che đi.
• A. Một gói đăng ký dịch vụ Azure — đó là subscription, nằm ở tầng trên.
• B. Một thành phần phần mềm cung cấp dịch vụ — mô tả chung chung và không đúng: nhiều tài nguyên (mạng ảo, resource group) không phải phần mềm cung cấp dịch vụ nào.

Đáp án

A — Cho phép người dùng khách từ tổ chức bên ngoài truy cập tài nguyên của tổ chức bạn

Vì sao đúng

B2B collaboration dựng cho việc cộng tác với đối tác, nhà thầu, nhà cung cấp. Người của công ty kia được mời vào thư mục của bạn dưới dạng tài khoản khách, nhưng họ đăng nhập bằng chính danh tính công ty họ.

Hai lợi ích lớn từ điều đó:

• Bạn không phải tạo và quản lý mật khẩu cho người ngoài — không có tài khoản nào để quên mật khẩu hay bị bỏ quên.
• Đối tác vô hiệu hoá tài khoản nhân viên đó thì người ấy mất luôn quyền vào tài nguyên của bạn.

Tài khoản khách cũng không tiêu giấy phép của tổ chức bạn.

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

• B. Cho khách hàng mua sản phẩm trực tiếp — mô tả một tình huống thương mại, và nếu là quản lý danh tính khách hàng thì đó là B2C.
• D. Quản lý danh tính cho người dùng nội bộ — đó là Entra ID thông thường.
• C. Quản lý danh tính cho ứng dụng đám mây — mô tả quá chung, đúng với cả Entra ID nói chung.

Đáp án

C — Private Cloud (đám mây riêng)

Vì sao đúng

Hai đặc điểm trong đề — yêu cầu tuân thủ nghiêm ngặt và cần giữ quyền kiểm soát dữ liệu nhạy cảm — đều chỉ về đám mây riêng. Toàn bộ hạ tầng phục vụ một tổ chức duy nhất, nên bạn quyết định được dữ liệu nằm ở đâu, ai chạm vào phần cứng, và cấu hình bảo mật ra sao mà không phải chấp nhận mặc định của nhà cung cấp.

Với ngành tài chính, đôi khi đây không phải lựa chọn mà là ràng buộc pháp lý.

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

• A. Hybrid Cloud — là lựa chọn hợp lý khi chỉ một phần dữ liệu nhạy cảm; đề mô tả yêu cầu kiểm soát bao trùm.
• D. Public Cloud — hạ tầng dùng chung, mức kiểm soát thấp nhất.
• B. Community Cloud — dùng chung giữa các tổ chức có nhu cầu tương đồng; hiếm gặp và vẫn là dùng chung.

Cái giá phải trả

Đám mây riêng có chi phí cao nhất và bạn gánh toàn bộ việc vận hành — mua phần cứng, vá lỗi, dựng dự phòng. Đó là cái đổi lấy quyền kiểm soát.

Đáp án

A — Management group dùng để áp chính sách và phân quyền cho nhiều subscription

Vì sao đúng

Đây chính là lý do management group tồn tại: gán Azure Policy hoặc vai RBAC một lần ở management group thì mọi subscription bên dưới tự động thừa hưởng. Không phải lặp lại cho từng subscription, và subscription tạo mới sau này cũng chịu ràng buộc ngay.

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

• C. Một subscription thuộc nhiều management group cùng lúc — sai: cây tài nguyên Azure là cây thật, mỗi subscription có đúng một cha.
• B. Chứa subscription từ nhiều tenant — sai: management group nằm trong một tenant, và tenant là ranh giới danh tính không vượt qua được.
• D. Tối đa 10 subscription mỗi nhóm — sai; giới hạn thực tế cao hơn rất nhiều (hàng nghìn), và cây lồng được tới 6 tầng.

Đáp án

C — Tất cả các đáp án đều đúng

Vì sao đúng

Availability Zone không phải tính năng của riêng một dịch vụ mà là thuộc tính của hạ tầng khu vực, nên nhiều dịch vụ tận dụng được:

• Virtual Machines — đặt máy vào các zone khác nhau, hoặc dùng scale set trải qua nhiều zone.
• App Service — bậc Premium hỗ trợ dư thừa theo zone.
• Azure Storage — tuỳ chọn ZRS nhân bản qua ba zone.

Điểm chung: tất cả đều nhằm giữ dịch vụ chạy khi mất trọn một trung tâm dữ liệu.

Điều cần biết

Không phải khu vực Azure nào cũng có availability zone, và không phải mọi bậc dịch vụ đều hỗ trợ. Đây là thứ phải kiểm tra trước khi thiết kế, vì đổi về sau thường phải dựng lại tài nguyên.

Đáp án

B, C và D — tuân thủ các khung chuẩn ngành, cập nhật và vá lỗi định kỳ, quản lý và giám sát tập trung

Vì sao đúng

Ba lợi ích này đến từ quy mô của nhà cung cấp đám mây — thứ mà một tổ chức đơn lẻ khó tự có:

• B. Chứng nhận tuân thủ — ISO 27001, SOC 2, PCI DSS, HIPAA đã được chứng nhận sẵn ở tầng hạ tầng, nên bạn kế thừa thay vì tự đi chứng nhận từ đầu.
• C. Vá lỗi định kỳ — với dịch vụ PaaS và SaaS, nhà cung cấp vá thay bạn.
• D. Quản lý và giám sát tập trung — một chỗ duy nhất để thấy tư thế bảo mật của toàn bộ môi trường.

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

• A. Có thể tắt các biện pháp bảo mật như mã hoá cho một số ứng dụng — đây không phải lợi ích mà là rủi ro, và trên Azure thì nhiều cơ chế không tắt được (ví dụ mã hoá khi lưu của Storage). Đó là điều tốt chứ không phải hạn chế.

Đáp án

B — Tính di động và nhất quán tốt hơn

Vì sao đúng

Container đóng gói ứng dụng cùng toàn bộ phụ thuộc — thư viện, thời gian chạy, cấu hình — vào một ảnh duy nhất. Nhờ vậy ảnh chạy ở máy lập trình viên, ở môi trường kiểm thử và trên sản xuất đều cho hành vi giống hệt nhau.

Đây chính là thứ giết chết câu "chạy được trên máy tôi mà": không còn khác biệt về môi trường để đổ lỗi.

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

• A. Bảo mật tốt hơn — container kém cô lập hơn máy ảo vì dùng chung nhân hệ điều hành; bảo mật không phải ưu điểm của nó.
• C. Tăng dung lượng lưu trữ — không liên quan; container còn thường không trạng thái.
• D. Cải thiện hiệu năng mạng — không phải mục đích của container.