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

Đáp án

D — Azure Policy

Vì sao đúng

Hai yêu cầu — quy ước đặt tên và khu vực được phép triển khai — đều là ràng buộc về những gì được phép tồn tại, và Policy là công cụ duy nhất trong danh sách thực thi được chúng: nó từ chối việc tạo tài nguyên vi phạm ngay tại thời điểm triển khai.

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

• A. Azure Resource Manager — là lớp API mà mọi thao tác đi qua; Policy chạy bên trong lớp đó, nhưng bản thân ARM không có quy tắc nào.
• C. Purview Governance Portal — quản trị dữ liệu: lập danh mục, phân loại, lineage. Không ràng buộc cấu hình tài nguyên.
• B. Defender for Cloud — đánh giá tư thế bảo mật và đưa khuyến nghị, nhưng khuyến nghị chứ không chặn.

Đáp án

A — Dùng tường lửa.

Vì sao đúng

⚠ Mô hình phòng thủ nhiều lớp — mỗi biện pháp thuộc một lớp: | Lớp | Biện pháp trong đề | |---|---| | ⚠ Vật lý | ⚠ khoá cửa trung tâm dữ liệu — phương án D | | ⚠ Vành đai (perimeter) | ⚠ TƯỜNG LỬA, DDoS Protection — phương án A | | ⚠ Mạng | ⚠ chia máy chủ thành subnet theo vai trò — phương án B | | ⚠ Điện toán | ⚠ vá lỗi hệ điều hành — phương án C |

⚠ Vành đai = ⚠ RANH GIỚI giữa mạng của bạn và thế giới bên ngoài
   ⚠ tường lửa đứng đúng ở chỗ đó

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

• B (chia subnet theo vai trò) — ⚠ là lớp MẠNG, phân đoạn bên trong chứ không phải ranh giới ngoài.

• C (vá hệ điều hành) — ⚠ là lớp ĐIỆN TOÁN.

• D (khoá cửa trung tâm dữ liệu) — ⚠ là lớp VẬT LÝ, và trên Azure thì Microsoft lo.

Ghi nhớ

⚠ Bảy lớp phòng thủ nhiều lớp — nhớ theo thứ tự từ ngoài vào: | Lớp | Biện pháp tiêu biểu | |---|---| | ⚠ Vật lý | ⚠ kiểm soát ra vào trung tâm dữ liệu | | ⚠ Định danh và truy cập | ⚠ MFA, RBAC, Conditional Access | | ⚠ Vành đai | ⚠ DDoS Protection, tường lửa biên | | ⚠ Mạng | ⚠ NSG, phân đoạn subnet, hạn chế kết nối | | ⚠ Điện toán | ⚠ vá lỗi, chống mã độc, khoá cổng quản trị | | ⚠ Ứng dụng | ⚠ WAF, mã an toàn, quản lý bí mật | | ⚠ Dữ liệu | ⚠ mã hoá, phân loại, kiểm soát truy cập |

Từ khoá nhận diện:

"ranh giới với bên ngoài" → ⚠ lớp vành đai "chia mạng bên trong" → ⚠ lớp mạng "vá lỗi máy chủ" → ⚠ lớp điện toán "mã hoá dữ liệu" → ⚠ lớp dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mỗi lớp có ít nhất một biện pháp chưa | ⚠ liệt kê ra, tìm lớp trống | | Có lớp nào đang gánh toàn bộ trách nhiệm không | | | Nếu tường lửa bị vượt qua thì lớp nào chặn tiếp | |

Và điều làm phòng thủ nhiều lớp khác với việc mua nhiều sản phẩm bảo mật: các lớp phải bù cho nhau khi một lớp thất bại, chứ không phải cùng làm một việc ở cùng một chỗ.

Đáp án

B — Bạn phải chờ nhiều năm để khấu hao khoản đầu tư đó vào thuế.

Vì sao đúng

⚠ CapEx và OpEx khác nhau ở cách ghi nhận chi phí: | Tiêu chí | CapEx | OpEx | |---|---|---| | ⚠ Bản chất | ⚠ đầu tư tài sản cố định | ⚠ chi phí vận hành | | ⚠ Trả tiền | ⚠ một lần, trả TRƯỚC | ⚠ đều đặn, theo mức dùng | | ⚠ Ghi vào sổ sách | ⚠ KHẤU HAO dần nhiều năm | ⚠ trừ NGAY trong kỳ | | ⚠ Ví dụ | ⚠ mua máy chủ, xây phòng máy | ⚠ thuê dịch vụ đám mây |

⚠ Đó chính là nhược điểm: ⚠ bỏ ra một khoản lớn hôm nay nhưng chỉ trừ thuế được từng phần mỗi năm, trong khi tiền đã ra khỏi túi ngay.

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

• C (không cần nhiều tiền trả trước) — ⚠ là ƯU điểm của OpEx, không phải nhược điểm của CapEx.

• D (trừ chi phí ngay khi phát sinh) — ⚠ cũng là ƯU điểm của OpEx.

• A (không chắc có lãi) — ⚠ đúng với mọi hoạt động kinh doanh, không phải điểm phân biệt hai mô hình.

Ghi nhớ

⚠ Vì sao đám mây được xem là chuyển CapEx sang OpEx: | Trước | Sau | |---|---| | ⚠ Mua máy chủ đủ dùng 3–5 năm | ⚠ thuê đúng lượng cần lúc này | | ⚠ Mua thừa cho lúc cao điểm | ⚠ co giãn theo nhu cầu thật | | ⚠ Tiền ra trước, giá trị đến sau | ⚠ trả khi dùng | | ⚠ Khấu hao nhiều năm | ⚠ ghi nhận chi phí ngay |

Từ khoá nhận diện:

"trả trước, tài sản, khấu hao" → ⚠ CapEx "trả theo tháng, chi phí vận hành" → ⚠ OpEx "so sánh chi phí tại chỗ với đám mây" → ⚠ TCO Calculator "ước tính chi phí trước khi triển khai" → ⚠ Pricing Calculator

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bộ phận tài chính ưu tiên mô hình nào | ⚠ hỏi họ, đừng tự quyết | | Đã chạy TCO Calculator chưa | | | Tải có đều đến mức sở hữu rẻ hơn không | |

Và điều dễ bị bỏ qua khi so hai mô hình: CapEx còn kéo theo chi phí ẩn — điện, làm mát, mặt bằng, nhân sự vận hành, thay thế phần cứng. So sánh chỉ dựa vào giá mua máy luôn có lợi cho phương án tự sở hữu một cách không công bằng.

Đáp án

C — Tự động hoá.

Vì sao đúng

⚠ Giá trị lớn nhất của dòng lệnh là LẶP LẠI ĐƯỢC: | Khả năng | Nội dung | |---|---| | ⚠ Viết một lần, chạy nhiều lần | ⚠ dựng lại y hệt môi trường | | ⚠ Đưa vào CI/CD | ⚠ triển khai tự động | | ⚠ Lưu vào Git | ⚠ xem lại ai đổi gì, khi nào | | ⚠ Làm hàng loạt | ⚠ 100 tài nguyên bằng một vòng lặp | | ⚠ Chạy theo lịch | ⚠ cron, Automation Account |

⚠ Portal   →  ⚠ một lần, bằng tay, không ai xem lại được
⚠ Dòng lệnh →  ⚠ vô số lần, y hệt nhau, có lịch sử

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

• A (rẻ hơn) — ⚠ giá tài nguyên GIỐNG NHAU dù tạo bằng cách nào.

• B (triển khai VM nhanh hơn) — ⚠ một máy đơn lẻ thì không nhanh hơn đáng kể; lợi thế chỉ xuất hiện khi làm nhiều lần hoặc nhiều máy.

Ghi nhớ

⚠ Bốn cách quản lý Azure và chỗ mạnh của từng cách: | Công cụ | Mạnh ở | |---|---| | ⚠ Portal | ⚠ khám phá, học, xử lý sự cố, xem biểu đồ | | ⚠ CLI và PowerShell | ⚠ tự động hoá theo trình tự lệnh | | ⚠ ARM template và Bicep | ⚠ khai báo trạng thái mong muốn | | ⚠ REST API và SDK | ⚠ nhúng vào ứng dụng |

Từ khoá nhận diện:

"lặp lại, kịch bản, tự động" → ⚠ CLI hoặc PowerShell "khai báo trạng thái cuối cùng" → ⚠ ARM template, Bicep, Terraform "khám phá và học" → ⚠ Portal "chạy CLI mà không cài lên máy" → ⚠ Cloud Shell

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Môi trường sản xuất được dựng bằng cách nào | ⚠ bấm tay thì không dựng lại được | | Kịch bản có nằm trong Git không | | | Có ai đó biết chạy lại kịch bản không | ⚠ đừng để chỉ một người biết |

Và câu hỏi kiểm tra thật sự cho một môi trường sản xuất: nếu mất hết hôm nay, dựng lại y hệt mất bao lâu? Nếu câu trả lời là "không biết", thì đó là lý do để chuyển sang hạ tầng dưới dạng mã.

Đáp án

D — Pay-As-You-Go

Vì sao đúng

Trả theo mức dùng là mô hình không cam kết: tài nguyên được tính tiền theo thời gian thực chạy — với máy ảo là theo giây — và bạn dừng lúc nào thì ngừng tính tiền lúc đó. Đây là mô hình mặc định và linh hoạt nhất, hợp cho tải khó đoán hoặc môi trường ngắn hạn.

Đổi lại là giá đơn vị cao nhất trong các mô hình.

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

• B. Reserved Instances — rẻ hơn nhiều nhưng đòi cam kết 1 hoặc 3 năm, ngược hẳn vế "không cam kết dài hạn".
• C. Spot Pricing — không cam kết và rất rẻ, nhưng máy bị thu hồi bất cứ lúc nào, nên nó là mô hình cho tải chịu được gián đoạn chứ không phải mô hình tính tiền theo giây thông thường.
• A. Enterprise Agreement — hợp đồng thương mại dài hạn cho tổ chức lớn.

Đáp án

B — Azure Cloud Shell

Vì sao đúng

Cloud Shell là môi trường dòng lệnh chạy ngay trong trình duyệt, và đề nêu đúng hai đặc điểm của nó: không phải cài gì trên máy, và cho chọn Bash hoặc PowerShell. Nó đã được cài sẵn Azure CLI, Azure PowerShell, Terraform, kubectl và nhiều công cụ khác, đồng thời tự xác thực bằng tài khoản bạn đang đăng nhập.

Nó cũng có ổ lưu trữ gắn kèm để giữ script giữa các phiên.

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

• A. Azure CLI cài trên máy và D. Azure PowerShell module — đều đòi cài đặt cục bộ, đúng thứ người quản trị này muốn tránh.
• C. Bảng điều khiển trong Portal — chạy trong trình duyệt nhưng là giao diện đồ hoạ, không phải dòng lệnh.

Đáp án

A — Chịu lỗi trước sự cố ở một trung tâm dữ liệu

Vì sao đúng

Availability Zone là các cơ sở vật lý tách biệt trong cùng một khu vực, mỗi zone có nguồn điện, hệ thống làm mát và mạng riêng. Đặt hai máy chủ web ở hai zone khác nhau nghĩa là cháy, mất điện hay sự cố mạng ở một toà nhà cũng không làm dịch vụ dừng.

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

• B. Độ trễ thấp hơn — thực ra hơi ngược lại: liên lạc giữa hai zone có độ trễ cao hơn một chút so với trong cùng zone. Đó là cái giá nhỏ đổi lấy khả năng chịu lỗi.
• C. Giảm chi phí — trải qua nhiều zone thường tốn hơn, vì có thêm phí truyền dữ liệu giữa các zone.
• D. Định tuyến mạng đơn giản hơn — không phải lợi ích của cấu hình này.

Đáp án

D — Network Security Group (NSG).

Vì sao đúng

⚠ NSG là bộ lọc theo luật, MIỄN PHÍ, gắn ở subnet hoặc card mạng: | Đặc điểm | Nội dung | |---|---| | ⚠ Miễn phí | ⚠ không tính tiền riêng | | ⚠ Luật vào và luật ra | ⚠ nguồn, đích, cổng, giao thức, cho phép hay chặn | | ⚠ Xét theo độ ưu tiên | ⚠ số nhỏ xét trước, khớp là dừng | | ⚠ Gắn ở subnet, ở card mạng, hoặc cả hai | |

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

• A (Azure Firewall) — ⚠ mạnh hơn nhiều nhưng TỐN PHÍ, và đặt ở biên mạng ảo chứ không phải từng subnet.

• C (DDoS Protection) — ⚠ chống tấn công lưu lượng lớn, không xét luật vào ra; bậc trả phí cũng tốn tiền.

• B (Advanced Threat Protection) — ⚠ công cụ PHÁT HIỆN mối đe doạ, không lọc gói tin.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với câu #22074 ở lô trước.

Từ khoá nhận diện:

"miễn phí, theo subnet, luật vào ra" → ⚠ NSG "tường lửa quản lý, lọc theo FQDN, có threat intelligence" → ⚠ Azure Firewall "chống lưu lượng tấn công khổng lồ" → ⚠ DDoS Protection "chặn SQL injection và XSS" → ⚠ WAF

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có luật nào mở RDP hoặc SSH ra Internet không | | | NSG ở subnet và ở card mạng có chồng nhau không | ⚠ gói phải qua CẢ HAI | | Luật chiều ra có chặn nhầm cập nhật hệ điều hành không | |

Và công cụ nên nhớ khi luật NSG không hoạt động như mong đợi: Network Watcher — IP flow verify. Nó chỉ thẳng ra luật nào đang chặn, thay vì phải đọc thủ công hai bộ luật chồng nhau.

Đáp án

D — AD Connect (Microsoft Entra Connect).

Vì sao đúng

⚠ Entra Connect là công cụ đồng bộ danh bạ giữa hai thế giới: | Đồng bộ gì | Nội dung | |---|---| | ⚠ Tài khoản người dùng | ⚠ từ AD tại chỗ lên Entra ID | | ⚠ Nhóm | | | ⚠ Băm mật khẩu | ⚠ password hash sync — dùng chung một mật khẩu | | ⚠ Thuộc tính người dùng | ⚠ phòng ban, chức danh, email |

⚠ Active Directory tại chỗ
        ↓ ⚠ Entra Connect chạy trên một máy chủ nội bộ
⚠ Microsoft Entra ID
        ↓
⚠ Người dùng đăng nhập Microsoft 365 và Azure bằng CÙNG tài khoản

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

• B (Azure AD Federation Services) — ⚠ tên gần giống AD FS, là cơ chế XÁC THỰC liên kết, không phải công cụ đồng bộ; AD FS là một tuỳ chọn mà Entra Connect có thể cấu hình.

• C (Azure AD Domain Services) — ⚠ cung cấp dịch vụ miền được quản lý trên Azure cho máy ảo cần join domain, không đồng bộ theo chiều tại chỗ lên đám mây.

• A (LDAP) — ⚠ là GIAO THỨC truy vấn thư mục, không phải phần mềm đồng bộ.

Ghi nhớ

⚠ Ba phương thức xác thực Entra Connect hỗ trợ: | Phương thức | Nội dung | |---|---| | ⚠ Password hash synchronization (PHS) | ⚠ đơn giản nhất, khuyến nghị mặc định | | ⚠ Pass-through authentication (PTA) | ⚠ mật khẩu kiểm tra tại chỗ, không lưu băm lên đám mây | | ⚠ Federation (AD FS) | ⚠ phức tạp nhất, cho yêu cầu đặc thù |

Từ khoá nhận diện:

"đồng bộ AD tại chỗ lên đám mây" → ⚠ Entra Connect "máy ảo cần join domain trên Azure" → ⚠ Entra Domain Services "xác thực liên kết, SAML" → ⚠ AD FS "định danh của đám mây" → ⚠ Entra ID

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy chủ chạy Entra Connect có được bảo vệ như máy chủ quản trị không | ⚠ nó nắm danh bạ toàn tổ chức | | Đồng bộ có đang lỗi âm thầm không | ⚠ kiểm tra trạng thái định kỳ | | Tài khoản đã nghỉ việc có được vô hiệu hoá và đồng bộ chưa | |

Và điều dễ bị đánh giá thấp: máy chủ chạy Entra Connect là một mục tiêu tấn công giá trị cao. Nó có quyền ghi lên danh bạ đám mây của cả tổ chức, nên phải được bảo vệ ở mức ngang với domain controller.

Đáp án

A — Bật spending limit (giới hạn chi tiêu) trong Account Center.

Vì sao đúng

⚠ Spending limit là cơ chế DỪNG dịch vụ, không chỉ báo tin: | Cơ chế | Hành vi | |---|---| | ⚠ Spending limit | ⚠ hết hạn mức thì TẠM DỪNG dịch vụ, không tính thêm tiền | | ⚠ Budget alert | ⚠ chỉ GỬI THÔNG BÁO, dịch vụ vẫn chạy và vẫn tính tiền |

⚠ Đề hỏi làm sao "không phát sinh chi phí vượt mức mà bạn không biết" — chỉ cơ chế dừng thật mới đảm bảo điều đó.

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

• C (đặt cảnh báo hoá đơn gửi email) — ⚠ rất hữu ích nhưng KHÔNG chặn được gì; nếu bạn không đọc email thì tiền vẫn chạy.

• B (chỉ dùng Azure Functions vì có hạn mức miễn phí lớn) — ⚠ không phải giải pháp quản lý chi phí; và vượt hạn mức vẫn tính tiền.

• D (chuyển sang Reserved Instances kèm Hybrid Benefit) — ⚠ GIẢM giá, nhưng không đặt trần nào cả.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ spending limit chỉ có ở loại đăng ký kèm tín dụng — tài khoản miễn phí, gói Visual Studio, một số ưu đãi. ⚠ Đăng ký Pay-As-You-Go và Enterprise Agreement KHÔNG bật được spending limit.

⚠ Bộ công cụ quản lý chi phí — dùng kết hợp: | Công cụ | Việc | |---|---| | ⚠ Spending limit | ⚠ dừng cứng khi hết tín dụng | | ⚠ Budget và alert | ⚠ cảnh báo theo ngưỡng phần trăm | | ⚠ Cost analysis | ⚠ xem tiền đi đâu | | ⚠ Azure Advisor | ⚠ khuyến nghị cắt giảm | | ⚠ Tags | ⚠ quy chi phí về đúng bộ phận | | ⚠ Azure Policy | ⚠ chặn tạo SKU đắt ngay từ đầu |

Từ khoá nhận diện:

"dừng dịch vụ khi hết tiền" → ⚠ spending limit "gửi email khi tới ngưỡng" → ⚠ budget alert "xem chi tiêu theo thẻ và theo nhóm" → ⚠ Cost analysis "chặn tạo tài nguyên đắt" → ⚠ Azure Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng ký này có bật được spending limit không | ⚠ kiểm tra loại đăng ký trước | | Đã đặt budget kèm cảnh báo ở 50%, 80%, 100% chưa | | | Có tài nguyên mồ côi nào đang tính tiền không | |

Và điều cần phân biệt rõ khi thiết kế kiểm soát chi phí: cảnh báo là để bạn BIẾT, giới hạn là để hệ thống DỪNG. Chỉ có cảnh báo thì bạn vẫn phải là người hành động — và cuối tuần thì không ai đọc email.