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

Đáp án

A — IaaS.

Vì sao đúng

⚠ IaaS cho môi trường gần giống nhất với trung tâm dữ liệu hiện có: | Tại chỗ | Trên IaaS | |---|---| | ⚠ Máy chủ vật lý | ⚠ máy ảo | | ⚠ Mạng LAN, VLAN | ⚠ Virtual Network, subnet | | ⚠ Tường lửa | ⚠ NSG, Azure Firewall | | ⚠ Đĩa lưu trữ | ⚠ Managed Disks | | ⚠ Kết quả | ⚠ ứng dụng chạy gần như KHÔNG phải sửa mã |

⚠ Đây là mô hình "lift and shift" — bê nguyên trạng lên, chưa tối ưu gì.

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

• D (PaaS) — ⚠ thường phải SỬA ứng dụng: bỏ phụ thuộc vào hệ điều hành, đổi cách lưu file, đổi cách quản lý phiên.

• B (FaaS) và C (Serverless) — ⚠ đòi VIẾT LẠI ứng dụng thành các hàm nhỏ chạy theo sự kiện; xa nhất so với ứng dụng cũ.

Ghi nhớ

⚠ Năm chiến lược di chuyển lên đám mây — "5 R": | Chiến lược | Nội dung | |---|---| | ⚠ Rehost | ⚠ lift and shift, sang IaaS, nhanh nhất | | ⚠ Refactor | ⚠ chỉnh nhẹ để dùng PaaS | | ⚠ Rearchitect | ⚠ thiết kế lại, ví dụ sang microservices | | ⚠ Rebuild | ⚠ viết lại từ đầu trên nền đám mây | | ⚠ Replace | ⚠ bỏ hẳn, mua SaaS thay thế |

⚠ Rehost   →  ⚠ nhanh, rẻ trước mắt, ÍT lợi ích đám mây
⚠ Rebuild  →  ⚠ chậm, đắt trước mắt, NHIỀU lợi ích đám mây

Từ khoá nhận diện:

"chuyển nguyên trạng, nhanh nhất" → ⚠ IaaS, rehost "chỉnh nhẹ để tận dụng dịch vụ quản lý" → ⚠ PaaS, refactor "viết lại thành hàm nhỏ" → ⚠ serverless, rebuild "đánh giá và lập kế hoạch di chuyển" → ⚠ Azure Migrate

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã được chỉnh đúng cỡ trước khi chuyển chưa | ⚠ đừng bê nguyên cấu hình cũ | | Có thành phần nào chuyển thẳng sang PaaS được không | ⚠ CSDL là ứng viên rõ nhất | | Có kế hoạch tối ưu sau khi chuyển không | |

Và lý do rehost vẫn là lựa chọn hợp lý để bắt đầu: nó rút ngắn thời gian rời khỏi trung tâm dữ liệu cũ. Nhưng nếu dừng lại ở đó, bạn chỉ đổi nơi đặt máy chứ chưa thu được lợi ích nào của đám mây.

Đáp án

B — Danh sách các tiêu chuẩn Microsoft tuân theo, kết quả kiểm thử xâm nhập, đánh giá bảo mật, sách trắng, câu hỏi thường gặp và các tài liệu chứng minh nỗ lực tuân thủ của Microsoft.

Vì sao đúng

⚠ Service Trust Portal là THƯ VIỆN TÀI LIỆU về phía Microsoft: | Tài liệu | Nội dung | |---|---| | ⚠ Báo cáo kiểm toán | ⚠ SOC 1, SOC 2, SOC 3, ISO/IEC 27001 | | ⚠ Kết quả kiểm thử xâm nhập | ⚠ do bên thứ ba thực hiện | | ⚠ Sách trắng và hướng dẫn triển khai | | | ⚠ Tài liệu theo ngành và theo khu vực | ⚠ GDPR, HIPAA, FedRAMP | | ⚠ Câu hỏi thường gặp về tuân thủ | |

⚠ Dùng khi kiểm toán viên hoặc khách hàng hỏi: ⚠ "Microsoft có chứng nhận gì, bằng chứng đâu?"

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

• C (công cụ giúp quản lý mức tuân thủ của bạn) — ⚠ đó là Purview Compliance Manager.

• A (khuyến nghị cụ thể về cách bạn dùng Azure) — ⚠ đó là Azure Advisor.

• D (tài liệu về từng dịch vụ Azure) — ⚠ đó là Microsoft Learn / Azure Docs.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22090 ở lô trước hỏi công cụ nào theo dõi mức tuân thủ của TỔ CHỨC BẠN (đáp án Compliance Manager, và Service Trust Portal là phương án nhiễu). ⚠ Câu này hỏi ngược lại. Hai câu bổ sung nhau, giữ nguyên cả hai khoá.

⚠ Bốn thứ về tuân thủ — phân biệt bằng câu hỏi chúng trả lời: | Thứ | Trả lời | |---|---| | ⚠ Service Trust Portal | ⚠ MICROSOFT có chứng nhận gì | | ⚠ Compliance Manager | ⚠ TÔI đang tuân thủ tới đâ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:

"tải báo cáo kiểm toán của Microsoft" → ⚠ Service Trust Portal "điểm tuân thủ của tổ chức tôi" → ⚠ Compliance Manager "khuyến nghị tối ưu tài nguyên" → ⚠ Advisor "phân loại và dán nhãn dữ liệu" → ⚠ Purview Information Protection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngành của bạn đòi chứng nhận nào | ⚠ tải đúng tài liệu đó về | | Phần tuân thủ nào thuộc trách nhiệm của bạn | | | Đã dùng Compliance Manager để theo dõi phần đó chưa | |

Và hiểu nhầm tốn kém nhất về tuân thủ trên đám mây: tưởng rằng dùng một nền tảng đã đạt ISO 27001 thì hệ thống của mình cũng tự đạt. Chứng nhận của Microsoft chỉ phủ phần Microsoft chịu trách nhiệm.

Đáp án

C — Bạn phải nộp đơn và được chọn thì mới dùng được dịch vụ đó.

Vì sao đúng

⚠ Private Preview là vòng thử nghiệm khép kín: | Đặc điểm | Nội dung | |---|---| | ⚠ Chỉ khách hàng được chọn | ⚠ qua biểu mẫu đăng ký hoặc lời mời | | ⚠ Phải bật riêng cho subscription | ⚠ không thấy trong Portal nếu chưa được bật | | ⚠ Số lượng hạn chế | | | ⚠ Không SLA, không hỗ trợ chính thức | | | ⚠ Có thể đổi hoặc bị bỏ hẳn | |

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

• A (ai cũng dùng được nhưng không được dùng cho sản xuất) — ⚠ mô tả PUBLIC Preview.

• D (đã sẵn sàng chung, có hỗ trợ của Microsoft) — ⚠ mô tả GA.

• B (ai cũng dùng được vào mục đích gì cũng được) — ⚠ không đúng với bất kỳ giai đoạn nào.

Ghi nhớ

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

⚠ Cùng với #22096 (ba giai đoạn là gì) và #22175 (GA có hỗ trợ đầy đủ), đây là bốn câu về vòng đời dịch vụ trong hai lô gần nhau.

⚠ Ba giai đoạn — bảng so sánh gọn: | Giai đoạn | Ai vào được | SLA | Sản xuất | |---|---|---|---| | ⚠ Private Preview | ⚠ được mời | ⚠ không | ⚠ không | | ⚠ Public Preview | ⚠ ai cũng bật được | ⚠ không | ⚠ không | | ⚠ GA | ⚠ mọi khách hàng | ⚠ có | ⚠ có |

Từ khoá nhận diện:

"phải nộp đơn, được chọn" → ⚠ Private Preview "ai cũng bật được, chưa có SLA" → ⚠ Public Preview "có SLA, có hỗ trợ đầy đủ" → ⚠ GA "sắp ngừng" → ⚠ retirement, báo trước thường 12 tháng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính năng đang dùng ở giai đoạn nào | | | Có tính năng Preview nào trong đường dẫn quan trọng không | | | Có phương án dự phòng nếu tính năng bị bỏ không | |

Và ranh giới cần nhớ khi đọc mọi tài liệu Azure: chữ "(Preview)" bên cạnh tên tính năng là một cảnh báo, không phải một nhãn quảng cáo. Nó có nghĩa là không có SLA và mọi thứ đều có thể đổi.

Đáp án

C — Cung cấp dịch vụ Azure đáp ứng các quy định cụ thể của chính phủ và yêu cầu về nơi lưu trữ dữ liệu.

Vì sao đúng

⚠ Sovereign region — vùng chủ quyền — sinh ra vì lý do PHÁP LÝ, không phải hiệu năng: | Mục đích | Nội dung | |---|---| | ⚠ Đáp ứng quy định của một quốc gia | ⚠ luật về dữ liệu công dân, dữ liệu nhà nước | | ⚠ Dữ liệu ở lại trong biên giới | ⚠ data residency | | ⚠ Vận hành tách biệt | ⚠ nhân sự, hạ tầng, đôi khi cả pháp nhân | | ⚠ Chứng nhận riêng cho khu vực đó | |

⚠ Ví dụ: | Đám mây chủ quyền | Phục vụ | |---|---| | ⚠ Azure Government | ⚠ khu vực công của Mỹ | | ⚠ Azure China 21Vianet | ⚠ khách hàng tại Trung Quốc, do đối tác vận hành | | ⚠ Microsoft Cloud for Sovereignty | ⚠ khung cho các chính phủ khác |

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

• A (giảm độ trễ cho ứng dụng toàn cầu) — ⚠ đó là mục đích của việc có NHIỀU VÙNG thông thường, không phải vùng chủ quyền.

• B (dịch vụ miễn phí cho trường học và tổ chức phi lợi nhuận) — ⚠ là chương trình tài trợ riêng.

• D (dịch vụ giá thấp cho doanh nghiệp vừa và nhỏ) — ⚠ không tồn tại.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22134 trong lô này hỏi cơ quan chính phủ Mỹ nên đăng ký gì (đáp án Azure Government). ⚠ Câu này hỏi khái niệm tổng quát đứng sau. Hai câu bổ sung nhau.

⚠ Ba khái niệm chủ quyền dữ liệu — hay bị gộp: | Khái niệm | Nghĩa | |---|---| | ⚠ Data residency | ⚠ dữ liệu nằm ở đâu về địa lý | | ⚠ Data sovereignty | ⚠ luật của nước nào áp lên dữ liệu đó | | ⚠ Data privacy | ⚠ quy tắc xử lý dữ liệu cá nhân | | ⚠ Điểm mấu chốt | ⚠ dữ liệu ở trong nước KHÔNG tự động nghĩa là chỉ luật nước đó áp dụng |

Từ khoá nhận diện:

"đáp ứng quy định chính phủ, dữ liệu ở trong nước" → ⚠ sovereign region "giảm độ trễ cho người dùng" → ⚠ chọn vùng gần người dùng "chịu được mất cả một vùng" → ⚠ region pair, đa vùng "khoá không cho triển khai ngoài vùng cho phép" → ⚠ Azure Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy định cụ thể yêu cầu điều gì | ⚠ đọc điều luật, đừng đoán | | Chọn vùng trong nước đã đủ chưa | | | Dịch vụ cần dùng có ở đám mây chủ quyền đó không | |

Và câu hỏi nên đặt trước khi chọn đám mây chủ quyền: yêu cầu thật sự là "dữ liệu ở trong nước" hay "vận hành tách biệt hoàn toàn"? Vế đầu chỉ cần chọn đúng vùng; vế sau mới cần một đám mây riêng, với toàn bộ hạn chế đi kèm.

Đáp án

B — JSON.

Vì sao đúng

⚠ ARM template là tệp JSON mô tả tài nguyên cần triển khai: | Phần của template | Nội dung | |---|---| | ⚠ $schema | ⚠ phiên bản lược đồ | | ⚠ parameters | ⚠ giá trị truyền vào lúc triển khai | | ⚠ variables | ⚠ giá trị tính sẵn dùng lại | | ⚠ resources | ⚠ danh sách tài nguyên cần tạo | | ⚠ outputs | ⚠ giá trị trả về sau khi triển khai |

⚠ Template mô tả TRẠNG THÁI MONG MUỐN
        ↓
⚠ Azure Resource Manager so với thực tế
        ↓
⚠ Tạo hoặc sửa cho khớp — chạy lại nhiều lần vẫn an toàn

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

• A (YAML) — ⚠ YAML dùng cho Azure Pipelines và Kubernetes, không phải ARM template.

• C (XML) và D (HTML) — ⚠ không dùng cho ARM template.

Ghi nhớ

⚠ Bicep — ngôn ngữ thay thế, dễ đọc hơn nhiều: | Đặc điểm | Nội dung | |---|---| | ⚠ Cú pháp gọn, ít ngoặc | ⚠ ngắn hơn JSON đáng kể | | ⚠ Biên dịch RA ARM template JSON | ⚠ Azure vẫn chỉ hiểu JSON | | ⚠ Tự suy ra thứ tự phụ thuộc | | | ⚠ Có mô-đun tái sử dụng | | | ⚠ Microsoft khuyến nghị | ⚠ viết mới thì dùng Bicep |

Từ khoá nhận diện:

"ARM template" → ⚠ JSON "gọn hơn, biên dịch ra ARM" → ⚠ Bicep "đa đám mây, có state file" → ⚠ Terraform "pipeline CI/CD của Azure DevOps" → ⚠ YAML

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Môi trường sản xuất dựng bằng mã hay bằng tay | | | Template có nằm trong Git không | | | Có bí mật nào bị nhúng thẳng vào template không | ⚠ phải tham chiếu Key Vault |

Và lỗi hay gặp nhất khi mới viết template: nhúng thẳng mật khẩu vào tệp rồi đưa lên Git. Template nên tham chiếu Key Vault cho mọi giá trị nhạy cảm, không bao giờ chứa chúng.

Đáp án

D — Azure Advisor.

Vì sao đúng

⚠ Advisor phân tích cách bạn ĐANG dùng Azure rồi đưa khuyến nghị cụ thể: | Trụ cột | Ví dụ | |---|---| | ⚠ Cost | ⚠ máy ảo dùng dưới công suất, nên mua reservation | | ⚠ Security | ⚠ thiếu MFA, cổng quản trị mở | | ⚠ Reliability | ⚠ chưa có sao lưu, chưa dư thừa | | ⚠ Operational excellence | ⚠ thiếu thẻ, thiếu cảnh báo | | ⚠ Performance | ⚠ SKU quá nhỏ, thiếu chỉ mục |

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

• B (Azure Monitor) — ⚠ thu thập chỉ số và nhật ký, không tự đưa khuyến nghị cải thiện.

• C (Azure Service Health) — ⚠ báo sự cố của nền tảng.

• A (Azure Dashboard) — ⚠ chỉ hiển thị.

Ghi nhớ

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

⚠ Đây là lô có mật độ câu gần trùng cao bất thường — cùng với các cặp về Private Preview, MFA, Availability Set và Cosmos DB.

⚠ Phân biệt bốn công cụ hay bị lẫn: | Công cụ | Trả lời | |---|---| | ⚠ Advisor | ⚠ tôi nên cải thiện gì | | ⚠ Monitor | ⚠ hệ thống đang chạy thế nào | | ⚠ Service Health | ⚠ Azure có đang trục trặc không | | ⚠ Defender for Cloud | ⚠ tư thế bảo mật của tôi ra sao |

Từ khoá nhận diện:

"khuyến nghị dựa trên cách dùng thật" → ⚠ Advisor "chỉ số, nhật ký, cảnh báo" → ⚠ Monitor "sự cố nền tảng" → ⚠ Service Health "secure score" → ⚠ Defender for Cloud

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có khuyến nghị bảo mật mức cao nào chưa xử lý không | | | Advisor ước tính tiết kiệm được bao nhiêu mỗi tháng | | | Ai chịu trách nhiệm rà soát danh sách này | |

Và điểm mạnh khiến Advisor đáng mở hằng tuần: nó đã xếp sẵn việc cần làm theo mức tác động, dựa trên dữ liệu thật của hệ thống bạn — thứ mà một buổi rà soát thủ công phải mất nhiều ngày mới dựng lại được.

Đáp án

A và D — Mã đã đóng gói, và cấu hình.

Vì sao đúng

⚠ Với App Service, bạn chỉ giao hai thứ: | Thành phần | Nội dung | |---|---| | ⚠ Mã đã đóng gói | ⚠ zip, WAR, JAR, container image, hoặc đẩy từ Git | | ⚠ Cấu hình | ⚠ app settings, chuỗi kết nối, biến môi trường, phiên bản runtime |

⚠ Bạn đưa:  ⚠ mã  +  ⚠ cấu hình
⚠ Azure lo: ⚠ máy chủ, hệ điều hành, runtime, vá lỗi, co giãn, cân bằng tải

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

• B (quản lý cập nhật hệ điều hành) — ⚠ là việc của MICROSOFT; nếu bạn phải làm thì đó đã là IaaS.

• C (kịch bản CSDL) — ⚠ CSDL là dịch vụ RIÊNG, không nằm trong gói triển khai App Service.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22125 ở lô trước hỏi vì sao App Service là PaaS (đáp án: bạn giao mã và cấu hình, không chạm phần cứng). ⚠ Câu này hỏi chính hai thành phần đó. Hai câu nhất quán.

⚠ Các cách triển khai lên App Service: | Cách | Nội dung | |---|---| | ⚠ Zip deploy | ⚠ đẩy gói nén lên | | ⚠ Git hoặc GitHub Actions | ⚠ đẩy mã, tự build và triển khai | | ⚠ Azure DevOps Pipelines | | | ⚠ Container image | ⚠ từ Azure Container Registry hoặc Docker Hub | | ⚠ FTPS | ⚠ cách cũ, không khuyến nghị |

Từ khoá nhận diện:

"mã và cấu hình" → ⚠ App Service, PaaS "triển khai vào staging rồi hoán đổi" → ⚠ deployment slots "cấu hình tập trung, feature flag" → ⚠ Azure App Configuration "bí mật" → ⚠ Key Vault, tham chiếu từ app settings

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bí mật có nằm trong app settings dạng rõ không | ⚠ nên tham chiếu Key Vault | | Đã dùng deployment slot chưa | | | Cấu hình có bị hoán đổi nhầm khi swap không | ⚠ đánh dấu slot setting |

Và điều làm nên khác biệt giữa một lần triển khai êm ả và một sự cố: deployment slot. Có nó thì việc quay lui là một thao tác hoán đổi vài giây, không có thì phải triển khai lại từ đầu trong lúc hệ thống đang lỗi.

Đáp án

B — Bạn cần tránh các điểm hỏng đơn lẻ.

Vì sao đúng

⚠ Sẵn sàng cao là bài toán về DƯ THỪA, không phải về công suất: | Điểm hỏng đơn lẻ | Cách gỡ | |---|---| | ⚠ Một máy ảo | ⚠ nhiều máy qua nhiều vùng sẵn sàng | | ⚠ Một CSDL | ⚠ replica, geo-replication | | ⚠ Một trung tâm dữ liệu | ⚠ Availability Zones | | ⚠ Một vùng | ⚠ triển khai đa vùng | | ⚠ Một đường mạng | ⚠ ExpressRoute kèm VPN dự phòng |

⚠ Một máy chủ rất mạnh vẫn chỉ là MỘT máy chủ — nó hỏng thì cả hệ thống ngừng.

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

• A (máy chủ phải có nhiều RAM và nhiều CPU) — ⚠ giải bài toán HIỆU NĂNG, không phải sẵn sàng cao.

• C (công suất phải vượt số người dùng đồng thời cao nhất) — ⚠ cũng là bài toán công suất.

• D (có một bản dự phòng chờ sẵn, khởi động khi bản chính hỏng) — ⚠ là mô hình cold standby, tốt hơn không có nhưng vẫn có thời gian ngừng trong lúc khởi động và chuyển đổi.

Ghi nhớ

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

⚠ Ba mô hình dự phòng — theo thời gian ngừng: | Mô hình | Thời gian ngừng | Chi phí | |---|---|---| | ⚠ Cold standby | ⚠ lâu — phải khởi động | ⚠ thấp | | ⚠ Warm standby | ⚠ ngắn — đã chạy sẵn quy mô nhỏ | ⚠ trung bình | | ⚠ Hot / active-active | ⚠ gần như không | ⚠ cao |

Từ khoá nhận diện:

"không có điểm hỏng đơn lẻ" → ⚠ sẵn sàng cao "máy mạnh hơn, nhiều RAM hơn" → ⚠ hiệu năng, KHÔNG phải sẵn sàng cao "khôi phục sau thảm hoạ cả vùng" → ⚠ disaster recovery "hỏng mà không gián đoạn chút nào" → ⚠ fault tolerance

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thành phần nào chỉ có MỘT không | | | Đã từng thử tắt một thành phần chưa | | | RTO và RPO đã được thống nhất chưa | |

Và điều dễ nhầm nhất giữa hai bài toán: máy mạnh hơn giúp phục vụ nhiều người hơn, chứ không giúp hệ thống sống sót khi máy đó hỏng. Hiệu năng và độ sẵn sàng là hai trục hoàn toàn khác nhau.

Đáp án

A — Trust Center.

Vì sao đúng

⚠ Microsoft Trust Center là nơi công bố cam kết và chứng nhận: | Nội dung | Chi tiết | |---|---| | ⚠ Danh sách tiêu chuẩn tuân thủ | ⚠ ISO/IEC 27001, SOC, FedRAMP, GDPR, HIPAA... | | ⚠ Cam kết về quyền riêng tư | | | ⚠ Cam kết về bảo mật | | | ⚠ Thông tin về nơi lưu dữ liệu | | | ⚠ Đường dẫn tới Service Trust Portal | ⚠ để tải tài liệu chi tiết |

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

• C (Azure Security Center, nay là Defender for Cloud) — ⚠ đánh giá tư thế bảo mật của TÀI NGUYÊN BẠN, không nói về chứng nhận của Microsoft.

• D (Azure Service Health) — ⚠ báo sự cố nền tảng.

• B (trang quyền riêng tư của Azure) — ⚠ chỉ nói về xử lý dữ liệu cá nhân, hẹp hơn nhiều.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này CHỒNG LẤN với câu #22181 trong CÙNG lô, và ranh giới giữa hai đáp án là rất mỏng.

⚠ Bốn địa chỉ về tuân thủ — phân biệt: | Nơi | Trả lời | |---|---| | ⚠ Trust Center | ⚠ Microsoft cam kết và đạt chuẩn gì | | ⚠ Service Trust Portal | ⚠ bằng chứng ở đâu, tải về thế nào | | ⚠ Compliance Manager | ⚠ TỔ CHỨC TÔI tuân thủ tới đâu | | ⚠ Azure Policy | ⚠ buộc tài nguyên tuân theo quy tắc |

Từ khoá nhận diện:

"Microsoft đạt chuẩn nào" → ⚠ Trust Center "tải báo cáo kiểm toán" → ⚠ Service Trust Portal "điểm tuân thủ của tôi" → ⚠ Compliance Manager "tư thế bảo mật tài nguyên của tôi" → ⚠ Defender for Cloud

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ngành của bạn đòi chứng nhận nào | | | Tài liệu cần có phải đăng nhập và ký NDA không | | | Phần tuân thủ nào vẫn thuộc trách nhiệm của bạn | |

Và ranh giới không được quên khi trích dẫn chứng nhận của Microsoft: chúng phủ nền tảng, không phủ hệ thống bạn dựng trên nền tảng đó. Kiểm toán viên sẽ hỏi tiếp về phần của bạn.

Đáp án

A — Cung cấp giải pháp quản lý danh tính tập trung cho môi trường lai

Vì sao đúng

Entra ID là dịch vụ danh tính: quản lý người dùng, nhóm, thiết bị và ứng dụng, cùng các chính sách xác thực đi kèm. Từ khoá "lai" cũng quan trọng — qua Entra Connect, danh tính từ Active Directory tại chỗ được đồng bộ lên, nên nhân viên dùng một bộ thông tin đăng nhập duy nhất cho cả hệ thống nội bộ lẫn dịch vụ đám mây.

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

Ba phương án còn lại thuộc về ba lĩnh vực khác hẳn:

• B. Lưu và phân tích dữ liệu có cấu trúc — Azure SQL hoặc Synapse.
• C. Tự động triển khai máy ảo bằng hạ tầng dạng mã — ARM template, Bicep hoặc Terraform.
• D. Theo dõi hiệu năng tài nguyên theo thời gian thực — Azure Monitor.