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

Đáp án

B — Reserved instance cho mức giá ưu đãi khi cam kết dài hạn, còn pay-as-you-go thì linh hoạt

Vì sao đúng

Đây là đánh đổi cơ bản giữa hai mô hình:

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

• C. Pay-as-you-go phải trả trước, reserved thì trả sau — đảo ngược hoàn toàn: reserved mới là mô hình có thể trả trước.
• D. Reserved cho hiệu năng cao hơn — sai: cùng một loại máy, cùng hiệu năng; chỉ khác cách tính tiền.
• A. Pay-as-you-go chỉ có ở đám mây công cộng — không đúng.

Đáp án

A — Xác minh tường minh và áp quyền tối thiểu cho mọi người dùng lẫn thiết bị

Vì sao đúng

Zero Trust dựa trên ba nguyên tắc, và phương án này gộp hai nguyên tắc quan trọng nhất:

• Xác minh tường minh — mỗi lần truy cập đều phải chứng minh lại, dựa trên danh tính, thiết bị, vị trí và mức rủi ro. Không có "đã vào rồi thì tin luôn".
• Quyền tối thiểu — cấp đúng mức cần, trong đúng khoảng thời gian cần.
• (Nguyên tắc thứ ba: giả định đã bị xâm nhập — thiết kế sao cho một điểm bị chiếm không lan ra toàn hệ thống.)

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

• B. Tin mọi người và thiết bị khi đã ở trong vành đai mạng — chính là mô hình cũ mà Zero Trust ra đời để thay thế. Vấn đề của nó: kẻ tấn công vào được một máy là đi lại tự do bên trong.
• C. Chỉ dựa vào tường lửa mạng — cùng lối tư duy vành đai.
• D. Cho truy cập không giới hạn sau khi đã xác thực — bỏ hẳn nguyên tắc quyền tối thiểu.

Đáp án

B — Chuyển hệ thống nguyên trạng lên đám mây (lift-and-shift)

Vì sao đúng

Lift-and-shift là trường hợp điển hình nhất của IaaS, vì máy ảo trên đám mây là thứ gần nhất với máy chủ vật lý tại chỗ: cùng hệ điều hành, cùng phần mềm, cùng cấu hình. Ứng dụng gần như không phải sửa gì, nên rủi ro và thời gian di chuyển đều thấp nhất.

Đây thường là bước đầu — chuyển lên trước cho ổn định, hiện đại hoá sau.

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

• C. Muốn giảm gánh nặng vận hành — ngược hẳn: IaaS là mô hình tốn công vận hành nhất, vì bạn vẫn phải vá hệ điều hành và cấu hình mọi thứ. Muốn giảm thì chọn PaaS.
• D. Phát triển ứng dụng hoàn toàn mới — với dự án mới thì PaaS hoặc serverless hợp hơn, vì không có ràng buộc kế thừa nào.
• A. Muốn chạy ứng dụng miễn phí — IaaS không có bậc miễn phí đáng kể.

Đáp án

A — Phân loại và tổ chức tài nguyên để quản lý tốt hơn

Vì sao đúng

Tag là cặp tên–giá trị gắn vào tài nguyên, và ứng dụng quan trọng nhất trong thực tế là quy chi phí: gắn CostCenter hay Department rồi cắt hoá đơn theo tag đó để biết bộ phận nào tiêu bao nhiêu.

Hai điều cần nhớ khi dùng:

• Giá trị tag phân biệt hoa thường (tên tag thì không), nên Production và production ra hai nhóm chi phí khác nhau.
• Tag không tự kế thừa từ resource group xuống tài nguyên bên trong; muốn vậy phải dùng Azure Policy.

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

• C. Gán quyền bảo mật — đó là RBAC; không phân quyền theo tag được.
• B. Tự động cấp phát tài nguyên — đó là ARM template hoặc Bicep.
• D. Theo dõi hiệu năng — đó là Azure Monitor.

Đáp án

A — Virtual Machine (máy ảo)

Vì sao đúng

Máy ảo nằm ở đầu linh hoạt nhất của thang trừu tượng: bạn chọn hệ điều hành, cài phần mềm tuỳ ý, cấu hình mạng và đĩa, và kiểm soát mọi thứ từ tầng hệ điều hành trở lên.

Đây là lựa chọn bắt buộc khi ứng dụng cần phần mềm đặc thù, cấu hình hệ điều hành riêng, hoặc đơn giản là chuyển nguyên trạng từ tại chỗ lên.

Cái giá phải trả

Càng nhiều quyền kiểm soát thì càng nhiều trách nhiệm: bạn tự vá hệ điều hành, tự cấu hình sao lưu, tự lo tính sẵn sàng cao. Đây là đánh đổi xuyên suốt mọi mô hình dịch vụ đám mây.

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

• D. Container — cho tính di động và khởi động nhanh, nhưng dùng chung nhân với máy chủ nên không kiểm soát được tầng hệ điều hành.
• B. Function và C. Serverless — nằm ở đầu kia của thang: gần như không có quyền kiểm soát nào, đổi lại là không phải vận hành gì.

Đáp án

B — Hiệu năng (performance)

Vì sao đúng

Câu này tìm thứ không thuộc chiến lược độ tin cậy. Hiệu năng là một trụ cột riêng trong khung Well-Architected — nó nói về việc hệ thống chạy nhanh tới đâu, còn độ tin cậy nói về việc hệ thống có chạy hay không.

Hai thứ này độc lập: một hệ thống có thể rất nhanh mà rất dễ sập, hoặc rất bền mà chậm.

Vì sao các phương án khác sai (chúng là thành phần của độ tin cậy)

• A. Dư thừa — nhiều bản sao ở nhiều nơi, nền của mọi thứ còn lại.
• C. Tính sẵn sàng — hệ thống truy cập được khi cần.
• D. Chịu lỗi — vẫn chạy khi một thành phần hỏng.

Đáp án

C — 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ụm, không node, không bộ điều phối. Bạn khai ảnh container cùng lượng CPU và bộ nhớ, ACI chạy nó và tính tiền theo giây. Đó chính là ý nghĩa của "serverless" áp cho container.

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

• B. AKS — chạy container rất mạnh nhưng bạn vẫn quản lý node pool; nó không phải serverless theo nghĩa này.
• A. 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.
• D. Azure Functions — đúng là serverless nhưng dựng cho hàm theo sự kiện, không phải để chạy ảnh container tuỳ ý.

Đáp án

C — Chịu lỗi (fault tolerance)

Vì sao đúng

Câu này tìm thứ không thuộc về tính đoán trước được. Trong khung Well-Architected, predictability có hai mặt và cả hai đều là chuyện biết trước điều gì sẽ xảy ra:

• Hiệu năng đoán trước được — hệ thống phản hồi ổn định, không dao động thất thường.
• Chi phí đoán trước được — hoá đơn không nhảy vọt ngoài dự kiến.

Chịu lỗi thì thuộc về độ tin cậy: nó nói về việc hệ thống vẫn chạy khi có sự cố, một câu hỏi khác hẳn.

Vì sao các phương án khác sai (chúng liên quan tới tính đoán trước được)

• A. Hiệu năng nhất quán — chính là vế đầu.
• D. Tối ưu chi phí — gắn với vế thứ hai.
• B. Khả năng co giãn — là cơ chế giữ cho hiệu năng ổn định khi tải thay đổi.

Đáp án

D — Reserved instances

Vì sao đúng

Hai đặc điểm trong đề — khối lượng công việc đoán trước được và nhu cầu dài hạn — đúng là điều kiện để reserved instance có lợi. Bạn cam kết dùng một lượng tài nguyên nhất định trong 1 hoặc 3 năm, đổi lấy mức giảm giá sâu.

Điều kiện "đoán trước được" là bắt buộc: nếu tải thay đổi bất thường hoặc hệ thống có thể bị bỏ đi giữa chừng thì bạn vẫn phải trả tiền cho phần đã cam kết.

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

• A. Pay-as-you-go — linh hoạt nhất nhưng giá đơn vị cao nhất; lãng phí với tải chạy liên tục.
• C. Spot instances — rẻ nhất nhưng bị thu hồi bất cứ lúc nào, nên chỉ hợp với công việc chịu được gián đoạn.
• B. Serverless computing — là mô hình tính toán, không phải mô hình định giá.

Đáp án

D — Áp dụng kiểm soát truy cập chi tiết dựa trên các điều kiện cụ thể

Vì sao đúng

Chữ "chi tiết" (granular) là điểm mấu chốt. Conditional Access không phải một công tắc bật tắt mà là một hệ luật kiểu "nếu... thì...", kết hợp nhiều tín hiệu:

Kết quả có thể là cho qua, đòi xác thực đa yếu tố, đòi thiết bị tuân thủ, hoặc chặn hẳn.

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

• **B. Bắt buộc xác thực đa yếu tố cho mọi người dùng — xác thực đa yếu tố là một trong các kết quả mà Conditional Access có thể yêu cầu, nhưng áp cho tất cả một cách cứng nhắc thì đã bỏ mất chữ "chi tiết".
• A. Áp chính sách mật khẩu mạnh — thuộc về chính sách mật khẩu, không phải Conditional Access.
• C. Chống tấn công lừa đảo — là hệ quả gián tiếp, không phải mục đích trực tiếp.