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

Tìm thấy 501 câu.

Câu 31 Monitoring and reporting

Which Azure service centralizes telemetry and log data from multiple resources so you can run queries, visualize results, and create alerts on events?

  1. A

    Microsoft Defender for Cloud
  2. B Storage Account or Event Hub
  3. C Azure Portal Dashboard
  4. D Azure Monitor
Xem giải thích

Đáp án

D — Azure Monitor.

Vì sao đúng

⚠ Azure Monitor là nền tảng quan sát tập trung của Azure: | Thành phần | Việc | |---|---| | ⚠ Metrics | ⚠ số liệu theo thời gian, độ trễ thấp | | ⚠ Logs — Log Analytics | ⚠ nhật ký, truy vấn bằng KQL | | ⚠ Alerts | ⚠ cảnh báo khi vượt ngưỡng | | ⚠ Workbooks và Dashboards | ⚠ trực quan hoá | | ⚠ Application Insights | ⚠ giám sát ứng dụng, APM |

⚠ Tài nguyên Azure, VM, ứng dụng, tại chỗ
        ↓ ⚠ gửi metric và log
⚠ Azure Monitor
        ↓
⚠ Truy vấn KQL  →  ⚠ biểu đồ  →  ⚠ cảnh báo  →  ⚠ hành động tự động

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

  • A (Defender for Cloud) — ⚠ lo tư thế BẢO MẬT và khuyến nghị, dùng dữ liệu của Monitor chứ không phải nơi gom telemetry.

  • B (Storage Account hoặc Event Hub) — ⚠ là ĐÍCH ĐẾN của nhật ký chẩn đoán, không có truy vấn hay cảnh báo.

  • C (Azure Portal Dashboard) — ⚠ chỉ là nơi HIỂN THỊ, không thu thập cũng không cảnh báo.

Ghi nhớ

⚠ Ba đích đến của nhật ký chẩn đoán — chọn theo mục đích: | Đích | Dùng khi | |---|---| | ⚠ Log Analytics workspace | ⚠ muốn truy vấn và cảnh báo | | ⚠ Storage Account | ⚠ lưu lâu dài, giá rẻ, tuân thủ | | ⚠ Event Hub | ⚠ đẩy sang hệ thống bên ngoài, SIEM |

Từ khoá nhận diện:

"gom log, truy vấn, cảnh báo" → ⚠ Azure Monitor "KQL" → ⚠ Log Analytics "giám sát mã ứng dụng, dấu vết yêu cầu" → ⚠ Application Insights "khuyến nghị bảo mật, secure score" → ⚠ Defender for Cloud "SIEM, điều tra sự cố an ninh" → ⚠ Microsoft Sentinel

⚠ Metrics và Logs khác nhau thế nào Khác
⚠ Metrics ⚠ số, đều đặn, giữ 93 ngày, truy vấn nhanh
⚠ Logs ⚠ bản ghi có cấu trúc, giữ tuỳ cấu hình, truy vấn mạnh
⚠ Cảnh báo tức thời ⚠ nên dựa trên metric
⚠ Điều tra nguyên nhân ⚠ cần log
⚠ Ba loại cảnh báo Loại
⚠ Metric alert ⚠ CPU vượt 80%
⚠ Log alert ⚠ truy vấn KQL trả về kết quả
⚠ Activity log alert ⚠ có người xoá tài nguyên
⚠ Gắn với ⚠ Action Group — email, SMS, webhook, Logic App

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên quan trọng đã bật diagnostic settings chưa | ⚠ KHÔNG bật mặc định | | Cảnh báo có tới đúng người đang trực không | | | Chi phí nhập log có đang tăng bất thường không | ⚠ tính theo GB |

Và điều dễ bị bỏ qua nhất: Azure không tự gửi nhật ký chẩn đoán đi đâu cả. Phải bật diagnostic settings cho từng tài nguyên, nếu không thì đến lúc cần điều tra sự cố sẽ chẳng có dữ liệu nào.

Câu 32 Core Azure solutions

Azure Logic Apps and Azure Functions are examples of which compute model in Azure?

  1. A SaaS model
  2. B App Services Model
  3. C Serverless model
  4. D IaaS model
Xem giải thích

Đáp án

C — Mô hình serverless (không máy chủ).

Vì sao đúng

⚠ Serverless không có nghĩa là không có máy chủ, mà là BẠN không quản lý máy chủ: | Đặc điểm | Nội dung | |---|---| | ⚠ Không cấp phát hạ tầng | | | ⚠ Tự co giãn từ 0 tới rất nhiều | | | ⚠ Trả tiền theo lượt thực thi | ⚠ không dùng thì không trả | | ⚠ Chạy theo sự kiện | ⚠ HTTP, hàng đợi, hẹn giờ, blob mới |

Dịch vụ Vai trò
⚠ Azure Functions ⚠ chạy MÃ theo sự kiện
⚠ Azure Logic Apps ⚠ ghép QUY TRÌNH bằng giao diện kéo thả, hơn 1.000 connector
⚠ Event Grid ⚠ định tuyến sự kiện
⚠ Service Bus ⚠ hàng đợi tin nhắn

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

  • A (SaaS) — ⚠ là phần mềm dùng sẵn như Microsoft 365, không phải nơi bạn chạy mã.

  • B (App Services) — ⚠ App Service là PaaS, và bạn vẫn phải chọn App Service Plan có kích cỡ.

  • D (IaaS) — ⚠ là máy ảo và mạng, ngược hẳn với serverless.

Ghi nhớ

⚠ Functions và Logic Apps — chọn cái nào: | Tiêu chí | Chọn | |---|---| | ⚠ Cần viết mã tuỳ ý | ⚠ Functions | | ⚠ Cần nối nhiều dịch vụ SaaS sẵn | ⚠ Logic Apps | | ⚠ Người không lập trình cũng dựng được | ⚠ Logic Apps | | ⚠ Xử lý dữ liệu phức tạp, hiệu năng cao | ⚠ Functions |

Từ khoá nhận diện:

"trả tiền theo lượt gọi, tự co giãn về 0" → ⚠ serverless "kéo thả, connector, không cần viết mã" → ⚠ Logic Apps "hàm chạy theo trigger" → ⚠ Functions "vẫn phải chọn cỡ máy" → ⚠ KHÔNG phải serverless

⚠ Điểm yếu của serverless Điểm yếu
⚠ Khởi động nguội ⚠ lần gọi đầu sau khi nghỉ chậm hơn
⚠ Giới hạn thời gian chạy ⚠ bậc tiêu thụ mặc định 5 phút, tối đa 10
⚠ Khó gỡ lỗi phân tán
⚠ Tải rất đều và rất cao ⚠ có thể ĐẮT hơn VM
⚠ Ba bậc chạy của Azure Functions Bậc
⚠ Consumption ⚠ serverless thật, trả theo lượt gọi
⚠ Premium ⚠ có instance ấm sẵn, hết khởi động nguội
⚠ Dedicated (App Service Plan) ⚠ chạy trên plan có sẵn, không còn serverless

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tải có ngắt quãng không | ⚠ đều và cao thì serverless chưa chắc rẻ | | Hàm có chạy quá thời gian giới hạn không | | | Khởi động nguội có ảnh hưởng người dùng không | |

Và điều quan trọng nhất khi cân nhắc serverless: lợi ích lớn nhất không phải là giá, mà là không phải vận hành máy chủ. Với tải rất đều, một VM đặt trước có thể rẻ hơn nhiều.

Câu 33 IaaS PaaS and SaaS

Which cloud service model is a virtual machine (VM) most directly an example of?

  1. A

    Platform as a Service (PaaS)
  2. B

    Infrastructure as a Service (IaaS)
  3. C

    Software as a Service (SaaS)
Xem giải thích

Đáp án

B — Infrastructure as a Service (IaaS).

Vì sao đúng

⚠ Máy ảo là ví dụ kinh điển nhất của IaaS: | Nhà cung cấp lo | Bạn lo | |---|---| | ⚠ Trung tâm dữ liệu | ⚠ hệ điều hành | | ⚠ Phần cứng vật lý | ⚠ vá lỗi và cập nhật | | ⚠ Lớp ảo hoá | ⚠ phần mềm cài lên máy | | ⚠ Mạng vật lý | ⚠ cấu hình và bảo mật ở mức máy | | | ⚠ dữ liệu và ứng dụng |

⚠ Bạn thuê một MÁY, không thuê một dịch vụ
   ⚠ toàn quyền, và toàn bộ trách nhiệm đi kèm

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

  • A (PaaS) — ⚠ nền tảng chạy ứng dụng, KHÔNG lộ hệ điều hành ra, ví dụ App Service, Azure SQL Database.

  • C (SaaS) — ⚠ phần mềm dùng ngay, ví dụ Microsoft 365, không có gì để bạn cài đặt.

Ghi nhớ

⚠ Ba mô hình dịch vụ — nhớ bằng ví dụ: | Mô hình | Ví dụ Azure | Bạn quản lý | |---|---|---| | ⚠ IaaS | ⚠ Virtual Machines | ⚠ hệ điều hành trở lên | | ⚠ PaaS | ⚠ App Service, Azure SQL Database | ⚠ ứng dụng và dữ liệu | | ⚠ SaaS | ⚠ Microsoft 365 | ⚠ chỉ dữ liệu và người dùng |

Từ khoá nhận diện:

"toàn quyền hệ điều hành" → ⚠ IaaS "chỉ đẩy mã lên, không thấy máy chủ" → ⚠ PaaS "đăng nhập là dùng ngay" → ⚠ SaaS "chuyển nguyên trạng lên đám mây" → ⚠ IaaS, lift and shift

⚠ Khi nào IaaS là lựa chọn đúng Khi nào
⚠ Chuyển hệ thống cũ lên nguyên trạng ⚠ lift and shift
⚠ Phần mềm đòi hỏi cấu hình hệ điều hành đặc thù
⚠ Cần cài driver hoặc agent riêng
⚠ Kiểm soát chi tiết mạng và bảo mật
⚠ Cái giá của IaaS Cái giá
⚠ Bạn vá lỗi hệ điều hành
⚠ Bạn dựng sẵn sàng cao
⚠ Bạn lo sao lưu
⚠ Trả tiền cả khi máy rảnh ⚠ tính theo giờ máy bật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có thật sự cần quyền hệ điều hành không | ⚠ nếu không thì PaaS ít việc hơn hẳn | | Máy có bật ngoài giờ làm việc không | ⚠ hẹn giờ tắt để tiết kiệm | | Ai chịu trách nhiệm vá lỗi máy này | |

Và câu hỏi nên đặt trước khi tạo một máy ảo: có dịch vụ PaaS nào làm được việc này không? Chọn IaaS là nhận thêm toàn bộ gánh nặng vận hành, nên chỉ chọn khi thực sự cần quyền kiểm soát đó.

Câu 34 Secure Azure Networking

Which of the following best describes a Distributed Denial of Service (DDoS) attack?

  1. A An attempt to guess a user's password through brute force methods
  2. B An attempt to read the contents of a web page from another website, thereby stealing the user's private information
  3. C An attempt to send SQL commands to the server in a way that it will execute them against the database
  4. D A denial of service attack that sends so much traffic to a network that it cannot respond fast enough; legitimate users become unable to use the service
Xem giải thích

Đáp án

D — Tấn công từ chối dịch vụ gửi lượng lớn lưu lượng khiến mạng không đáp ứng kịp, người dùng thật không dùng được dịch vụ.

Vì sao đúng

⚠ DDoS — Distributed Denial of Service: | Yếu tố | Nội dung | |---|---| | ⚠ Denial of Service | ⚠ làm dịch vụ ngừng phục vụ | | ⚠ Distributed | ⚠ từ RẤT NHIỀU nguồn cùng lúc | | ⚠ Thường dùng botnet | ⚠ hàng nghìn máy bị chiếm quyền | | ⚠ Mục tiêu | ⚠ làm cạn băng thông, kết nối, hoặc CPU |

⚠ Hàng nghìn máy khắp thế giới
        ↓ ⚠ cùng gửi yêu cầu
⚠ Máy chủ nạn nhân quá tải
        ↓
⚠ Người dùng THẬT không vào được

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

  • A (dò mật khẩu bằng vét cạn) — ⚠ là brute force attack.

  • B (đọc nội dung trang khác để lấy thông tin) — ⚠ mô tả cross-site scripting hoặc CSRF.

  • C (gửi lệnh SQL để máy chủ thực thi) — ⚠ là SQL injection.

Ghi nhớ

⚠ Ba tầng tấn công DDoS: | Tầng | Ví dụ | |---|---| | ⚠ Volumetric — cạn băng thông | ⚠ UDP flood, DNS amplification | | ⚠ Protocol — cạn tài nguyên kết nối | ⚠ SYN flood | | ⚠ Application — tầng 7 | ⚠ HTTP flood, tốn ít lưu lượng mà rất hiệu quả |

⚠ Hai bậc DDoS Protection của Azure: | Bậc | Nội dung | |---|---| | ⚠ Infrastructure Protection | ⚠ MIỄN PHÍ, bật sẵn cho mọi khách hàng, bảo vệ nền tảng | | ⚠ Network Protection (trước là Standard) | ⚠ TRẢ PHÍ, điều chỉnh theo lưu lượng của bạn, có báo cáo, có đội hỗ trợ, có bảo vệ chi phí |

Từ khoá nhận diện:

"nhiều nguồn, làm quá tải" → ⚠ DDoS "dò mật khẩu" → ⚠ brute force "chèn lệnh vào truy vấn" → ⚠ SQL injection "chạy script trong trình duyệt nạn nhân" → ⚠ XSS

⚠ Bảo vệ tầng 7 cần thêm gì Cần
⚠ DDoS Protection lo tầng 3 và 4
⚠ Tầng 7 cần Web Application Firewall ⚠ trên Application Gateway hoặc Front Door
⚠ Hai thứ ⚠ BỔ SUNG cho nhau, không thay thế nhau
⚠ Điểm hấp dẫn của bậc trả phí Điểm
⚠ Cost protection ⚠ hoàn tín dụng cho phần co giãn do bị tấn công
⚠ Đội ứng cứu nhanh
⚠ Báo cáo và nhật ký giảm nhẹ chi tiết
⚠ Vì ⚠ tự co giãn khi bị tấn công có thể sinh hoá đơn rất lớn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng công khai đã có WAF chưa | | | Có cảnh báo khi lưu lượng tăng đột biến không | | | Có giới hạn trần co giãn không | ⚠ để tấn công không biến thành hoá đơn |

Và điểm hay bị bỏ sót nhất khi nghĩ về DDoS trên đám mây: thiệt hại có thể không phải là sập dịch vụ mà là hoá đơn. Hệ thống tự co giãn sẽ ngoan ngoãn mở rộng để phục vụ chính cuộc tấn công.

Câu 35 Azure Identity services

Which Azure service is the primary identity and authentication platform?

  1. A

    Microsoft Entra ID (formerly Azure Active Directory)
  2. B Live Connect
  3. C Facebook Connect
  4. D Network Security Group
Xem giải thích

Đáp án

A — Microsoft Entra ID (tên cũ Azure Active Directory).

Vì sao đúng

⚠ Entra ID là nền tảng định danh của toàn bộ hệ sinh thái Microsoft đám mây: | Phục vụ | Nội dung | |---|---| | ⚠ Azure | ⚠ đăng nhập Portal, quyền RBAC | | ⚠ Microsoft 365 | ⚠ cùng một danh bạ người dùng | | ⚠ Ứng dụng bên thứ ba | ⚠ hàng nghìn ứng dụng SaaS qua SSO | | ⚠ Ứng dụng tự viết | ⚠ qua OAuth 2.0 và OpenID Connect |

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

  • B (Live Connect) và C (Facebook Connect) — ⚠ là dịch vụ đăng nhập của tài khoản cá nhân, không phải nền tảng định danh doanh nghiệp của Azure.

  • D (Network Security Group) — ⚠ lọc lưu lượng mạng, không liên quan tới định danh.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #22068 ⚠ dịch vụ nào buộc MFA và kiểm soát truy cập ứng dụng ⚠ A — Entra ID
⚠ #22084 (câu này) ⚠ nền tảng định danh và xác thực chính ⚠ A — Entra ID
⚠ Hai câu ⚠ cùng đáp án, cùng chữ cái, khác góc hỏi
⚠ Không mâu thuẫn ⚠ giữ nguyên cả hai khoá

Từ khoá nhận diện:

"định danh, xác thực, SSO, MFA" → ⚠ Entra ID "quyền trên tài nguyên Azure" → ⚠ RBAC, dựa trên định danh của Entra ID "lọc gói tin" → ⚠ NSG "tài khoản Microsoft cá nhân" → ⚠ KHÔNG phải Entra ID doanh nghiệp

⚠ Bốn bậc giấy phép Entra ID Bậc
⚠ Free ⚠ quản lý người dùng, SSO cơ bản
⚠ Microsoft 365 Apps ⚠ kèm gói M365
⚠ P1 ⚠ Conditional Access, nhóm động, tự phục vụ đặt lại mật khẩu tại chỗ
⚠ P2 ⚠ Identity Protection, PIM, đánh giá quyền truy cập
⚠ Vì sao đổi tên từ Azure AD Lý do
⚠ Entra là họ sản phẩm định danh ⚠ rộng hơn Azure
⚠ Entra ID phục vụ cả M365 và ứng dụng ngoài
⚠ Đề thi cũ vẫn ghi Azure Active Directory ⚠ hiểu là CÙNG một thứ
⚠ Trong họ Entra còn có ⚠ Entra Permissions Management, Entra Verified ID

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu tài khoản Global Administrator | ⚠ nên rất ít | | Tài khoản khẩn cấp có được loại khỏi chính sách MFA không | ⚠ để không tự khoá mình ra ngoài | | Người rời tổ chức đã bị vô hiệu hoá chưa | |

Và lý do Entra ID đứng ở trung tâm mọi câu hỏi bảo mật đám mây: khi mọi thứ truy cập qua Internet, định danh chính là biên giới bảo mật — không còn tường lửa vành đai nào để dựa vào nữa.

Câu 36 Azure costs

Which of the following Azure actions is most likely to produce the most immediate reduction in your Azure costs?

  1. A Using Azure Reserved Instances for most of your virtual machines
  2. B Changing your storage accounts from globally redundant (GRS) to locally redundant (LRS)
  3. C

    Using Azure Policy to restrict the use of expensive VM SKUs
  4. D Auto shutdown of development and QA servers over night and on weekends
Xem giải thích

Đáp án

A — Dùng Azure Reserved Instances cho phần lớn máy ảo.

Vì sao đúng

⚠ Reserved Instances (Reservations) — cam kết 1 hoặc 3 năm, đổi lấy giảm giá: | Đặc điểm | Nội dung | |---|---| | ⚠ Giảm tới 72% | ⚠ so với giá trả theo giờ | | ⚠ Áp dụng NGAY sau khi mua | ⚠ hoá đơn kỳ tới đã khác | | ⚠ Không phải đổi gì trong hệ thống | ⚠ máy vẫn chạy y nguyên | | ⚠ Tự khớp với VM đang chạy cùng cỡ, cùng vùng | | | ⚠ Áp dụng cho nhiều dịch vụ | ⚠ VM, SQL Database, Cosmos DB, App Service... |

⚠ Mua reservation
        ↓ ⚠ hiệu lực ngay
⚠ Mọi VM khớp điều kiện được tính giá ưu đãi
        ↓
⚠ Không phải sửa kiến trúc, không phải tắt gì

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

  • B (đổi GRS sang LRS) — ⚠ tiết kiệm THẬT nhưng chỉ ở phần lưu trữ, thường nhỏ hơn nhiều so với chi phí máy ảo, và giảm mức bền vững của dữ liệu.

  • C (dùng Azure Policy chặn SKU đắt) — ⚠ chỉ ngăn CHI PHÍ TƯƠNG LAI, không đụng gì tới máy đang chạy.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án D — tự động tắt máy dev và QA ban đêm và cuối tuần — cũng giảm chi phí gần như ngay lập tức và không cần cam kết dài hạn.

Phương án Điểm mạnh
⚠ A — Reserved Instances ⚠ quy mô lớn, áp cho toàn bộ VM sản xuất, giảm tới 72%
⚠ D — tắt máy ngoài giờ ⚠ có hiệu lực ngay đêm đó, không cam kết, nhưng chỉ áp cho máy KHÔNG chạy 24/7
⚠ Khoá chọn A ⚠ vì "phần lớn máy ảo" quy mô rộng hơn nhóm dev và QA
⚠ Ghi chú ⚠ trong thực tế nên làm CẢ HAI, D thường làm trước vì không tốn gì

⚠ Bốn cách giảm chi phí Azure — theo thứ tự nên làm: | Cách | Nội dung | |---|---| | ⚠ Tắt thứ không dùng | ⚠ rẻ nhất và nhanh nhất | | ⚠ Chỉnh đúng cỡ máy | ⚠ rightsizing theo khuyến nghị của Advisor | | ⚠ Mua reservation hoặc savings plan | ⚠ cho phần tải ổn định | | ⚠ Dùng Hybrid Benefit | ⚠ nếu đã có giấy phép Windows hoặc SQL Server |

Từ khoá nhận diện:

"cam kết 1 hoặc 3 năm" → ⚠ Reserved Instances "linh hoạt hơn reservation, áp theo mức chi tiêu mỗi giờ" → ⚠ Azure Savings Plan "tải chịu được gián đoạn, giảm tới 90%" → ⚠ Spot VM "đã có giấy phép tại chỗ" → ⚠ Azure Hybrid Benefit

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có VM nào chạy 24/7 mà không cần không | | | Advisor đang khuyến nghị mua reservation nào | | | Đã bật Hybrid Benefit cho VM Windows chưa | |

Và điều nên nhớ trước khi mua reservation: nó khoá bạn vào một cỡ máy ở một vùng trong nhiều năm. Hãy chỉnh đúng cỡ máy trước, rồi mới mua cam kết cho cỡ đã tối ưu.

Câu 37 Benefits of cloud services

Which of the following is an essential design principle for achieving high availability in a cloud computing environment?

  1. A

    It's impossible to create a highly available system.
  2. B

    The system must maintain 100% availability at all times.
  3. C

    The system must be designed for resilience, with no single points of failure.
  4. D

    The system must operate on a minimum of two virtual machines.
Xem giải thích

Đáp án

C — Hệ thống phải được thiết kế để chịu lỗi, không có điểm hỏng đơn lẻ.

Vì sao đúng

⚠ Single point of failure — điểm hỏng đơn lẻ — là thành phần mà nếu nó chết thì cả hệ thống chết: | Điểm hỏng đơn lẻ điển hình | Cách gỡ | |---|---| | ⚠ Một máy ảo duy nhất | ⚠ Scale Set trải nhiều vùng sẵn sàng | | ⚠ Một CSDL không sao chép | ⚠ replica, geo-replication | | ⚠ Một trung tâm dữ liệu | ⚠ Availability Zones | | ⚠ Một vùng địa lý | ⚠ triển khai đa vùng | | ⚠ Một đường mạng | ⚠ ExpressRoute kèm VPN dự phòng |

⚠ Nguyên tắc: giả định MỌI thành phần sẽ hỏng
        ↓
⚠ Thiết kế sao cho hệ thống vẫn chạy khi nó hỏng

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

  • B (phải đạt 100% mọi lúc) — ⚠ KHÔNG khả thi; không nhà cung cấp nào cam kết 100%.

  • D (tối thiểu hai máy ảo) — ⚠ QUÁ HẸP; hai máy trong cùng một tủ rack vẫn cùng chết, và nhiều dịch vụ PaaS chẳng có máy ảo nào.

  • A (không thể tạo hệ thống sẵn sàng cao) — ⚠ SAI hoàn toàn.

Ghi nhớ

⚠ Ba khái niệm hay bị gộp làm một: | Khái niệm | Nghĩa | |---|---| | ⚠ High availability | ⚠ ít thời gian chết, chịu được hỏng thành phần | | ⚠ Disaster recovery | ⚠ hồi phục sau thảm hoạ lớn, thường là chuyển vùng | | ⚠ Fault tolerance | ⚠ hỏng mà KHÔNG gián đoạn chút nào, đắt nhất |

Từ khoá nhận diện:

"không có điểm hỏng đơn lẻ" → ⚠ nguyên tắc gốc của sẵn sàng cao "hỏng cả một vùng" → ⚠ disaster recovery, region pair "RTO và RPO" → ⚠ chỉ tiêu của kế hoạch khôi phục "100% uptime" → ⚠ luôn là phương án SAI trong đề thi

⚠ RTO và RPO nghĩa là gì Nghĩa
⚠ RTO — Recovery Time Objective ⚠ chấp nhận ngừng bao lâu
⚠ RPO — Recovery Point Objective ⚠ chấp nhận mất bao nhiêu dữ liệu
⚠ Hai con số này ⚠ quyết định kiến trúc và chi phí
⚠ Đòi cả hai bằng 0 ⚠ là đòi hệ thống đắt gấp nhiều lần
⚠ Công cụ sẵn sàng cao trên Azure Công cụ
⚠ Availability Zones ⚠ trải qua nhiều toà nhà trong một vùng
⚠ Availability Sets ⚠ trải qua nhiều tủ rack trong một toà nhà
⚠ Load Balancer và Traffic Manager ⚠ phân phối lưu lượng, bỏ qua node chết
⚠ Azure Site Recovery ⚠ sao chép sang vùng khác
⚠ Region pairs ⚠ Azure không cập nhật hai vùng cặp cùng lúc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vẽ sơ đồ và tìm thành phần nào chỉ có MỘT | | | Đã thử tắt một thành phần xem hệ thống có sống không | ⚠ diễn tập, đừng chỉ tin lý thuyết | | RTO và RPO đã được thống nhất bằng văn bản chưa | |

Và cách kiểm tra thiết kế nhanh nhất: chỉ vào từng ô trong sơ đồ và hỏi "nếu cái này chết thì sao". Chỗ nào không trả lời được là một điểm hỏng đơn lẻ chưa được xử lý.

Câu 38 Azure management tools

An administrator prefers to manage Azure resources through a web-based graphical interface rather than using command-line tools.


Which tool should they use?

  1. A

    Azure Portal
  2. B

    Azure PowerShell
  3. C

    Azure Cloud Shell
  4. D

    Azure Command-Line Interface (CLI)
Xem giải thích

Đáp án

A — Azure Portal

Vì sao đúng

Azure Portal là giao diện đồ hoạ trên nền web để quản lý mọi tài nguyên Azure: tạo, cấu hình, theo dõi và xoá — tất cả bằng chuột. Nó cũng là nơi tốt nhất để khám phá dịch vụ mới, vì các tuỳ chọn được trình bày kèm giải thích.

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

  • C. Azure Cloud Shell — cũng chạy trong trình duyệt, nhưng nó là dòng lệnh (Bash hoặc PowerShell), không phải giao diện đồ hoạ. Đây là phương án nhiễu gần nhất, và điểm phân biệt nằm ở chữ "graphical" chứ không phải chữ "web-based".
  • B. Azure PowerShell và D. Azure CLI — đều là công cụ dòng lệnh, đúng thứ người quản trị này muốn tránh.
Câu 39 IaaS PaaS and SaaS

Which cloud service model best describes Microsoft Outlook as delivered through Microsoft 365 (web and desktop clients)?

  1. A

    Software as a Service (SaaS)
  2. B

    Platform as a Service (PaaS)
  3. C

    Infrastructure as a Service (IaaS)
Xem giải thích

Đáp án

A — Software as a Service (SaaS).

Vì sao đúng

⚠ Outlook trong Microsoft 365 là phần mềm dùng ngay, không cài máy chủ: | Microsoft lo | Bạn lo | |---|---| | ⚠ Hạ tầng | ⚠ dữ liệu của bạn | | ⚠ Hệ điều hành | ⚠ tài khoản người dùng | | ⚠ Máy chủ Exchange | ⚠ cấu hình chính sách trong ứng dụng | | ⚠ Bản vá và nâng cấp | | | ⚠ Sao lưu và sẵn sàng cao | |

⚠ Bạn mua giấy phép  →  ⚠ đăng nhập  →  ⚠ dùng
   ⚠ Không có gì để cài, không có gì để vá

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

  • B (PaaS) — ⚠ là nền tảng để BẠN chạy ứng dụng của mình, ví dụ App Service.

  • C (IaaS) — ⚠ là máy ảo và mạng; nếu bạn tự dựng Exchange Server trên VM thì mới là IaaS.

Ghi nhớ

⚠ Cùng một chức năng, ba mô hình khác nhau: | Cách làm | Mô hình | |---|---| | ⚠ Dùng Outlook trong Microsoft 365 | ⚠ SaaS | | ⚠ Dựng Exchange Server trên VM Azure | ⚠ IaaS | | ⚠ Viết ứng dụng gửi mail chạy trên App Service | ⚠ PaaS | | ⚠ Bài học | ⚠ mô hình phụ thuộc CÁCH triển khai, không phụ thuộc chức năng |

Từ khoá nhận diện:

"đăng nhập là dùng, không cài gì" → ⚠ SaaS "đẩy mã lên, không thấy máy chủ" → ⚠ PaaS "toàn quyền hệ điều hành" → ⚠ IaaS "Microsoft 365, Dynamics 365, Salesforce" → ⚠ SaaS

⚠ SaaS được và mất gì Điều
⚠ ĐƯỢC: ít việc vận hành nhất
⚠ ĐƯỢC: triển khai nhanh, chi phí dự đoán được ⚠ theo số giấy phép
⚠ MẤT: ít tuỳ biến nhất
⚠ MẤT: phụ thuộc nhà cung cấp ⚠ vendor lock-in
⚠ MẤT: nhà cung cấp quyết định lịch nâng cấp
⚠ Trong SaaS bạn vẫn chịu trách nhiệm gì Trách nhiệm
⚠ Dữ liệu ⚠ kể cả việc sao lưu ngoài nếu cần giữ lâu
⚠ Định danh và quyền ⚠ ai được vào, MFA
⚠ Thiết bị người dùng
⚠ Đây là ⚠ phần KHÔNG BAO GIỜ chuyển sang nhà cung cấp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu trong SaaS có được sao lưu độc lập không | ⚠ chính sách giữ của nhà cung cấp có đủ không | | Đã bật MFA cho toàn bộ người dùng chưa | | | Có bao nhiêu giấy phép đang trả tiền mà không ai dùng | |

Và cách nhận diện mô hình nhanh nhất khi làm bài: hỏi "tôi phải quản lý cái gì?" — không quản lý gì ngoài dữ liệu và người dùng thì đó là SaaS.

Câu 40 Azure management tools

Can you grant someone access to your Azure subscription without sharing your username and password (for example, by assigning them a role through Azure Active Directory/role-based access control)?

  1. A YES
  2. B NO
Xem giải thích

Đáp án

A — CÓ.

Vì sao đúng

⚠ Azure RBAC cho phép cấp quyền theo ĐỊNH DANH, không bao giờ phải chia sẻ mật khẩu: | Bước | Nội dung | |---|---| | ⚠ Người đó có tài khoản riêng | ⚠ trong Entra ID, hoặc là khách mời B2B | | ⚠ Bạn gán vai trò cho tài khoản đó | ⚠ Reader, Contributor, Owner... | | ⚠ Chọn phạm vi | ⚠ management group, subscription, resource group, hoặc một tài nguyên | | ⚠ Họ đăng nhập bằng tài khoản của chính họ | | | ⚠ Gỡ quyền bất cứ lúc nào | |

⚠ Chia sẻ mật khẩu  →  ⚠ không biết ai làm gì, không thu hồi riêng được
⚠ Gán vai trò       →  ⚠ có nhật ký, thu hồi được, giới hạn phạm vi được

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

  • B (KHÔNG) — ⚠ SAI; chia sẻ mật khẩu là điều Azure thiết kế để bạn KHÔNG phải làm.

Ghi nhớ

⚠ Bốn vai trò tích hợp cơ bản: | Vai trò | Quyền | |---|---| | ⚠ Reader | ⚠ chỉ xem | | ⚠ Contributor | ⚠ tạo và sửa mọi thứ, NHƯNG không cấp quyền cho người khác | | ⚠ Owner | ⚠ toàn quyền, kể cả cấp quyền | | ⚠ User Access Administrator | ⚠ chỉ quản lý việc cấp quyền |

Từ khoá nhận diện:

"cấp quyền mà không chia sẻ tài khoản" → ⚠ RBAC "làm được mọi thứ trừ cấp quyền" → ⚠ Contributor "quyền quản trị chỉ trong vài giờ" → ⚠ Privileged Identity Management "mời người ngoài tổ chức" → ⚠ Entra ID B2B guest

⚠ Phạm vi gán quyền — kế thừa xuống dưới Cấp
⚠ Management Group ⚠ rộng nhất
⚠ Subscription
⚠ Resource Group
⚠ Resource ⚠ hẹp nhất
⚠ Quy tắc ⚠ gán ở mức HẸP NHẤT đủ dùng
⚠ Vì sao không nên chia sẻ tài khoản Lý do
⚠ Nhật ký không cho biết ai thực sự thao tác
⚠ Người rời đi thì phải đổi mật khẩu cho tất cả
⚠ Không giới hạn được phạm vi cho từng người
⚠ MFA gắn với một thiết bị, chia sẻ là phá vỡ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài khoản dùng chung nào không | ⚠ nếu có thì thay bằng tài khoản riêng và RBAC | | Ai đang giữ vai Owner ở mức subscription | | | Quyền có được gán ở phạm vi hẹp nhất không | |

Và nguyên tắc gọn nhất khi cấp quyền trên Azure: quyền tối thiểu, phạm vi hẹp nhất, và luôn gắn với một con người cụ thể. Chia sẻ mật khẩu phá vỡ cả ba.