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

Đáp án

B — Microsoft Purview Compliance Manager

Vì sao đúng

Compliance Manager gắn với các chuẩn và quy định cụ thể — GDPR, ISO 27001, HIPAA — và cho bạn: danh sách các biện pháp kiểm soát cần thực hiện, nơi lưu bằng chứng chứng minh đã thực hiện, điểm tuân thủ, và hướng dẫn cho từng mục còn thiếu.

Đó là thứ bạn cần khi phải chứng minh với kiểm toán viên, không chỉ để cấu hình hệ thống.

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

• C. Azure Policy — thực thi kỹ thuật rất tốt (chặn tạo tài nguyên sai chuẩn), nhưng nó không ánh xạ sang điều khoản của quy định và không lưu bằng chứng. Hai công cụ này bổ sung nhau.
• D. Defender for Cloud — quản lý tư thế bảo mật và phát hiện mối đe doạ.
• A. Azure Monitor — thu thập số liệu và log.

Đáp án

B — Azure Blob Storage

Vì sao đúng

Blob Storage là kho đối tượng dựng cho dữ liệu phi cấu trúc: tệp văn bản, ảnh, video, bản sao lưu, dữ liệu nhật ký. Nó không áp đặt cấu trúc nào lên nội dung, không có trần dung lượng thực tế, và truy cập được qua HTTP/HTTPS.

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

Ba dịch vụ còn lại trong cùng tài khoản lưu trữ, nhưng mỗi cái cho một mô hình dữ liệu khác:

• A. File Storage — file share qua giao thức SMB, dùng khi ứng dụng cần đường dẫn tệp.
• C. Table Storage — kho khoá–giá trị cho dữ liệu có cấu trúc.
• D. Queue Storage — hàng đợi cho thông điệp nhỏ giữa các thành phần.

Đáp án

A — Virtual Machine Scale Sets.

Vì sao đúng

⚠ Scale Set quản lý một NHÓM máy ảo giống hệt nhau như một khối: | Khả năng | Nội dung | |---|---| | ⚠ Tự co giãn | ⚠ từ một máy tới hàng trăm máy | | ⚠ Cân bằng tải sẵn | ⚠ tích hợp Load Balancer hoặc Application Gateway | | ⚠ Cấu hình một lần cho cả nhóm | | | ⚠ Cập nhật cuốn chiếu | | | ⚠ Trải qua nhiều vùng sẵn sàng | |

⚠ CPU trung bình vượt 70% trong 10 phút
        ↓
⚠ Scale Set thêm máy  →  ⚠ Load Balancer tự đưa vào vòng phục vụ
        ↓
⚠ Tải giảm  →  ⚠ Scale Set bớt máy

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

• B (Azure Virtual Machines) — ⚠ máy ảo ĐƠN LẺ, tự co giãn phải làm tay.

• C (Application Gateway) — ⚠ cân bằng tải tầng 7 kèm WAF, nhưng KHÔNG tạo hay xoá máy ảo.

• D (Azure App Services) — ⚠ PaaS cho ứng dụng web, có tự co giãn riêng, nhưng đề hỏi rõ "nhóm máy ảo giống hệt".

Ghi nhớ

⚠ Đối chiếu trong lô: ⚠ câu #22070 hỏi số VM tối đa trong một Scale Set (1.000 với ảnh nền tảng); câu này hỏi dịch vụ nào làm việc đó. ⚠ Hai câu bổ sung cho nhau, không mâu thuẫn.

⚠ Bốn kiểu trigger co giãn: | Kiểu | Ví dụ | |---|---| | ⚠ Theo chỉ số | ⚠ CPU, bộ nhớ, độ sâu hàng đợi | | ⚠ Theo lịch | ⚠ thêm máy vào giờ cao điểm hằng ngày | | ⚠ Theo số lượng cố định | ⚠ luôn giữ N máy | | ⚠ Predictive | ⚠ học từ lịch sử để co giãn trước |

Từ khoá nhận diện:

"nhóm VM giống hệt, tự co giãn" → ⚠ Scale Sets "phân phối lưu lượng tầng 4" → ⚠ Load Balancer "tầng 7, định tuyến theo URL, có WAF" → ⚠ Application Gateway "định tuyến toàn cầu theo DNS" → ⚠ Traffic Manager "tăng tốc và bảo vệ web toàn cầu" → ⚠ Front Door

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật co giãn có cả hai chiều chưa | | | Ứng dụng có chạy được khi máy bị xoá bất chợt không | ⚠ đừng giữ trạng thái trong máy | | Đã đặt trần số máy tối đa chưa | |

Và điều kiện tiên quyết để co giãn ngang có ích: ứng dụng phải không giữ trạng thái trên máy. Nếu phiên đăng nhập hay file tạm nằm trên đĩa cục bộ, thêm máy không giúp gì mà bớt máy còn làm mất dữ liệu.

Đáp án

D — 99,99%.

Vì sao đúng

⚠ Đặt máy ảo qua nhiều Availability Zone cho SLA cao nhất của VM: | Cách triển khai | SLA | |---|---| | ⚠ Một VM | ⚠ 99,9% | | ⚠ Availability Set | ⚠ 99,95% | | ⚠ Nhiều Availability Zone | ⚠ 99,99% — cao nhất |

⚠ Một vùng Azure có ít nhất 3 Availability Zone
   ⚠ Zone 1  ⚠ Zone 2  ⚠ Zone 3
   ⚠ mỗi zone là một hoặc nhiều trung tâm dữ liệu RIÊNG
   ⚠ nguồn điện riêng, làm mát riêng, mạng riêng
        ↓
⚠ Một zone chết  →  ⚠ hai zone còn lại phục vụ tiếp

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

• B (99,95%) — ⚠ là SLA của Availability SET.

• A (99,90%) — ⚠ là SLA của MỘT VM đơn.

• C (100%) — ⚠ không nhà cung cấp nào cam kết.

Ghi nhớ

⚠ Đối chiếu trong lô: ⚠ ba câu cùng chủ đề bảng SLA của VM.

⚠ 99,99% nghĩa là bao nhiêu thời gian chết: | Chu kỳ | Thời gian chết cho phép | |---|---| | ⚠ Mỗi năm | ⚠ ≈ 52,6 phút | | ⚠ Mỗi tháng | ⚠ ≈ 4,4 phút | | ⚠ Mỗi tuần | ⚠ ≈ 1 phút |

Từ khoá nhận diện:

"nhiều availability zone" → ⚠ 99,99% "availability set" → ⚠ 99,95% "một VM" → ⚠ 99,9% "muốn cao hơn 99,99%" → ⚠ phải triển khai ĐA VÙNG, không còn là SLA của VM nữa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy có thực sự nằm ở các zone khác nhau chưa | | | Load Balancer có zone-redundant không | | | Ứng dụng có chịu được độ trễ giữa các zone không | ⚠ vài mili giây |

Và giới hạn cần nhớ của Availability Zones: chúng bảo vệ khỏi sự cố trong một vùng, không bảo vệ khỏi việc mất cả vùng. Muốn chịu được điều đó thì phải triển khai sang vùng thứ hai.

Đáp án

B — Azure SQL Database.

Vì sao đúng

⚠ Azure SQL Database là PaaS, không phải IaaS: | Với Azure SQL Database | Ai lo | |---|---| | ⚠ Hệ điều hành | ⚠ Microsoft | | ⚠ Cài đặt và vá SQL Server | ⚠ Microsoft | | ⚠ Sao lưu và sẵn sàng cao | ⚠ Microsoft | | ⚠ Thiết kế bảng và truy vấn | ⚠ bạn |

⚠ Bạn không bao giờ nhìn thấy máy chủ nào — đó chính là dấu hiệu của PaaS.

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

⚠ Cả bốn phương án còn lại đều LÀ IaaS: | Phương án | Vì sao là IaaS | |---|---| | ⚠ A — Virtual Machine Scale Sets | ⚠ vẫn là máy ảo, bạn lo hệ điều hành | | ⚠ C — SQL Server trong VM | ⚠ bạn tự cài, tự vá, tự sao lưu | | ⚠ D — Virtual Network | ⚠ hạ tầng mạng do bạn cấu hình | | ⚠ E — Virtual Machine | ⚠ ví dụ kinh điển của IaaS |

Ghi nhớ

⚠ Đối chiếu trong lô: ⚠ câu #22069 hỏi dịch vụ nào là CSDL quan hệ quản lý hoàn toàn (đáp án Azure SQL Database), câu #22082 hỏi VM thuộc mô hình nào (đáp án IaaS). ⚠ Câu này là mặt trái của cả hai — cùng một kiến thức, hỏi ngược.

⚠ Cặp đôi hay bị so sánh — SQL Server trên VM và Azure SQL Database: | Tiêu chí | SQL Server trên VM | Azure SQL Database | |---|---|---| | ⚠ Mô hình | ⚠ IaaS | ⚠ PaaS | | ⚠ Vá lỗi | ⚠ bạn làm | ⚠ Microsoft làm | | ⚠ Toàn quyền hệ điều hành | ⚠ có | ⚠ không | | ⚠ SQL Agent, CLR, linked server | ⚠ có đủ | ⚠ hạn chế | | ⚠ Công sức vận hành | ⚠ cao | ⚠ thấp |

Từ khoá nhận diện:

"quản lý hoàn toàn, không thấy máy chủ" → ⚠ PaaS "toàn quyền hệ điều hành" → ⚠ IaaS "đăng nhập là dùng" → ⚠ SaaS "cần tính năng cấp máy chủ nhưng vẫn muốn PaaS" → ⚠ SQL Managed Instance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có VM nào đang chạy thứ mà PaaS làm được không | | | Ai chịu trách nhiệm vá lỗi từng thành phần | ⚠ liệt kê rõ ràng | | Chuyển sang PaaS thì mất tính năng nào | |

Và cách phân loại nhanh nhất khi làm bài: hỏi "tôi có phải vá hệ điều hành không?" — có thì IaaS, không thì PaaS trở lên.

Đáp án

B — Azure Synapse Analytics

Vì sao đúng

Ba yêu cầu trong đề — petabyte, dữ liệu có cấu trúc lẫn phi cấu trúc, gần thời gian thực — đều vượt quá khả năng của một cơ sở dữ liệu thông thường. Synapse là nền tảng phân tích gộp nhiều mảnh: SQL pool cho dữ liệu đã mô hình hoá, Spark cho dữ liệu phi cấu trúc, truy vấn không máy chủ trên data lake, và pipeline để nạp dữ liệu.

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

• A. Power BI — công cụ trực quan hoá; nó là bước cuối để hiển thị kết quả, không phải nơi xử lý petabyte.
• C. Azure SQL Database — cơ sở dữ liệu giao dịch, có trần rõ ràng ở quy mô này.
• D. App Service — nền tảng chạy ứng dụng web.

Đáp án

B — Nó đòi người dùng phải SỞ HỮU thứ gì đó, như điện thoại để đọc SMS, dùng ứng dụng di động, hoặc sinh trắc học.

Vì sao đúng

⚠ MFA phá vỡ giá trị của mật khẩu bị đánh cắp: | Tình huống | Kết quả | |---|---| | ⚠ Chỉ có mật khẩu | ⚠ ai biết mật khẩu là vào được | | ⚠ Có MFA | ⚠ biết mật khẩu VẪN không vào được nếu không cầm yếu tố thứ hai |

⚠ Mật khẩu bị lộ qua phishing hay rò rỉ dữ liệu
        ↓
⚠ Kẻ tấn công thử đăng nhập
        ↓
⚠ Hệ thống đòi yếu tố thứ hai  →  ⚠ chúng không có  →  ⚠ CHẶN

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

• A (MFA không tăng bảo mật) — ⚠ SAI hoàn toàn; MFA là biện pháp hiệu quả nhất chống chiếm tài khoản.

• C (đòi có SSO) — ⚠ SSO là chuyện KHÁC; SSO làm đăng nhập tiện hơn, MFA làm đăng nhập an toàn hơn.

• D (người dùng phải được duyệt trước lần đăng nhập đầu) — ⚠ là quy trình cấp tài khoản, không phải MFA.

Ghi nhớ

⚠ Đối chiếu trong lô: ⚠ câu #22092 hỏi tính năng nào của Entra ID cung cấp yếu tố đăng nhập thêm (đáp án MFA); câu này hỏi MFA tăng bảo mật BẰNG CÁCH NÀO. ⚠ Hai câu bổ sung nhau, giữ nguyên cả hai khoá.

⚠ Ba loại yếu tố xác thực: | Loại | Ví dụ | |---|---| | ⚠ Thứ bạn BIẾT | ⚠ mật khẩu, PIN, câu hỏi bí mật | | ⚠ Thứ bạn CÓ | ⚠ điện thoại, khoá FIDO2, thẻ thông minh | | ⚠ Thứ bạn LÀ | ⚠ vân tay, khuôn mặt, mống mắt | | ⚠ MFA nghĩa là | ⚠ kết hợp ÍT NHẤT HAI loại KHÁC NHAU |

⚠ Hai mật khẩu KHÔNG phải là MFA — vì cùng thuộc một loại yếu tố.

Từ khoá nhận diện:

"thứ bạn có, điện thoại" → ⚠ MFA "đăng nhập một lần cho nhiều ứng dụng" → ⚠ SSO, tiện lợi chứ không phải bảo mật "không cần mật khẩu" → ⚠ passwordless "buộc MFA theo điều kiện" → ⚠ Conditional Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản quản trị đã bật MFA chưa | | | Có đang dựa vào SMS làm yếu tố chính không | ⚠ nên chuyển sang app hoặc khoá | | Đã bật number matching để chống MFA fatigue chưa | |

Và điều làm MFA đáng giá hơn mọi biện pháp khác cùng chi phí: nó vô hiệu hoá toàn bộ giá trị của một mật khẩu bị đánh cắp. Mọi cuộc tấn công bắt đầu bằng mật khẩu lộ đều dừng lại ở đây.

Đáp án

B — Load Balancer hoặc Application Gateway.

Vì sao đúng

⚠ Cả hai đều phân phối lưu lượng tới nhiều máy phía sau: | Dịch vụ | Tầng | Đặc điểm | |---|---|---| | ⚠ Azure Load Balancer | ⚠ tầng 4 — TCP/UDP | ⚠ nhanh, độ trễ rất thấp, không đọc nội dung | | ⚠ Application Gateway | ⚠ tầng 7 — HTTP/HTTPS | ⚠ định tuyến theo URL, dừng TLS, có WAF |

⚠ Yêu cầu từ người dùng
        ↓
⚠ Load Balancer / Application Gateway
     ↙        ↓        ↘
⚠ VM 1     ⚠ VM 2     ⚠ VM 3
   ⚠ máy nào chết thì bị loại khỏi vòng phục vụ

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

• A (App Services) — ⚠ là nơi CHẠY ứng dụng web, có cân bằng tải nội bộ nhưng không phải dịch vụ phân phối lưu lượng tới VM của bạn.

• C (Logic Apps) — ⚠ ghép quy trình tự động.

• D (Virtual Network) — ⚠ là mạng ảo, không phân phối tải.

Ghi nhớ

⚠ Bốn dịch vụ cân bằng tải của Azure — phân biệt bằng PHẠM VI và TẦNG: | Dịch vụ | Phạm vi | Tầng | |---|---|---| | ⚠ Load Balancer | ⚠ trong một vùng | ⚠ 4 | | ⚠ Application Gateway | ⚠ trong một vùng | ⚠ 7 | | ⚠ Traffic Manager | ⚠ toàn cầu | ⚠ DNS | | ⚠ Front Door | ⚠ toàn cầu | ⚠ 7, kèm CDN và WAF |

Từ khoá nhận diện:

"TCP/UDP, độ trễ thấp" → ⚠ Load Balancer "định tuyến theo đường dẫn URL, có WAF" → ⚠ Application Gateway "điều hướng người dùng tới vùng gần nhất bằng DNS" → ⚠ Traffic Manager "tăng tốc toàn cầu, có cache và WAF" → ⚠ Front Door

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Health probe có trỏ đúng endpoint kiểm tra sức khoẻ không | ⚠ đừng probe trang chủ nặng | | Ứng dụng có cần session affinity không | | | Có cần WAF không | ⚠ nếu có thì phải là Application Gateway hoặc Front Door |

Và thứ quyết định chất lượng của một bộ cân bằng tải không phải thuật toán phân phối, mà là health probe. Probe sai thì lưu lượng vẫn được gửi tới máy đã chết, và người dùng vẫn thấy lỗi.

Đáp án

C — Ngăn không cho dùng một số loại máy ảo nhất định trong một resource group.

Vì sao đúng

⚠ Azure Policy áp luật lên CẤU HÌNH của tài nguyên: | Việc Policy làm tốt | Ví dụ | |---|---| | ⚠ Giới hạn loại và cỡ tài nguyên | ⚠ chỉ cho phép SKU trong danh sách | | ⚠ Giới hạn vùng triển khai | ⚠ chỉ được tạo ở Southeast Asia | | ⚠ Buộc gắn thẻ | ⚠ thiếu thẻ thì từ chối tạo | | ⚠ Buộc bật mã hoá hoặc nhật ký | | | ⚠ Kiểm tra tuân thủ tài nguyên đang có | ⚠ audit |

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

• A (chỉ cho một vai người dùng truy cập resource group) — ⚠ đó là việc của RBAC, không phải Policy. ⚠ Policy quản CÁI GÌ được tạo, RBAC quản AI được làm.

• B (buộc VM luôn cập nhật bản vá mới nhất) — ⚠ là việc của Azure Update Manager; Policy chỉ kiểm tra và báo chứ không tự vá.

• D (hiện thêm lời nhắc hỏi người dùng có chắc không) — ⚠ Policy KHÔNG tương tác với người dùng; nó cho phép hoặc từ chối, không hỏi lại.

Ghi nhớ

⚠ Các hiệu lực (effect) của Azure Policy: | Hiệu lực | Làm gì | |---|---| | ⚠ Deny | ⚠ chặn tạo hoặc sửa | | ⚠ Audit | ⚠ cho qua nhưng ghi nhận không tuân thủ | | ⚠ Append | ⚠ tự thêm thuộc tính, ví dụ thẻ | | ⚠ Modify | ⚠ sửa thuộc tính | | ⚠ DeployIfNotExists | ⚠ tự triển khai thứ còn thiếu | | ⚠ Disabled | ⚠ tạm tắt luật |

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 "chặn xoá nhầm" → ⚠ Resource Lock "gói sẵn cả môi trường chuẩn" → ⚠ Azure Blueprint / Deployment Stacks "vá lỗi hệ điều hành" → ⚠ Update Manager

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chính sách giới hạn vùng triển khai chưa | ⚠ để dữ liệu không rời khỏi nơi cho phép | | Có buộc gắn thẻ chi phí chưa | | | Tài nguyên quan trọng đã có resource lock chưa | |

Và cách phân biệt gọn nhất giữa hai lớp kiểm soát: RBAC trả lời "ai", Policy trả lời "cái gì". Người có quyền Owner vẫn không tạo được máy ảo cỡ bị Policy cấm.

Đáp án

D — Web Application Firewall (WAF).

Vì sao đúng

⚠ WAF là tính năng tuỳ chọn chỉ có ở Application Gateway: | Dịch vụ | Tầng | Có WAF | |---|---|---| | ⚠ Azure Load Balancer | ⚠ 4 — TCP/UDP | ⚠ KHÔNG | | ⚠ Application Gateway | ⚠ 7 — HTTP/HTTPS | ⚠ CÓ, bật tuỳ chọn |

⚠ Lý do kỹ thuật: ⚠ Load Balancer làm việc ở tầng 4, không đọc nội dung HTTP, nên về nguyên tắc không thể phát hiện tấn công tầng ứng dụng. Application Gateway dừng và đọc HTTP nên mới lọc được.

⚠ WAF chặn những gì: | Loại tấn công | Nội dung | |---|---| | ⚠ SQL injection | ⚠ chèn lệnh SQL vào tham số | | ⚠ Cross-site scripting (XSS) | ⚠ chèn script chạy trong trình duyệt nạn nhân | | ⚠ Command injection | ⚠ chèn lệnh hệ điều hành | | ⚠ Các mục trong OWASP Top 10 | |

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

• A (MFA) — ⚠ tính năng của Entra ID, không phải của bộ cân bằng tải.

• B (DDoS Protection nâng cao) — ⚠ là dịch vụ RIÊNG, áp cho cả mạng ảo chứ không phải tính năng của Application Gateway.

• C (Azure AD Advanced Information Protection) — ⚠ bảo vệ TÀI LIỆU, không liên quan.

Ghi nhớ

⚠ Đối chiếu trong lô: ⚠ câu #22117 hỏi dịch vụ nào phân phối lưu lượng (đáp án gộp cả Load Balancer và Application Gateway); câu này hỏi điểm KHÁC BIỆT giữa hai cái. ⚠ Hai câu bổ sung nhau.

⚠ WAF có ở ba nơi: | Nơi | Phạm vi | |---|---| | ⚠ Application Gateway | ⚠ trong một vùng | | ⚠ Azure Front Door | ⚠ toàn cầu, ở biên | | ⚠ Azure CDN | ⚠ ở biên |

Từ khoá nhận diện:

"chặn SQL injection và XSS" → ⚠ WAF "chống lưu lượng tấn công khổng lồ" → ⚠ DDoS Protection "lọc gói theo cổng và IP" → ⚠ NSG "tường lửa tập trung cho cả VNet" → ⚠ Azure Firewall

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng công khai có WAF trước mặt không | | | WAF đang ở chế độ Detection hay Prevention | ⚠ Detection mãi thì không bảo vệ gì | | Có luật nào bị tắt vì cảnh báo giả không | ⚠ xem lại định kỳ |

Và bẫy hay gặp khi triển khai WAF: bật Detection để "quan sát" rồi quên chuyển sang Prevention. Nhật ký đầy cảnh báo mà không có gì bị chặn.