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

Đáp án

B — Quản lý tài nguyên Azure, bao gồm cả việc phân quyền cho người khác

Vì sao đúng

Owner là vai cơ bản cao nhất, và điểm phân biệt nằm ở vế thứ hai: khả năng gán vai cho người khác. Đây chính là ranh giới với Contributor.

Vì Owner tự nâng quyền cho mình hoặc cho ai khác được, đây là vai nên cấp cho rất ít người, và nên dùng kèm Privileged Identity Management để chỉ kích hoạt khi cần.

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

• D. Quản lý tài nguyên nhưng không phân quyền được — mô tả chính xác Contributor.
• A. Chỉ xem tài nguyên — đó là Reader.
• C. Giám sát tài nguyên để tìm mối đe doạ — đó là Defender for Cloud, không phải một vai RBAC.

Đáp án

C — Management group

Vì sao đúng

Cây tài nguyên Azure có bốn tầng, và management group nằm ở trên cùng:

Management group          ← cao nhất, lồng được tới 6 tầng
  └── Subscription        ← ranh giới thanh toán và hạn mức
        └── Resource group
              └── Resource

Chính sách và phân quyền gán ở tầng nào thì kế thừa xuống toàn bộ nhánh bên dưới. Đó là lý do management group tồn tại: áp một luật cho hàng chục subscription bằng một lần gán.

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

• D. Subscription — nằm dưới management group; đây là phương án nhiễu gần nhất vì nhiều tổ chức nhỏ không dùng management group nên subscription trông như tầng cao nhất.
• A. Resource group và B. Resource — hai tầng dưới cùng.

Ngoài cây này còn có tenant (Entra ID), nhưng đó là ranh giới danh tính chứ không phải một tầng trong cây tài nguyên.

Đáp án

C — Không bao giờ tin, luôn xác minh (never trust, always verify)

Vì sao đúng

Đây là câu tóm tắt kinh điển của Zero Trust, và ý nghĩa của nó là: vị trí trong mạng không tạo ra sự tin cậy. Một yêu cầu đến từ trong văn phòng cũng phải chứng minh danh tính và tình trạng thiết bị y như yêu cầu đến từ quán cà phê.

Mô hình này ra đời vì mô hình vành đai đã hỏng: người làm việc từ xa, ứng dụng chạy trên đám mây, và kẻ tấn công vào được một máy là đi lại tự do bên trong.

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

• B. "Trust but verify" — đây là phương án nhiễu gần nhất và cũng là một câu nói nổi tiếng, nhưng nó vẫn bắt đầu bằng sự tin cậy. Zero Trust bỏ hẳn phần đó.
• A. Tin cho tới khi chứng minh ngược lại — chính là mô hình vành đai cũ.
• D. Bảo mật bằng cách giấu đi — nguyên tắc đã bị bác bỏ từ lâu.

Đáp án

A — Subscription

Vì sao đúng

Cây tài nguyên Azure là cây thật, mỗi nút có đúng một cha:

Management group
  └── Subscription
        └── Resource group      ← thuộc về ĐÚNG MỘT subscription
              └── Resource      ← thuộc về ĐÚNG MỘT resource group

Vì vậy resource group thuộc về một subscription duy nhất, và đó cũng là lý do resource group không chứa được tài nguyên từ nhiều subscription.

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

• B. Management Group — nằm cao hơn hai tầng; nó chứa subscription, không chứa trực tiếp resource group.
• C. Resource group khác — resource group không lồng vào nhau được.
• D. Microsoft Entra ID — là ranh giới danh tính, không phải một tầng trong cây tài nguyên.

Một điều đáng biết

Tài nguyên chuyển được sang resource group khác, kể cả sang subscription khác — nhưng đó là thao tác có điều kiện và không phải loại tài nguyên nào cũng hỗ trợ.

Đáp án

D — Một Azure subscription

Vì sao đúng

Câu này tìm thứ không phải tài nguyên. Subscription là vùng chứa — nó là ranh giới thanh toán, hạn mức và quản trị, đứng trên tài nguyên trong cây phân cấp.

Cách phân biệt gọn: tài nguyên là thứ bạn tạo bên trong một subscription và có resource ID riêng; subscription là cái chứa chúng.

Vì sao các phương án khác sai (chúng là tài nguyên)

• A. Tài khoản lưu trữ, B. Cơ sở dữ liệu Azure SQL, C. Mạng ảo — cả ba đều được tạo bên trong một resource group, có resource ID, gắn tag được, và phân quyền bằng RBAC được.

Cùng lối tư duy đó, resource group cũng không phải tài nguyên — nó cũng là vùng chứa.

Đáp án

A — Mạng toàn cầu của Microsoft

Vì sao đúng

Lưu lượng giữa hai VNet đã peering — kể cả khi chúng nằm ở hai khu vực khác nhau hay hai châu lục — luôn đi trên hạ tầng xương sống riêng của Microsoft, không bao giờ ra Internet công cộng.

Điều này có ba hệ quả thực tế:

• Bảo mật — dữ liệu không đi qua mạng công cộng, nên giảm hẳn bề mặt rủi ro.
• Hiệu năng — độ trễ thấp hơn và ổn định hơn, vì không phụ thuộc tình trạng Internet.
• Đơn giản — không cần cổng VPN nào để mã hoá đường truyền.

Đổi lại, lưu lượng giữa hai khu vực có tính phí theo lượng dữ liệu truyền.

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

• B. Internet công cộng — đây là hiểu nhầm phổ biến khi hai VNet ở xa nhau; thực tế peering toàn cầu vẫn đi hoàn toàn trong mạng của Microsoft.

Đáp án

B — Bảo đảm tuân thủ về nơi lưu trữ dữ liệu

Vì sao đúng

Sovereign region là các khu vực Azure tách biệt về vật lý và logic khỏi đám mây công cộng, dựng riêng cho khách hàng có yêu cầu pháp lý đặc biệt — ví dụ Azure Government cho cơ quan chính phủ Mỹ, hoặc Azure China do đối tác trong nước vận hành.

Chúng bảo đảm dữ liệu không rời khỏi ranh giới pháp lý, và có những chứng nhận tuân thủ mà đám mây công cộng thông thường không có.

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

• D. Cho phép truy cập dịch vụ Azure ở các vị trí địa lý cụ thể — đó là vai trò của region thông thường; sovereign region đi xa hơn ở chỗ nó tách biệt hẳn khỏi đám mây công cộng.
• C. Hiệu năng cao hơn — không có; đôi khi còn ngược lại vì quy mô nhỏ hơn.
• A. Giảm giá cho khách hàng ở một số khu vực — thường đắt hơn do quy mô nhỏ và yêu cầu vận hành riêng.

🧩 Phân tích chi tiết câu hỏi trắc nghiệm Azure Storage Redundancy

📘 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả tình huống công ty có hai trung tâm dữ liệu (datacenters) tại Los Angeles và New York, sử dụng subscription Microsoft Azure. Bạn đang cấu hình hai datacenter này thành geo-clustered sites để đảm bảo tính sẵn sàng cao (site resiliency) – nghĩa là tạo cụm địa lý để chống chịu sự cố tại một vị trí. Nhiệm vụ là khuyến nghị một tùy chọn redundancy (sao lưu dư thừa) cho Azure Storage phù hợp với các yêu cầu sau:
✑ Dữ liệu phải được lưu trữ trên nhiều node (multiple nodes) – đảm bảo sao chép nội bộ để tránh mất dữ liệu do hỏng phần cứng.
✑ Dữ liệu phải được lưu trữ trên các node ở các vị trí địa lý riêng biệt (separate geographic locations) – tức là sao chép qua các vùng (regions) khác nhau, không chỉ trong cùng một vùng.
✑ Dữ liệu có thể đọc được từ vị trí phụ (secondary) cũng như vị trí chính (primary) – secondary location phải hỗ trợ đọc (read-access), không chỉ dùng cho khôi phục thảm họa (DR).

Mục tiêu là chọn loại Azure Blob Storage (hoặc tương tự) redundancy phù hợp nhất cho kịch bản geo-clustering, đảm bảo tính sẵn sàng toàn cầu. (Dựa trên kiến thức Azure Storage redundancy cập nhật đến 2024-2026, không có thay đổi lớn từ Microsoft Docs).

✅ Đáp án đúng: Read-only geo-redundant storage
Lý do lựa chọn (chi tiết):
Loại này chính là RA-GRS (Read-access Geo-redundant Storage) – sao chép dữ liệu đồng bộ hóa bất đồng bộ (asynchronous) từ primary region sang secondary region (cách nhau ít nhất 300km, ví dụ LA sang NY). Nó đáp ứng hoàn hảo cả 3 yêu cầu:

• Multiple nodes: Sao chép 3 bản trong primary (LRS) + 3 bản trong secondary.
• Separate geographic locations: Secondary region riêng biệt địa lý (paired regions như West US 2 và East US).
• Read from secondary: Secondary hỗ trợ read-only access (có thể đọc dữ liệu ngay cả khi primary outage), lý tưởng cho geo-clustering với workload đọc cao.
  RA-GRS có RPO thấp (~15 phút lag), RTO thấp cho read, phù hợp resiliency cao đến 2026.

🛠️ Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên yêu cầu câu hỏi và kiến thức Azure mới nhất (không hỗ trợ GZRS/GAZRS ở tất cả account đến 2026, nhưng không liên quan câu hỏi).

• ❌ Geo-redundant storage
  Phân tích sai: Đây là GRS (Geo-redundant Storage), sao chép async từ primary sang secondary region (separate locations ✅, multiple nodes ✅). Nhưng SAI lớn: Secondary KHÔNG hỗ trợ read access – chỉ dùng cho failover DR, không đọc được từ secondary như yêu cầu. Không phù hợp geo-clustering cần read từ cả hai.

• ✅ Read-only geo-redundant storage
  Phân tích đúng: Như đã giải thích ở trên, RA-GRS đáp ứng đầy đủ 3 yêu cầu: multiple nodes (6 copies tổng), separate geo-locations (hai regions), và read-access từ secondary (read-only). Hoàn hảo cho datacenters LA-NY làm geo-cluster.

• ❌ Zone-redundant storage
  Phân tích sai: ZRS (Zone-redundant Storage) sao chép đồng bộ (synchronous) qua 3 Availability Zones trong CÙNG MỘT region (multiple nodes ✅). SAI: Không separate geographic locations (chỉ intra-region), và không có secondary region để read từ vị trí xa như LA-NY.

• ❌ Locally redundant storage
  Phân tích sai: LRS (Locally redundant Storage) chỉ sao chép 3 bản trong CÙNG MỘT datacenter (multiple nodes ✅, rẻ nhất). SAI hoàn toàn: Không separate geo-locations, không secondary để read – chỉ resiliency local, không dùng cho geo-clustering.

📚 Tài liệu tham khảo (cập nhật mới nhất 2024-2026):

• Microsoft Docs: Azure Storage redundancy options – Chi tiết GRS/RA-GRS/ZRS/LRS.
• Azure Fundamentals AZ-900: Storage redundancy in exams.
• Paired regions: Azure regions (ví dụ West US 2 pair với East US).

Hy vọng phân tích này giúp bạn nắm vững Azure Storage cho kỳ thi Fundamentals! 🚀 Nếu cần thêm ví dụ thực tế, hỏi nhé!

🧩 Phân tích chi tiết câu hỏi

📖 Nội dung câu hỏi:
Câu hỏi thuộc dạng "Does the solution meet the goal?" (Giải pháp có đáp ứng mục tiêu không?), thường xuất hiện trong các bộ câu hỏi mô tả cùng một tình huống nhưng mỗi câu có kết quả khác nhau.
Tình huống cụ thể:

• Công ty của bạn đang sử dụng Azure subscription với Basic support plan (kế hoạch hỗ trợ cơ bản, miễn phí).
• Họ muốn yêu cầu Microsoft đánh giá thiết kế (assessment) của môi trường Azure (design review hoặc architecture assessment).
• Tuy nhiên, Basic plan không hỗ trợ tính năng này (chỉ hỗ trợ quản lý hóa đơn và sức khỏe dịch vụ Azure).
• Mục tiêu: Nâng cấp lên một support plan hỗ trợ tính năng đánh giá thiết kế từ Microsoft, đồng thời giữ chi phí ở mức tối thiểu (minimize expenses).
  Giải pháp đề xuất: Khuyến nghị công ty đăng ký Professional Direct support plan.
  Câu hỏi chính: Giải pháp này có đáp ứng mục tiêu không?

🛠️ Bối cảnh kiến thức Azure Support Plans (cập nhật đến 2026):
Theo tài liệu chính thức Microsoft Azure (phiên bản mới nhất 2024-2026), các support plan được phân cấp như sau:

• Basic: Miễn phí, không hỗ trợ đánh giá thiết kế.
• Developer: Hỗ trợ break-fix cơ bản, chi phí thấp (~$29/tháng).
• Standard: Hỗ trợ architecture guidance và design review qua support ticket (reactive), chi phí trung bình (~$100/tháng), đủ để yêu cầu assessment thiết kế.
• Professional Direct: Hỗ trợ cao cấp hơn Standard (bao gồm proactive services, assigned engineer, 24/7), chi phí cao hơn nhiều (~$1,000+/tháng tùy quy mô).
  Tính năng "assessment of an Azure environment's design" (đánh giá thiết kế) có thể thực hiện qua Standard plan bằng cách tạo support request cho architecture guidance. Professional Direct là thừa thãi và đắt đỏ hơn.

✅ Đáp án đúng: No
Lý do lựa chọn (bằng tiếng Việt):
Giải pháp không đáp ứng mục tiêu vì Professional Direct support plan tuy hỗ trợ đầy đủ tính năng đánh giá thiết kế (và hơn thế), nhưng không giữ chi phí ở mức tối thiểu. Plan rẻ hơn là Standard đã đủ hỗ trợ yêu cầu này qua architecture guidance reactive, giúp tiết kiệm chi phí đáng kể. Việc chọn Professional Direct vi phạm nguyên tắc "keeping expenses to a minimum".

📋 Giải thích tất cả các phương án (giữ nguyên text gốc bằng tiếng Anh)

• Yes ❌ [SAI]
  Giải thích: Phương án này sai vì giả định giải pháp hoàn hảo, nhưng Professional Direct quá đắt đỏ so với nhu cầu. Standard plan rẻ hơn đã hỗ trợ "assessment" qua support request cho design review, nên Yes không chính xác khi mục tiêu nhấn mạnh minimize expenses.

• No ✅ [ĐÚNG]
  Giải thích: Phương án này đúng vì giải pháp đề xuất không tối ưu chi phí. Mặc dù Professional Direct hỗ trợ tính năng (proactive architecture assessment), nhưng Standard plan là lựa chọn tối thiểu (rẻ hơn, vẫn cho phép yêu cầu đánh giá thiết kế reactive). Điều này phù hợp nguyên tắc "make sure... while keeping expenses to a minimum".

📘 Tài liệu tham khảo:

• Azure Support Plans Overview (Microsoft Docs, cập nhật 2024-2026).
• Azure Support Plan Comparison Matrix – Xem phần "Architecture & best practices guidance".
• Azure Well-Architected Framework Reviews – Hỗ trợ từ Standard plan trở lên qua support tickets.

💡 Lưu ý thêm: Nếu cần minimize chi phí thực sự, khuyến nghị Standard plan thay vì Professional Direct! 🏆

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc dạng kiểu "Does the solution meet the goal?" thường gặp trong kỳ thi Microsoft Azure Fundamentals (AZ-900), mô tả một tình huống triển khai cụ thể và kiểm tra xem giải pháp đề xuất có đáp ứng yêu cầu hay không.

Nội dung chính:
Bạn được giao nhiệm vụ triển khai các máy ảo Azure (Azure virtual machines) cho công ty. Yêu cầu là sử dụng giải pháp triển khai đám mây phù hợp (appropriate cloud deployment solution). Giải pháp đề xuất: Sử dụng Software as a Service (SaaS).
Câu hỏi: Giải pháp này có đáp ứng mục tiêu không?

Bối cảnh quan trọng:

• Azure Virtual Machines là dịch vụ IaaS (Infrastructure as a Service), cho phép người dùng kiểm soát hoàn toàn hạ tầng (OS, ứng dụng, cấu hình phần cứng ảo).
• Các mô hình triển khai đám mây Azure bao gồm IaaS, PaaS, SaaS (theo tài liệu Microsoft cập nhật đến 2026, không thay đổi cơ bản). SaaS chỉ cung cấp phần mềm sẵn dùng, không hỗ trợ triển khai máy ảo tùy chỉnh.
  📘 Nguồn tham khảo: Microsoft Learn - AZ-900: Cloud deployment models, Azure Virtual Machines overview (phiên bản mới nhất 2026).

✅ Đáp án đúng: No

Lý do lựa chọn:
Giải pháp SaaS KHÔNG phù hợp vì Azure Virtual Machines yêu cầu mô hình IaaS để triển khai máy ảo tùy chỉnh, nơi bạn quản lý toàn bộ hạ tầng. SaaS chỉ cung cấp ứng dụng sẵn dùng (như Microsoft 365), không cho phép triển khai VM. Sử dụng SaaS sẽ không đáp ứng yêu cầu "deploying Azure virtual machines". Giải pháp đúng phải là IaaS (Azure Virtual Machines).

🛠️ Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Phần giải thích sử dụng tiếng Việt hoàn toàn:

• Yes ❌
  Sai vì: Phương án này cho rằng SaaS đáp ứng yêu cầu triển khai Azure Virtual Machines. Thực tế, SaaS là mô hình dùng sẵn phần mềm (end-user applications), người dùng không kiểm soát hạ tầng, OS hay VM. Không thể deploy VM qua SaaS – điều này vi phạm nguyên tắc mô hình đám mây Azure (IaaS mới hỗ trợ VM).

• No ✅
  Đúng vì: Phương án này chính xác xác nhận SaaS KHÔNG đáp ứng mục tiêu. Để triển khai Azure Virtual Machines, cần IaaS để cung cấp hạ tầng ảo hóa linh hoạt (scale, configure VM theo nhu cầu). Tài liệu Azure 2026 nhấn mạnh: SaaS dành cho productivity apps, không phải infrastructure deployment.

Kết luận nổi bật: 🏆 Chọn No để tránh nhầm lẫn giữa các mô hình đám mây. Học thêm qua Microsoft Learn để nắm vững AZ-900! 🚀