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

Đáp án

D — Địa chỉ IP riêng KHẢ DỤNG ĐẦU TIÊN trong dải của Subnet1.

Vì sao đúng

⚠ Azure cấp IP riêng theo thứ tự tăng dần, bỏ qua năm địa chỉ dành riêng:

⚠ Subnet 10.0.1.0/24
   ⚠ 10.0.1.0 → địa chỉ mạng (Azure giữ)
   ⚠ 10.0.1.1 → cổng mặc định (Azure giữ)
   ⚠ 10.0.1.2 → DNS (Azure giữ)
   ⚠ 10.0.1.3 → DNS (Azure giữ)
   ⚠ 10.0.1.255 → broadcast (Azure giữ)
        ↓
⚠ VM đầu tiên nhận 10.0.1.4

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

• B (10.0.0.2 luôn là IP đầu tiên) — ⚠ SAI hai điểm: ⚠ .2 và .3 do Azure giữ cho DNS, ⚠ và dải subnet chưa chắc bắt đầu từ 10.0.0.0.

• A (IP ngẫu nhiên không biết trước) — ⚠ SAI: ⚠ quy tắc cấp phát rất rõ ràng.

• C (IP từ dải công khai của Azure) — ⚠ SAI: ⚠ đây là IP RIÊNG trong VNet; ⚠ IP công khai là tài nguyên riêng biệt.

Ghi nhớ

⚠ Năm địa chỉ Azure giữ trong mỗi subnet: | Địa chỉ | Dùng cho | |---|---| | ⚠ .0 | ⚠ địa chỉ mạng | | ⚠ .1 | ⚠ cổng mặc định | | ⚠ .2, .3 | ⚠ ánh xạ DNS của Azure | | ⚠ Địa chỉ cuối | ⚠ broadcast | | ⚠ Hệ quả | ⚠ subnet /24 có 251 địa chỉ dùng được, không phải 254 |

Từ khoá nhận diện:

"IP khả dụng đầu tiên" → ⚠ cách Azure cấp phát "5 địa chỉ dành riêng" → ⚠ mọi subnet Azure "IP công khai" → ⚠ tài nguyên riêng, phải gán thêm "IP tĩnh" → ⚠ cấu hình trên network interface

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subnet còn đủ địa chỉ khi mở rộng không | ⚠ nhớ trừ 5 địa chỉ | | Có phụ thuộc IP động ở đâu không | | | VM có cần IP công khai thật không | ⚠ thường là không |

Và chi tiết hay khiến việc tính toán dung lượng subnet bị sai: Azure giữ năm địa chỉ trong mỗi subnet, không phải hai như mạng truyền thống. Với subnet nhỏ, sai lệch đó là đáng kể.

Đáp án

A — System-assigned Managed Identity hoặc User-assigned Managed Identity.

Vì sao đúng

⚠ Managed identity chính là câu trả lời cho yêu cầu "không lưu bất kỳ tài khoản mật khẩu nào":

⚠ App Service có managed identity
        ↓ ⚠ cấp quyền cho identity đó trên Key Vault
⚠ Ứng dụng xin token từ endpoint nội bộ
        ↓
⚠ Dùng token đọc secret
        ↓
⚠ KHÔNG có mật khẩu nào trong mã hay cấu hình

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

• D (chứng chỉ TLS/SSL) — ⚠ để mã hoá đường truyền, không phải xác thực ứng dụng với Key Vault.

• B (TLS mutual authentication) — ⚠ xác thực hai chiều bằng chứng chỉ: ⚠ vẫn phải quản lý chứng chỉ.

• C (Private Link) — ⚠ kiểm soát MẠNG: ⚠ đưa Key Vault vào mạng riêng, ⚠ nhưng vẫn cần cơ chế xác thực.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21428 trong cùng lô.

⚠ Chuỗi hoàn chỉnh: App Service đọc Key Vault không dùng mật khẩu: | Bước | Nội dung | |---|---| | ⚠ 1. Bật managed identity cho App Service | | | ⚠ 2. Cấp quyền cho identity trên Key Vault | ⚠ RBAC hoặc access policy | | ⚠ 3. Dùng Key Vault reference trong App Settings | ⚠ cách gọn nhất | | ⚠ Cú pháp | ⚠ @Microsoft.KeyVault(SecretUri=...) | | ⚠ Kết quả | ⚠ ứng dụng đọc như biến môi trường bình thường |

Từ khoá nhận diện:

"không lưu mật khẩu nào" → ⚠ managed identity "mã hoá đường truyền" → ⚠ TLS "đưa dịch vụ vào mạng riêng" → ⚠ Private Link "tham chiếu secret trong App Settings" → ⚠ Key Vault reference

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn mật khẩu nào trong App Settings không | | | Managed identity có quyền tối thiểu không | | | Key Vault đã bật purge protection chưa | |

Và cách đơn giản nhất để một ứng dụng App Service dùng secret mà không phải sửa một dòng mã: Key Vault reference trong App Settings. Ứng dụng vẫn đọc biến môi trường như thường, còn Azure lo phần lấy secret.

Đáp án

D — SAS phải được tạo bằng khoá tài khoản hoặc bằng stored access policy

Vì sao đúng

SAS là một chuỗi được ký, và chữ ký đó phải dựa trên một bí mật: khoá tài khoản lưu trữ, hoặc khoá uỷ nhiệm từ Entra ID với user delegation SAS. Đó chính là cơ chế khiến dịch vụ tin được rằng chuỗi này do người có thẩm quyền phát ra.

Gắn SAS với stored access policy còn mang lại một lợi ích lớn: thu hồi được. SAS thông thường đã ký là không huỷ được cho tới khi hết hạn; còn khi nó trỏ tới một policy thì sửa hoặc xoá policy là mọi SAS gắn với nó mất hiệu lực ngay.

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

• B. SAS chỉ cấp được quyền đọc — sai: khai được đọc, ghi, xoá, liệt kê, và nhiều quyền khác.
• C. SAS không đặt được thời hạn — sai ngược hoàn toàn; thời hạn là một trong những tham số quan trọng nhất của nó.
• A. SAS chỉ tạo được cho blob công khai — sai: SAS sinh ra chính là để cấp quyền vào tài nguyên riêng tư.

Đáp án

C — az acr build

Vì sao đúng

⚠ ACR Tasks là bộ tính năng build ảnh TRÊN đám mây: | Lệnh thuộc ACR Tasks | Việc | |---|---| | ⚠ az acr build | ⚠ quick task: build ngay một lần | | ⚠ az acr task create | ⚠ tạo task tự động chạy | | ⚠ az acr task run | ⚠ chạy task đã tạo | | ⚠ az acr run | ⚠ chạy task đa bước từ file YAML |

⚠ ACR Tasks làm gì
   ⚠ Build ảnh trên hạ tầng Azure
   ⚠ Tự build khi commit vào Git
   ⚠ Tự build khi ẢNH CƠ SỞ cập nhật
   ⚠ Chuỗi build, test, đẩy

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

• A (az acr import) — ⚠ sao chép ảnh từ registry khác, không build.

• B (az acr update) — ⚠ sửa cấu hình của registry.

• D (az acr create) — ⚠ tạo tài nguyên registry.

⚠ Ba lệnh sai đều là lệnh QUẢN LÝ registry, ⚠ chỉ build là tác vụ dựng ảnh.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về az acr build qua hai lô.

⚠ Ba loại task của ACR Tasks: | Loại | Nội dung | |---|---| | ⚠ Quick task | ⚠ az acr build — chạy ngay một lần | | ⚠ Automatically triggered task | ⚠ theo commit, theo lịch, theo ảnh cơ sở | | ⚠ Multi-step task | ⚠ build, test, đẩy theo file YAML |

Từ khoá nhận diện:

"build trên đám mây" → ⚠ ACR Tasks "tự build khi ảnh cơ sở đổi" → ⚠ base image update trigger "sao chép ảnh" → ⚠ az acr import "tạo registry" → ⚠ az acr create

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ảnh cơ sở cập nhật thì ảnh của bạn có tự build lại không | | | Có đang build ảnh trên agent CI có Docker không | ⚠ ACR Tasks có thể thay thế | | Ảnh đã được quét lỗ hổng chưa | |

Và tính năng của ACR Tasks đáng bật nhất cho mọi hệ thống chạy thật, thường bị bỏ qua vì không ai nghĩ tới: tự động build lại khi ảnh cơ sở được vá lỗi bảo mật.

Đáp án

B — Mỗi 5 phút.

Vì sao đúng

⚠ Phân tích sáu trường:

⚠ {giây} {phút} {giờ} {ngày} {tháng} {thứ}
⚠    0    */5     *     *      *      *
⚠    │     │
⚠    │     └── mỗi 5 phút (0, 5, 10, 15...)
⚠    └──────── giây 0
        ↓
⚠ 00:00:00, 00:05:00, 00:10:00...
⚠ → MỖI 5 PHÚT, suốt ngày

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

• A (mỗi 5 giờ) — ⚠ */5 đang ở trường PHÚT, không phải giờ.

• C (mỗi 12 phút) và D (mỗi 20 phút) — ⚠ không khớp với con số 5.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về NCRONTAB qua hai lô.

⚠ Bốn ký hiệu trong NCRONTAB: | Ký hiệu | Nghĩa | Ví dụ | |---|---|---| | ⚠ * | ⚠ mọi giá trị | ⚠ * ở giờ = mọi giờ | | ⚠ */n | ⚠ mỗi n đơn vị | ⚠ */5 ở phút = mỗi 5 phút | | ⚠ a,b,c | ⚠ danh sách | ⚠ 15,30,45 | | ⚠ a-b | ⚠ khoảng | ⚠ 1-5 ở thứ = Hai tới Sáu |

Từ khoá nhận diện:

"*/5 ở trường phút" → ⚠ mỗi 5 phút "số cụ thể ở trường giờ" → ⚠ chỉ giờ đó "sáu trường" → ⚠ NCRONTAB Azure Functions "năm trường" → ⚠ cron Linux, dịch trường đi một ô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm đủ sáu trường chưa | | | Tần suất có thật sự cần dày như vậy không | | | Có thể dùng trigger sự kiện thay cho timer không | |

Và câu hỏi nên đặt trước khi viết một Timer Trigger chạy mỗi vài phút: có sự kiện nào để phản ứng trực tiếp thay vì phải hỏi thăm liên tục không? Trigger theo sự kiện vừa nhanh hơn vừa rẻ hơn.

Đáp án

B — 6 bản sao.

Vì sao đúng

⚠ GRS giữ ba bản ở vùng chính và ba bản ở vùng ghép đôi:

⚠ Vùng CHÍNH
   ⚠ 3 bản sao (như LRS)
        ↓ ⚠ nhân bản BẤT ĐỒNG BỘ
⚠ Vùng PHỤ (paired region)
   ⚠ 3 bản sao
        ↓
⚠ Tổng: 6 bản

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

• A (3) — ⚠ là LRS hoặc ZRS.

• C (1) và D (2) — ⚠ không có mức nào giữ ít hơn ba bản.

Ghi nhớ

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

⚠ Mẹo nhớ bảng nhân bản: | Mẹo | Nội dung | |---|---| | ⚠ Không có chữ G | ⚠ 3 bản, một vùng | | ⚠ Có chữ G (Geo) | ⚠ 6 bản, hai vùng | | ⚠ Có chữ Z (Zone) | ⚠ trải qua các availability zone | | ⚠ Có RA- | ⚠ đọc được ở vùng phụ |

Từ khoá nhận diện:

"6 bản, hai vùng" → ⚠ GRS hoặc GZRS "3 bản, ba zone" → ⚠ ZRS "3 bản, một chỗ, rẻ nhất" → ⚠ LRS "đọc được ở vùng phụ" → ⚠ RA-GRS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần chịu mất zone hay mất cả vùng | | | Vùng ghép đôi có nằm trong phạm vi pháp lý cho phép không | | | Đã có soft delete và versioning chưa | ⚠ nhân bản không thay thế được |

Và điều lô này chứng minh rõ nhất qua năm câu trùng lặp, ba trong số đó về cùng một bảng nhân bản: thuộc chắc một bảng kiến thức ngắn có giá trị hơn nhiều so với ghi nhớ từng câu hỏi riêng lẻ.

Đáp án

C — in, out, inout

Vì sao đúng

⚠ Thuộc tính direction cho biết binding đưa dữ liệu VÀO hay lấy dữ liệu RA:

⚠ {
⚠   "type": "queueTrigger",
⚠   "direction": "in"     ← trigger luôn là in
⚠ },
⚠ {
⚠   "type": "blob",
⚠   "direction": "out"    ← output binding
⚠ }

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

• B (blob, files, queue, table) — ⚠ là giá trị của thuộc tính type, không phải direction.

• D (stdin, stdout, stderr) — ⚠ khái niệm của tiến trình hệ điều hành.

• A (left, right) — ⚠ không liên quan.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh chùm ba câu về binding qua hai lô.

⚠ Cấu trúc một binding trong function.json: | Thuộc tính | Nội dung | |---|---| | ⚠ type | ⚠ loại: httpTrigger, blob, queue, cosmosDB... | | ⚠ direction | ⚠ in, out, inout | | ⚠ name | ⚠ tên biến trong mã | | ⚠ Tuỳ loại | ⚠ path, connection, queueName... |

Từ khoá nhận diện:

"in, out, inout" → ⚠ direction "blob, queue, table" → ⚠ type "tên biến trong mã" → ⚠ name "chuỗi kết nối" → ⚠ connection, trỏ tới app setting

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chuỗi kết nối nào nằm trong function.json không | | | Trigger có đúng direction là in không | | | Đang dùng mô hình khai báo hay mô hình attribute | |

Và quy tắc bất di bất dịch với tệp cấu hình binding: thuộc tính connection chỉ chứa TÊN của cấu hình, không bao giờ chứa chính chuỗi kết nối. Tệp đó nằm trong kho mã nguồn và ai cũng đọc được.

Đáp án

B — Đặt maxDequeueCount lớn hơn 1 trong host.json

Vì sao đúng

Azure Functions có sẵn cơ chế xử lý thông điệp độc (poison message) cho Storage Queue: maxDequeueCount khai số lần một thông điệp được thử xử lý trước khi bị coi là không xử lý được. Vượt quá số đó, runtime tự chuyển thông điệp sang hàng đợi <tên-hàng-đợi>-poison.

Nhờ vậy một thông điệp hỏng không kẹt lại làm nghẽn hàng đợi mãi, mà vẫn được giữ ở nơi riêng để điều tra thay vì bị vứt đi.

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

• C. Bật dead-lettering trong thiết lập Storage Queue — Azure Storage Queue không có tính năng này; dead-letter queue là khái niệm của Azure Service Bus. Đây là bẫy chính, vì hai dịch vụ hàng đợi rất hay bị lẫn.
• D. Tự viết mã chuyển thông điệp sang hàng đợi khác — làm lại bằng tay thứ runtime đã có sẵn.
• A. Đặt visibilityTimeout rất lớn — chỉ kéo dài thời gian thông điệp bị ẩn giữa các lần thử, làm vấn đề chậm lộ ra hơn chứ không giải quyết gì.

Đáp án

A — Đặt thuộc tính ConsistencyLevel của QueryRequestOptions khi thực hiện truy vấn.

Vì sao đúng

⚠ Cosmos DB cho phép ghi đè mức nhất quán ở TỪNG YÊU CẦU:

⚠ Mức mặc định của tài khoản: Eventual
        ↓ ⚠ với truy vấn cụ thể
⚠ QueryRequestOptions.ConsistencyLevel = Strong
        ↓
⚠ Truy vấn ĐÓ dùng mức mạnh hơn
⚠ Các truy vấn khác vẫn dùng mức mặc định

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

• D (sửa mức nhất quán của CSDL trước khi truy vấn) — ⚠ cách rất tệ: ⚠ ảnh hưởng ⚠ toàn bộ ứng dụng, và là thao tác cấu hình chứ không phải mã.

• B (chỉ rõ partition key và row key) — ⚠ giúp truy vấn nhanh hơn, không liên quan tới mức nhất quán.

• C (MaxConcurrency) — ⚠ điều khiển số truy vấn song song, không phải nhất quán.

Ghi nhớ

⚠ Năm mức nhất quán của Cosmos DB — từ mạnh tới yếu: | Mức | Bảo đảm | Chi phí | |---|---|---| | ⚠ Strong | ⚠ luôn đọc được bản mới nhất | ⚠ cao nhất | | ⚠ Bounded staleness | ⚠ chậm tối đa N phiên bản hoặc T giây | | | ⚠ Session | ⚠ MẶC ĐỊNH — đọc được thứ CHÍNH BẠN vừa ghi | | | ⚠ Consistent prefix | ⚠ không đọc lộn thứ tự | | | ⚠ Eventual | ⚠ cuối cùng sẽ hội tụ | ⚠ rẻ nhất, nhanh nhất |

Từ khoá nhận diện:

"ghi đè cho một truy vấn" → ⚠ QueryRequestOptions.ConsistencyLevel "đọc được thứ mình vừa ghi" → ⚠ Session "luôn mới nhất, chấp nhận chậm" → ⚠ Strong "nhanh và rẻ nhất" → ⚠ Eventual

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mức mặc định của tài khoản là gì | | | Truy vấn nào thật sự cần nhất quán mạnh | | | Có đang dùng Strong cho mọi thứ không | ⚠ rất tốn RU |

Và điều tinh tế đáng nhớ về mức nhất quán trên Cosmos DB: bạn nâng được cho từng truy vấn nhưng không hạ được. Chọn mức mặc định vừa đủ rồi nâng ở chỗ cần, chứ đừng đặt Strong cho cả tài khoản.

Đáp án

B — Microsoft.Resources/deployments

Vì sao đúng

⚠ Template lồng nhau được khai như một TÀI NGUYÊN thuộc loại deployment:

⚠ {
⚠   "type": "Microsoft.Resources/deployments",
⚠   "name": "trienKhaiMang",
⚠   "properties": {
⚠     "mode": "Incremental",
⚠     "templateLink": { "uri": "..." }
⚠   }
⚠ }

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

• A (dependsOn) — ⚠ là THUỘC TÍNH khai phụ thuộc, không phải loại tài nguyên.

• D (Microsoft.Resources/deploymentScripts) — ⚠ chạy script PowerShell hoặc Bash TRONG lúc triển khai, việc khác hẳn.

• C (Microsoft.Compute/virtualMachines/extensions) — ⚠ cài extension lên máy ảo.

Ghi nhớ

⚠ Vì sao chia nhỏ template: | Lý do | Nội dung | |---|---| | ⚠ Template lớn khó đọc và khó bảo trì | | | ⚠ Tái dùng module cho nhiều dự án | | | ⚠ Nhiều người làm song song trên từng phần | | | ⚠ Triển khai sang resource group hoặc subscription KHÁC | | | ⚠ Giới hạn ARM | ⚠ template có giới hạn kích thước và số tài nguyên |

Từ khoá nhận diện:

"lồng template" → ⚠ Microsoft.Resources/deployments "chạy script khi triển khai" → ⚠ deploymentScripts "khai phụ thuộc" → ⚠ dependsOn "cài agent lên VM" → ⚠ extensions

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template có quá lớn để đọc không | ⚠ nên tách module | | Có nên chuyển sang Bicep không | ⚠ module gọn hơn nhiều | | Linked template có nơi lưu trữ truy cập được không | |

Và lý do thực dụng nhất để chuyển từ ARM JSON sang Bicep, thấy rõ ngay khi template lớn dần: khai một module trong Bicep chỉ mất một dòng, còn viết template lồng trong JSON mất cả một khối cấu hình rắc rối.