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

Đáp án

B — Purview Compliance Manager (trước là Microsoft Compliance Manager).

Vì sao đúng

⚠ Compliance Manager là công cụ ĐÁNH GIÁ VÀ THEO DÕI tuân thủ: | Chức năng | Nội dung | |---|---| | ⚠ Chấm điểm tuân thủ | ⚠ compliance score | | ⚠ Danh sách hành động cần làm | ⚠ chia theo trách nhiệm Microsoft và của bạn | | ⚠ Mẫu đánh giá sẵn | ⚠ GDPR, ISO/IEC 27001, NIST, HIPAA... | | ⚠ Theo dõi tiến độ theo thời gian | | | ⚠ Xuất báo cáo cho kiểm toán | |

⚠ Chọn tiêu chuẩn  →  ⚠ nhận danh sách kiểm soát
        ↓
⚠ Làm từng việc  →  ⚠ điểm tăng  →  ⚠ báo cáo cho kiểm toán viên

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

• D (Service Trust Portal) — ⚠ nơi TẢI VỀ báo cáo kiểm toán và tài liệu tuân thủ của Microsoft; là thư viện tài liệu, không theo dõi tình trạng của TỔ CHỨC BẠN.

• A (Microsoft Privacy Statement) — ⚠ văn bản nói Microsoft xử lý dữ liệu cá nhân thế nào, không phải công cụ.

• C (Azure Government Services) — ⚠ đám mây riêng cho cơ quan chính phủ Mỹ, không phải công cụ đánh giá.

Ghi nhớ

⚠ Bốn thứ về tuân thủ hay bị lẫn — phân biệt bằng CÂU HỎI chúng trả lời: | Thứ | Trả lời câu hỏi | |---|---| | ⚠ Compliance Manager | ⚠ TỔ CHỨC TÔI đang tuân thủ tới đâu | | ⚠ Service Trust Portal | ⚠ MICROSOFT có chứng nhận gì, báo cáo kiểm toán ở đâu | | ⚠ Privacy Statement | ⚠ Microsoft dùng dữ liệu của tôi thế nào | | ⚠ Azure Policy | ⚠ làm sao BUỘC tài nguyên tuân theo quy tắc |

Từ khoá nhận diện:

"điểm tuân thủ, hành động cải thiện" → ⚠ Compliance Manager "tải báo cáo SOC, ISO của Microsoft" → ⚠ Service Trust Portal "phân loại và dán nhãn dữ liệu nhạy cảm" → ⚠ Microsoft Purview Information Protection "khoá vùng triển khai, buộc gắn thẻ" → ⚠ Azure Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức phải tuân thủ tiêu chuẩn nào | ⚠ liệt kê ra trước đã | | Điểm tuân thủ hiện tại là bao nhiêu | | | Hành động nào thuộc trách nhiệm của bạn chứ không phải Microsoft | |

Và điều làm Compliance Manager hữu ích hơn một bảng tính: nó tách rõ phần Microsoft đã làm và phần bạn còn phải làm. Rất nhiều tổ chức tưởng dùng đám mây là tự động tuân thủ, trong khi phần việc của họ vẫn còn nguyên.

Đáp án

B — Tất cả những việc trên.

Vì sao đúng

⚠ Azure AI Services (trước là Cognitive Services) làm được cả bốn việc được liệt kê: | Việc | Dịch vụ | |---|---| | ⚠ Đọc văn bản thành giọng rất giống người | ⚠ Speech — Text to Speech, có Neural Voice | | ⚠ Nhận diện chữ trong ảnh | ⚠ Azure AI Vision — OCR, Read API | | ⚠ Chuyển âm thanh thành văn bản | ⚠ Speech — Speech to Text | | ⚠ Dịch văn bản giữa các ngôn ngữ | ⚠ Azure AI Translator |

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

• A, C, D, E — ⚠ mỗi phương án chỉ đúng MỘT phần; đề hỏi việc gì Azure AI Services làm được, và cả bốn đều nằm trong danh mục.

Ghi nhớ

⚠ Các nhóm dịch vụ AI của Azure: | Nhóm | Dịch vụ tiêu biểu | |---|---| | ⚠ Vision | ⚠ OCR, phân tích ảnh, Custom Vision, Face | | ⚠ Speech | ⚠ nói thành chữ, chữ thành nói, dịch giọng nói, nhận diện người nói | | ⚠ Language | ⚠ phân tích cảm xúc, trích thực thể, tóm tắt, hỏi đáp | | ⚠ Translator | ⚠ dịch văn bản và tài liệu | | ⚠ Document Intelligence | ⚠ bóc dữ liệu từ hoá đơn, biểu mẫu | | ⚠ Azure OpenAI | ⚠ mô hình sinh, GPT |

Từ khoá nhận diện:

"đọc chữ trong ảnh chụp" → ⚠ OCR, thuộc Vision "bóc trường dữ liệu từ hoá đơn" → ⚠ Document Intelligence "phân tích cảm xúc câu đánh giá" → ⚠ Language "đọc văn bản như người thật" → ⚠ Speech, neural voice

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có API dựng sẵn nào làm được việc này chưa | ⚠ đừng huấn luyện mô hình khi không cần | | Dữ liệu gửi lên có chứa thông tin nhạy cảm không | | | Đã đọc điều khoản về việc dữ liệu có được dùng để huấn luyện không | |

Và điều đáng nhớ nhất về Azure AI Services: phần lớn nhu cầu AI thông thường đã có API dựng sẵn. Chỉ nên tự huấn luyện mô hình khi bài toán thật sự đặc thù cho lĩnh vực của bạn.

Đáp án

C — Multi-Factor Authentication (xác thực đa yếu tố).

Vì sao đúng

⚠ MFA đòi thêm ít nhất một yếu tố nữa ngoài mật khẩu: | Loại yếu tố | Ví dụ | |---|---| | ⚠ Thứ bạn BIẾT | ⚠ mật khẩu, mã PIN | | ⚠ Thứ bạn CÓ | ⚠ điện thoại, app Authenticator, khoá FIDO2 | | ⚠ Thứ bạn LÀ | ⚠ vân tay, khuôn mặt |

⚠ Nhập mật khẩu đúng
        ↓
⚠ Điện thoại rung  →  ⚠ duyệt trong Microsoft Authenticator
        ↓
⚠ Đăng nhập thành công

⚠ Kẻ trộm được mật khẩu vẫn không vào được vì không cầm điện thoại của bạn.

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

• A (Azure Information Protection) — ⚠ phân loại và bảo vệ TÀI LIỆU, không phải xác thực đăng nhập.

• B (Defender for Cloud) — ⚠ quản lý tư thế bảo mật của tài nguyên.

• D (Advanced Threat Protection) — ⚠ phát hiện mối đe doạ, không phải yếu tố đăng nhập.

Ghi nhớ

⚠ Đối chiếu trong lô: ⚠ câu #22068 hỏi dịch vụ nào cho phép buộc MFA — đáp án là Entra ID; câu này hỏi TÍNH NĂNG cụ thể — đáp án là MFA. ⚠ MFA là một tính năng CỦA Entra ID, không mâu thuẫn.

⚠ Các phương thức MFA — theo độ mạnh: | Phương thức | Độ mạnh | |---|---| | ⚠ Khoá bảo mật FIDO2, Windows Hello | ⚠ mạnh nhất, chống phishing | | ⚠ Microsoft Authenticator — duyệt kèm số | ⚠ rất tốt | | ⚠ Mã OTP trong app | ⚠ tốt | | ⚠ Gọi điện | ⚠ yếu hơn | | ⚠ SMS | ⚠ YẾU NHẤT — bị đánh cắp SIM |

Từ khoá nhận diện:

"yếu tố thứ hai, điện thoại, Authenticator" → ⚠ MFA "buộc MFA khi đăng nhập từ nước ngoài" → ⚠ Conditional Access "đăng nhập không cần mật khẩu" → ⚠ passwordless, FIDO2 hoặc Windows Hello "tự đặt lại mật khẩu" → ⚠ Self-Service Password Reset

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Toàn bộ tài khoản quản trị đã bật MFA chưa | | | Có tài khoản khẩn cấp được loại trừ và cất an toàn chưa | | | Đã bật number matching chưa | |

Và nếu chỉ được làm một việc bảo mật duy nhất cho một tổ chức: hãy bật MFA. Không có biện pháp nào khác cho tỷ lệ chặn tấn công cao đến thế với chừng ấy công sức.

Đáp án

C — Triển khai hai máy ảo trở lên qua các Availability Zone khác nhau trong cùng một vùng.

Vì sao đúng

⚠ SLA của VM tăng dần theo cách triển khai: | Cách triển khai | SLA | |---|---| | ⚠ Một VM đơn, đĩa premium SSD | ⚠ 99,9% | | ⚠ Hai VM trở lên trong Availability Set | ⚠ 99,95% | | ⚠ Hai VM trở lên qua nhiều Availability Zone | ⚠ 99,99% — CAO NHẤT |

⚠ Availability Zone = ⚠ toà nhà RIÊNG trong cùng vùng
   ⚠ nguồn điện riêng, làm mát riêng, mạng riêng
        ↓
⚠ Cháy một toà nhà  →  ⚠ máy ở toà khác vẫn chạy

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

• B (Availability Set) — ⚠ 99,95%, THẤP hơn; chỉ trải qua tủ rack và miền cập nhật trong cùng một trung tâm dữ liệu.

• A (hai VM trong cùng trung tâm dữ liệu) — ⚠ không có SLA riêng nếu không nằm trong Availability Set; cùng toà nhà là cùng chết.

• D (một VM duy nhất) — ⚠ thấp nhất, và là điểm hỏng đơn lẻ.

Ghi nhớ

⚠ Ba mức bảo vệ — nhớ theo PHẠM VI hỏng: | Cơ chế | Chịu được | |---|---| | ⚠ Availability Set | ⚠ hỏng tủ rack, bảo trì có kế hoạch | | ⚠ Availability Zone | ⚠ hỏng cả một trung tâm dữ liệu | | ⚠ Region pair / đa vùng | ⚠ thảm hoạ cả một vùng địa lý |

Từ khoá nhận diện:

"SLA cao nhất cho VM" → ⚠ Availability Zones "fault domain và update domain" → ⚠ Availability Set "khôi phục sau thảm hoạ vùng" → ⚠ Azure Site Recovery, region pair "cùng trung tâm dữ liệu" → ⚠ không bảo vệ được gì nhiều

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng đang dùng có hỗ trợ Availability Zones không | | | Load Balancer và IP công cộng có zone-redundant không | | | Máy đã thực sự nằm ở các zone KHÁC nhau chưa | ⚠ kiểm tra, đừng giả định |

Và lỗi hay gặp nhất khi dựng kiến trúc nhiều zone: trải máy ảo ra ba zone nhưng để load balancer hoặc đĩa dữ liệu ở một zone duy nhất. Chuỗi chỉ mạnh bằng mắt xích yếu nhất.

Đáp án

B — Tạo và gán một custom policy definition trong Azure Policy

Vì sao đúng

Azure Policy có sẵn hàng trăm định nghĩa dựng sẵn, nhưng khi quy định của tổ chức không nằm trong đó thì bạn tự viết định nghĩa riêng bằng JSON: khai điều kiện nào bị coi là vi phạm và hiệu ứng gì sẽ xảy ra (Deny, Audit, Modify, DeployIfNotExists).

Custom policy hoạt động y hệt policy dựng sẵn — chặn được lúc triển khai và quét lại tài nguyên đã có.

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

• C. Dùng Resource Lock để chặn thay đổi vi phạm — khoá chặn mọi thay đổi một cách mù quáng, nó không hiểu quy tắc nào bị vi phạm.
• D. Mở phiếu hỗ trợ xin Microsoft thêm policy dựng sẵn — không cần và không khả thi cho quy định nội bộ.
• A. Chỉ triển khai ở khu vực có sẵn kiểm soát tuân thủ — không thực thi được quy tắc riêng của bạn.

Đáp án

D — Tiết kiệm đáng kể khi tài nguyên không cần chạy liên tục.

Vì sao đúng

⚠ Trả theo mức dùng chỉ tính tiền khi thực sự có việc: | Kiểu tải | Mô hình phù hợp | |---|---| | ⚠ Ngắt quãng, không đoán trước | ⚠ trả theo mức dùng | | ⚠ Chạy đều 24/7 | ⚠ trả theo giờ hoặc mua cam kết thường RẺ HƠN |

⚠ Azure Functions bậc tiêu thụ
   ⚠ 0 lượt gọi  →  ⚠ 0 đồng
   ⚠ Một đợt cao điểm  →  ⚠ trả cho đúng đợt đó
⚠ VM chạy 24/7
   ⚠ trả tiền cả lúc không ai dùng

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

• A (dễ dự đoán chi phí tương lai) — ⚠ NGƯỢC LẠI; trả theo mức dùng khó dự đoán hơn hẳn.

• C (mô hình giá đơn giản hơn) — ⚠ cũng NGƯỢC; phải hiểu đơn vị tính là lượt gọi, GB, RU hay giây thực thi.

• B (luôn luôn rẻ hơn trả theo giờ) — ⚠ SAI; với tải cao và đều, trả theo mức dùng ĐẮT hơn đáng kể.

Ghi nhớ

⚠ Điểm hoà vốn — nghĩ theo TỶ LỆ SỬ DỤNG: | Tỷ lệ dùng | Nên chọn | |---|---| | ⚠ Thấp và thất thường | ⚠ trả theo mức dùng | | ⚠ Cao và đều | ⚠ tài nguyên cấp sẵn, mua reservation | | ⚠ Vì thế | ⚠ serverless KHÔNG mặc định rẻ hơn |

Từ khoá nhận diện:

"chỉ trả khi dùng, tải thất thường" → ⚠ consumption "cần dự đoán hoá đơn" → ⚠ mô hình cấp sẵn hoặc reservation "cam kết 1 hoặc 3 năm" → ⚠ Reserved Instances, giảm tới 72% "chịu được bị thu hồi máy" → ⚠ Spot VM, giảm tới 90%

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải này thực sự chạy bao nhiêu phần trăm thời gian | ⚠ đo, đừng đoán | | Đã đặt budget alert chưa | | | Chi phí tháng này lệch bao nhiêu so với tháng trước | |

Và điều hay bị hiểu sai nhất về giá đám mây: linh hoạt và rẻ là hai chuyện khác nhau. Trả theo mức dùng mua cho bạn sự linh hoạt; nó chỉ rẻ hơn khi bạn thực sự không dùng đến tài nguyên phần lớn thời gian.

Đáp án

B — Private Preview, Public Preview và General Availability.

Vì sao đúng

⚠ Ba giai đoạn vòng đời dịch vụ Azure: | Giai đoạn | Nội dung | |---|---| | ⚠ Private Preview | ⚠ chỉ khách hàng được MỜI, thử nghiệm sớm, phản hồi cho nhóm sản phẩm | | ⚠ Public Preview | ⚠ AI cũng dùng được, thường miễn phí hoặc giảm giá, KHÔNG có SLA | | ⚠ General Availability (GA) | ⚠ sẵn sàng cho sản xuất, CÓ SLA, có hỗ trợ đầy đủ |

⚠ Private Preview  →  ⚠ Public Preview  →  ⚠ GA
   ⚠ mời riêng        ⚠ mở cho mọi người   ⚠ dùng cho sản xuất
   ⚠ không SLA        ⚠ không SLA          ⚠ có SLA

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

• A, C, D — ⚠ đều là tên bịa, không phải thuật ngữ Microsoft dùng.

Ghi nhớ

⚠ Vì sao KHÔNG dùng dịch vụ Preview cho sản xuất: | Lý do | Nội dung | |---|---| | ⚠ Không có SLA | ⚠ Microsoft không cam kết thời gian hoạt động | | ⚠ Hỗ trợ hạn chế | ⚠ không đảm bảo mức hỗ trợ như GA | | ⚠ Tính năng có thể ĐỔI hoặc BỊ BỎ | | | ⚠ Có thể chưa đủ chứng nhận tuân thủ | | | ⚠ Có thể chưa có ở mọi vùng | |

Từ khoá nhận diện:

"chỉ khách hàng được mời" → ⚠ Private Preview "ai cũng thử được, chưa có SLA" → ⚠ Public Preview "dùng cho sản xuất, có SLA" → ⚠ General Availability "dịch vụ sắp ngừng" → ⚠ retirement, thường báo trước 12 tháng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tính năng Preview nào đang chạy trong sản xuất không | | | Đã đăng ký nhận Azure Updates chưa | | | Dịch vụ đang dùng có thông báo ngừng nào không | |

Và lý do phân biệt Preview với GA lại quan trọng đến vậy: SLA chỉ tồn tại từ GA trở đi. Xây hệ thống quan trọng trên một dịch vụ Preview nghĩa là bạn không có cam kết nào để dựa vào khi có sự cố.

Đáp án

B — Một thiết bị VPN Gateway tương thích.

Vì sao đúng

⚠ Kết nối Site-to-Site cần MỘT gateway ở MỖI đầu: | Đầu | Thiết bị | |---|---| | ⚠ Phía Azure | ⚠ Virtual Network Gateway kiểu VPN | | ⚠ Phía tại chỗ | ⚠ thiết bị VPN vật lý hoặc ảo tương thích, có IP công cộng |

⚠ Mạng tại chỗ
   ⚠ thiết bị VPN (Cisco, Fortinet, pfSense, RRAS...)
        ↓ ⚠ đường hầm IPsec/IKE qua Internet
   ⚠ Virtual Network Gateway
⚠ Mạng ảo Azure

⚠ Microsoft công bố danh sách thiết bị đã kiểm chứng kèm cấu hình mẫu — thiết bị phải hỗ trợ IPsec/IKE.

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

• A (một máy ảo chuyên dụng) — ⚠ không bắt buộc; có thể dùng thiết bị phần cứng sẵn có.

• C (Application Gateway) — ⚠ cân bằng tải tầng 7 cho web, không dựng đường hầm VPN.

• D (Azure Virtual Network) — ⚠ là mạng ảo, không phải thiết bị đầu cuối.

Ghi nhớ

⚠ Ba kiểu kết nối lai — phân biệt: | Kiểu | Nội dung | |---|---| | ⚠ Point-to-Site (P2S) | ⚠ MỘT máy tính nối vào VNet, cho người làm từ xa | | ⚠ Site-to-Site (S2S) | ⚠ cả MẠNG tại chỗ nối vào VNet, qua Internet có mã hoá | | ⚠ ExpressRoute | ⚠ đường RIÊNG, KHÔNG qua Internet, băng thông cao |

Từ khoá nhận diện:

"cả văn phòng nối vào Azure" → ⚠ Site-to-Site "một laptop nối vào" → ⚠ Point-to-Site "không qua Internet, độ trễ ổn định" → ⚠ ExpressRoute "nối hai VNet với nhau" → ⚠ VNet Peering

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thiết bị tại chỗ có trong danh sách đã kiểm chứng không | | | Dải IP hai bên có chồng lấn không | ⚠ nguyên nhân hỏng phổ biến nhất | | Băng thông của SKU gateway có đủ không | |

Và lỗi hay gặp nhất khi dựng kết nối lai: dải địa chỉ IP hai bên trùng nhau. Đường hầm dựng xong vẫn không định tuyến được, và triệu chứng rất khó đọc nếu không nghĩ tới nó ngay từ đầu.

Đáp án

A — Chuyển từ chi phí đầu tư sang chi phí vận hành (CapEx sang OpEx)

Vì sao đúng

Đề nêu hai điều: không phải mua phần cứng trước, và chỉ trả cho phần thực dùng. Đó chính là sự dịch chuyển từ CapEx sang OpEx.

Ý nghĩa thực tế lớn hơn con số: với CapEx, bạn phải dự đoán nhu cầu nhiều năm trước và mua thừa để phòng xa; với OpEx, năng lực bám theo nhu cầu thật và tiền chỉ ra khi có việc.

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

• D. Elasticity — là cơ chế kỹ thuật cho phép mô hình này hoạt động, nhưng câu hỏi đang hỏi về lợi ích tài chính được mô tả.
• B. Chịu lỗi và C. Tính sẵn sàng cao — thuộc về độ tin cậy, không phải chi phí.

Đáp án

B — Một người trả tiền, nhưng nhiều người có tài khoản trên Azure, và cần tách tài nguyên giữa các khách hàng để tuyệt đối không lộ sang nhau.

Vì sao đúng

⚠ Subscription là ranh giới CÁCH LY và ranh giới QUẢN LÝ mạnh nhất dưới tenant: | Subscription là ranh giới của | Nội dung | |---|---| | ⚠ Cách ly quyền truy cập | ⚠ RBAC gán ở mức subscription không lan sang subscription khác | | ⚠ Hạn mức tài nguyên | ⚠ quota theo từng subscription | | ⚠ Thanh toán | ⚠ hoá đơn tách riêng được | | ⚠ Chính sách | ⚠ Azure Policy áp riêng |

⚠ Tenant Entra ID
   ├── ⚠ Subscription khách hàng A  →  ⚠ chỉ người của A thấy
   └── ⚠ Subscription khách hàng B  →  ⚠ chỉ người của B thấy
   ⚠ Cùng một hoá đơn, nhưng tách bạch tuyệt đối

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

• A (một người trả tiền, một người quản lý, chỉ muốn biết tài nguyên nào cho dự án nào) — ⚠ KHÔNG cần thêm subscription; chỉ cần resource group và thẻ (tags) là đủ để tách chi phí và nhóm tài nguyên.

Ghi nhớ

⚠ Chọn cấp phân tách theo NHU CẦU: | Nhu cầu | Dùng | |---|---| | ⚠ Chỉ để nhóm và báo cáo chi phí | ⚠ thẻ (tags) | | ⚠ Nhóm tài nguyên cùng vòng đời | ⚠ resource group | | ⚠ Cách ly quyền, hạn mức, hoá đơn | ⚠ subscription | | ⚠ Áp chính sách cho nhiều subscription cùng lúc | ⚠ management group | | ⚠ Tổ chức hoàn toàn khác, danh bạ khác | ⚠ tenant riêng |

⚠ Thứ bậc quản lý của Azure:

⚠ Management Group
      ↓
⚠ Subscription
      ↓
⚠ Resource Group
      ↓
⚠ Resource

⚠ Quyền và chính sách KẾ THỪA từ trên xuống dưới.

Từ khoá nhận diện:

"tuyệt đối không lộ sang nhau" → ⚠ subscription riêng "chỉ muốn biết chi phí theo dự án" → ⚠ tags "xoá cả nhóm cùng lúc" → ⚠ resource group "áp chính sách cho toàn tổ chức" → ⚠ management group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhu cầu là báo cáo chi phí hay cách ly thật | ⚠ hai việc rất khác nhau | | Đã áp chuẩn đặt thẻ chưa | ⚠ Azure Policy buộc gắn thẻ được | | Có resource group nào chứa lẫn Prod và Dev không | |

Và nguyên tắc nên nhớ khi thiết kế cấu trúc: đừng tách subscription chỉ để báo cáo chi phí. Thẻ làm được việc đó mà không kéo theo gánh nặng quản lý của một subscription mới.