Ngân hàng đề — Microsoft Azure Fundamentals
Tìm thấy 501 câu.
- A 99.90%
- B 99.99%
- C 100%
- D 99.95%
Xem giải thích
Đáp án
D — 99,95%.
Vì sao đúng
⚠ Bảng SLA của máy ảo Azure: | Cách triển khai | SLA | |---|---| | ⚠ Một VM đơn, đĩa premium SSD trở lên | ⚠ 99,9% | | ⚠ 2+ VM trong cùng Availability Set | ⚠ 99,95% | | ⚠ 2+ VM qua nhiều Availability Zone | ⚠ 99,99% |
⚠ Availability Set trải máy qua:
⚠ Fault domain → ⚠ khác nguồn điện, khác switch mạng
⚠ Update domain → ⚠ không bảo trì cùng lúc
⚠ NHƯNG vẫn trong MỘT trung tâm dữ liệu
Vì sao các phương án khác sai
-
B (99,99%) — ⚠ là SLA của Availability ZONES, cao hơn một bậc.
-
A (99,90%) — ⚠ là SLA của MỘT VM đơn.
-
C (100%) — ⚠ không tồn tại.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #22106 ở lô trước — cùng hỏi SLA của Availability Set, chỉ khác vài từ trong đề bài.
| Câu | Đề bài | Khoá |
|---|---|---|
| ⚠ #22106 | ⚠ "SLA cho hai VM trở lên trong cùng Availability Set" | ⚠ B — 99,95% |
| ⚠ #22170 (câu này) | ⚠ "...trong cùng Availability Set trong cùng vùng" | ⚠ D — 99,95% |
| ⚠ Cùng đáp án | ⚠ nhưng KHÁC chữ cái vì bộ đề xáo thứ tự | |
| ⚠ Không mâu thuẫn | ⚠ giữ nguyên cả hai khoá |
⚠ Trong hai lô gần nhau đã gặp bốn câu về cùng bảng SLA này — #22093, #22106, #22113, và #22170. ⚠ Đây là điểm được hỏi rất dày, nên thuộc lòng ba con số là đáng giá.
⚠ Mẹo nhớ: | Con số | Gắn với | |---|---| | ⚠ 99,9% | ⚠ một máy | | ⚠ 99,95% | ⚠ Set — thêm một nửa | | ⚠ 99,99% | ⚠ Zone — bốn số chín |
Từ khoá nhận diện:
"availability set" → ⚠ 99,95% "availability zone" → ⚠ 99,99% "một VM, đĩa premium" → ⚠ 99,9% "đĩa standard HDD" → ⚠ KHÔNG đủ điều kiện hưởng SLA của VM đơn
| ⚠ Điều kiện để thực sự nhận SLA | Điều kiện |
|---|---|
| ⚠ Ít nhất hai máy trong set | |
| ⚠ Set phải khai LÚC TẠO máy | ⚠ không thêm được sau |
| ⚠ Các thành phần khác cũng phải dư thừa | ⚠ load balancer, IP công cộng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy có thực sự nằm trong Availability Set không | | | Có nâng lên Availability Zones được không | ⚠ cao hơn một bậc | | Loại đĩa có đủ điều kiện không | |
Và ràng buộc thực tế cần nhớ về Availability Set: phải chỉ định ngay khi tạo máy. Máy đang chạy không thêm vào set được — muốn có thì phải tạo lại từ đầu.
- A Separating your application into multiple subnets allows you to have different NSG security rules for each subnet, which can make it harder for a hacker to get from one compromised server onto another.
-
B
There are only a limited number of IP addresses available per subnet, so you need multiple subnets over a certain number.
- C Each server type of your application requires its own subnet. It's not possible to mix web servers, database servers and application servers on the same subnet.
Xem giải thích
Đáp án
A — Tách ứng dụng thành nhiều subnet cho phép đặt luật NSG khác nhau cho từng subnet, khiến kẻ tấn công khó đi từ máy đã chiếm được sang máy khác.
Vì sao đúng
⚠ Phân đoạn mạng chặn LAN NGANG (lateral movement): | Subnet | Ai được nói chuyện với ai | |---|---| | ⚠ Web | ⚠ nhận từ Internet, gọi được sang App | | ⚠ App | ⚠ chỉ nhận từ Web, gọi được sang DB | | ⚠ Database | ⚠ CHỈ nhận từ App, KHÔNG chạm Internet |
⚠ Internet → ⚠ Web → ⚠ App → ⚠ DB
⚠ Chiếm được máy Web
↓
⚠ NSG chặn không cho gọi thẳng sang DB
↓
⚠ Thiệt hại bị giới hạn ở một lớp
Vì sao các phương án khác sai
-
B (mỗi subnet chỉ có số IP hạn chế nên phải chia nhiều subnet) — ⚠ subnet của Azure lớn tuỳ bạn khai, có thể tới /8; đây không phải lý do chính.
-
C (mỗi loại máy chủ BẮT BUỘC phải có subnet riêng) — ⚠ SAI; trộn chung được về mặt kỹ thuật, chỉ là không nên.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #22141 trong lô này xếp việc "chia máy chủ thành subnet theo vai trò" vào lớp MẠNG của phòng thủ nhiều lớp. ⚠ Câu này giải thích LÝ DO của biện pháp đó.
⚠ Nguyên tắc "giả định đã bị xâm nhập": | Ý tưởng | Nội dung | |---|---| | ⚠ Không hỏi "làm sao để không bị chiếm" | | | ⚠ Mà hỏi "khi bị chiếm rồi thì thiệt hại tới đâu" | | | ⚠ Phân đoạn thu hẹp phạm vi thiệt hại | | | ⚠ Đây là | ⚠ một trong ba nguyên tắc Zero Trust |
Từ khoá nhận diện:
"chặn lan ngang giữa các máy" → ⚠ phân đoạn mạng, NSG theo subnet "nhóm máy theo vai trò để viết luật gọn" → ⚠ Application Security Group "kiểm soát tập trung ở biên VNet" → ⚠ Azure Firewall "CSDL không cần IP công cộng" → ⚠ Private Endpoint
| ⚠ Application Security Group — công cụ làm việc này gọn hơn | Nội dung |
|---|---|
| ⚠ Gán card mạng vào một nhóm theo VAI TRÒ | ⚠ web, app, db |
| ⚠ Viết luật NSG theo TÊN NHÓM | ⚠ không phải theo dải IP |
| ⚠ Thêm máy vào nhóm là tự áp luật | |
| ⚠ Lợi ích | ⚠ luật đọc được như tiếng người, không phải bảng địa chỉ |
| ⚠ Thực hành phân đoạn tốt | Thực hành |
|---|---|
| ⚠ Tầng dữ liệu KHÔNG bao giờ chạm Internet | |
| ⚠ Chỉ mở đúng cổng cần giữa các tầng | |
| ⚠ Chặn chiều ra ở tầng dữ liệu | |
| ⚠ Quản trị đi qua Bastion, không qua Internet |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy CSDL có IP công cộng không | ⚠ nếu có thì gỡ ngay | | Máy Web có gọi thẳng được sang CSDL không | ⚠ thử bằng IP flow verify | | Luật NSG có viết theo nhóm vai trò không | |
Và giá trị thật của việc chia subnet không nằm ở chỗ tổ chức cho gọn, mà ở chỗ: một máy bị chiếm không đồng nghĩa với cả hệ thống bị chiếm. Đó là khác biệt giữa một sự cố và một thảm hoạ.
- A To trick users into giving up personal information
- B To crack the password from administrator accounts
- C To extract data from a database
-
D
To overwhelm and exhaust application resources
Xem giải thích
Đáp án
D — Làm quá tải và vắt kiệt tài nguyên của ứng dụng.
Vì sao đúng
⚠ DDoS nhắm vào KHẢ NĂNG PHỤC VỤ, không nhắm vào dữ liệu: | Tài nguyên bị vắt kiệt | Kiểu tấn công | |---|---| | ⚠ Băng thông mạng | ⚠ volumetric — UDP flood, amplification | | ⚠ Bảng kết nối | ⚠ protocol — SYN flood | | ⚠ CPU và bộ nhớ ứng dụng | ⚠ application layer — HTTP flood |
⚠ Kết quả: ⚠ người dùng thật không vào được, dù dữ liệu không hề bị lấy đi.
Vì sao các phương án khác sai
-
A (lừa người dùng cung cấp thông tin cá nhân) — ⚠ là phishing.
-
B (bẻ mật khẩu tài khoản quản trị) — ⚠ là brute force hoặc credential stuffing.
-
C (rút dữ liệu khỏi CSDL) — ⚠ là SQL injection hoặc data exfiltration.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #22083 ở lô trước hỏi định nghĩa DDoS; câu này hỏi mục tiêu của nó. ⚠ Hai câu bổ sung nhau, giữ nguyên cả hai khoá.
⚠ Phân biệt các loại tấn công thường gặp trong đề: | Tấn công | Mục tiêu | |---|---| | ⚠ DDoS | ⚠ làm ngừng phục vụ | | ⚠ Phishing | ⚠ lừa lấy thông tin đăng nhập | | ⚠ Brute force | ⚠ dò mật khẩu | | ⚠ SQL injection | ⚠ đọc hoặc sửa dữ liệu | | ⚠ XSS | ⚠ chạy mã trong trình duyệt nạn nhân | | ⚠ Ransomware | ⚠ mã hoá dữ liệu đòi tiền chuộc |
Từ khoá nhận diện:
"làm quá tải, người dùng thật không vào được" → ⚠ DDoS "email giả mạo dụ bấm link" → ⚠ phishing "thử hàng triệu mật khẩu" → ⚠ brute force "chèn lệnh vào ô nhập liệu" → ⚠ injection
| ⚠ Vì sao DDoS trên đám mây nguy hiểm theo cách khác | Lý do |
|---|---|
| ⚠ Hệ thống tự co giãn sẽ MỞ RỘNG để phục vụ cuộc tấn công | |
| ⚠ Dịch vụ không sập, nhưng hoá đơn tăng vọt | |
| ⚠ Tên gọi | ⚠ economic denial of sustainability |
| ⚠ Cách chống | ⚠ đặt trần co giãn, mua DDoS Protection có cost protection |
| ⚠ Bảo vệ nhiều lớp trước DDoS | Lớp |
|---|---|
| ⚠ DDoS Infrastructure Protection | ⚠ miễn phí, bật sẵn |
| ⚠ DDoS IP hoặc Network Protection | ⚠ trả phí, có điều chỉnh và bảo vệ chi phí |
| ⚠ WAF | ⚠ cho tấn công tầng 7 |
| ⚠ Front Door hoặc CDN | ⚠ hấp thụ lưu lượng ở biên |
| ⚠ Trần tự co giãn | ⚠ chặn thiệt hại về chi phí |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trần số thể hiện tối đa khi co giãn không | | | Ứng dụng công khai có WAF chưa | | | Có cảnh báo khi lưu lượng tăng bất thường không | |
Và điều làm DDoS khác mọi cuộc tấn công khác: kẻ tấn công không cần chiếm được gì cả. Chúng chỉ cần gửi đủ lưu lượng hợp lệ về mặt kỹ thuật để hệ thống của bạn không còn chỗ cho người dùng thật.
Which feature within Azure alerts you to service issues that happen in Azure itself, not specifically related to your own resources?
- A Azure Service Health
- B Azure Security Center
- C Azure Monitor
- D Azure Portal Dashboard
Xem giải thích
Đáp án
A — Azure Service Health.
Vì sao đúng
⚠ Service Health báo sự cố của NỀN TẢNG Azure, đã lọc theo những gì bạn dùng: | Loại thông báo | Nội dung | |---|---| | ⚠ Service issues | ⚠ sự cố đang xảy ra ở dịch vụ và vùng bạn dùng | | ⚠ Planned maintenance | ⚠ bảo trì đã lên lịch | | ⚠ Health advisories | ⚠ thay đổi cần bạn hành động, ví dụ dịch vụ sắp ngừng | | ⚠ Security advisories | ⚠ cảnh báo bảo mật |
⚠ Azure Status → ⚠ công khai, toàn cầu, không lọc
⚠ Service Health → ⚠ lọc theo subscription của BẠN
⚠ Resource Health → ⚠ một tài nguyên cụ thể
Vì sao các phương án khác sai
-
C (Azure Monitor) — ⚠ giám sát tài nguyên CỦA BẠN, không báo sự cố nền tảng.
-
B (Azure Security Center, nay là Defender for Cloud) — ⚠ lo tư thế bảo mật.
-
D (Azure Portal Dashboard) — ⚠ chỉ hiển thị, không phải nguồn thông tin riêng.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #22130 ở lô trước hỏi ngoài Service Health còn xem ở đâu (đáp án: Resource Health của từng tài nguyên). ⚠ Câu này hỏi chính Service Health. Hai câu nhất quán.
⚠ Ba tầng thông tin sức khoẻ — nhớ theo phạm vi: | Tầng | Trả lời | |---|---| | ⚠ Azure Status | ⚠ Azure toàn cầu có sao không | | ⚠ Service Health | ⚠ sự cố nào chạm tới TÔI | | ⚠ Resource Health | ⚠ tài nguyên NÀY có khoẻ không |
Từ khoá nhận diện:
"sự cố của chính Azure, lọc theo tôi" → ⚠ Service Health "trang trạng thái công khai" → ⚠ Azure Status "một máy ảo cụ thể" → ⚠ Resource Health "chỉ số và nhật ký của tôi" → ⚠ Azure Monitor
| ⚠ Việc quan trọng nhất phải làm | Việc |
|---|---|
| ⚠ Tạo Service Health alert | ⚠ Azure KHÔNG tự gửi thông báo |
| ⚠ Chọn đúng dịch vụ và vùng đang dùng | |
| ⚠ Gắn Action Group | ⚠ email, SMS, webhook, ITSM |
| ⚠ Không có cảnh báo | ⚠ thì phải tự vào Portal xem, tức là biết muộn |
| ⚠ Vì sao Service Health hữu ích khi có sự cố | Lý do |
|---|---|
| ⚠ Biết ngay lỗi là do Azure hay do mình | ⚠ tiết kiệm hàng giờ gỡ lỗi sai hướng |
| ⚠ Có mã theo dõi để báo cáo lên trên | |
| ⚠ Có căn cứ để yêu cầu tín dụng SLA | |
| ⚠ Biết bảo trì sắp tới để lên kế hoạch |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã có Service Health alert chưa | ⚠ mặc định không có | | Cảnh báo có phủ đủ dịch vụ và vùng đang dùng không | | | Quy trình xử lý sự cố có bước "kiểm tra Service Health" chưa | |
Và bước đầu tiên nên có trong mọi quy trình xử lý sự cố trên Azure: kiểm tra Service Health trước khi gỡ lỗi ứng dụng. Nếu nền tảng đang trục trặc thì mọi phút đọc log ứng dụng đều là phút lãng phí.
- A A custom designed policy
- B Requiring all resources in Azure to use tags
- C The ability to group policies together
- D Assigning permissions to a role in Azure
Xem giải thích
Đáp án
C — Khả năng gộp nhiều chính sách lại với nhau.
Vì sao đúng
⚠ Policy initiative (nay gọi là policy set definition) là một BỘ chính sách: | Đặc điểm | Nội dung | |---|---| | ⚠ Gom nhiều policy definition | ⚠ thành một đơn vị | | ⚠ Gán một lần | ⚠ thay vì gán từng chính sách một | | ⚠ Xem tuân thủ tổng hợp | ⚠ một điểm số cho cả bộ | | ⚠ Có bộ dựng sẵn | ⚠ theo chuẩn ISO 27001, PCI DSS, NIST, CIS |
⚠ Policy definition → ⚠ một luật đơn lẻ
⚠ Initiative → ⚠ nhiều luật gom lại
⚠ Assignment → ⚠ áp bộ đó lên một phạm vi
Vì sao các phương án khác sai
-
A (một chính sách tự thiết kế) — ⚠ đó là custom policy definition, một luật đơn lẻ.
-
B (buộc mọi tài nguyên phải có thẻ) — ⚠ là VÍ DỤ về một chính sách, không phải định nghĩa initiative.
-
D (gán quyền cho một vai trò) — ⚠ là RBAC, không liên quan tới Policy.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #22118 trong lô này hỏi kịch bản nào hợp với Azure Policy; câu này hỏi initiative là gì. ⚠ Hai câu bổ sung nhau.
⚠ Ba khái niệm của Azure Policy — theo thứ tự: | Khái niệm | Là gì | |---|---| | ⚠ Policy definition | ⚠ một luật, ví dụ "chỉ được tạo ở Southeast Asia" | | ⚠ Initiative | ⚠ một bộ nhiều luật phục vụ cùng mục tiêu | | ⚠ Assignment | ⚠ áp lên management group, subscription, hoặc resource group |
Từ khoá nhận diện:
"gom nhiều chính sách" → ⚠ initiative "một luật đơn lẻ" → ⚠ policy definition "áp lên phạm vi nào" → ⚠ assignment "đóng gói cả môi trường chuẩn" → ⚠ Blueprint hoặc Deployment Stacks
| ⚠ Vì sao dùng initiative thay vì gán lẻ | Lý do |
|---|---|
| ⚠ Một chuẩn tuân thủ có hàng chục luật | ⚠ gán lẻ là không quản nổi |
| ⚠ Báo cáo tuân thủ tổng hợp cho cả bộ | |
| ⚠ Thêm bớt luật trong bộ mà không phải gán lại | |
| ⚠ Có sẵn bộ theo chuẩn ngành | ⚠ Azure Security Benchmark, ISO 27001 |
| ⚠ Hiệu lực của policy | Hiệu lực |
|---|---|
| ⚠ Deny | ⚠ chặn tạo hoặc sửa |
| ⚠ Audit | ⚠ cho qua nhưng đánh dấu không tuân thủ |
| ⚠ Append và Modify | ⚠ tự thêm hoặc sửa thuộc tính |
| ⚠ DeployIfNotExists | ⚠ tự triển khai thứ còn thiếu |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bộ chính sách theo chuẩn nào đang được gán không | | | Điểm tuân thủ hiện tại là bao nhiêu | | | Chính sách mới nên chạy Audit bao lâu trước khi chuyển Deny | ⚠ đừng chặn ngay |
Và cách triển khai chính sách an toàn cho môi trường đang chạy: bắt đầu bằng Audit, xem báo cáo, sửa những gì lệch chuẩn, rồi mới chuyển sang Deny. Đặt Deny ngay từ đầu sẽ chặn cả những việc hợp lệ mà chưa ai kịp điều chỉnh.
True or false: If your feature is in the General Availability phase, then your feature will receive support from all Microsoft support channels.
- A TRUE
- B FALSE
Xem giải thích
Đáp án
A — ĐÚNG.
Vì sao đúng
⚠ General Availability là mốc dịch vụ được coi là sẵn sàng cho sản xuất: | Từ GA trở đi | Nội dung | |---|---| | ⚠ Hỗ trợ đầy đủ qua mọi kênh | ⚠ hỗ trợ kỹ thuật, tài liệu, cộng đồng | | ⚠ Có SLA | ⚠ cam kết thời gian hoạt động | | ⚠ Có cam kết tương thích ngược | | | ⚠ Có chính sách ngừng dịch vụ rõ ràng | ⚠ thường báo trước 12 tháng | | ⚠ Đủ chứng nhận tuân thủ | |
Vì sao các phương án khác sai
- B (SAI) — ⚠ không đúng; chính GA là mốc phân biệt "dùng thử" với "dùng thật".
Ghi nhớ
⚠ Đối chiếu: ⚠ lô này và lô trước có ba câu về vòng đời dịch vụ.
| Câu | Hỏi gì | Khoá |
|---|---|---|
| ⚠ #22096 | ⚠ ba giai đoạn là gì | ⚠ Private Preview, Public Preview, GA |
| ⚠ #22135 | ⚠ vào Private Preview bằng cách nào | ⚠ phải nộp đơn xin |
| ⚠ #22175 (câu này) | ⚠ GA có được hỗ trợ đầy đủ không | ⚠ CÓ |
| ⚠ Ba câu | ⚠ nhất quán, vẽ trọn vòng đời một dịch vụ Azure |
⚠ So sánh ba giai đoạn: | Giai đoạn | SLA | Hỗ trợ | Dùng cho sản xuất | |---|---|---|---| | ⚠ Private Preview | ⚠ không | ⚠ qua nhóm sản phẩm | ⚠ KHÔNG | | ⚠ Public Preview | ⚠ không | ⚠ hạn chế | ⚠ KHÔNG | | ⚠ GA | ⚠ có | ⚠ đầy đủ | ⚠ CÓ |
Từ khoá nhận diện:
"hỗ trợ đầy đủ, có SLA" → ⚠ GA "chưa có SLA" → ⚠ Preview, cả hai loại "phải nộp đơn xin" → ⚠ Private Preview "dịch vụ sắp ngừng" → ⚠ retirement, thường báo trước 12 tháng
| ⚠ Các mức hỗ trợ của Azure | Mức |
|---|---|
| ⚠ Basic | ⚠ miễn phí, chỉ hỗ trợ về hoá đơn và đăng ký |
| ⚠ Developer | ⚠ hỗ trợ kỹ thuật giờ hành chính |
| ⚠ Standard | ⚠ 24/7, phù hợp môi trường sản xuất |
| ⚠ Professional Direct | ⚠ phản hồi nhanh hơn, có tư vấn |
| ⚠ Lưu ý | ⚠ hỗ trợ ĐẦY ĐỦ vẫn cần bạn mua gói hỗ trợ tương ứng |
| ⚠ Sau GA còn giai đoạn nào | Giai đoạn |
|---|---|
| ⚠ Deprecation announcement | ⚠ thông báo sẽ ngừng |
| ⚠ Retirement | ⚠ ngừng hẳn |
| ⚠ Theo dõi ở | ⚠ Azure Updates và Service Health advisories |
| ⚠ Trong hai lô gần đây đã gặp | ⚠ nhiều dịch vụ đang ở giai đoạn này |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dịch vụ đang dùng ở giai đoạn nào | | | Gói hỗ trợ hiện tại có đủ cho môi trường sản xuất không | ⚠ Basic không có hỗ trợ kỹ thuật | | Có thông báo ngừng dịch vụ nào chưa xử lý không | |
Và điểm cần phân biệt rõ: GA nghĩa là dịch vụ đủ điều kiện được hỗ trợ, chứ không tự động nghĩa là bạn có hỗ trợ. Mức hỗ trợ bạn nhận được phụ thuộc vào gói hỗ trợ mà tổ chức đã mua.
- A Each user account is associated with a unique subscription. If you need more than one subscription, you need to create multiple user accounts.
- B It is the level at which services are billed. All resources created under a subscription are billed to that subscription.
Xem giải thích
Đáp án
B — Đó là cấp mà dịch vụ được tính tiền; mọi tài nguyên tạo dưới một subscription đều tính vào subscription đó.
Vì sao đúng
⚠ Subscription là ranh giới của bốn thứ: | Ranh giới | Nội dung | |---|---| | ⚠ Thanh toán | ⚠ hoá đơn tách theo subscription | | ⚠ Cách ly quyền | ⚠ RBAC gán ở đây không lan sang subscription khác | | ⚠ Hạn mức tài nguyên | ⚠ quota tính riêng từng subscription | | ⚠ Chính sách | ⚠ Azure Policy áp riêng được |
⚠ Tenant (Entra ID)
├── ⚠ Subscription — Sản xuất → ⚠ hoá đơn riêng
└── ⚠ Subscription — Phát triển → ⚠ hoá đơn riêng
Vì sao các phương án khác sai
- A (mỗi tài khoản người dùng gắn với một subscription duy nhất; muốn nhiều subscription thì phải tạo nhiều tài khoản) — ⚠ SAI hoàn toàn; ⚠ một người truy cập được NHIỀU subscription, và một subscription có NHIỀU người dùng chung.
Ghi nhớ
⚠ Đối chiếu: ⚠ lô này và lô trước có ba câu về cấu trúc quản lý.
| Câu | Hỏi gì |
|---|---|
| ⚠ #22099 | ⚠ khi nào nên có nhiều subscription |
| ⚠ #22156 | ⚠ tenant là gì |
| ⚠ #22176 (câu này) | ⚠ subscription là gì |
| ⚠ Ba câu | ⚠ cùng vẽ nên thứ bậc quản lý của Azure |
⚠ Thứ bậc quản lý — quyền và chính sách kế thừa từ trên xuống:
⚠ Management Group → ⚠ nhóm nhiều subscription
↓
⚠ Subscription → ⚠ ranh giới hoá đơn và cách ly
↓
⚠ Resource Group → ⚠ nhóm tài nguyên cùng vòng đời
↓
⚠ Resource → ⚠ tài nguyên cụ thể
Từ khoá nhận diện:
"cấp tính tiền" → ⚠ subscription "thể hiện Entra ID của tổ chức" → ⚠ tenant "áp chính sách cho nhiều subscription" → ⚠ management group "chỉ để báo cáo chi phí theo dự án" → ⚠ tags, không cần subscription mới
| ⚠ Lý do tách nhiều subscription | Lý do |
|---|---|
| ⚠ Tách môi trường Prod và Dev | |
| ⚠ Tách theo bộ phận để tính chi phí | |
| ⚠ Chạm trần hạn mức tài nguyên | |
| ⚠ Yêu cầu tuân thủ khác nhau | |
| ⚠ Cách ly tuyệt đối giữa các khách hàng |
| ⚠ Điều cần biết thêm | Điều |
|---|---|
| ⚠ Một subscription chỉ tin cậy MỘT tenant | |
| ⚠ Chuyển subscription sang tenant khác được | ⚠ nhưng MẤT hết gán quyền RBAC |
| ⚠ Đổi tên subscription được | ⚠ không ảnh hưởng gì |
| ⚠ Có nhiều loại đăng ký | ⚠ Free, Pay-As-You-Go, EA, CSP, Visual Studio |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức đang có mấy subscription và ai là Owner | | | Prod và Dev có nằm chung một subscription không | | | Đã dùng management group để áp chính sách chung chưa | |
Và cấu trúc nên dựng sớm nhất có thể: management group đứng trên các subscription. Áp chính sách ở đó thì mọi subscription tạo về sau tự động tuân theo, còn dựng muộn thì phải đi sửa lại từng cái một.
- A It requires the user to have access to their verified phone in order to log in
- B It is another password that a user has to memorize, making it more secure
- C It doesn't make it more secure
-
D
It allows the user to log in without a password because they have already previously been validated using a browser cookie
Xem giải thích
Đáp án
A — Nó đòi người dùng phải có trong tay chiếc điện thoại đã xác minh mới đăng nhập được.
Vì sao đúng
⚠ MFA thêm một yếu tố thuộc loại KHÁC với mật khẩu: | Loại yếu tố | Ví dụ | |---|---| | ⚠ Thứ bạn BIẾT | ⚠ mật khẩu, PIN | | ⚠ Thứ bạn CÓ | ⚠ điện thoại, app Authenticator, khoá FIDO2 | | ⚠ Thứ bạn LÀ | ⚠ vân tay, khuôn mặt |
⚠ Mật khẩu bị lộ không còn đủ để vào, vì kẻ tấn công không cầm được thiết bị của bạn.
Vì sao các phương án khác sai
-
B (thêm một mật khẩu nữa phải nhớ) — ⚠ SAI; hai mật khẩu vẫn thuộc CÙNG một loại yếu tố, nên không phải MFA.
-
C (không làm hệ thống an toàn hơn) — ⚠ SAI hoàn toàn.
-
D (cho phép đăng nhập không cần mật khẩu nhờ cookie đã xác thực trước) — ⚠ mô tả sai; đó gần với ghi nhớ phiên đăng nhập, và cookie không phải yếu tố xác thực thứ hai.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này GẦN TRÙNG với #22116 ở lô trước — cùng hỏi MFA làm hệ thống an toàn hơn bằng cách nào.
| Câu | Đề bài | Khoá |
|---|---|---|
| ⚠ #22116 | ⚠ "MFA tăng bảo mật bằng cách nào" | ⚠ B — đòi thứ người dùng SỞ HỮU |
| ⚠ #22177 (câu này) | ⚠ "MFA làm hệ thống an toàn hơn thế nào" | ⚠ A — đòi điện thoại đã xác minh |
| ⚠ Nội dung | ⚠ cùng một ý | |
| ⚠ Chữ cái | ⚠ KHÁC nhau vì bộ đề xáo thứ tự | |
| ⚠ Không mâu thuẫn | ⚠ giữ nguyên cả hai khoá |
⚠ Cùng với #22092 (tính năng nào của Entra ID cung cấp yếu tố thứ hai) và #22152 (buộc MFA cho quản trị viên), lô này và lô trước có bốn câu về MFA — đây là chủ đề được hỏi rất dày.
⚠ Các phương thức MFA theo độ mạnh: | Phương thức | Độ mạnh | |---|---| | ⚠ FIDO2, Windows Hello | ⚠ mạnh nhất, chống phishing | | ⚠ Authenticator có number matching | ⚠ rất tốt | | ⚠ Mã OTP trong app | ⚠ tốt | | ⚠ Gọi điện | ⚠ yếu hơn | | ⚠ SMS | ⚠ yếu nhất — đánh cắp SIM |
Từ khoá nhận diện:
"thứ bạn có, điện thoại, app xác thực" → ⚠ MFA "hai mật khẩu" → ⚠ KHÔNG phải MFA "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 phương thức chính không | | | Đã bật number matching chống MFA fatigue chưa | |
Và lý do MFA luôn đứng đầu mọi danh sách khuyến nghị bảo mật: nó vô hiệu hoá giá trị của một mật khẩu bị đánh cắp, mà mật khẩu bị đánh cắp lại là điểm khởi đầu của gần như mọi cuộc tấn công chiếm tài khoản.
Which Azure compute service allows you to run containerized applications without managing the underlying infrastructure?
-
A
Azure Kubernetes Service (AKS)
-
B
Azure App Service
-
C
Azure Virtual Machines
-
D
Azure Container Instances
Xem giải thích
Đáp án
D — Azure Container Instances (ACI)
Vì sao đúng
ACI chạy container mà không cần dựng hay quản lý hạ tầng nào: không có cụm, không có node, không có bộ điều phối. Bạn khai ảnh container cùng lượng CPU và bộ nhớ cần, ACI chạy nó và tính tiền theo giây.
Đây là lựa chọn đơn giản nhất khi cần chạy một container đơn lẻ hoặc một tác vụ ngắn.
Vì sao các phương án khác sai
- A. AKS — chạy container nhưng bạn vẫn quản lý node pool và các khái niệm của Kubernetes; mạnh hơn nhiều nhưng cũng nặng hơn nhiều.
- C. Virtual Machines — bạn tự quản lý toàn bộ, kể cả hệ điều hành.
- B. App Service — chạy được container nhưng bạn vẫn quản lý App Service Plan, và nó dựng cho ứng dụng web chứ không phải tác vụ container tổng quát.
- A 4
- B 1
- C 40
- D 100
Xem giải thích
Đáp án
A — 4 phút.
Vì sao đúng
⚠ Phép tính:
⚠ Một tháng ≈ 30 ngày × 24 giờ × 60 phút = 43.200 phút
⚠ Thời gian ngừng cho phép = 43.200 × 0,01% = 4,32 phút
↓
⚠ Làm tròn ≈ 4 phút
⚠ Bảng quy đổi "số 9" — nên thuộc: | SLA | Mỗi tháng | Mỗi năm | |---|---|---| | ⚠ 99% | ⚠ ≈ 7,2 giờ | ⚠ ≈ 3,65 ngày | | ⚠ 99,9% | ⚠ ≈ 43 phút | ⚠ ≈ 8,76 giờ | | ⚠ 99,95% | ⚠ ≈ 22 phút | ⚠ ≈ 4,38 giờ | | ⚠ 99,99% | ⚠ ≈ 4 phút | ⚠ ≈ 52,6 phút | | ⚠ 99,999% | ⚠ ≈ 26 giây | ⚠ ≈ 5,26 phút |
Vì sao các phương án khác sai
-
B (1 phút) — ⚠ quá thấp, gần với mức 99,999%.
-
C (40 phút) — ⚠ là mức 99,9%, kém một bậc.
-
D (100 phút) — ⚠ thấp hơn 99,9%.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #22113 ở lô trước cho biết triển khai qua nhiều Availability Zone đạt SLA 99,99%; câu này quy đổi con số đó ra thời gian ngừng thực tế. ⚠ Hai câu bổ sung nhau.
⚠ Mẹo nhẩm nhanh trong phòng thi: | Mẹo | Nội dung | |---|---| | ⚠ 99,9% ≈ 43 phút mỗi tháng | ⚠ nhớ con số gốc này | | ⚠ Thêm một số 9 → CHIA 10 | ⚠ 99,99% ≈ 4,3 phút | | ⚠ Thêm nữa → chia 10 tiếp | ⚠ 99,999% ≈ 26 giây | | ⚠ Ngược lại | ⚠ bớt một số 9 → nhân 10 |
Từ khoá nhận diện:
"4 phút mỗi tháng" → ⚠ 99,99% "43 phút mỗi tháng" → ⚠ 99,9% "nhiều thành phần nối tiếp" → ⚠ NHÂN các SLA lại, kết quả THẤP hơn mọi thành phần "muốn nhiều số 9 hơn" → ⚠ thêm dư thừa, và chi phí tăng rất nhanh
| ⚠ Vì sao mỗi số 9 lại đắt hơn nhiều lần | Lý do |
|---|---|
| ⚠ Từ 99,9% lên 99,99% | ⚠ cần trải qua nhiều vùng sẵn sàng |
| ⚠ Từ 99,99% lên 99,999% | ⚠ cần triển khai đa vùng, chuyển đổi tự động |
| ⚠ Mỗi bậc đòi thêm dư thừa và thêm vận hành | |
| ⚠ Câu hỏi thực tế | ⚠ doanh nghiệp thật sự cần bao nhiêu số 9 |
| ⚠ SLA tổng hợp — hay bị tính nhầm | Ví dụ |
|---|---|
| ⚠ App Service 99,95% | |
| ⚠ SQL Database 99,99% | |
| ⚠ Nhân lại ≈ 99,94% | ⚠ THẤP hơn cả hai thành phần |
| ⚠ Bài học | ⚠ thêm một phụ thuộc là hạ SLA tổng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tính SLA tổng hợp của cả chuỗi chưa | | | Doanh nghiệp chịu được ngừng bao lâu | ⚠ đây là RTO, hỏi bằng phút | | Chi phí thêm một số 9 có tương xứng không | |
Và câu hỏi nên đặt trước khi đuổi theo thêm một số 9: thiệt hại thật của bốn phút ngừng là bao nhiêu? Với nhiều hệ thống, câu trả lời là gần như không đáng kể — và khoản đầu tư đó nên đi vào chỗ khác.