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

Tìm thấy 501 câu.

Câu 141 Security tools and features
What is the recommended way within Azure to store secrets such as private cryptographic keys?
  1. A Azure Advanced Threat Protection (ATP)
  2. B Within the application code
  3. C In an Azure Storage account private blob container
  4. D Azure Key Vault
Xem giải thích

Đáp án

D — Azure Key Vault.

Vì sao đúng

⚠ Key Vault là dịch vụ chuyên dụng để lưu bí mật: | Lưu được | Nội dung | |---|---| | ⚠ Keys | ⚠ khoá mã hoá — dùng được nhưng KHÔNG lấy ra được | | ⚠ Secrets | ⚠ mật khẩu, chuỗi kết nối, token | | ⚠ Certificates | ⚠ chứng chỉ TLS, tự gia hạn |

⚠ Key Vault cung cấp
   ⚠ Mã hoá khi lưu
   ⚠ Kiểm soát truy cập chi tiết
   ⚠ NHẬT KÝ mọi lần truy cập
   ⚠ Soft delete và purge protection
   ⚠ Tuỳ chọn bảo vệ bằng HSM

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

  • A (Advanced Threat Protection) — ⚠ là công cụ PHÁT HIỆN, không lưu trữ gì.

  • B (trong mã ứng dụng) — ⚠ cách tệ nhất: ⚠ mã nằm trong Git và ai cũng đọc được.

  • C (blob container riêng tư) — ⚠ thiếu mọi thứ Key Vault có: ⚠ không có nhật ký chi tiết, không có HSM, không có quản lý vòng đời khoá.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ TRÙNG NGUYÊN VĂN với câu #21523 thuộc đề Microsoft Azure Developer.

Câu Chứng chỉ Khoá
⚠ #21523 ⚠ Azure Developer ⚠ D — Key Vault
⚠ #22190 (câu này) ⚠ Azure Fundamentals ⚠ D — Key Vault
⚠ Đề bài ⚠ giống hệt từng chữ
⚠ Chữ cái đáp án đúng ⚠ TRÙNG nhau, cùng là D
⚠ Nhưng hai phương án sai ⚠ ĐỔI CHỖ — "blob riêng tư" từ A sang C, "ATP" từ C sang A
⚠ Bài học ⚠ cùng một câu ở hai chứng chỉ vẫn phải đọc lại phương án, không nhớ chữ cái

⚠ Chùm câu về quản lý bí mật đã gặp: | Câu | Hỏi gì | Khoá | |---|---|---| | ⚠ #21428 | ⚠ nhiều app khó quản quyền | ⚠ user-assigned identity | | ⚠ #21465 | ⚠ không lưu mật khẩu nào | ⚠ managed identity | | ⚠ #21513 | ⚠ Key Vault reference làm gì | ⚠ lấy secret từ vault | | ⚠ #22190 (câu này) | ⚠ nơi khuyến nghị lưu bí mật | ⚠ Key Vault |

⚠ Ba loại đối tượng trong Key Vault — phân biệt: | Loại | Lấy ra được không | |---|---| | ⚠ Key | ⚠ KHÔNG — chỉ dùng để mã hoá và ký | | ⚠ Secret | ⚠ CÓ — đọc được giá trị | | ⚠ Certificate | ⚠ có, gồm cả khoá riêng | | ⚠ Đề hỏi "khoá mật mã riêng tư" | ⚠ lưu dạng KEY để không ai lấy ra được |

Từ khoá nhận diện:

"lưu bí mật, khoá, chứng chỉ" → ⚠ Key Vault "không lưu bí mật nào" → ⚠ managed identity "cấu hình tập trung, feature flag" → ⚠ App Configuration "phát hiện tấn công" → ⚠ Defender

⚠ Hai lớp bảo vệ BẮT BUỘC cho Key Vault Lớp
⚠ Soft delete ⚠ giữ vault và secret đã xoá — nay BẬT MẶC ĐỊNH
⚠ Purge protection ⚠ không xoá vĩnh viễn được trước hạn
⚠ Vì sao quan trọng ⚠ xoá vault chứa khoá mã hoá là MẤT DỮ LIỆU VĨNH VIỄN
⚠ Với CMK ⚠ purge protection là BẮT BUỘC
⚠ Managed HSM — khi cần mức cao hơn Nội dung
⚠ Key Vault Premium: khoá bảo vệ bằng HSM dùng chung
⚠ Managed HSM: HSM ĐƠN NHIỆM cho riêng bạn
⚠ Tuân thủ FIPS 140-2 Level 3
⚠ Chọn theo ⚠ yêu cầu tuân thủ của ngành
⚠ Thực hành tốt tổng hợp Thực hành
⚠ Ứng dụng truy cập bằng managed identity
⚠ RBAC phạm vi hẹp thay cho access policy
⚠ Private endpoint cho môi trường thật
⚠ Bật nhật ký chẩn đoán
⚠ Luân chuyển secret định kỳ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Purge protection đã bật chưa | | | Ai có quyền xoá trên vault | ⚠ càng ít càng tốt | | Có nhật ký ai truy cập secret nào không | |

Và rủi ro nghiêm trọng nhất liên quan tới Key Vault, nghiêm trọng hơn cả việc bị lộ bí mật: xoá nhầm một vault chứa khoá mã hoá dữ liệu. Không có purge protection thì dữ liệu được mã hoá bằng khoá đó không bao giờ đọc lại được.

Câu 142 Azure subscriptions
If you have an Azure free account, with a $200 credit for the first month, what happens when you reach the $200 limit?
  1. A Your credit card is automatically billed.
  2. B Your account is automatically closed.
  3. C All services are stopped and you must decide whether you want to convert to a paid account or not.
  4. D You cannot create any more resources until you add more credits to the account.
Xem giải thích

Đáp án

C — Mọi dịch vụ bị dừng và bạn phải tự quyết định có chuyển sang tài khoản trả phí hay không.

Vì sao đúng

⚠ Tài khoản miễn phí có spending limit bật SẴN: | Bước | Nội dung | |---|---| | ⚠ Dùng hết 200 USD, hoặc hết 30 ngày | | | ⚠ Tài nguyên bị TẠM DỪNG | ⚠ không bị xoá ngay | | ⚠ KHÔNG tự trừ thẻ tín dụng | | | ⚠ Bạn chủ động nâng cấp lên Pay-As-You-Go | ⚠ thì tài nguyên chạy lại | | ⚠ Không nâng cấp | ⚠ dữ liệu bị xoá sau một thời gian giữ |

⚠ Hết tín dụng  →  ⚠ DỪNG, không tính tiền
        ↓
⚠ Bạn quyết định:  ⚠ nâng cấp  hoặc  ⚠ để tài khoản hết hạn

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

  • A (thẻ tín dụng bị trừ tự động) — ⚠ SAI; đó chính là điều spending limit ngăn chặn.

  • B (tài khoản tự đóng) — ⚠ không đóng ngay; nó bị tạm dừng và có thời gian ân hạn.

  • D (không tạo thêm được tài nguyên cho tới khi nạp thêm tín dụng) — ⚠ mô tả THIẾU; không chỉ ngừng tạo mới mà tài nguyên đang chạy cũng dừng.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô này và lô trước có ba câu về tài khoản miễn phí và kiểm soát chi phí.

Câu Hỏi gì Khoá
⚠ #22067 ⚠ tín dụng ban đầu là bao nhiêu ⚠ 200 USD
⚠ #22165 ⚠ bao nhiêu giờ VM B1S miễn phí ⚠ 750 giờ mỗi tháng
⚠ #22149 ⚠ làm sao chặn chi phí vượt mức ⚠ spending limit
⚠ #22191 (câu này) ⚠ hết tín dụng thì sao ⚠ dịch vụ dừng, tự quyết định nâng cấp
⚠ Bốn câu ⚠ nhất quán, cùng vẽ nên cơ chế tài khoản miễn phí

⚠ Spending limit và budget alert — khác nhau căn bản: | Cơ chế | Hành vi | |---|---| | ⚠ Spending limit | ⚠ DỪNG dịch vụ, chỉ có ở đăng ký kèm tín dụng | | ⚠ Budget alert | ⚠ chỉ BÁO, dịch vụ vẫn chạy |

Từ khoá nhận diện:

"hết tín dụng thì dừng" → ⚠ spending limit "gửi email khi tới ngưỡng" → ⚠ budget alert "200 USD trong 30 ngày" → ⚠ tín dụng tài khoản miễn phí "12 tháng dịch vụ miễn phí" → ⚠ phần quyền lợi thứ hai

⚠ Điều nên làm sau khi nâng cấp lên trả phí Việc
⚠ Đặt budget và cảnh báo NGAY ⚠ vì spending limit không còn
⚠ Xoá tài nguyên thử nghiệm không dùng
⚠ Kiểm tra đĩa và IP mồ côi
⚠ Hẹn giờ tắt máy ngoài giờ học

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản đang ở loại đăng ký nào | ⚠ quyết định có spending limit hay không | | Đã đặt budget alert chưa | | | Có tài nguyên nào đang chạy mà không dùng không | |

Và điều làm tài khoản miễn phí an toàn cho người mới học, cũng là điều biến mất ngay khi nâng cấp: spending limit. Sau khi chuyển sang trả phí, không còn cơ chế nào tự dừng dịch vụ — bạn phải tự dựng lấy hàng rào bằng budget và cảnh báo.

Câu 143 Core Azure components
What are groups of subscriptions called?
  1. A Management Groups
  2. B Subscription Groups
  3. C Azure Policy
  4. D ARM Groups
Xem giải thích

Đáp án

A — Management Groups (nhóm quản lý).

Vì sao đúng

⚠ Management group là cấp NGAY TRÊN subscription: | Đặc điểm | Nội dung | |---|---| | ⚠ Chứa nhiều subscription | ⚠ hoặc chứa management group con | | ⚠ Lồng nhau tới 6 cấp | ⚠ không kể cấp gốc | | ⚠ Chính sách và quyền KẾ THỪA xuống dưới | | | ⚠ Có một root management group | ⚠ chứa toàn bộ tenant | | ⚠ Một subscription chỉ thuộc MỘT management group | |

⚠ Root Management Group
   ├── ⚠ MG Sản xuất
   │      ├── ⚠ Subscription A
   │      └── ⚠ Subscription B
   └── ⚠ MG Phi sản xuất
          └── ⚠ Subscription C

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

  • B (Subscription Groups) và D (ARM Groups) — ⚠ không tồn tại.

  • C (Azure Policy) — ⚠ là dịch vụ áp luật lên cấu hình, không phải cách nhóm subscription.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22176 trong lô này hỏi subscription là gì; câu này hỏi cấp trên nó. ⚠ Hai câu bổ sung nhau.

⚠ Thứ bậc quản lý đầy đủ:

⚠ Tenant (Entra ID)
      ↓
⚠ Root Management Group
      ↓
⚠ Management Group        →  ⚠ lồng tới 6 cấp
      ↓
⚠ Subscription            →  ⚠ ranh giới hoá đơn
      ↓
⚠ Resource Group          →  ⚠ nhóm cùng vòng đời
      ↓
⚠ Resource

⚠ Quyền RBAC và Azure Policy KẾ THỪA từ trên xuống, không bao giờ ngược lại.

Từ khoá nhận diện:

"nhóm nhiều subscription" → ⚠ management group "cấp tính tiền" → ⚠ subscription "nhóm tài nguyên cùng vòng đời" → ⚠ resource group "tổ chức, danh bạ định danh" → ⚠ tenant

⚠ Vì sao nên dựng management group SỚM Lý do
⚠ Áp chính sách một lần cho toàn tổ chức
⚠ Subscription tạo về sau tự động thừa hưởng
⚠ Gán quyền ở một chỗ thay vì từng subscription
⚠ Dựng muộn ⚠ phải đi sửa lại từng subscription một
⚠ Cấu trúc thường gặp Cấu trúc
⚠ Theo môi trường ⚠ Prod, Non-prod, Sandbox
⚠ Theo bộ phận ⚠ Tài chính, Kỹ thuật, Kinh doanh
⚠ Theo mức tuân thủ ⚠ dữ liệu nhạy cảm và dữ liệu thường
⚠ Khuyến nghị ⚠ giữ CẠN và ĐƠN GIẢN, đừng lồng sâu vì có thể lồng được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã có management group chưa hay mọi subscription đứng rời | | | Chính sách bắt buộc có được áp ở cấp gốc không | | | Cấu trúc có phản ánh cách tổ chức thật sự vận hành không | |

Và lời khuyên thực tế về thiết kế thứ bậc: giữ nó cạn. Sáu cấp lồng nhau là giới hạn kỹ thuật, không phải mục tiêu — cấu trúc càng sâu thì càng khó biết một quyền hay một chính sách thật ra đến từ đâu.

Câu 144 Azure management tools

What is a key benefit of using Azure Cloud Shell?

  1. A

    It provides a graphical user interface (GUI) for managing Azure services.
  2. B

    It provides a pre-configured, browser-based shell for managing Azure resources without requiring local installations.
  3. C

    It allows you to run virtual machines directly in the browser.
  4. D

    It automatically optimizes the cost of your Azure resources.
Xem giải thích

Đáp án

B — Cung cấp một shell chạy trong trình duyệt, đã được cấu hình sẵn

Vì sao đúng

Hai chữ quan trọng nhất là "pre-configured" và "browser-based". Cloud Shell đã cài sẵn Azure CLI, Azure PowerShell, Terraform, Git, kubectl và nhiều công cụ khác, đồng thời tự xác thực bằng tài khoản bạn đang đăng nhập — nên mở ra là gõ lệnh được ngay, không có bước cài đặt hay đăng nhập riêng.

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

  • A. Cung cấp giao diện đồ hoạ — đó là Azure Portal; Cloud Shell là dòng lệnh.
  • C. Cho chạy máy ảo ngay trong trình duyệt — Cloud Shell là một phiên làm việc chạy trên container, nhưng nó dùng để quản lý tài nguyên chứ không phải nơi chạy khối lượng công việc.
  • D. Tự động tối ưu chi phí — đó là việc của Azure Advisor.
Câu 145 Azure governance methodologies
What does the letter R in RBAC stand for?
  1. A Rights
  2. B Rule
  3. C Review
  4. D Role
Xem giải thích

Đáp án

D — Role (vai trò).

Vì sao đúng

⚠ RBAC = Role-Based Access Control — kiểm soát truy cập dựa trên VAI TRÒ: | Thành phần của một role assignment | Nội dung | |---|---| | ⚠ Security principal | ⚠ AI — người dùng, nhóm, service principal, managed identity | | ⚠ Role definition | ⚠ ĐƯỢC LÀM GÌ — tập hợp các quyền | | ⚠ Scope | ⚠ Ở ĐÂU — management group, subscription, resource group, resource |

⚠ Ai  +  ⚠ Vai trò gì  +  ⚠ Phạm vi nào  =  ⚠ một role assignment

⚠ Ý tưởng cốt lõi: ⚠ không gán quyền cho từng người một, mà gán quyền cho VAI TRÒ rồi đặt người vào vai trò đó.

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

  • A (Rights), B (Rule), C (Review) — ⚠ đều không phải; chữ R trong RBAC luôn là Role.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22089 ở lô 170 hỏi có cấp được quyền mà không chia sẻ mật khẩu không (đáp án CÓ, bằng RBAC). ⚠ Câu này hỏi chính tên gọi. Hai câu bổ sung nhau.

⚠ 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 | | ⚠ 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:

"ai được làm gì trên tài nguyên" → ⚠ RBAC "cái gì được phép tạo" → ⚠ Azure Policy "chặn xoá tài nguyên" → ⚠ Resource Lock "quyền quản trị tạm thời" → ⚠ PIM

⚠ Quy tắc kế thừa của RBAC Quy tắc
⚠ Quyền gán ở cấp trên KẾ THỪA xuống dưới
⚠ Gán ở management group là áp cho mọi subscription bên dưới
⚠ Quyền là CỘNG DỒN ⚠ nhiều gán thì hợp lại
⚠ Deny assignment thắng mọi allow ⚠ hiếm dùng, thường do Blueprint hoặc dịch vụ quản lý tạo
⚠ Thực hành tốt Thực hành
⚠ Gán quyền cho NHÓM, không gán cho từng người
⚠ Phạm vi hẹp nhất đủ dùng
⚠ Rất ít Owner ở cấp subscription
⚠ Đánh giá quyền định kỳ ⚠ access review

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai đang giữ vai Owner ở cấp subscription | | | Có quyền nào gán trực tiếp cho cá nhân không | ⚠ nên chuyển sang nhóm | | Quyền có được gán ở phạm vi hẹp nhất không | |

Và điều làm RBAC bền vững hơn cách cấp quyền thủ công: khi một người đổi việc, bạn chỉ cần đổi nhóm của họ, chứ không phải đi rà lại từng tài nguyên xem họ còn quyền ở đâu.

Câu 146 Core Azure components
What are resource groups?
  1. A Within Azure security model, users are organized into groups, and those groups are granted permissions to resources
  2. B Automatically assigned groups of resources that all have the same type (virtual machine, app service, etc)
  3. C Based on the tag assigned to a resource by the deployment script, it is assigned to a group
  4. D A folder structure in Azure in which you organize resources like databases, virtual machines, virtual networks, or almost any resource
Xem giải thích

Đáp án

D — Là một cấu trúc thư mục trong Azure để bạn tổ chức tài nguyên như CSDL, máy ảo, mạng ảo, hay gần như mọi loại tài nguyên.

Vì sao đúng

⚠ Resource group là vật chứa logic: | Đặc điểm | Nội dung | |---|---| | ⚠ Mỗi tài nguyên thuộc ĐÚNG MỘT resource group | | | ⚠ Trộn nhiều loại tài nguyên được | ⚠ VM, CSDL, mạng nằm chung | | ⚠ Tài nguyên trong nhóm có thể ở NHIỀU VÙNG khác nhau | | | ⚠ Xoá nhóm là XOÁ HẾT bên trong | | | ⚠ Gán quyền và chính sách ở cấp nhóm được | |

⚠ Bản thân resource group cũng có một vùng — nơi lưu siêu dữ liệu của nhóm, không bắt buộc trùng vùng của tài nguyên bên trong.

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

  • A (người dùng được xếp vào nhóm rồi cấp quyền cho nhóm) — ⚠ đó là nhóm bảo mật trong Entra ID, không phải resource group.

  • B (nhóm tự động gán theo LOẠI tài nguyên) — ⚠ SAI; bạn tự chọn tài nguyên nào vào nhóm nào.

  • C (gán theo thẻ mà kịch bản triển khai đặt) — ⚠ thẻ là cơ chế KHÁC, dùng để phân loại và báo cáo chi phí.

Ghi nhớ

⚠ Đối chiếu: ⚠ lô trước có #22176 (subscription là gì) và #22192 (nhóm các subscription gọi là gì). ⚠ Câu này bổ sung cấp thấp nhất trong thứ bậc.

⚠ Thứ bậc đầy đủ:

⚠ Tenant  →  ⚠ Management Group  →  ⚠ Subscription  →  ⚠ Resource Group  →  ⚠ Resource

⚠ Nên nhóm theo tiêu chí nào: | Cách nhóm | Khi nào | |---|---| | ⚠ Theo vòng đời | ⚠ thứ tạo và xoá cùng nhau — phổ biến nhất | | ⚠ Theo ứng dụng | ⚠ mỗi ứng dụng một nhóm | | ⚠ Theo môi trường | ⚠ Prod, Dev, Test | | ⚠ Tránh | ⚠ một nhóm khổng lồ chứa mọi thứ |

Từ khoá nhận diện:

"vật chứa logic, xoá cùng nhau" → ⚠ resource group "ranh giới hoá đơn" → ⚠ subscription "phân loại để báo cáo chi phí" → ⚠ tags "nhóm người dùng để cấp quyền" → ⚠ security group trong Entra ID

⚠ Điều cần biết thêm Điều
⚠ Chuyển tài nguyên sang nhóm khác được ⚠ nhưng không phải dịch vụ nào cũng hỗ trợ
⚠ Đổi tên nhóm thì KHÔNG được ⚠ phải tạo mới và di chuyển
⚠ Resource lock đặt ở cấp nhóm được ⚠ chống xoá nhầm cả nhóm
⚠ Có giới hạn số tài nguyên mỗi nhóm ⚠ rất lớn, hiếm khi chạm tới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhóm có chứa lẫn Prod và Dev không | | | Nhóm quan trọng đã có resource lock chưa | ⚠ xoá nhóm là mất hết | | Cách nhóm hiện tại có phản ánh vòng đời thật không | |

Và rủi ro thực tế lớn nhất với resource group: xoá nhóm là xoá sạch mọi thứ bên trong, không hỏi lại từng cái. Đặt CanNotDelete lock cho các nhóm sản xuất là việc mất một phút và tránh được một thảm hoạ.

Câu 147 Security tools and features

Which Azure networking service allows you to securely connect your on-premises network to Azure over the internet?

  1. A

    Azure Load Balancer
  2. B

    Azure VPN Gateway
  3. C

    Azure ExpressRoute
  4. D

    Azure Virtual Network (VNet)
Xem giải thích

Đáp án

B — Azure VPN Gateway

Vì sao đúng

Từ khoá quyết định là "qua Internet". VPN Gateway dựng đường hầm IPsec mã hoá giữa mạng tại chỗ và VNet, chạy trên chính đường Internet sẵn có — nên dựng nhanh, chi phí thấp, và không cần làm việc với nhà cung cấp mạng nào.

Đổi lại là băng thông và độ trễ phụ thuộc tình trạng Internet công cộng, không có cam kết.

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

  • C. ExpressRoute — cũng nối mạng tại chỗ với Azure và cho băng thông cùng độ trễ ổn định hơn hẳn, nhưng nó là kết nối riêng không đi qua Internet. Đây là phương án nhiễu gần nhất, và điểm phân biệt nằm đúng ở cụm "over the internet" trong đề.
  • D. Virtual Network — là mạng riêng trong Azure, không phải cơ chế kết nối ra ngoài.
  • A. Load Balancer — phân phối lưu lượng giữa các máy.
Câu 148 Chọn nhiều đáp án Benefits of cloud services
What two advantages does cloud computing elasticity give to you? Pick two.
  1. A You can save money.
  2. B You can do more regular backups and you won't lose as much when that backup gets restored
  3. C You can serve users better during peak traffic periods by automatically adding more capacity.
  4. D Servers have become a commodity and Microsoft doesn't even need to even fix servers that fail within Azure.
Xem giải thích

Đáp án

A và C — Bạn tiết kiệm được tiền, và phục vụ người dùng tốt hơn trong giai đoạn cao điểm nhờ tự động thêm công suất.

Vì sao đúng

⚠ Elasticity là khả năng TỰ ĐỘNG co giãn theo tải thật: | Chiều | Lợi ích | |---|---| | ⚠ Mở rộng khi tải tăng | ⚠ người dùng không bị chậm hay lỗi lúc cao điểm | | ⚠ Thu hẹp khi tải giảm | ⚠ không trả tiền cho công suất bỏ không |

⚠ Mô hình truyền thống: ⚠ mua đủ cho ĐỈNH  →  ⚠ 90% thời gian máy rảnh
⚠ Đám mây co giãn:      ⚠ trả cho đúng cái đang dùng

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

  • B (sao lưu thường xuyên hơn nên mất ít dữ liệu hơn khi khôi phục) — ⚠ liên quan tới RPO và chiến lược sao lưu, không phải elasticity.

  • D (máy chủ thành hàng hoá phổ thông, Microsoft không cần sửa máy hỏng) — ⚠ mô tả sai; Microsoft có thay thế phần cứng hỏng, và điều này không liên quan tới co giãn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #22164 ở lô trước hỏi lợi ích then chốt của đám mây (giảm CapEx). ⚠ Câu này đi sâu vào một lợi ích cụ thể — tính co giãn.

⚠ Scalability và elasticity — phân biệt: | Khái niệm | Nghĩa | |---|---| | ⚠ Scalability | ⚠ KHẢ NĂNG mở rộng, có thể phải làm thủ công | | ⚠ Elasticity | ⚠ TỰ ĐỘNG co giãn theo tải, cả hai chiều | | ⚠ Điều kiện | ⚠ muốn elastic thì trước hết phải scalable |

⚠ Hai hướng co giãn: | Hướng | Nội dung | |---|---| | ⚠ Scale out / in — NGANG | ⚠ thêm bớt SỐ máy, không gián đoạn | | ⚠ Scale up / down — DỌC | ⚠ đổi CỠ máy, thường phải khởi động lại | | ⚠ Đám mây thiên về | ⚠ co giãn ngang |

Từ khoá nhận diện:

"tự động thêm bớt theo tải" → ⚠ elasticity "có thể mở rộng khi cần" → ⚠ scalability "chịu lỗi thành phần" → ⚠ high availability, khác hẳn "trả theo mức dùng" → ⚠ consumption pricing

⚠ Điều kiện để elasticity thật sự tiết kiệm Điều kiện
⚠ Phải có CẢ luật thu hẹp ⚠ thiếu là chỉ tăng không giảm
⚠ Ứng dụng không giữ trạng thái trên máy
⚠ Máy mới lên đủ nhanh để kịp đợt cao điểm
⚠ Có trần tối đa ⚠ để tải bất thường không thành hoá đơn bất thường

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật co giãn có đủ hai chiều chưa | | | Máy mới mất bao lâu mới phục vụ được | | | Số máy có bao giờ về mức tối thiểu không | ⚠ nếu không thì luật thu hẹp đang không chạy |

Và sai lầm phổ biến nhất khiến tính co giãn không tiết kiệm được đồng nào: chỉ đặt luật mở rộng. Sau vài đợt cao điểm, hệ thống ở lại mức cao mãi mãi và bạn trả tiền cho công suất không ai dùng.

Câu 149 Describe cost management in Azure

How does data transfer between Azure regions impact costs?

  1. A

    It's charged based on the amount of data transferred and the distance
  2. B

    It's charged based on the source region only
  3. C

    It's charged based on the destination region only
  4. D

    It's always free, regardless of the distance
Xem giải thích

Đáp án

A — Tính theo lượng dữ liệu truyền và khoảng cách

Vì sao đúng

Azure tính phí truyền dữ liệu đi ra khỏi một khu vực, và mức giá phụ thuộc cả khối lượng lẫn khoảng cách địa lý — truyền trong cùng châu lục rẻ hơn truyền xuyên lục địa.

Nguyên tắc thực tế cần nhớ: dữ liệu đi vào Azure thường miễn phí, dữ liệu đi ra thì tính tiền. Đó là lý do việc thiết kế kiến trúc nên hạn chế dữ liệu đi qua lại giữa các khu vực, và cũng là lý do phí truyền dữ liệu hay là khoản bất ngờ trong hoá đơn.

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

  • B và C. Chỉ tính theo khu vực nguồn hoặc đích — bỏ qua yếu tố khối lượng, vốn là cơ sở chính của cách tính.
  • D. Luôn miễn phí — sai; chỉ có dữ liệu đi vào mới thường miễn phí.
Câu 150 Describe the core architectural components of Azure

What is the minimum number of Availability Zones required to create a highly available application in Azure?

  1. A

    1
  2. B

    4
  3. C

    2
  4. D

    3
Xem giải thích

Đáp án

C — 2

Vì sao đúng

Muốn có tính sẵn sàng thì phải có ít nhất hai bản ở hai vị trí tách biệt: một cái hỏng vẫn còn cái kia. Với một zone duy nhất thì không có gì gánh khi zone đó sập.

Trên thực tế Azure có ít nhất ba availability zone ở mỗi khu vực hỗ trợ, và nhiều dịch vụ mặc định trải qua cả ba. Nhưng ngưỡng tối thiểu để gọi là sẵn sàng cao vẫn là hai.

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

  • A. 1 — không có dự phòng nào.
  • D. 3 — là con số zone có sẵn trong mỗi khu vực, và cũng là cấu hình được khuyến nghị, nhưng câu hỏi hỏi mức tối thiểu. Đây là bẫy chính.
  • B. 4 — vượt quá số zone thường có trong một khu vực.