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

Đáp án

D — Azure SQL Database.

Vì sao đúng

⚠ Azure SQL Database là CSDL quan hệ PaaS được quản lý hoàn toàn: | Microsoft lo | Bạn lo | |---|---| | ⚠ Vá lỗi và nâng cấp | ⚠ thiết kế bảng và chỉ mục | | ⚠ Sao lưu tự động | ⚠ truy vấn và ứng dụng | | ⚠ Sẵn sàng cao | ⚠ chọn bậc hiệu năng | | ⚠ Hạ tầng và hệ điều hành | ⚠ bảo mật ở mức dữ liệu |

⚠ Bạn tạo CSDL  →  ⚠ nhận chuỗi kết nối  →  ⚠ dùng ngay
   ⚠ KHÔNG có máy chủ nào để bạn quản lý

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

• A (Azure Cosmos DB) — ⚠ CSDL NoSQL phân tán toàn cầu, không phải quan hệ SQL.

• B (Azure Blob Storage) — ⚠ lưu đối tượng phi cấu trúc, không phải CSDL.

• C (Azure Table Storage) — ⚠ kho khoá–giá trị NoSQL, không có SQL.

Ghi nhớ

⚠ Ba mức dịch vụ SQL trên Azure — đừng lẫn: | Dịch vụ | Mức quản lý | |---|---| | ⚠ SQL Server trên VM | ⚠ IaaS — bạn lo hệ điều hành và vá lỗi | | ⚠ SQL Managed Instance | ⚠ PaaS — gần như SQL Server đủ tính năng | | ⚠ Azure SQL Database | ⚠ PaaS — từng CSDL riêng, quản lý nhiều nhất |

Từ khoá nhận diện:

"quan hệ, SQL, quản lý hoàn toàn" → ⚠ Azure SQL Database "cần SQL Agent, CLR, cross-database query" → ⚠ Managed Instance "cần toàn quyền hệ điều hành" → ⚠ SQL Server trên VM "NoSQL, phân tán toàn cầu" → ⚠ Cosmos DB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có cần tính năng cấp máy chủ không | ⚠ nếu có thì phải Managed Instance | | Đã chọn đúng bậc hiệu năng chưa | ⚠ quá cao là lãng phí | | CSDL có cần chạy 24/7 không | ⚠ nếu không thì cân nhắc Serverless |

Và lý do PaaS đáng chọn khi có thể: những việc chiếm nhiều thời gian nhất của một DBA — vá lỗi, sao lưu, dựng sẵn sàng cao — đều đã được làm sẵn, để bạn tập trung vào thiết kế dữ liệu.

Đáp án

B — 1000.

Vì sao đúng

⚠ Virtual Machine Scale Set — giới hạn quy mô: | Kiểu ảnh | Số VM tối đa | |---|---| | ⚠ Ảnh nền tảng của Azure | ⚠ 1.000 | | ⚠ Ảnh tuỳ chỉnh của bạn | ⚠ 600 |

⚠ VM Scale Set
   ⚠ tạo và quản lý một NHÓM VM giống hệt nhau
   ⚠ tự thêm bớt máy theo tải
   ⚠ tối đa 1.000 máy với ảnh nền tảng

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

• A (100), C (250), D (500) — ⚠ đều thấp hơn giới hạn thật.

Ghi nhớ

⚠ Vì sao dùng Scale Set thay vì tạo từng VM: | Lợi ích | Nội dung | |---|---| | ⚠ Tự co giãn theo tải | ⚠ theo CPU, theo lịch, theo hàng đợi | | ⚠ Cấu hình một lần cho cả nhóm | | | ⚠ Tích hợp Load Balancer và Application Gateway | | | ⚠ Trải máy qua nhiều vùng sẵn sàng | | | ⚠ Cập nhật cuốn chiếu | ⚠ không gián đoạn dịch vụ |

Từ khoá nhận diện:

"nhóm VM giống hệt, tự co giãn" → ⚠ Scale Set "nhóm VM để chịu lỗi phần cứng trong một trung tâm dữ liệu" → ⚠ Availability Set "trải qua nhiều toà nhà trong một vùng" → ⚠ Availability Zone "1.000 máy" → ⚠ giới hạn Scale Set với ảnh nền tảng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật co giãn có cả mở rộng và thu hẹp chưa | ⚠ thiếu vế thu hẹp là đốt tiền | | Đã đặt số máy tối thiểu và tối đa hợp lý chưa | | | Scale Set có trải qua nhiều vùng sẵn sàng không | |

Và điều dễ quên khi đặt luật co giãn: phải có cả luật thu hẹp. Rất nhiều hệ thống chỉ đặt luật mở rộng, nên sau một đợt cao điểm thì số máy ở lại mức cao mãi mãi.

Đáp án

D — Platform as a Service (PaaS)

Vì sao đúng

Từ khoá quyết định là "không phải quản lý hệ điều hành hay máy chủ web". Đó chính là ranh giới giữa IaaS và PaaS:

Đề nói lập trình viên muốn triển khai ứng dụng tự viết, nên SaaS bị loại — SaaS là phần mềm có sẵn, không phải nơi chạy mã của bạn.

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

• A. IaaS — vẫn phải tự vá hệ điều hành và cấu hình máy chủ web.
• B. SaaS — không triển khai được ứng dụng tự viết.
• C. FaaS — là dạng đặc biệt hợp cho hàm theo sự kiện; ứng dụng web đầy đủ thì PaaS phù hợp hơn.

Đáp án

C — Lưu trữ rẻ hơn nhiều so với bậc hot.

Vì sao đúng

⚠ Bốn bậc truy cập của Blob Storage: | Bậc | Giá lưu | Giá truy cập | Dùng khi | |---|---|---|---| | ⚠ Hot | ⚠ cao nhất | ⚠ thấp nhất | ⚠ truy cập thường xuyên | | ⚠ Cool | ⚠ thấp hơn | ⚠ cao hơn | ⚠ ít nhất 30 ngày | | ⚠ Cold | ⚠ thấp hơn nữa | ⚠ cao hơn nữa | ⚠ ít nhất 90 ngày | | ⚠ Archive | ⚠ rẻ nhất | ⚠ đắt nhất, phải rã đông | ⚠ ít nhất 180 ngày |

⚠ Càng xuống bậc thấp:
   ⚠ giá LƯU giảm  ↓
   ⚠ giá ĐỌC GHI tăng  ↑

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

• A (dữ liệu truy cập thường xuyên) — ⚠ đó là bậc HOT.

• B (không truy xuất được ngay, phải rã đông) — ⚠ đó là bậc ARCHIVE; cool vẫn đọc được ngay.

• D (đắt hơn hot) — ⚠ ngược lại về phí lưu trữ.

Ghi nhớ

⚠ Nguyên tắc chọn bậc — nghĩ theo TẦN SUẤT ĐỌC: | Tần suất | Bậc | |---|---| | ⚠ Hằng ngày | ⚠ Hot | | ⚠ Vài lần mỗi tháng | ⚠ Cool | | ⚠ Vài lần mỗi quý | ⚠ Cold | | ⚠ Gần như không bao giờ, chỉ giữ để tuân thủ | ⚠ Archive |

Từ khoá nhận diện:

"lưu rẻ, đọc đắt, vẫn đọc ngay" → ⚠ Cool "rẻ nhất, phải rã đông hàng giờ" → ⚠ Archive "truy cập liên tục" → ⚠ Hot "tự chuyển bậc theo tuổi" → ⚠ Lifecycle management policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu này thực sự được đọc bao lâu một lần | ⚠ đo, đừng đoán | | Đã bật chính sách vòng đời tự chuyển bậc chưa | | | Có dữ liệu nào sắp bị xoá sớm hơn thời gian tối thiểu không | |

Và điều dễ tính nhầm nhất về bậc lưu trữ: rẻ hơn ở phí lưu không có nghĩa là tổng chi phí thấp hơn. Nếu dữ liệu vẫn bị đọc thường xuyên, phí truy cập của bậc cool có thể vượt xa phần tiết kiệm được.

Đáp án

D — Là những tài nguyên thực thi tác vụ đòi hỏi chu kỳ CPU.

Vì sao đúng

⚠ "Compute" là nhóm dịch vụ CHẠY mã, phân biệt với nhóm lưu trữ và nhóm mạng: | Nhóm | Việc | |---|---| | ⚠ Compute | ⚠ chạy mã, tiêu CPU | | ⚠ Storage | ⚠ giữ dữ liệu | | ⚠ Networking | ⚠ nối các thứ lại |

⚠ Tài nguyên điện toán trên Azure gồm nhiều thứ, không chỉ VM: | Dịch vụ | Kiểu | |---|---| | ⚠ Virtual Machines | ⚠ máy ảo | | ⚠ Virtual Machine Scale Sets | ⚠ nhóm máy ảo tự co giãn | | ⚠ App Service | ⚠ web app quản lý sẵn | | ⚠ Azure Functions | ⚠ hàm không máy chủ | | ⚠ Container Instances, AKS | ⚠ vùng chứa | | ⚠ Azure Batch | ⚠ tính toán theo lô quy mô lớn |

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

• A (chỉ là máy ảo) — ⚠ QUÁ HẸP; Functions và App Service cũng là compute.

• B (gồm VM, tài khoản lưu trữ và mạng ảo) — ⚠ TRỘN cả ba nhóm lại; storage và network không phải compute.

• C (mọi thứ trong Azure Marketplace) — ⚠ Marketplace là nơi bán, không phải một loại tài nguyên.

Ghi nhớ

Từ khoá nhận diện:

"chạy mã, tiêu CPU" → ⚠ compute "giữ file, blob, đĩa" → ⚠ storage "VNet, subnet, load balancer" → ⚠ networking "nơi tìm giải pháp của bên thứ ba" → ⚠ Marketplace

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Workload chạy liên tục hay ngắt quãng | ⚠ quyết định chọn VM hay Functions | | Có cần toàn quyền hệ điều hành không | | | Đang trả tiền cho VM nào bật mà không dùng không | |

Và điều đáng nhớ: "compute" là một họ dịch vụ chứ không phải một sản phẩm. Chọn đúng bậc trong họ đó là quyết định ảnh hưởng nhiều nhất tới cả chi phí lẫn công sức vận hành.

Đáp án

C — Network Security Group (NSG).

Vì sao đúng

⚠ NSG là bộ lọc gói cơ bản, gắn ở mức SUBNET hoặc CARD MẠNG: | Đặc điểm | Nội dung | |---|---| | ⚠ Danh sách luật vào và ra | ⚠ inbound và outbound | | ⚠ Mỗi luật gồm | ⚠ nguồn, đích, cổng, giao thức, cho phép hay chặn | | ⚠ Xét theo độ ưu tiên | ⚠ số nhỏ xét trước | | ⚠ MIỄN PHÍ | | | ⚠ Gắn được vào subnet, card mạng, hoặc cả hai | |

⚠ Gói tin vào subnet
        ↓
⚠ NSG của subnet xét luật
        ↓
⚠ NSG của card mạng xét luật
        ↓
⚠ Tới VM

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

• B (Azure Firewall) — ⚠ dịch vụ tường lửa QUẢN LÝ ở mức mạng ảo, mạnh hơn nhiều nhưng TỐN PHÍ và không phải "cơ bản, theo subnet".

• A (DDoS Standard) — ⚠ chống tấn công từ chối dịch vụ, không lọc luật vào ra.

• D (Application Gateway kèm WAF) — ⚠ cân bằng tải tầng 7 và lọc tấn công web, không phải bộ lọc subnet cơ bản.

Ghi nhớ

Từ khoá nhận diện:

"cơ bản, theo subnet, miễn phí" → ⚠ NSG "tường lửa trung tâm, lọc theo FQDN, có threat intelligence" → ⚠ Azure Firewall "chống SQL injection, XSS cho web" → ⚠ WAF "chống tấn công lưu lượng lớn" → ⚠ DDoS Protection

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có NSG nào mở RDP hoặc SSH ra Internet không | ⚠ kiểm tra trước tiên | | Subnet và card mạng có NSG chồng nhau không | | | Luật chiều ra có chặn nhầm gì không | |

Và điều gây nhầm nhất khi gỡ lỗi mạng Azure: gói tin có thể bị chặn ở hai nơi. Khi thấy kết nối không thông, phải xem cả NSG của subnet lẫn NSG của card mạng, chứ không chỉ một chỗ.

Đáp án

D — Tính sẵn sàng cao và khả năng chịu lỗi

Vì sao đúng

Đề nêu đích danh vấn đề: giảm rủi ro gián đoạn do hỏng phần cứng. Đó là định nghĩa của tính chịu lỗi — hệ thống vẫn chạy khi một thành phần hỏng.

Trên đám mây, điều này có được nhờ hạ tầng dư thừa sẵn có: đĩa được nhân bản nhiều bản, máy trải qua nhiều fault domain, và availability zone tách biệt về nguồn điện lẫn mạng. Một máy chủ vật lý hỏng thì khối lượng công việc được chuyển sang máy khác.

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

• B. Elasticity — nói về việc co giãn theo tải, không phải về chịu lỗi.
• A. Chuyển từ CapEx sang OpEx — lợi ích tài chính, không liên quan tới thời gian dừng.
• C. Triển khai nhanh — lợi ích về tốc độ đưa sản phẩm ra thị trường.

Đáp án

A — SLA khác nhau theo từng dịch vụ, có thể bao gồm cam kết về thời gian hoạt động, hiệu năng và kết nối.

Vì sao đúng

⚠ Mỗi dịch vụ Azure có SLA RIÊNG: | Dịch vụ | SLA tiêu biểu | |---|---| | ⚠ VM đơn có đĩa premium SSD | ⚠ 99,9% | | ⚠ VM trong Availability Set | ⚠ 99,95% | | ⚠ VM trải qua nhiều Availability Zone | ⚠ 99,99% | | ⚠ Azure SQL Database | ⚠ 99,99% | | ⚠ Cosmos DB nhiều vùng | ⚠ 99,999% cho đọc | | ⚠ Dịch vụ bậc Free hoặc Preview | ⚠ KHÔNG có SLA |

⚠ SLA phụ thuộc:
   ⚠ dịch vụ nào
   ⚠ bậc nào
   ⚠ bạn triển khai ra sao

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

• C (mọi dịch vụ đều 99,9%) — ⚠ SAI; con số khác nhau rất nhiều.

• D (100% cho mọi dịch vụ) — ⚠ KHÔNG nhà cung cấp nào cam kết 100%.

• B (không cần quan tâm SLA) — ⚠ NGUY HIỂM; cách bạn triển khai quyết định SLA nhận được.

Ghi nhớ

⚠ SLA của hệ thống nhiều thành phần là TÍCH các SLA thành phần: | Thành phần | SLA | |---|---| | ⚠ App Service | ⚠ 99,95% | | ⚠ SQL Database | ⚠ 99,99% | | ⚠ Nhân lại | ⚠ ≈ 99,94% — THẤP hơn thành phần yếu nhất | | ⚠ Bài học | ⚠ thêm phụ thuộc là hạ SLA tổng |

Từ khoá nhận diện:

"SLA khác nhau tuỳ dịch vụ" → ⚠ đúng "dịch vụ Preview" → ⚠ không có SLA "muốn SLA cao hơn" → ⚠ triển khai dư thừa, nhiều vùng sẵn sàng "vi phạm SLA" → ⚠ được hoàn tín dụng, PHẢI tự yêu cầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tính SLA tổng hợp của cả chuỗi phụ thuộc | ⚠ nhân lại, đừng lấy số cao nhất | | Có thành phần nào đang ở bậc không có SLA không | | | Cách triển khai hiện tại đạt được bậc SLA nào | |

Và điều hay bị hiểu sai nhất về SLA: nó là cam kết của Microsoft về hạ tầng, không phải cam kết rằng ứng dụng của bạn sẽ luôn chạy. Kiến trúc dư thừa là việc của bạn.

Đáp án

B — Tôi chịu trách nhiệm bảo vệ khoá truy cập.

Vì sao đúng

⚠ Mô hình trách nhiệm chung — dữ liệu và định danh LUÔN là của khách hàng: | Luôn thuộc về bạn | Nội dung | |---|---| | ⚠ Dữ liệu | | | ⚠ Định danh và tài khoản | | | ⚠ Thiết bị đầu cuối | | | ⚠ Quản lý quyền truy cập | ⚠ bao gồm khoá và bí mật |

⚠ Luôn thuộc về Microsoft: | Phần | Nội dung | |---|---| | ⚠ Trung tâm dữ liệu vật lý | | | ⚠ Máy chủ và mạng vật lý | |

⚠ Microsoft cấp cho bạn khoá
        ↓
⚠ Bạn quyết định ai được cầm, cất ở đâu, xoay vòng khi nào
        ↓
⚠ Khoá lộ ra ngoài  →  ⚠ trách nhiệm của bạn

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

• A (Azure chịu trách nhiệm) — ⚠ SAI; Microsoft bảo vệ hạ tầng sinh ra khoá, nhưng KHÔNG quản lý được việc bạn dán khoá vào mã nguồn.

Ghi nhớ

⚠ Cách bảo vệ khoá Storage Account — theo thứ tự tốt dần: | Cách | Mức | |---|---| | ⚠ Dán khoá vào mã nguồn | ⚠ TỆ NHẤT — đừng bao giờ | | ⚠ Đặt trong biến môi trường | ⚠ khá hơn chút | | ⚠ Cất trong Azure Key Vault | ⚠ tốt | | ⚠ Dùng SAS token có hạn, phạm vi hẹp | ⚠ tốt hơn | | ⚠ Dùng Entra ID và Managed Identity | ⚠ TỐT NHẤT — không có khoá nào để lộ |

Từ khoá nhận diện:

"dữ liệu, định danh, khoá" → ⚠ trách nhiệm khách hàng ở MỌI mô hình "trung tâm dữ liệu vật lý" → ⚠ trách nhiệm Microsoft ở mọi mô hình "hệ điều hành" → ⚠ IaaS là bạn, PaaS và SaaS là Microsoft "không có khoá nào để lộ" → ⚠ Managed Identity

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá có nằm trong kho mã nguồn không | ⚠ quét lịch sử git, không chỉ bản mới nhất | | Đã bao lâu chưa xoay khoá | | | Có dùng được Managed Identity thay khoá không | |

Và nguyên tắc gọn nhất của mô hình trách nhiệm chung: càng lên bậc dịch vụ cao, Microsoft lo càng nhiều — nhưng dữ liệu và định danh thì không bao giờ chuyển giao.

Đáp án

C — Azure Portal.

Vì sao đúng

⚠ Azure Portal là bảng điều khiển web chính thức: | Đặc điểm | Nội dung | |---|---| | ⚠ Chạy trên trình duyệt | ⚠ portal.azure.com | | ⚠ Tạo, sửa, xoá mọi tài nguyên | | | ⚠ Bảng điều khiển tuỳ biến được | | | ⚠ Có Cloud Shell nhúng sẵn | ⚠ chạy CLI và PowerShell ngay trong trình duyệt | | ⚠ Không cần cài gì | |

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

• A (PowerShell) — ⚠ giao diện DÒNG LỆNH, không phải đồ hoạ.

• B (Azure Storage Explorer) — ⚠ có giao diện đồ hoạ nhưng CHỈ cho lưu trữ, không quản lý mọi tài nguyên.

• D (RDP) — ⚠ giao thức để nối vào máy tính từ xa, không quản lý tài nguyên Azure.

Ghi nhớ

⚠ Bốn cách quản lý Azure — hỏi rất nhiều: | Công cụ | Kiểu | |---|---| | ⚠ Azure Portal | ⚠ đồ hoạ, trình duyệt | | ⚠ Azure CLI | ⚠ dòng lệnh, cú pháp az, đa nền tảng | | ⚠ Azure PowerShell | ⚠ dòng lệnh, cmdlet kiểu động từ–danh từ | | ⚠ Cloud Shell | ⚠ CLI và PowerShell chạy trong trình duyệt | | ⚠ ARM template và Bicep | ⚠ khai báo hạ tầng bằng mã | | ⚠ REST API và SDK | ⚠ cho lập trình |

Từ khoá nhận diện:

"đồ hoạ, trình duyệt, không cài gì" → ⚠ Portal "kịch bản lặp lại được" → ⚠ CLI hoặc PowerShell "hạ tầng dưới dạng mã, khai báo trạng thái mong muốn" → ⚠ ARM template hoặc Bicep "chạy dòng lệnh mà không cài lên máy" → ⚠ Cloud Shell

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cấu hình này có cần lặp lại nhiều lần không | ⚠ nếu có thì viết mã, đừng bấm tay | | Ai đang có quyền vào Portal | | | Có ghi lại thay đổi ở đâu không | ⚠ Activity Log |

Và lời khuyên thực tế về Portal: dùng để học và để xem, nhưng đừng dựng môi trường sản xuất bằng cách bấm chuột. Thứ bấm tay không lặp lại được và không ai xem lại được.