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

Đáp án

D — CLI, PowerShell, Portal, Visual Studio Code và ARM Template.

Vì sao đúng

⚠ Gần như mọi tài nguyên Azure đều tạo được qua nhiều kênh: | Kênh | Nội dung | |---|---| | ⚠ Azure Portal | ⚠ giao diện web | | ⚠ Azure CLI | ⚠ az apim create | | ⚠ PowerShell | ⚠ New-AzApiManagement | | ⚠ ARM template / Bicep | ⚠ hạ tầng dạng mã | | ⚠ Visual Studio Code | ⚠ có extension riêng cho APIM | | ⚠ REST API và SDK | |

⚠ Mọi kênh đều gọi vào
        ↓
⚠ Azure Resource Manager
        ↓
⚠ Cùng một kết quả

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

• A (chỉ Portal), B (thiếu ARM và VS Code), C (thiếu CLI và PowerShell) — ⚠ đều LIỆT KÊ THIẾU.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là dạng câu ⚠ "chọn danh sách đầy đủ nhất".

⚠ Extension VS Code cho Azure — đáng biết: | Extension | Việc | |---|---| | ⚠ Azure API Management | ⚠ tạo và quản lý APIM, sửa policy | | ⚠ Azure Functions | ⚠ tạo, chạy, triển khai Functions | | ⚠ Azure App Service | | | ⚠ Azure Resources | ⚠ duyệt mọi tài nguyên | | ⚠ Bicep | ⚠ gợi ý và kiểm tra cú pháp | | ⚠ Lợi ích | ⚠ làm việc với Azure mà không rời trình soạn thảo |

Từ khoá nhận diện:

"tạo tài nguyên bằng cách nào" → ⚠ thường là nhiều kênh "chỉ Portal" → ⚠ gần như luôn SAI "hạ tầng dạng mã" → ⚠ ARM, Bicep "trong trình soạn thảo" → ⚠ VS Code extension

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kênh nào phù hợp với quy trình của đội | | | Có nên dùng Bicep cho việc tạo lặp lại không | | | Bậc APIM có đáp ứng yêu cầu SLA không | |

Và điều đáng nhớ khi lần đầu tạo một instance API Management: nó mất tới bốn mươi lăm phút. Lệnh không treo, dịch vụ chỉ đơn giản là cần thời gian đó để dựng.

Đáp án

B — Tệp YAML.

Vì sao đúng

⚠ Docker Compose dùng tệp docker-compose.yml định dạng YAML:

⚠ services:
⚠   web:
⚠     image: nginx
⚠     ports:
⚠       - "80:80"
⚠   db:
⚠     image: postgres
⚠     environment:
⚠       POSTGRES_PASSWORD: example

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

• C (JSON) — ⚠ Docker dùng JSON ở nơi khác: ⚠ ví dụ daemon.json; ⚠ nhưng Compose thì dùng YAML.

• A (XML) và D (.config) — ⚠ không phải định dạng của hệ sinh thái Docker.

Ghi nhớ

⚠ Định dạng tệp trong hệ sinh thái container: | Tệp | Định dạng | |---|---| | ⚠ Dockerfile | ⚠ cú pháp riêng, không phải YAML | | ⚠ docker-compose.yml | ⚠ YAML | | ⚠ Kubernetes manifest | ⚠ YAML | | ⚠ Helm chart | ⚠ YAML với template | | ⚠ ACR Task | ⚠ YAML | | ⚠ ARM template | ⚠ JSON | | ⚠ Bicep | ⚠ cú pháp riêng | | ⚠ Thế giới container | ⚠ gần như hoàn toàn dùng YAML |

Từ khoá nhận diện:

"Docker Compose, Kubernetes, Helm" → ⚠ YAML "ARM template" → ⚠ JSON "Dockerfile" → ⚠ cú pháp riêng, không phải YAML "Bicep" → ⚠ cú pháp riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tệp YAML có dùng tab không | ⚠ lỗi phổ biến nhất | | Compose dùng cho dev hay production | | | Có nên chuyển sang Container Apps không | |

Và lỗi phổ biến nhất khi làm việc với bất kỳ tệp YAML nào, từ Docker Compose tới Kubernetes: dùng ký tự tab thay vì dấu cách. Nhìn thì giống hệt nhau, mà trình phân tích từ chối cả tệp.

Đáp án

C — retention

Vì sao đúng

⚠ Lệnh đầy đủ là az acr config retention update:

⚠ az acr config retention update \
⚠   --registry myacr \
⚠   --status enabled \
⚠   --days 30 \
⚠   --type UntaggedManifests
        ↓
⚠ Ảnh CHƯA GẮN THẺ quá 30 ngày sẽ tự xoá

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

• B (delete) — ⚠ xoá THỦ CÔNG một ảnh cụ thể, không tự động.

• A (untagged) và D (timeout) — ⚠ không phải lệnh con hợp lệ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ giải quyết vấn đề đã nêu ở #21420.

⚠ Ba cách dọn dẹp ACR: | Cách | Nội dung | |---|---| | ⚠ Retention policy | ⚠ tự xoá ảnh chưa gắn thẻ — đề này | | ⚠ acr purge task | ⚠ xoá theo bộ lọc và tuổi, kể cả ảnh CÓ thẻ | | ⚠ az acr repository delete | ⚠ xoá thủ công | | ⚠ Retention policy | ⚠ có ở bậc Premium | | ⚠ acr purge | ⚠ chạy được như task theo lịch |

Từ khoá nhận diện:

"tự xoá ảnh chưa gắn thẻ" → ⚠ retention policy "xoá theo tuổi và bộ lọc" → ⚠ acr purge task "xoá một ảnh cụ thể" → ⚠ az acr repository delete "registry phình to" → ⚠ thường do ảnh chưa gắn thẻ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Registry đang chiếm bao nhiêu dung lượng | | | Có bao nhiêu ảnh chưa gắn thẻ | | | Có ảnh nào đang được tham chiếu theo digest không | |

Và nguồn gốc âm thầm khiến chi phí registry container tăng đều mà không ai để ý: ảnh mất thẻ sau mỗi lần build đè lên cùng một tag. Chúng không hiện trên giao diện nhưng vẫn tính tiền lưu trữ.

Đáp án

D — Ứng dụng Authenticator, tin nhắn văn bản, cuộc gọi điện thoại và security key.

Vì sao đúng

⚠ Entra ID hỗ trợ nhiều phương thức xác thực bổ sung: | Phương thức | Mức bảo mật | |---|---| | ⚠ Microsoft Authenticator | ⚠ cao — khuyến nghị | | ⚠ FIDO2 security key | ⚠ CAO NHẤT — chống phishing | | ⚠ Windows Hello for Business | ⚠ rất cao | | ⚠ Passkey | ⚠ rất cao | | ⚠ Chứng chỉ | ⚠ cao | | ⚠ OATH token | ⚠ trung bình | | ⚠ Tin nhắn SMS | ⚠ THẤP — dễ bị SIM swap | | ⚠ Gọi điện | ⚠ thấp | | ⚠ KHÔNG hỗ trợ | ⚠ EMAIL làm phương thức MFA đăng nhập |

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

• C (có EMAIL) — ⚠ bẫy chính: ⚠ email ⚠ chỉ dùng để KHÔI PHỤC mật khẩu (SSPR), ⚠ không phải phương thức MFA khi đăng nhập.

• B (email, SMS, câu hỏi bảo mật) — ⚠ câu hỏi bảo mật cũng chỉ dùng cho SSPR.

• A (chỉ tin nhắn) — ⚠ quá hẹp.

Ghi nhớ

⚠ Phân biệt MFA và SSPR — điểm mấu chốt: | Mục đích | Phương thức được phép | |---|---| | ⚠ MFA khi ĐĂNG NHẬP | ⚠ app, SMS, gọi điện, security key, chứng chỉ | | ⚠ SSPR (tự đặt lại mật khẩu) | ⚠ thêm EMAIL và CÂU HỎI BẢO MẬT | | ⚠ Vì sao khác nhau | ⚠ email không đủ mạnh làm yếu tố thứ hai khi đăng nhập | | ⚠ Đây là | ⚠ điểm phân biệt mà đề đang kiểm tra |

Từ khoá nhận diện:

"MFA đăng nhập" → ⚠ app, SMS, gọi điện, security key "đặt lại mật khẩu" → ⚠ SSPR, có thêm email và câu hỏi "chống phishing" → ⚠ FIDO2, Windows Hello, passkey "kém an toàn nhất" → ⚠ SMS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bao nhiêu người chỉ dùng SMS | | | Number matching đã bật chưa | | | Có lộ trình chuyển sang passwordless không | |

Và phân biệt mà câu hỏi này thật sự kiểm tra: email và câu hỏi bảo mật dùng được để KHÔI PHỤC mật khẩu, nhưng không đủ mạnh để làm yếu tố thứ hai khi đăng nhập.

Đáp án

D — Live Metrics Stream

Vì sao đúng

Live Metrics Stream hiển thị số liệu theo thời gian thực với độ trễ dưới một giây: số yêu cầu, tỷ lệ lỗi, thời gian phản hồi, mức dùng tài nguyên — và cho lọc để chỉ xem những yêu cầu thoả điều kiện. Đây là công cụ dùng khi bạn vừa phát hành và muốn thấy ngay tác động, hoặc khi đang có sự cố và cần nhìn hệ thống ngay lúc này.

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

• A. Application Map — vẽ sơ đồ phụ thuộc giữa các thành phần và chỉ ra nút thắt, nhưng dựa trên dữ liệu đã tổng hợp chứ không phải luồng trực tiếp.
• C. Analytics Query — truy vấn KQL trên dữ liệu đã lưu; rất mạnh để điều tra sau, nhưng có độ trễ nạp dữ liệu.
• B. Performance Counters — số đo hạ tầng, phạm vi hẹp hơn nhiều.

Đáp án

C — Tab Connection Strings trong cấu hình của App Service.

Vì sao đúng

⚠ Cấu hình trên Azure GHI ĐÈ cấu hình trong tệp của ứng dụng:

⚠ web.config có <connectionStrings>
        ↓
⚠ App Service Configuration cũng có
        ↓
⚠ Khi chạy, App Service TIÊM giá trị của mình vào
        ↓
⚠ Giá trị trên AZURE THẮNG

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

• A (chuỗi trong web.config) — ⚠ SAI: ⚠ nó bị ghi đè.

• B (không có cách nào biết được) — ⚠ SAI: ⚠ quy tắc rất rõ ràng và có tài liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là một trong những ⚠ nguyên nhân gỡ lỗi mất thời gian nhất trong thực tế.

⚠ Connection Strings và Application Settings — khác biệt: | Điểm | App Settings | Connection Strings | |---|---|---| | ⚠ Tiêm vào | ⚠ biến môi trường | ⚠ biến môi trường có TIỀN TỐ theo loại | | ⚠ Tiền tố | ⚠ không | ⚠ SQLAZURECONNSTR_, MYSQLCONNSTR_... | | ⚠ .NET đọc được qua | ⚠ cấu hình thường | ⚠ ConnectionStrings section | | ⚠ Với ứng dụng KHÔNG phải .NET | ⚠ cả hai đều chỉ là biến môi trường |

Từ khoá nhận diện:

"cấu hình trên Azure và trong mã cùng có" → ⚠ Azure thắng "sửa tệp mà không có tác dụng" → ⚠ bị ghi đè "xem giá trị thật đang chạy" → ⚠ Kudu Environment "secret không nên ở đâu" → ⚠ cả hai chỗ — dùng Key Vault reference

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giá trị thật đang chạy là gì | ⚠ kiểm tra ở Kudu Environment | | Chuỗi kết nối có đánh dấu slot setting chưa | | | Có secret nào trong tệp cấu hình đưa lên Git không | |

Và cách nhanh nhất để chấm dứt tranh cãi về việc ứng dụng đang dùng cấu hình nào: mở Kudu và xem biến môi trường thật sự đang có giá trị gì. Mọi suy đoán từ tệp cấu hình đều có thể sai.

Đáp án

A — Table API.

Vì sao đúng

⚠ Mỗi API của Cosmos DB ứng với một mô hình dữ liệu: | API | Mô hình | |---|---| | ⚠ Table API | ⚠ KHOÁ-GIÁ TRỊ | | ⚠ MongoDB API | ⚠ tài liệu | | ⚠ Cassandra API | ⚠ cột rộng | | ⚠ Gremlin API | ⚠ đồ thị | | ⚠ NoSQL (Core SQL) | ⚠ tài liệu — API gốc |

⚠ PartitionKey + RowKey → Thực thể
        ↓
⚠ Tra theo khoá: rất nhanh
⚠ Truy vấn theo trường khác: kém

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

• B (MongoDB API) — ⚠ mô hình TÀI LIỆU.

• D (Cassandra API) — ⚠ cột rộng.

• C (Gremlin API) — ⚠ đồ thị.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ TRÙNG với #19539 ở lô 166, thứ tự phương án ⚠ bị xáo.

⚠ Tổng kết năm câu trùng của lô 169: | Câu | Trùng với | Chữ cái đổi | |---|---|---| | ⚠ #21508 (soft delete) | ⚠ #19505 | ⚠ D → B | | ⚠ #21510 (LRS 3 bản) | ⚠ #19617 | ⚠ B → A | | ⚠ #21511 (ARM template) | ⚠ #19630 | ⚠ A → B | | ⚠ #21533 (chi phí Redis) | ⚠ #19504 | ⚠ A → B | | ⚠ #21540 (Table API) | ⚠ #19539 | ⚠ C → A | | ⚠ Kết luận | ⚠ TẤT CẢ NĂM câu đều đổi chữ cái |

⚠ Năm API Cosmos DB — bảng chốt: | API | Mô hình | Tên mới | |---|---|---| | ⚠ Core (SQL) | ⚠ tài liệu | ⚠ for NoSQL | | ⚠ MongoDB | ⚠ tài liệu | ⚠ for MongoDB | | ⚠ Cassandra | ⚠ cột rộng | ⚠ for Apache Cassandra | | ⚠ Gremlin | ⚠ đồ thị | ⚠ for Apache Gremlin | | ⚠ Table | ⚠ khoá-giá trị | ⚠ for Table |

Từ khoá nhận diện:

"khoá-giá trị" → ⚠ Table API "JSON, truy vấn nhiều trường" → ⚠ NoSQL "đồ thị, quan hệ" → ⚠ Gremlin "cột rộng" → ⚠ Cassandra

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình dữ liệu thật sự là gì | | | Table Storage đã đủ chưa | | | Có nhầm chữ cái từ lần gặp trước không | |

Và bài học rõ ràng nhất của lô này, với năm câu trùng và cả năm đều đổi chữ cái: học thuộc vị trí đáp án là cách ôn thi chắc chắn thất bại. Chỉ có hiểu nội dung mới bền.

Đáp án

D — Cài đặt kiểm soát truy cập theo vai trong chính ứng dụng

Vì sao đúng

Entra ID lo phần xác thực — chứng minh người dùng là ai — rồi phát ra token chứa các claim, trong đó có vai hoặc nhóm mà người đó thuộc về. Nhưng phần uỷ quyền — quyết định vai đó được làm gì trong ứng dụng của bạn — thì Entra ID không biết, vì nó không hiểu logic nghiệp vụ.

Vì vậy ứng dụng phải đọc claim trong token và kiểm tra trước khi cho truy cập từng tính năng.

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

• B. Conditional Access theo nhóm — kiểm soát điều kiện đăng nhập (thiết bị, vị trí, xác thực đa yếu tố), không phân quyền tới từng tài nguyên bên trong ứng dụng.
• A. Hạn chế người được xác thực trong app registration — chặn ai đăng nhập được vào ứng dụng nói chung, nhưng không phân biệt được quyền giữa những người đã vào.
• C. Entra External ID — dành cho danh tính khách hàng bên ngoài, không phải người dùng của tổ chức.

Đáp án

B — Cấu hình managed identity cho ACI và gán quyền cần thiết

Vì sao đúng

Managed identity là cách truy cập an toàn nhất vì không có bí mật nào tồn tại: Azure cấp cho container một danh tính, nó lấy token từ nền tảng, và bạn gán cho danh tính đó đúng vai cần trên tài khoản lưu trữ. Không có gì để rò rỉ, không có gì hết hạn, không có gì phải xoay vòng.

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

• A. Truyền SAS token vào biến môi trường — token có thời hạn, nên phải có cơ chế tạo lại; và biến môi trường của container đọc được từ nhiều nơi.
• D. Đưa chuỗi kết nối vào biến môi trường — tệ hơn nữa: chuỗi kết nối chứa khoá tài khoản, tức là toàn quyền trên toàn bộ tài khoản lưu trữ.
• C. Chép tệp vào container lúc khởi động bằng Azure CLI — làm phình thời gian khởi động, và dữ liệu trở thành bản sao tĩnh không cập nhật.

Đáp án

B — Bounded Staleness

Vì sao đúng

Từ khoá quyết định nằm ở cuối đề: "trong độ trễ tối đa 5 giây". Bounded Staleness là mức nhất quán duy nhất cho bạn khai một cận trên cụ thể cho độ lệch — theo khoảng thời gian hoặc theo số phiên bản. Dữ liệu ở các khu vực có thể chậm hơn bản chính, nhưng không bao giờ chậm quá mức bạn đặt.

Đây chính là điểm cân bằng: chặt hơn Eventual vì có cam kết đo được, nhưng không phải trả giá đồng bộ toàn cầu như Strong.

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

• C. Strong — bảo đảm mạnh hơn mức cần, và trả giá bằng độ trễ ghi cao hơn hẳn; nó cũng không dùng được với ghi đa vùng.
• D. Eventual và A. Consistent Prefix — đều không có cận trên nào về thời gian trễ, nên không đáp ứng được yêu cầu "tối đa 5 giây".

So sánh với câu cùng chủ đề

Bộ đề này có một câu gần như giống hệt nhưng yêu cầu là "nhất thiết phải giống nhau ở mọi nơi, bất kể độ trễ" — và đáp án ở đó là Strong. Điểm phân biệt nằm ở chỗ đề có nêu một ngưỡng thời gian cụ thể hay không.