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

Đáp án

B — Giảm tải cho máy chủ với các tệp TĨNH như ảnh, video và PDF bằng cách phân phối chúng qua một mạng lưới các nút.

Vì sao đúng

⚠ CDN đặt bản sao nội dung tại các điểm gần người dùng:

⚠ Không có CDN
   ⚠ Người dùng ở Việt Nam
   ⚠ → máy chủ ở Mỹ
   ⚠ → độ trễ cao, máy chủ chịu mọi lượt tải
        ↓ ⚠ có CDN
⚠ Bản sao ở điểm hiện diện gần nhất
   ⚠ → độ trễ thấp
   ⚠ → máy chủ gốc gần như không bị chạm tới

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

• D (truy xuất dữ liệu nhanh và rẻ để dùng lại sau) — ⚠ mô tả CACHE nói chung, quá mơ hồ.

• A (lưu thông tin phiên tạm thời) — ⚠ đó là session store, ví dụ Redis.

• C (Azure quản lý máy ảo và cập nhật hệ điều hành) — ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ CDN hợp và không hợp với gì: | Hợp | Không hợp | |---|---| | ⚠ Ảnh, CSS, JavaScript | ⚠ nội dung cá nhân hoá từng người | | ⚠ Video, PDF, tệp tải về | ⚠ API trả dữ liệu động | | ⚠ Trang tĩnh | ⚠ dữ liệu thay đổi từng giây | | ⚠ Nguyên tắc | ⚠ cùng một nội dung cho NHIỀU người |

Từ khoá nhận diện:

"nội dung tĩnh, phân phối toàn cầu" → ⚠ CDN "lưu phiên đăng nhập" → ⚠ Redis, session store "cache dữ liệu ứng dụng" → ⚠ Redis "tăng tốc API động" → ⚠ Front Door hoặc cache tầng ứng dụng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nội dung có giống nhau cho mọi người không | ⚠ điều kiện để cache được | | Có chiến lược đổi tên tệp khi cập nhật không | | | TTL đặt bao lâu | |

Và kỹ thuật giải quyết dứt điểm vấn đề khó chịu nhất của CDN, đơn giản đến mức hay bị bỏ qua: thêm mã băm nội dung vào tên tệp. Nội dung đổi thì tên đổi, và không bao giờ phải xoá cache nữa.

Đáp án

B — Cho phép CHỌN THỦ CÔNG trung tâm dữ liệu để đặt máy ảo, đạt tính sẵn sàng cao hơn các lựa chọn khác.

Vì sao đúng

⚠ Availability Zone là các trung tâm dữ liệu VẬT LÝ TÁCH BIỆT trong cùng một vùng:

⚠ Vùng (region) — ví dụ East US
   ⚠ Zone 1 ← toà nhà riêng
   ⚠ Zone 2 ← toà nhà riêng
   ⚠ Zone 3 ← toà nhà riêng
        ↓
⚠ Nguồn điện, làm mát, mạng ĐỘC LẬP
        ↓
⚠ Đặt VM vào các zone khác nhau
   ⚠ → mất một zone vẫn còn chạy

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

• D (các rack máy chủ trong cùng một trung tâm dữ liệu) — ⚠ đó là AVAILABILITY SET: ⚠ fault domain và update domain nằm ⚠ trong cùng một DC.

• C (đồng nghĩa với vùng Azure) — ⚠ SAI: ⚠ một vùng chứa NHIỀU zone.

• A (cấu trúc thư mục để tổ chức tài nguyên) — ⚠ đó là RESOURCE GROUP.

Ghi nhớ

⚠ Availability Set và Availability Zone — phân biệt cốt lõi: | Tiêu chí | Availability Set | Availability Zone | |---|---|---| | ⚠ Phạm vi | ⚠ TRONG một trung tâm dữ liệu | ⚠ các trung tâm dữ liệu KHÁC nhau | | ⚠ Chống được | ⚠ hỏng rack, bảo trì | ⚠ mất cả một toà nhà | | ⚠ SLA | ⚠ 99,95% | ⚠ 99,99% | | ⚠ Khái niệm | ⚠ fault domain, update domain | ⚠ zone 1, 2, 3 | | ⚠ Zone mạnh hơn | ⚠ nhưng không phải vùng nào cũng có |

Từ khoá nhận diện:

"trung tâm dữ liệu tách biệt trong cùng vùng" → ⚠ Availability Zone "rack khác nhau trong cùng DC" → ⚠ Availability Set "vùng khác nhau" → ⚠ DR liên vùng "nhóm tài nguyên" → ⚠ Resource Group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng đang dùng có availability zone không | | | Mọi thành phần có hỗ trợ zone không | ⚠ VM, đĩa, IP, load balancer | | SLA mục tiêu là bao nhiêu | |

Và điều dễ bị bỏ sót khi thiết kế kiến trúc phân tán theo zone: mọi thành phần trong chuỗi đều phải hỗ trợ zone. Một load balancer Basic SKU đủ để kéo cả hệ thống về mức sẵn sàng của một zone duy nhất.

Đáp án

A — Cách duy nhất là gỡ chính sách, tạo tài nguyên, rồi đặt lại chính sách.

Vì sao đúng

⚠ Azure Policy hoạt động ở tầng KHÁC hoàn toàn so với phân quyền RBAC:

⚠ Yêu cầu tạo tài nguyên
        ↓
⚠ 1. Kiểm tra RBAC: bạn có QUYỀN không?
        ↓ ⚠ có
⚠ 2. Kiểm tra POLICY: có VI PHẠM luật không?
        ↓ ⚠ vi phạm
⚠ TỪ CHỐI
        ↓
⚠ Kể cả Owner hay Global Admin cũng bị chặn

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

• B (Owner tạo được bất chấp policy) — ⚠ SAI: ⚠ đây là hiểu lầm phổ biến nhất về Azure Policy.

• C (dùng tài khoản Contributor trở lên) — ⚠ cũng SAI: ⚠ mọi mức quyền đều bị chặn như nhau.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ khoá A nói "cách DUY NHẤT", ⚠ nhưng ⚠ thực tế còn hai cách khác.

⚠ RBAC và Policy — bảng phân biệt: | Tiêu chí | RBAC | Azure Policy | |---|---|---| | ⚠ Câu hỏi | ⚠ AI được làm gì | ⚠ KẾT QUẢ có hợp lệ không | | ⚠ Đối tượng | ⚠ người dùng, nhóm, danh tính | ⚠ tài nguyên | | ⚠ Quyền cao có vượt qua được | ⚠ có, Owner làm được nhiều hơn | ⚠ KHÔNG | | ⚠ Ví dụ | ⚠ "Nam được tạo VM" | ⚠ "VM phải có thẻ Environment" |

Từ khoá nhận diện:

"chặn tạo tài nguyên không đúng chuẩn" → ⚠ Azure Policy "ai được làm gì" → ⚠ RBAC "Owner vẫn bị chặn" → ⚠ Policy "miễn trừ một trường hợp" → ⚠ policy exemption

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Policy đang ở hiệu ứng Audit hay Deny | | | Có dùng exemption thay vì gỡ policy không | | | Có exemption nào không còn cần thiết không | |

Và cách xử lý đúng khi cần tạo một tài nguyên bị chính sách chặn, tốt hơn hẳn cách mà bộ đề gọi là "duy nhất": tạo một policy exemption có thời hạn và có ghi lý do. Gỡ chính sách đi dù chỉ vài phút là mở cửa cho mọi vi phạm khác.

Đáp án

D — Azure DevOps.

Vì sao đúng

⚠ Azure Pipelines là một trong năm dịch vụ của Azure DevOps: | Dịch vụ | Việc | |---|---| | ⚠ Azure Pipelines | ⚠ CI/CD — build, test, deploy | | ⚠ Azure Repos | ⚠ kho mã Git | | ⚠ Azure Boards | ⚠ quản lý công việc, Scrum, Kanban | | ⚠ Azure Test Plans | ⚠ quản lý kiểm thử | | ⚠ Azure Artifacts | ⚠ kho gói: NuGet, npm, Maven |

⚠ Commit vào kho
        ↓ ⚠ Pipeline kích hoạt
⚠ Build → chạy test → đóng gói
        ↓
⚠ Triển khai lên Azure

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

• B (GitHub) — ⚠ bẫy đáng chú ý: ⚠ GitHub có ⚠ Actions, chức năng tương đương, ⚠ nhưng đề hỏi cụ thể tên ⚠ "Pipelines" — ⚠ đó là thuật ngữ của Azure DevOps.

• A (Azure Monitor) — ⚠ giám sát, không phải CI/CD.

• C (Virtual Machines) — ⚠ hạ tầng tính toán.

Ghi nhớ

⚠ Azure DevOps và GitHub — hai lựa chọn của Microsoft: | Tiêu chí | Azure DevOps | GitHub | |---|---|---| | ⚠ CI/CD | ⚠ Azure Pipelines | ⚠ GitHub Actions | | ⚠ Kho mã | ⚠ Azure Repos | ⚠ GitHub Repos | | ⚠ Quản lý việc | ⚠ Azure Boards | ⚠ GitHub Issues, Projects | | ⚠ Kho gói | ⚠ Artifacts | ⚠ Packages | | ⚠ Xu hướng | ⚠ Microsoft đầu tư mạnh vào GitHub | | ⚠ Azure DevOps | ⚠ vẫn mạnh ở quản lý dự án doanh nghiệp |

Từ khoá nhận diện:

"Pipelines" → ⚠ Azure DevOps "Actions, workflow" → ⚠ GitHub "Boards, work item" → ⚠ Azure DevOps "Pull request, Issues" → ⚠ cả hai đều có

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Pipeline định nghĩa bằng YAML hay giao diện | | | Kết nối tới Azure dùng secret hay federation | | | Có cổng phê duyệt trước khi lên production không | |

Và cải tiến bảo mật đáng làm nhất cho mọi pipeline triển khai lên Azure: chuyển service connection sang workload identity federation. Sau đó không còn bí mật nào cần lưu và luân chuyển nữa.

Đáp án

C — Tấn công ở tầng ỨNG DỤNG (Layer 7).

Vì sao đúng

⚠ Azure DDoS Protection hoạt động ở tầng MẠNG và VẬN CHUYỂN: | Tầng | DDoS Protection có chặn không | |---|---| | ⚠ L3 — Network | ⚠ CÓ — flood gói tin, ICMP | | ⚠ L4 — Transport | ⚠ CÓ — SYN flood, UDP flood | | ⚠ L7 — Application | ⚠ KHÔNG — cần WAF |

⚠ Tấn công L3/L4
   ⚠ làm ngập băng thông và kết nối
        ↓ ⚠ DDoS Protection chặn

⚠ Tấn công L7
   ⚠ HTTP flood, slowloris
   ⚠ trông giống lưu lượng THẬT
        ↓ ⚠ cần WAF phân tích nội dung

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

• A (L4) và B (L3) — ⚠ đều ĐƯỢC bảo vệ bởi DDoS Protection.

Ghi nhớ

⚠ Phân công bảo vệ theo tầng: | Tầng | Công cụ | |---|---| | ⚠ L3, L4 | ⚠ Azure DDoS Protection | | ⚠ L7 | ⚠ WAF trên Application Gateway hoặc Front Door | | ⚠ Lọc IP và cổng | ⚠ NSG, Azure Firewall | | ⚠ Bảo vệ đầy đủ | ⚠ cần CẢ DDoS Protection LẪN WAF |

Từ khoá nhận diện:

"làm ngập băng thông, SYN flood" → ⚠ L3/L4, DDoS Protection "HTTP flood, SQL injection, XSS" → ⚠ L7, cần WAF "lọc theo IP và cổng" → ⚠ NSG "kiểm tra nội dung request" → ⚠ WAF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có WAF cho tầng ứng dụng chưa | ⚠ DDoS Protection không thay được | | Đang dùng mức Basic hay trả phí | | | Có kế hoạch ứng phó khi bị tấn công không | |

Và điều cần nói rõ khi trình bày về bảo vệ DDoS: nó chặn được lũ lụt băng thông, nhưng không phân biệt được một request HTTP hợp lệ với một request cố ý làm quá tải ứng dụng. Đó là công việc của WAF.

Đáp án

A — Tạo nhiều subscription trong cùng một tenant

Vì sao đúng

Đề nêu ba thứ cần tách: hoá đơn, quyền, và hạn mức tài nguyên. Subscription là ranh giới đúng cho cả ba:

Giữ mọi subscription trong cùng một tenant là phần quan trọng thứ hai: nhân viên vẫn dùng một tài khoản duy nhất cho tất cả.

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

• D. Dùng resource group — resource group không tách được hạn mức; hạn mức áp ở mức subscription.
• B. Nhiều management group trong một subscription — đảo ngược thứ tự: management group nằm trên subscription, không nằm trong.
• C. Tạo tenant riêng cho từng đơn vị — quá tay: mỗi tenant là một thư mục danh tính riêng, nên người dùng phải có tài khoản riêng cho từng nơi.

Đáp án

D — Log Analytics Workspace.

Vì sao đúng

⚠ Log Analytics Workspace là vùng chứa của Azure Monitor:

⚠ Nhiều tài nguyên Azure
        ↓ ⚠ diagnostic settings
⚠ Log Analytics Workspace
   ⚠ dữ liệu tổ chức thành BẢNG
        ↓ ⚠ truy vấn KQL
⚠ Biểu đồ, cảnh báo, workbook

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.

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

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ GẦN TRÙNG với #21460 trong CÙNG MỘT LÔ.

⚠ Ba đích gửi log — nhắc lại: | Đí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ẻ | | ⚠ Event Hub | ⚠ chuyển sang 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 | |---|---| | Diagnostic settings đã bật cho tài nguyên quan trọng chưa | | | Đang nạp bao nhiêu GB mỗi ngày | | | Có bảng nào nên chuyển sang Basic Logs không | |

Và điều lô này cho thấy rõ nhất về cách bộ đề được xây dựng: hai câu hỏi hoàn toàn giống nhau về nội dung, chỉ khác cách diễn đạt, cùng nằm trong một lô năm mươi câu. Hash MD5 không bắt được, chỉ đọc kỹ mới nhận ra.

Đáp án

B — Public cloud phục vụ CÔNG CHÚNG hoặc một nhóm ngành lớn và do nhà cung cấp dịch vụ sở hữu, còn private cloud do một tổ chức sở hữu và vận hành cho mục đích riêng.

Vì sao đúng

⚠ Ba mô hình triển khai đám mây — phân biệt bằng AI SỞ HỮU và AI DÙNG: | Mô hình | Ai sở hữu | Ai dùng | |---|---|---| | ⚠ Public cloud | ⚠ nhà cung cấp | ⚠ công chúng | | ⚠ Private cloud | ⚠ một tổ chức | ⚠ chính tổ chức đó | | ⚠ Hybrid cloud | ⚠ kết hợp cả hai | |

⚠ Public
   ⚠ Azure, AWS, Google Cloud
   ⚠ dùng chung hạ tầng, cách ly logic
⚠ Private
   ⚠ trung tâm dữ liệu riêng, hoặc Azure Stack
   ⚠ hạ tầng dành riêng

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

• C — ⚠ ĐẢO NGƯỢC hai định nghĩa; ⚠ bẫy đối xứng.

• A và D — ⚠ gộp chung hai mô hình, xoá mất điểm phân biệt.

Ghi nhớ

⚠ Ba mô hình — bảng đầy đủ: | Mô hình | Ưu điểm | Nhược điểm | |---|---|---| | ⚠ Public | ⚠ không đầu tư ban đầu, co giãn ngay, dịch vụ phong phú | ⚠ ít kiểm soát, dữ liệu ở ngoài | | ⚠ Private | ⚠ kiểm soát hoàn toàn, đáp ứng tuân thủ khắt khe | ⚠ đầu tư lớn, tự vận hành | | ⚠ Hybrid | ⚠ linh hoạt, chuyển đổi dần | ⚠ phức tạp, phải quản lý hai môi trường |

Từ khoá nhận diện:

"công chúng, nhà cung cấp sở hữu" → ⚠ public cloud "một tổ chức dùng riêng" → ⚠ private cloud "kết hợp tại chỗ và đám mây" → ⚠ hybrid "nhiều nhà cung cấp đám mây" → ⚠ multi-cloud, khái niệm KHÁC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ràng buộc pháp lý về nơi lưu dữ liệu không | | | Đang là hybrid hay multi-cloud | ⚠ hai thứ khác nhau | | Chi phí vận hành private cloud đã tính đủ chưa | |

Và điểm phân biệt gọn nhất giữa hai mô hình, đủ để trả lời mọi câu hỏi dạng này: hạ tầng đó phục vụ nhiều tổ chức hay chỉ một.

Đáp án

B — Management Groups.

Vì sao đúng

⚠ Management Group là cấp CAO NHẤT trong phân cấp của Azure:

⚠ Root Management Group
   ⚠ Management Group "Sản xuất"
      ⚠ Subscription A
      ⚠ Subscription B
   ⚠ Management Group "Phi sản xuất"
      ⚠ Subscription C
        ↓
⚠ Policy và RBAC gán ở đây KẾ THỪA xuống
   ⚠ mọi subscription, resource group, tài nguyên

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

• A (Resource Groups) — ⚠ nằm BÊN TRONG một subscription, không gom được nhiều subscription.

• D (RBAC) — ⚠ là cơ chế PHÂN QUYỀN, không phải cấu trúc phân cấp.

• C (Microsoft Entra ID) — ⚠ quản lý DANH TÍNH, không phải tài nguyên.

Ghi nhớ

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

⚠ Bốn cấp phạm vi — bảng chốt: | 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 tài nguyên | | ⚠ Resource | ⚠ tài nguyên cụ thể | | ⚠ RBAC và Policy | ⚠ gán được ở MỌI cấp, KẾ THỪA xuống dưới |

Từ khoá nhận diện:

"nhiều subscription, quản trị tập trung" → ⚠ Management Group "nhóm tài nguyên trong một subscription" → ⚠ Resource Group "ai được làm gì" → ⚠ RBAC "người dùng và nhóm" → ⚠ Entra ID

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai được gán quyền ở Root Management Group không | ⚠ rà soát kỹ | | Phân cấp có quá sâu không | | | Policy ở cấp cao có chạy Audit trước không | |

Và phạm vi cần rà soát cẩn thận nhất trong toàn bộ một tenant Azure: quyền và chính sách gán ở Root Management Group. Một thay đổi ở đó ảnh hưởng tới mọi subscription mà tổ chức đang có.

Đáp án

B — HDInsight.

Vì sao đúng

⚠ HDInsight là nền tảng phân tích dữ liệu lớn mã nguồn mở được Azure quản lý: | Framework hỗ trợ | Nội dung | |---|---| | ⚠ Apache Hadoop | ⚠ HDFS, MapReduce, YARN | | ⚠ Apache Spark | | | ⚠ Apache Hive | ⚠ SQL trên dữ liệu lớn | | ⚠ Apache Kafka | ⚠ luồng sự kiện | | ⚠ Apache HBase | ⚠ CSDL NoSQL | | ⚠ Azure lo | ⚠ dựng cụm, vá lỗi, giám sát |

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

• A (Azure Hadoop Services) — ⚠ KHÔNG TỒN TẠI: ⚠ tên bịa nghe rất hợp lý.

• C (Data Factory) — ⚠ điều phối luồng dữ liệu, không phải nền tảng Hadoop.

• D (Kubernetes Service) — ⚠ điều phối container.

Ghi nhớ

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

⚠ Bốn nền tảng phân tích dữ liệu lớn trên Azure: | Nền tảng | Định vị | |---|---| | ⚠ HDInsight | ⚠ Hadoop, Hive, Kafka, HBase — nhiều framework mã nguồn mở | | ⚠ Databricks | ⚠ Spark tối ưu, notebook cộng tác, ML | | ⚠ Synapse | ⚠ SQL pool + Spark + pipeline trong một | | ⚠ Microsoft Fabric | ⚠ hợp nhất tất cả, hướng đi mới |

Từ khoá nhận diện:

"Hadoop, Hive, HBase, Kafka" → ⚠ HDInsight "Spark, notebook, MLflow" → ⚠ Databricks "SQL pool, kho dữ liệu" → ⚠ Synapse "Azure Hadoop Services" → ⚠ tên BỊA

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần framework cụ thể nào không | ⚠ quyết định HDInsight hay Databricks | | Cụm có tự tắt khi rảnh không | | | Đội thạo Spark hay SQL | |

Và mẹo loại phương án hữu ích khi gặp tên dịch vụ lạ: Azure hiếm khi đặt tên theo kiểu "Azure + tên công nghệ + Services". Những cái tên như HDInsight hay Synapse nghe lạ hơn nhưng lại là thật.