Ngân hàng đề — Microsoft Azure Security Technology
Tìm thấy 100 câu.
You want to provide access to an application for partners who do not have accounts in your Entra ID tenant. Which of the following should you consider?
-
A
Internal identities
-
B
Managed identities
-
C
B2B collaboration
-
D
External identities
Xem giải thích
Đáp án
C — B2B collaboration.
Vì sao đúng
⚠ B2B collaboration đúng cho kịch bản đối tác: | Đặc điểm | Nội dung | |---|---| | ⚠ Mời bằng email | ⚠ họ dùng tài khoản của TỔ CHỨC HỌ | | ⚠ KHÔNG tạo tài khoản mới trong tenant của bạn | ⚠ chỉ là đối tượng khách mời | | ⚠ Áp được Conditional Access và MFA | | | ⚠ Thu hồi quyền bằng cách xoá đối tượng khách | | | ⚠ MFA và quản mật khẩu do phía họ lo | |
Vì sao các phương án khác sai
-
B (Managed identities) — ⚠ định danh cho DỊCH VỤ Azure, không phải cho người.
-
A (Internal identities) — ⚠ là nhân viên trong tổ chức, không phải đối tác.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án D — External identities ⚠ cũng đúng theo nghĩa rộng, vì B2B collaboration nằm trong Microsoft Entra External ID.
| Phương án | Quan hệ |
|---|---|
| ⚠ D — External identities | ⚠ TÊN CHUNG của cả họ tính năng cho người dùng ngoài |
| ⚠ C — B2B collaboration (khoá) | ⚠ tính năng CỤ THỂ cho kịch bản đối tác |
| ⚠ Đề mô tả rõ | ⚠ "đối tác", "không có tài khoản trong tenant" — đúng đặc trưng của B2B |
| ⚠ External ID còn gồm | ⚠ B2C, dành cho KHÁCH HÀNG chứ không phải đối tác |
| ⚠ Nguyên tắc chọn | ⚠ khi có cả tên chung lẫn tên cụ thể, chọn cái CỤ THỂ khớp tình huống |
| ⚠ Khoá | ⚠ giữ nguyên C |
⚠ B2B và B2C — chọn theo đối tượng: | Tiêu chí | B2B | B2C | |---|---|---| | ⚠ Đối tượng | ⚠ đối tác, nhà cung cấp | ⚠ khách hàng, người tiêu dùng | | ⚠ Quy mô | ⚠ hàng nghìn | ⚠ hàng triệu | | ⚠ Danh bạ | ⚠ cùng tenant, là khách mời | ⚠ tenant RIÊNG | | ⚠ Đăng nhập bằng | ⚠ tài khoản tổ chức của họ | ⚠ email, mạng xã hội |
Từ khoá nhận diện:
"đối tác dùng tài khoản của họ" → ⚠ B2B collaboration "khách hàng đăng ký bằng Facebook" → ⚠ B2C "định danh cho dịch vụ Azure" → ⚠ managed identity "nhân viên của mình" → ⚠ internal identity
| ⚠ Quản trị tài khoản khách | Việc |
|---|---|
| ⚠ Access Reviews định kỳ | ⚠ rà xem ai còn cần |
| ⚠ Entitlement Management | ⚠ gói quyền có hạn, có người duyệt |
| ⚠ Cross-tenant access settings | ⚠ kiểm soát tenant nào được cộng tác |
| ⚠ Siết quyền mặc định của guest | ⚠ mặc định guest thấy khá nhiều thông tin danh bạ |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tenant có bao nhiêu tài khoản khách | ⚠ thường nhiều hơn người ta tưởng | | Có khách nào đã lâu không đăng nhập không | | | Quyền mặc định của guest đã siết chưa | |
Và rủi ro tích tụ âm thầm trong mọi tenant có dùng B2B: tài khoản khách không bao giờ được dọn. Dự án kết thúc từ lâu nhưng đối tượng khách vẫn còn đó với nguyên quyền — Access Reviews định kỳ là cách duy nhất giữ danh sách sạch.
A security administrator is securing users in Microsoft Entra ID. Which of the following is NOT a recommended practice?
-
A
Enabling multi-factor authentication (MFA)
-
B
Assigning privileged roles only when required
-
C
Sharing user credentials between team members for easy access
-
D
Regularly reviewing sign-in logs for suspicious activities
Xem giải thích
Đáp án
C — Chia sẻ thông tin đăng nhập giữa các thành viên trong nhóm cho tiện.
Vì sao đúng
⚠ Dùng chung tài khoản phá vỡ toàn bộ nền tảng bảo mật định danh: | Hậu quả | Nội dung | |---|---| | ⚠ Nhật ký không cho biết AI thực sự thao tác | ⚠ mất khả năng quy trách nhiệm | | ⚠ Không thu hồi quyền cho từng người được | ⚠ một người nghỉ là phải đổi mật khẩu cho tất cả | | ⚠ MFA gắn với một thiết bị | ⚠ chia sẻ là phá vỡ cơ chế | | ⚠ Không áp được quyền tối thiểu | ⚠ ai cũng có quyền như nhau | | ⚠ Mật khẩu lan truyền qua chat, email, giấy nhớ | |
Vì sao các phương án khác sai
- A (bật MFA), B (chỉ gán vai trò đặc quyền khi cần), D (rà soát nhật ký đăng nhập) — ⚠ đều là thực hành TỐT được khuyến nghị.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23826 ở lô trước hỏi thực hành TỐT (xác thực mạnh, quyền tối thiểu, xác thực hiện đại). ⚠ Câu này hỏi thực hành XẤU. Hai câu là hai mặt của cùng một danh sách.
⚠ Giải pháp đúng thay cho việc dùng chung tài khoản: | Nhu cầu | Giải pháp đúng | |---|---| | ⚠ Nhiều người cần cùng quyền | ⚠ tạo NHÓM, gán quyền cho nhóm | | ⚠ Ứng dụng cần truy cập | ⚠ managed identity hoặc service principal | | ⚠ Truy cập khẩn cấp | ⚠ tài khoản break-glass có kiểm soát và giám sát | | ⚠ Quyền quản trị dùng chung | ⚠ PIM — mỗi người tự kích hoạt bằng tài khoản của mình |
Từ khoá nhận diện:
"dùng chung tài khoản" → ⚠ thực hành XẤU, luôn là đáp án sai trong đề "nhiều người cùng quyền" → ⚠ nhóm bảo mật "ứng dụng truy cập" → ⚠ managed identity "quyền quản trị khi cần" → ⚠ PIM
| ⚠ Tài khoản break-glass — ngoại lệ có kiểm soát | Nội dung |
|---|---|
| ⚠ Hai tài khoản khẩn cấp | ⚠ loại trừ khỏi mọi chính sách Conditional Access |
| ⚠ Mật khẩu rất dài, chia làm nhiều phần | ⚠ cất ở nơi vật lý an toàn |
| ⚠ Có CẢNH BÁO khi được dùng | |
| ⚠ Kiểm thử định kỳ | |
| ⚠ Đây KHÔNG phải | ⚠ tài khoản dùng chung hằng ngày |
| ⚠ Danh sách thực hành tốt cho người dùng Entra ID | Mục |
|---|---|
| ⚠ MFA cho mọi người | |
| ⚠ Chặn legacy authentication | |
| ⚠ Quyền tối thiểu, dùng PIM cho vai trò đặc quyền | |
| ⚠ Chặn mật khẩu yếu | |
| ⚠ Rà soát nhật ký và Access Reviews định kỳ | |
| ⚠ MỘT người MỘT tài khoản |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài khoản nào đang dùng chung không | ⚠ thường lộ ra qua nhật ký đăng nhập từ nhiều nơi | | Tài khoản dịch vụ có dùng managed identity chưa | | | Tài khoản break-glass có được giám sát không | |
Và cái mất lớn nhất khi dùng chung tài khoản, lớn hơn cả rủi ro lộ mật khẩu: mất khả năng quy trách nhiệm. Khi có sự cố, nhật ký chỉ nói được rằng "tài khoản X đã làm" — mà tài khoản X là năm người.
You have sensitive data columns in an Azure SQL database that should not be exposed in their entirety to some of the application users. Which feature should you use to hide this sensitive data in result sets?
-
A
Standard query filters
-
B
Regular indexing
-
C
Always Encrypted
-
D
Dynamic Data Masking
Xem giải thích
Đáp án
D — Dynamic Data Masking.
Vì sao đúng
⚠ Dynamic Data Masking che một phần dữ liệu trong KẾT QUẢ TRUY VẤN: | Đặc điểm | Nội dung | |---|---| | ⚠ Dữ liệu trong CSDL KHÔNG đổi | ⚠ chỉ che ở lớp hiển thị | | ⚠ Áp theo người dùng | ⚠ người có quyền vẫn thấy đầy đủ | | ⚠ Không cần sửa ứng dụng | | | ⚠ Cấu hình ở cấp CỘT | |
⚠ Các hàm che sẵn có: | Hàm | Kết quả | |---|---| | ⚠ Default | ⚠ XXXX cho chuỗi, 0 cho số | | ⚠ Credit card | ⚠ chỉ hiện bốn số cuối | | ⚠ Email | ⚠ aXX@XXXX.com | | ⚠ Random number | ⚠ số ngẫu nhiên trong khoảng | | ⚠ Custom string | ⚠ giữ N ký tự đầu và cuối |
Vì sao các phương án khác sai
-
C (Always Encrypted) — ⚠ MÃ HOÁ dữ liệu ở phía client; ⚠ mạnh hơn nhưng hạn chế truy vấn và cần sửa ứng dụng — không phải "che trong kết quả" như đề hỏi.
-
A (bộ lọc truy vấn chuẩn) và B (đánh chỉ mục thông thường) — ⚠ không phải cơ chế bảo mật.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23816 ở lô trước liệt kê TDE, Always Encrypted và Dynamic Data Masking cùng nhau. ⚠ Câu này chọn đúng một trong ba cho tình huống cụ thể. Hai câu nhất quán.
⚠ Ba biện pháp bảo vệ dữ liệu SQL — phân vai: | Biện pháp | Bảo vệ khỏi | |---|---| | ⚠ TDE | ⚠ người lấy được TỆP đĩa | | ⚠ Always Encrypted | ⚠ cả quản trị viên CSDL | | ⚠ Dynamic Data Masking | ⚠ người dùng ứng dụng không cần thấy đầy đủ |
Từ khoá nhận diện:
"che một phần trong kết quả" → ⚠ Dynamic Data Masking "kể cả DBA cũng không đọc được" → ⚠ Always Encrypted "mã hoá tệp khi lưu" → ⚠ TDE "chỉ thấy dòng của mình" → ⚠ Row-Level Security
| ⚠ Giới hạn QUAN TRỌNG của Dynamic Data Masking | Giới hạn |
|---|---|
| ⚠ KHÔNG phải mã hoá | ⚠ dữ liệu vẫn nguyên trong CSDL |
| ⚠ Người có quyền truy vấn khéo vẫn suy ra được | ⚠ ví dụ dùng mệnh đề WHERE để dò từng ký tự |
| ⚠ Không chặn được ai đó sao chép cả bảng | |
| ⚠ Vì thế | ⚠ là lớp TIỆN LỢI, không phải lớp bảo vệ chính |
| ⚠ Kết hợp nhiều lớp cho dữ liệu nhạy cảm | Lớp |
|---|---|
| ⚠ Quyền tối thiểu | ⚠ hạn chế ai truy vấn được bảng đó |
| ⚠ Row-Level Security | ⚠ giới hạn dòng thấy được |
| ⚠ Dynamic Data Masking | ⚠ che cột nhạy cảm |
| ⚠ Always Encrypted | ⚠ cho cột đặc biệt nhạy cảm |
| ⚠ Auditing | ⚠ ghi lại ai đã truy vấn gì |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cột nào chứa dữ liệu nhạy cảm | ⚠ dùng Data Discovery and Classification | | Có ai đang nhầm masking là mã hoá không | | | Người dùng ứng dụng có quyền rộng hơn cần thiết không | |
Và điều hay bị hiểu sai nhất về Dynamic Data Masking: nó là lớp che mắt, không phải lớp bảo vệ. Một người có quyền truy vấn và đủ kiên nhẫn vẫn suy ra được giá trị thật — nên đừng dùng nó thay cho việc siết quyền.
You are setting up a secure infrastructure for your organization's data in Azure. Which of the following actions are critical to ensuring the confidentiality, integrity, and availability of your secrets and cryptographic keys? (Select three)
-
A
Create and configure an Azure Key Vault
-
B
Deploy resources using a landing zone
-
C
Enable key rotation for stored keys
-
D
Use Azure Blueprint to assign a landing zone
-
E
RBAC for management plane
Xem giải thích
Đáp án
A, C và E.
- A — Tạo và cấu hình một Azure Key Vault.
- C — Bật xoay vòng khoá cho các khoá đã lưu.
- E — RBAC cho management plane.
Vì sao đúng
⚠ Ba biện pháp phủ đủ ba yếu tố C-I-A: | Yếu tố | Biện pháp | |---|---| | ⚠ Confidentiality — bảo mật | ⚠ Key Vault mã hoá và kiểm soát truy cập | | ⚠ Integrity — toàn vẹn | ⚠ xoay vòng khoá, nhật ký, soft delete | | ⚠ Availability — sẵn sàng | ⚠ Key Vault có dư thừa sẵn; RBAC ngăn xoá nhầm |
⚠ RBAC cho management plane kiểm soát ai được xoá vault, đổi cấu hình, gán quyền — ⚠ tách biệt với data plane vốn kiểm soát ai đọc được secret.
Vì sao các phương án khác sai
- B (triển khai tài nguyên bằng landing zone) và D (dùng Blueprint gán landing zone) — ⚠ về kiến trúc nền tảng và chuẩn hoá triển khai; ⚠ hữu ích nhưng không trực tiếp bảo vệ bí mật và khoá.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23856 ở lô này cũng về Key Vault, xoay vòng khoá và sao lưu. ⚠ Hai câu bổ sung nhau, cùng vẽ nên bức tranh vận hành Key Vault.
⚠ Hai mặt phẳng của Key Vault — RẤT quan trọng: | Mặt phẳng | Kiểm soát | |---|---| | ⚠ Management plane | ⚠ quản chính VAULT — tạo, xoá, đổi cấu hình, gán quyền | | ⚠ Data plane | ⚠ quản NỘI DUNG — đọc, ghi, xoá secret, key, certificate | | ⚠ Hai mặt phẳng | ⚠ cấp quyền RIÊNG BIỆT | | ⚠ Hệ quả | ⚠ có quyền Owner trên vault KHÔNG tự động đọc được secret | | ⚠ Nhưng | ⚠ Owner có thể TỰ CẤP quyền data plane cho mình |
Từ khoá nhận diện:
"lưu bí mật và khoá" → ⚠ Key Vault "tự động đổi khoá định kỳ" → ⚠ key rotation policy "ai được xoá vault" → ⚠ RBAC management plane "ai được đọc secret" → ⚠ RBAC data plane hoặc access policy
| ⚠ Hai mô hình quyền data plane | Mô hình |
|---|---|
| ⚠ Access policy | ⚠ mô hình CŨ, gán quyền theo danh sách trên vault |
| ⚠ Azure RBAC | ⚠ mô hình MỚI, khuyến nghị — vai trò như Key Vault Secrets User |
| ⚠ RBAC tốt hơn ở chỗ | ⚠ kế thừa được, gán ở nhiều phạm vi, quản tập trung |
| ⚠ Danh sách bảo vệ Key Vault | Mục |
|---|---|
| ⚠ Soft delete và purge protection | ⚠ BẮT BUỘC |
| ⚠ RBAC thay cho access policy | |
| ⚠ Private endpoint cho môi trường thật | |
| ⚠ Nhật ký chẩn đoán bật và có người xem | |
| ⚠ Xoay vòng khoá tự động | |
| ⚠ Vault riêng cho từng môi trường |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có quyền management plane trên vault | ⚠ họ tự cấp được quyền đọc secret | | Purge protection đã bật chưa | | | Có khoá nào chưa bao giờ xoay vòng không | |
Và điểm giao nhau nguy hiểm giữa hai mặt phẳng quyền của Key Vault: người có quyền Owner tuy không đọc được secret ngay, nhưng có thể tự cấp cho mình quyền đó. Nên kiểm soát management plane cũng chặt như data plane.
You are the Azure administrator for your company and use several applications that rely on Azure Key Vault to store and access keys for Azure Service Bus.
Currently, you regenerate the keys manually and store them in the Key Vault, which is a time-consuming process. To streamline this, you need to configure Azure to automatically rotate the keys. Your solution should require minimal effort.
What step should you take to meet this requirement?
-
A
Configure the keys to automatically rotate every six months, setting an expiration date for each rotation.
-
B
Allow each application the permission to rotate its keys.
-
C
Utilize a scheduled task along with PowerShell to expire the old keys and generate new ones.
-
D
Utilize an Automation account along with a runbook to rotate keys effectively.
Xem giải thích
Đáp án
A — Cấu hình khoá tự xoay vòng sáu tháng một lần, kèm ngày hết hạn
Vì sao đúng
Key Vault có cơ chế xoay vòng tự động ngay trong dịch vụ: bạn khai chính sách xoay vòng và ngày hết hạn, phần còn lại do nền tảng lo. Không phải viết mã, không phải duy trì script, và không có gì để hỏng âm thầm.
So với việc làm tay hằng tháng như hiện tại, đây là thay đổi đúng hướng: giảm công sức mà vẫn giữ được kỷ luật xoay vòng.
Vì sao các phương án khác sai
- C. Dùng scheduled task với PowerShell và D. Dùng Automation account với runbook — cả hai làm được, nhưng là tự dựng lại thứ Key Vault đã có sẵn: bạn phải viết mã, cấp quyền cho nó, và giám sát xem nó có chạy không.
- B. Cho từng ứng dụng quyền tự xoay khoá của mình — vi phạm nguyên tắc quyền tối thiểu: ứng dụng chỉ cần đọc khoá, cấp thêm quyền quản lý khoá là mở rộng bề mặt rủi ro.
You are tasked with monitoring and protecting your external assets in Azure. You also want to add custom compliance initiatives tailored to your organization's requirements.
Which of the following actions would you take? (Select two)
-
A
Use Microsoft Defender External Attack Surface Management to identify and monitor external assets
-
B
Add custom initiatives in Microsoft Defender for Cloud
-
C
Implement Azure Inventory for external asset monitoring
-
D
Add industry standards using Azure Multi-cloud Connector
Xem giải thích
Đáp án
A và B.
- A — Dùng Microsoft Defender External Attack Surface Management để nhận diện và giám sát tài sản bên ngoài.
- B — Thêm custom initiative vào Microsoft Defender for Cloud.
Vì sao đúng
⚠ Hai yêu cầu, hai công cụ: | Yêu cầu | Công cụ | |---|---| | ⚠ Giám sát tài sản BÊN NGOÀI | ⚠ Defender EASM — khám phá mọi thứ tổ chức phơi ra Internet | | ⚠ Thêm chuẩn tuân thủ RIÊNG | ⚠ custom initiative trong Regulatory Compliance |
⚠ EASM làm gì: | Khả năng | Nội dung | |---|---| | ⚠ Khám phá tự động | ⚠ tên miền, subdomain, IP, chứng chỉ, dịch vụ đang phơi ra | | ⚠ Tìm cả tài sản mà tổ chức KHÔNG BIẾT mình có | ⚠ shadow IT, hệ thống cũ bị quên | | ⚠ Phát hiện lỗ hổng trên tài sản đó | | | ⚠ Theo dõi thay đổi theo thời gian | |
Vì sao các phương án khác sai
-
C (dùng Azure Inventory để giám sát tài sản bên ngoài) — ⚠ Inventory của Defender for Cloud chỉ liệt kê tài nguyên TRONG Azure, không khám phá tài sản Internet.
-
D (thêm chuẩn ngành bằng Azure Multi-cloud Connector) — ⚠ connector dùng để KẾT NỐI AWS và GCP, không phải để thêm chuẩn tuân thủ.
Ghi nhớ
⚠ Đối chiếu: ⚠ lô này có #23821 và #23854 cùng về khả năng tuân thủ của Defender for Cloud. ⚠ Ba câu nhất quán.
⚠ Vì sao EASM giải bài toán mà công cụ nội bộ không giải được: | Vấn đề | Nội dung | |---|---| | ⚠ Tổ chức không biết hết mình đang phơi ra gì | ⚠ tên miền cũ, môi trường thử nghiệm, hệ thống của công ty vừa mua lại | | ⚠ Kẻ tấn công tìm ra trước bạn | ⚠ chúng cũng quét Internet | | ⚠ EASM quét từ BÊN NGOÀI vào | ⚠ giống góc nhìn của kẻ tấn công | | ⚠ Kết quả thường gây bất ngờ | ⚠ hầu như tổ chức nào cũng tìm ra tài sản đã quên |
Từ khoá nhận diện:
"tài sản phơi ra Internet" → ⚠ EASM "liệt kê tài nguyên trong Azure" → ⚠ Inventory "chuẩn riêng của tổ chức" → ⚠ custom initiative "kết nối AWS và GCP" → ⚠ multi-cloud connector
| ⚠ Custom initiative dùng để làm gì | Việc |
|---|---|
| ⚠ Gom nhiều Azure Policy thành một bộ | |
| ⚠ Hiện lên trong Regulatory Compliance như một chuẩn | |
| ⚠ Áp quy tắc nội bộ mà chuẩn dựng sẵn không phủ | |
| ⚠ Nền tảng | ⚠ chính là policy initiative của Azure Policy |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức có biết hết tài sản đang phơi ra Internet không | | | Có tên miền hoặc IP nào không ai nhận là của mình không | | | Quy tắc nội bộ đã đưa vào custom initiative chưa | |
Và phát hiện thường gây bất ngờ nhất khi chạy EASM lần đầu: tổ chức nào cũng có tài sản Internet mà không ai còn nhớ. Một môi trường thử nghiệm dựng ba năm trước, một tên miền của dự án đã dừng — và chúng vẫn đang chạy, vẫn chưa vá.
You've been assigned the task of enhancing the security posture of your Azure environment. You decide to leverage Microsoft Defender for Cloud.
Which of the following actions would you take to ensure a holistic security configuration for your Azure resources? (Select three)
-
A
Enable Microsoft Defender for Storage to protect data within Blob Storage
-
B
Configure Microsoft Defender for Servers to assess the health of your virtual machines
-
C
Use Microsoft Defender for Cloud to automate DevOps workflows
-
D
Set up workflow automation in Microsoft Defender for Cloud to automate responses to specific security alerts
-
E
Neglecting Non-Azure Resources
Xem giải thích
Đáp án
A, B và D.
- A — Bật Defender for Storage để bảo vệ dữ liệu trong Blob Storage.
- B — Cấu hình Defender for Servers để đánh giá tình trạng máy ảo.
- D — Thiết lập workflow automation để tự động phản ứng trước cảnh báo cụ thể.
Vì sao đúng
⚠ Ba việc phủ ba khía cạnh: | Khía cạnh | Việc | |---|---| | ⚠ Bảo vệ dữ liệu | ⚠ Defender for Storage — phát hiện tải lên mã độc, truy cập bất thường | | ⚠ Bảo vệ máy chủ | ⚠ Defender for Servers — EDR, quét lỗ hổng, JIT | | ⚠ Tự động phản ứng | ⚠ workflow automation chạy Logic App khi có cảnh báo |
Vì sao các phương án khác sai
-
C (dùng Defender for Cloud để tự động hoá quy trình DevOps) — ⚠ Defender for Cloud có phần DevSecOps để QUÉT pipeline, nhưng không tự động hoá quy trình phát triển; ⚠ đó là việc của Azure DevOps hoặc GitHub Actions.
-
E (bỏ qua tài nguyên ngoài Azure) — ⚠ NGƯỢC hoàn toàn với thực hành tốt; ⚠ Defender for Cloud bảo vệ được cả máy tại chỗ qua Azure Arc và cả AWS, GCP.
Ghi nhớ
⚠ Defender for Cloud bảo vệ được cả ngoài Azure: | Môi trường | Cách kết nối | |---|---| | ⚠ Máy chủ tại chỗ | ⚠ Azure Arc | | ⚠ AWS | ⚠ native connector | | ⚠ Google Cloud | ⚠ native connector | | ⚠ Kết quả | ⚠ một Secure Score chung cho toàn bộ hạ tầng |
⚠ Workflow automation — kích hoạt và hành động: | Kích hoạt bởi | Hành động | |---|---| | ⚠ Security alert | ⚠ gửi Teams, tạo ticket, cô lập máy | | ⚠ Recommendation thay đổi | ⚠ thông báo chủ sở hữu tài nguyên | | ⚠ Regulatory compliance thay đổi | ⚠ báo cáo cho đội tuân thủ | | ⚠ Chạy trên | ⚠ Azure Logic Apps |
Từ khoá nhận diện:
"bảo vệ blob khỏi mã độc" → ⚠ Defender for Storage "quét lỗ hổng và EDR trên máy" → ⚠ Defender for Servers "tự động phản ứng khi có cảnh báo" → ⚠ workflow automation "bảo vệ máy tại chỗ" → ⚠ Azure Arc kèm Defender for Servers
| ⚠ Defender for Storage phát hiện gì | Phát hiện |
|---|---|
| ⚠ Tải lên tệp có mã độc | ⚠ quét bằng Microsoft Defender Antivirus |
| ⚠ Truy cập từ IP bất thường hoặc IP thoát Tor | |
| ⚠ Truy cập ẩn danh vào container | |
| ⚠ Dấu hiệu rò rỉ dữ liệu | ⚠ tải xuống bất thường |
| ⚠ Nhạy cảm với dữ liệu | ⚠ ưu tiên cảnh báo trên dữ liệu đã phân loại nhạy cảm |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên ngoài Azure đã được kết nối chưa | ⚠ máy tại chỗ, AWS, GCP | | Có workflow automation nào đang chạy không | | | Cảnh báo có tới đúng người trực không | |
Và điểm mù phổ biến nhất trong chương trình bảo mật đám mây: tài nguyên NGOÀI Azure không được đưa vào bức tranh chung. Máy chủ tại chỗ và tài khoản AWS đứng ngoài mọi bảng điều khiển, và chúng thường là chỗ ít được vá nhất.
You're tasked with enhancing the database security in your organization's Azure environment. To achieve this, you decide to utilize Microsoft Defender for Cloud capabilities specific to Azure SQL Database. Which of the following actions would be most appropriate to ensure the security of your Azure SQL Database?
-
A
Enable Microsoft Defender for Azure SQL Database to detect potential vulnerabilities and threats
-
B
Implement workflow automation to automate DevOps processes
-
C
Configure Microsoft Defender for Containers to protect your SQL container deployments
-
D
Activate Microsoft Defender for App Service to monitor your database-hosted web apps
Xem giải thích
Đáp án
A — Bật Microsoft Defender for Azure SQL Database để phát hiện lỗ hổng và mối đe doạ tiềm tàng.
Vì sao đúng
⚠ Defender for SQL cung cấp hai nhóm khả năng: | Nhóm | Nội dung | |---|---| | ⚠ Vulnerability Assessment | ⚠ quét cấu hình CSDL so với chuẩn, đưa khuyến nghị khắc phục | | ⚠ Advanced Threat Protection | ⚠ phát hiện SQL injection, đăng nhập bất thường, rò rỉ dữ liệu |
⚠ Các cảnh báo tiêu biểu: | Cảnh báo | Nội dung | |---|---| | ⚠ Potential SQL injection | | | ⚠ Đăng nhập từ vị trí bất thường | | | ⚠ Đăng nhập từ ứng dụng lạ | | | ⚠ Brute force credentials | | | ⚠ Trích xuất dữ liệu bất thường | |
Vì sao các phương án khác sai
-
C (Defender for Containers cho triển khai SQL trong container) — ⚠ đề nói rõ là Azure SQL DATABASE, một dịch vụ PaaS chứ không phải container.
-
D (Defender for App Service) — ⚠ bảo vệ ứng dụng web, không phải CSDL.
-
B (workflow automation cho quy trình DevOps) — ⚠ workflow automation là để phản ứng CẢNH BÁO, không phải tự động hoá DevOps.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #23853 ở lô này liệt kê "bật Defender cho Azure SQL Database" là một việc làm được với Defender for Cloud. ⚠ Hai câu nhất quán.
⚠ Bảo vệ Azure SQL Database — nhiều lớp: | Lớp | Biện pháp | |---|---| | ⚠ Mạng | ⚠ firewall, private endpoint, tắt public access | | ⚠ Xác thực | ⚠ Entra ID, managed identity | | ⚠ Uỷ quyền | ⚠ quyền tối thiểu, row-level security | | ⚠ Mã hoá | ⚠ TDE, TLS, Always Encrypted | | ⚠ Che dữ liệu | ⚠ Dynamic Data Masking | | ⚠ Kiểm toán | ⚠ Auditing | | ⚠ Phát hiện đe doạ | ⚠ Defender for SQL |
Từ khoá nhận diện:
"phát hiện SQL injection và đe doạ" → ⚠ Defender for SQL "quét cấu hình CSDL so với chuẩn" → ⚠ Vulnerability Assessment, thuộc Defender for SQL "ghi lại ai truy vấn gì" → ⚠ Auditing "mã hoá khi lưu" → ⚠ TDE
| ⚠ Defender for SQL phủ những gì | Phủ |
|---|---|
| ⚠ Azure SQL Database | |
| ⚠ Azure SQL Managed Instance | |
| ⚠ SQL Server trên VM Azure | |
| ⚠ SQL Server tại chỗ qua Azure Arc | |
| ⚠ Azure Synapse Analytics |
| ⚠ Vì sao đáng bật | Lý do |
|---|---|
| ⚠ Là lớp phòng thủ CUỐI CÙNG | ⚠ khi mọi lớp trước đã bị vượt qua |
| ⚠ Phát hiện SQL injection ngay tại CSDL | ⚠ kể cả khi WAF bỏ lọt |
| ⚠ Quét cấu hình tự động, có khuyến nghị cụ thể | |
| ⚠ Chi phí thấp so với giá trị |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Defender for SQL đã bật cho mọi CSDL chưa | | | Có khuyến nghị nào từ vulnerability assessment chưa xử lý không | | | Cảnh báo SQL có tới đúng người không | |
Và lý do Defender for SQL đáng bật dù đã có WAF: nó nhìn thấy truy vấn thật sự chạm tới CSDL. WAF chặn ở tầng web và có thể bỏ lọt; lớp ở CSDL là nơi cuối cùng còn cơ hội phát hiện.
You are asked to set up a monitoring solution for security events in your Azure environment. You decide to leverage Azure Monitor and Microsoft Sentinel. Which of the following actions would you take for a holistic monitoring solution?
-
A
Use Azure Monitor to collect data on application performance
-
B
Configure data connectors in Microsoft Sentinel to integrate various data sources
-
C
Create and customize analytics rules in Microsoft Sentinel to detect specific patterns
-
D
Modify Microsoft Defender for Cloud to integrate with Azure Monitor
-
E
Configure Data Collection
Xem giải thích
Đáp án
B, C và E.
- B — Cấu hình data connector trong Sentinel để tích hợp nhiều nguồn dữ liệu.
- C — Tạo và tuỳ chỉnh analytics rule trong Sentinel để phát hiện mẫu cụ thể.
- E — Cấu hình Data Collection.
Vì sao đúng
⚠ Ba bước dựng giải pháp giám sát bảo mật: | Bước | Nội dung | |---|---| | ⚠ Data Collection | ⚠ thu thập nhật ký và chỉ số vào Log Analytics | | ⚠ Data connectors | ⚠ đưa dữ liệu từ nhiều nguồn vào Sentinel | | ⚠ Analytics rules | ⚠ biến dữ liệu thành phát hiện và incident |
Vì sao các phương án khác sai
-
A (thu thập dữ liệu HIỆU NĂNG ứng dụng) — ⚠ giám sát vận hành, không phải giám sát bảo mật.
-
D (sửa Defender for Cloud để tích hợp Azure Monitor) — ⚠ hai dịch vụ đã tích hợp SẴN.
Ghi nhớ
⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này TRÙNG NỘI DUNG với câu #23851 trong CÙNG lô.
| Câu | Đề bài | Phương án | Khoá |
|---|---|---|---|
| ⚠ #23851 | ⚠ giống hệt, có thêm "(Select three)" | ⚠ cùng năm phương án | ⚠ B, C, E |
| ⚠ #23873 (câu này) | ⚠ giống hệt, KHÔNG có "(Select three)" | ⚠ cùng năm phương án | ⚠ B, C, E |
| ⚠ Khác biệt duy nhất | ⚠ dòng chữ "(Select three)" ở cuối đề bài | ||
| ⚠ Vì thế hash MD5 KHÔNG bắt được | ⚠ chỉ đọc mới nhận ra | ||
| ⚠ Không mâu thuẫn | ⚠ giữ nguyên cả hai khoá |
⚠ Bốn thành phần của Microsoft Sentinel: | Thành phần | Vai trò | |---|---| | ⚠ Data connectors | ⚠ hơn 100 nguồn dựng sẵn | | ⚠ Analytics rules | ⚠ sinh incident từ dữ liệu | | ⚠ Workbooks | ⚠ bảng điều khiển | | ⚠ Playbooks | ⚠ tự động phản ứng trên Logic Apps | | ⚠ Hunting queries | ⚠ chủ động săn tìm |
Từ khoá nhận diện:
"đưa dữ liệu vào Sentinel" → ⚠ data connector "phát hiện mẫu tấn công" → ⚠ analytics rule "tự động phản ứng" → ⚠ playbook "giám sát hiệu năng ứng dụng" → ⚠ Application Insights, KHÔNG phải bảo mật
| ⚠ Cân nhắc chi phí Sentinel | Cân nhắc |
|---|---|
| ⚠ Tính theo GB nhập vào | |
| ⚠ Chọn nguồn theo giá trị phát hiện | |
| ⚠ Basic logs cho nguồn ít giá trị điều tra | |
| ⚠ Commitment tier để giảm giá |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguồn nào thực sự sinh ra phát hiện có ích | | | Có playbook cho sự cố thường gặp chưa | | | Ai xử lý incident hằng ngày | |
Và bài học rút ra từ chính cặp câu trùng này: khác biệt giữa hai câu chỉ là ba chữ trong ngoặc. Khi làm bài, luôn đọc hết đề — kể cả phần tưởng như chỉ là hướng dẫn định dạng.
You are tasked with ensuring that your organization's Azure resources are compliant with company standards.
Using Azure services, which tool would allow you to evaluate the configuration settings of Azure resources against defined requirements?
-
A
Azure Policy
-
B
Azure Blueprint
-
C
Azure Landing Zone
-
D
Azure Key Vault
Xem giải thích
Đáp án
A — Azure Policy
Vì sao đúng
Azure Policy làm đúng hai việc mà đề nêu: đánh giá tài nguyên hiện có xem có tuân thủ chuẩn của công ty không, và áp đặt chuẩn đó lên tài nguyên tạo mới bằng cách từ chối những gì vi phạm.
Bảng tuân thủ của nó cho biết tỷ lệ tài nguyên đạt chuẩn theo từng chính sách, nên bạn đo được tiến độ thay vì chỉ phỏng đoán.
Vì sao các phương án khác sai
- B. Azure Blueprint — gói nhiều thứ lại thành một khuôn triển khai (bao gồm cả policy, vai RBAC, ARM template). Nó dùng để dựng môi trường mới đúng chuẩn, chứ không phải công cụ đánh giá mức tuân thủ.
- C. Azure Landing Zone — là kiến trúc tham chiếu, không phải một dịch vụ.
- D. Azure Key Vault — lưu bí mật và khoá.