Lộ trình
Microsoft AzureCơ bảnTuần 1: Nền tảngBài 1 / 30

Ngày 1: Nhập môn Cloud & Azure

Thời lượng: 45 phút
Mục tiêu: 2 nhiệm vụ chính
Tiến độ lộ trình
az-900ngày 1
hoàn thành1 / 30 bài
Bối cảnh bài học

Xây mental model Azure từ nhu cầu workload đến subscription, region, resource group và shared responsibility.

đọc hiểuthực hànhcheckpoint
Bài giảng hôm nay

Học hiểu, rồi mới thực hành

Xây mental model Azure từ nhu cầu workload đến subscription, region, resource group và shared responsibility.

Bắt đầu đọc bài giảng

Nhiệm vụ bài học hôm nay

  • Đăng ký tài khoản Azure Free
  • Làm quen giao diện Azure Portal
Instructor walkthrough

Bài giảng chi tiết: từ bài toán đến bằng chứng

Scenario xuyên suốt

Một team muốn đưa ứng dụng bán hàng lên Azure nhưng đang trộn lẫn region với availability zone, resource group với subscription và nghĩ cloud provider chịu toàn bộ security. Bài học tạo nền tảng để đọc các bài AZ-900 sau mà không học service rời rạc.

01Đọc bài toán

Xác định actor, workload, constraint và trạng thái cuối cần đạt.

02Vẽ luồng / boundary

Chỉ ra request, dependency, identity và failure domain trước khi chọn công cụ.

03Chọn và thực hành

Thay đổi nhỏ nhất trong lab cô lập; command nào cũng phải nói rõ nó kiểm tra điều gì.

04Kiểm chứng / recovery

Đối chiếu trạng thái thực tế, tạo một failure variant và ghi cách hoàn tác.

Cách nối lý thuyết với thực tế
  • Cloud là mô hình cung cấp compute, storage, network và managed capability theo nhu cầu; elasticity và consumption model ảnh hưởng cost.
  • Region là geographic area; availability zone là failure domain trong region có hỗ trợ; region pair/sovereignty có thể ảnh hưởng DR và compliance.
  • Management group → subscription → resource group → resource là hierarchy quản trị; resource group là lifecycle boundary, không phải security boundary duy nhất.
  • Microsoft quản lý phần physical cloud; customer vẫn chịu identity, data, configuration và phần workload theo service model.

Bài toán mở đầu

Một team cần chạy web bán hàng ở Azure. Traffic thay đổi theo chiến dịch, dữ liệu khách hàng phải ở khu vực phù hợp, sandbox không được ảnh hưởng production và finance cần dự báo hóa đơn. Trước khi chọn App Service, VM hay database, hãy mô hình hóa workload, ownership, governance và cost boundary.

1. Azure cloud model

Cloud không chỉ là “máy chủ ở nơi khác”. Điểm cần nhận diện là provisioning theo nhu cầu, elasticity, managed abstraction và consumption-based pricing. IaaS cho nhiều quyền kiểm soát hơn nhưng kéo theo OS/network patching; PaaS giảm vận hành hạ tầng nhưng customer vẫn chịu code, identity, data và cấu hình; SaaS chuyển thêm responsibility sang provider nhưng vẫn cần quản lý người dùng và dữ liệu.

2. Geography và failure domain

Region là khu vực địa lý chứa một hoặc nhiều datacenter. Availability zone là failure domain độc lập trong một số region, dùng để giảm ảnh hưởng lỗi datacenter. Region pair có thể hỗ trợ kế hoạch continuity nhưng không tự tạo DR; phải kiểm tra service support, replication, RTO/RPO, data residency và cost.

Đừng chọn region chỉ vì gần người dùng. Hãy ghi decision record: latency, compliance, service availability, capacity/quota, resilience và giá.

3. Hierarchy và governance

Mô hình quản trị phổ biến: Management group → Subscription → Resource group → Resource. Subscription là boundary billing/access quan trọng. Resource group gom resource có lifecycle/ownership liên quan; xóa resource group có thể xóa resource bên trong, nên phải kiểm tra trước khi thao tác. RBAC có thể đặt ở nhiều scope và kế thừa; Azure Policy kiểm soát resource có được phép tạo/configure theo rule; lock giảm nguy cơ xóa hoặc sửa ngoài ý muốn; tag hỗ trợ ownership/cost allocation nhưng không phải security control.

4. Shared responsibility bằng ví dụ

Với VM, customer thường quản lý guest OS, patching, identity, firewall rules, application và data. Với App Service, Azure quản lý nhiều phần platform nhưng customer vẫn chịu code, auth, secrets, network integration và data. Với Azure SQL, managed database giảm operational work nhưng schema, access, backup/retention requirement và data classification vẫn cần thiết kế.

Bài tập thiết kế

Vẽ hai subscription prodsandbox; trong mỗi subscription đặt resource group theo lifecycle. Đánh dấu scope của RBAC, Policy, lock, tag và budget. Viết ba lý do không nên dùng một subscription duy nhất cho mọi workload. Sau đó tạo responsibility matrix cho VM/App Service/Azure SQL.

Checkpoint

Bạn đạt bài khi có thể giải thích một lựa chọn bằng requirement và failure/governance concern, không chỉ đọc lại định nghĩa. Hãy giữ decision record này để nối sang các bài về compute, storage, networking, identity và cost management.

Terminal reference

Command list và cách dùng

Chạy từng lệnh theo đúng thứ tự. Trước các lệnh có thể tạo hoặc thay đổi tài nguyên, hãy kiểm tra profile, account và region.

Commands · read-only checkpoints
az account show --output table
az account list --output table
az group list --output table
Hands-on lab

Thực hành theo scenario

  1. Vẽ hierarchy management group → subscription → resource group → resource cho một công ty có production và sandbox.
  2. Tạo decision table cho một workload cần latency thấp, data residency và khả năng chịu lỗi; chọn region/zone ở mức khái niệm và ghi assumption.
  3. Trong Azure portal, chỉ mở subscription/resource group/region metadata ở chế độ read-only; không tạo resource nếu chưa kiểm tra trial credit, budget và cleanup.
  4. Viết responsibility matrix cho VM, App Service và Azure SQL: Microsoft làm gì, customer cấu hình gì.
Evidence checkpoint

Kiểm chứng kết quả

Không coi lệnh chạy thành công là đủ. Hãy đối chiếu output với trạng thái mong đợi:

  • Giải thích được khác nhau giữa region, availability zone, region pair và geography.
  • Đặt đúng resource vào subscription/resource group theo lifecycle và ownership.
  • Phân biệt identity/RBAC/Policy/lock và biết mỗi control giải quyết vấn đề gì.
  • Đọc được một scenario và nêu assumption trước khi chọn Azure service hoặc region.
  • Không có credential/secret thật trong ghi chú lab; biết kiểm tra subscription và budget trước thao tác có thể tính phí.
Transfer to exam / production

Bẫy thường gặp và trade-off

AZ-900 thường đưa distractor đúng tên nhưng sai scope: resource group không thay RBAC, region không đồng nghĩa zone, và managed service không xóa trách nhiệm cấu hình của customer.

Checkpoint · 3 phút

Kiểm tra nhanh

Câu hỏi: Một team muốn hạn chế loại VM được tạo trong subscription và bắt buộc mọi resource có tag costCenter. Control nào phù hợp nhất?

Kết thúc bài

Checklist trước khi sang Ngày 2