Ngân hàng đề — Microsoft Azure Administrator
Tìm thấy 456 câu.
- A Managing resource costs by setting budget limits.
- B Assigning user roles for resources.
- C Enforcing organizational standards and assessing compliance at-scale.
- D Configuring network security groups.
Xem giải thích
Đáp án
C — Áp đặt tiêu chuẩn của tổ chức và đánh giá mức tuân thủ ở quy mô lớn
Vì sao đúng
Azure Policy đặt ra luật về những gì được phép tồn tại trong môi trường: chỉ được tạo tài nguyên ở những khu vực nào, mọi tài nguyên phải có thẻ nào, loại máy ảo nào bị cấm. Nó vừa chặn việc tạo tài nguyên vi phạm, vừa quét lại tài nguyên đã có để báo cáo mức tuân thủ — nên áp được cho cả môi trường đang chạy chứ không chỉ cho thứ tạo mới.
Vì sao các phương án khác sai
- B. Gán vai cho người dùng — đó là Azure RBAC. Đây là cặp hay bị nhầm nhất: RBAC trả lời "ai được làm gì", còn Policy trả lời "cái gì được phép tồn tại".
- A. Quản lý chi phí bằng hạn mức ngân sách — thuộc về Azure Cost Management.
- D. Cấu hình network security group — là một loại tài nguyên mà Policy có thể ràng buộc, không phải mục đích của Policy.
- A Best practices in writing code.
- B Cost optimization and performance enhancements.
- C User management and role assignments.
- D Azure region selection.
Xem giải thích
Đáp án
B — Tối ưu chi phí và cải thiện hiệu năng
Vì sao đúng
Azure Advisor phân tích cấu hình và số liệu sử dụng thật của môi trường bạn, rồi đưa ra khuyến nghị theo năm trụ: chi phí, hiệu năng, độ tin cậy, bảo mật, và vận hành xuất sắc. Ví dụ điển hình: chỉ ra máy ảo dùng dưới công suất để bạn hạ cấu hình, hoặc gợi ý mua reserved instance cho tải chạy liên tục.
Vì sao các phương án khác sai
- A. Thực hành tốt khi viết mã — Advisor nhìn vào tài nguyên đang chạy, không đọc mã nguồn.
- C. Quản lý người dùng và gán vai — thuộc về Entra ID và RBAC.
- D. Chọn khu vực Azure — là quyết định kiến trúc lúc thiết kế, không phải khuyến nghị của Advisor.
- A Configuring a firewall to allow requests from specific IP ranges.
- B Setting up a virtual network to allow only traffic from within the VNet to access the storage.
-
C
Utilizing Entra ID-based authentication for Azure Files.
- D Creating a new Azure subscription.
Xem giải thích
Đáp án
A và B — cấu hình tường lửa cho phép dải IP cụ thể, và cho phép chỉ lưu lượng từ trong VNet
Vì sao đúng
Hai cách này đều là giới hạn ở tầng mạng — quyết định gói tin từ đâu được chạm tới tài khoản lưu trữ:
- A. Lọc theo dải IP công khai — hợp khi truy cập đến từ văn phòng hoặc trung tâm dữ liệu có địa chỉ cố định.
- B. Chỉ cho lưu lượng từ VNet — qua service endpoint hoặc private endpoint; đây là cách chặt nhất vì tài khoản lưu trữ không còn tiếp cận được từ Internet.
Vì sao các phương án khác sai
- C. Xác thực bằng Entra ID cho Azure Files — là cơ chế xác thực (bạn là ai), không phải cơ chế hạn chế truy cập theo mạng mà đề hỏi. Đây là phương án nhiễu hợp lý nhất.
- D. Tạo một subscription mới — không liên quan gì tới việc kiểm soát truy cập.
- A To configure virtual network settings.
- B To provide delegated, time-limited access to storage resources.
- C To authenticate applications using OAuth 2.0.
- D To connect virtual machines to storage accounts.
Xem giải thích
Đáp án
B — Cấp quyền truy cập được uỷ nhiệm và có giới hạn thời gian tới tài nguyên lưu trữ
Vì sao đúng
Shared Access Signature là một chuỗi ký được gắn vào URL, cho phép bạn chia sẻ quyền truy cập mà không chia sẻ khoá tài khoản. Bạn khai chính xác: tài nguyên nào, quyền gì (đọc, ghi, xoá), hiệu lực từ lúc nào tới lúc nào, và chỉ chấp nhận từ dải IP nào.
Ứng dụng điển hình: cho khách hàng tải một tệp lên bucket của bạn trong 15 phút mà không cần cấp cho họ bất kỳ thông tin đăng nhập nào.
Vì sao các phương án khác sai
- C. Xác thực ứng dụng bằng OAuth 2.0 — đó là cơ chế của Entra ID, một hướng khác hẳn.
- A. Cấu hình mạng ảo và D. Nối máy ảo với tài khoản lưu trữ — không liên quan tới phân quyền.
- A Local Redundancy Storage (LRS)
-
B
(Read-Access) Geo-Zone-Redundant Storage ((RA)-GZRS)
- C Object-Level Redundancy (OLR)
- D Remote Redundancy Storage (RRS)
-
E
(Read-Access) Geo-Redundant Storage ((RA)-GRS)
Xem giải thích
Đáp án
A, B và E — LRS, (RA-)GZRS và (RA-)GRS
Vì sao đúng
Azure Storage có bốn mức dư thừa, xếp theo phạm vi bảo vệ tăng dần:
| Mức | Nhân bản ở đâu | Chịu được |
|---|---|---|
| LRS | 3 bản trong một trung tâm dữ liệu | Hỏng ổ đĩa, hỏng máy chủ |
| ZRS | 3 bản qua ba availability zone | Mất trọn một zone |
| GRS | LRS ở vùng chính + bản sao ở vùng phụ cách xa | Mất trọn một khu vực |
| GZRS | ZRS ở vùng chính + bản sao ở vùng phụ | Cả hai loại sự cố trên |
Tiền tố RA- nghĩa là bản sao ở vùng phụ đọc được, chứ không chỉ nằm chờ.
Vì sao các phương án khác sai
- C. "Object-Level Redundancy (OLR)" và D. "Remote Redundancy Storage (RRS)" — không phải tên có thật; chúng được đặt nghe giống thật để gây nhiễu.
- A Azure Key Vault
- B Azure Storage Firewall
- C Azure Storage Explorer
- D Azure Blob Manager
Xem giải thích
Đáp án
C — Azure Storage Explorer
Vì sao đúng
Storage Explorer là ứng dụng máy tính để bàn miễn phí cho phép duyệt tài khoản lưu trữ như duyệt thư mục, và kéo thả tệp giữa máy của bạn với blob container, file share, queue hay table. Với việc chép dữ liệu thủ công hoặc kiểm tra nhanh nội dung thì đây là công cụ tiện nhất.
Vì sao các phương án khác sai
- A. Azure Key Vault — lưu bí mật và khoá, không liên quan tới dữ liệu blob.
- B. Azure Storage Firewall — hạn chế truy cập theo mạng, chứ không phải công cụ truyền dữ liệu.
- D. "Azure Blob Manager" — không phải tên công cụ có thật.
Với khối lượng lớn hoặc cần tự động hoá thì dùng AzCopy — công cụ dòng lệnh nhanh hơn nhiều.
- A Soft delete to recover a deleted share.
- B Conversion of a file share into a blob container.
- C Creation of snapshots for a point-in-time copy of the file share.
- D Auto-expansion of file shares.
Xem giải thích
Đáp án
A và C — soft delete để khôi phục file share đã xoá, và snapshot để chụp bản tại một thời điểm
Vì sao đúng
Hai tính năng bảo vệ ở hai mức khác nhau, và biết rõ ranh giới giữa chúng rất quan trọng:
- A. Soft delete — giữ lại cả file share sau khi xoá, trong khoảng thời gian bạn khai, để khôi phục được khi lỡ tay.
- C. Snapshot — bản chụp chỉ đọc tại một thời điểm, dùng để lấy lại từng tệp ở trạng thái cũ. Đây mới là thứ giúp khi ai đó ghi đè hay xoá nhầm một tệp.
Vì sao các phương án khác sai
- B. Chuyển file share thành blob container — không có cơ chế nào như vậy; đây là hai loại dịch vụ lưu trữ khác nhau với giao thức truy cập khác nhau.
- D. Tự mở rộng dung lượng file share — dung lượng phải nâng bằng thao tác chủ động, không tự phình theo nhu cầu.
Which feature in Azure Blob Storage is used to automate the transition of blobs to cooler storage tiers, archive blobs or delete blobs at the end of their lifecycles?
-
A
Azure Blob Storage Soft Delete
-
B
Immutable Blob Storage
- C Azure Blob Versioning
- D Azure Blob Lifecycle Management
Xem giải thích
Đáp án
D — Azure Blob Lifecycle Management
Vì sao đúng
Đề mô tả đúng ba việc mà lifecycle management làm tự động theo luật bạn khai: chuyển blob xuống tầng lạnh hơn, đưa vào tầng archive, và xoá khi hết vòng đời. Luật dựa trên tuổi của blob hoặc thời điểm truy cập cuối, chạy hằng ngày mà không cần ai nhớ làm.
Đây cũng là công cụ tối ưu chi phí lưu trữ hiệu quả nhất, vì dữ liệu gần như luôn nguội dần theo thời gian.
Vì sao các phương án khác sai
- A. Soft delete — giữ blob đã xoá thêm một thời gian để khôi phục; là cơ chế bảo vệ, không phải cơ chế chuyển tầng.
- C. Blob Versioning — giữ các phiên bản cũ khi blob bị ghi đè; cũng là bảo vệ, và nó làm tăng chi phí lưu trữ.
- B. Immutable Blob Storage — khoá blob không cho sửa hay xoá trong thời hạn khai báo, phục vụ yêu cầu tuân thủ; ngược hẳn với việc tự động xoá.
- A Resources
- B Outputs
- C Dependencies
- D Extensions
-
E
Variables
Xem giải thích
Đáp án
A, B và E — resources, outputs và variables
Vì sao đúng
Một ARM template có cấu trúc cố định gồm các phần cấp cao nhất sau:
| Phần | Vai trò |
|---|---|
parameters |
Giá trị truyền vào lúc triển khai |
variables |
Giá trị tính sẵn dùng lại trong template, tránh lặp |
resources |
Bắt buộc — danh sách tài nguyên cần tạo |
outputs |
Giá trị trả về sau khi triển khai, ví dụ chuỗi kết nối |
Vì sao các phương án khác sai
- C. "Dependencies" — quan hệ phụ thuộc có tồn tại nhưng khai bằng thuộc tính
dependsOnbên trong từng tài nguyên, không phải một phần riêng ở cấp cao nhất. Đây là phương án nhiễu gần nhất. - D. "Extensions" — cũng vậy: VM extension là một loại tài nguyên con nằm trong
resources, không phải một mục riêng.
You have successfully deployed resources using an ARM template. Now, you want to use the Bicep language to manage these resources in the future.
What command do you use to transition from ARM to Bicep?
-
A
bicep build -
B
bicep compile -
C
bicep version -
D
bicep decompile
Xem giải thích
Đáp án
D — bicep decompile
Vì sao đúng
Tên lệnh nói đúng việc: decompile là dịch ngược từ dạng đã biên dịch về dạng nguồn cấp cao. Ở đây là chuyển tệp ARM template dạng JSON sang cú pháp Bicep gọn hơn, để từ nay quản lý bằng Bicep.
Một lưu ý thực tế: kết quả dịch ngược thường cần chỉnh lại bằng tay — tên biến sinh tự động không mấy dễ đọc, và cấu trúc chưa tận dụng hết các cấu trúc gọn của Bicep. Nó là điểm khởi đầu chứ không phải bản hoàn chỉnh.
Vì sao các phương án khác sai
- A.
bicep build— chiều ngược lại: biên dịch Bicep thành ARM JSON để triển khai. - B. "
bicep compile" — không phải lệnh có thật; lệnh biên dịch làbuild. - C.
bicep version— chỉ in phiên bản công cụ.