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

Đáp án

B — Configuration → General Settings.

Vì sao đúng

⚠ Phiên bản runtime nằm trong trang General Settings của mục Configuration:

⚠ App Service → Configuration
   ⚠ Application settings   ← biến môi trường
   ⚠ Connection strings
   ⚠ GENERAL SETTINGS       ← phiên bản runtime
      ⚠ Stack: Python
      ⚠ Major version: 3
      ⚠ Minor version: 3.10

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

• A (Deployment Center) — ⚠ cấu hình NGUỒN triển khai: ⚠ GitHub, Azure Repos, container registry.

• D (Settings → Properties) — ⚠ chỉ hiển thị thông tin đọc: ⚠ URL, trạng thái, subscription.

• C (App Service Plan → Apps) — ⚠ liệt kê các app trên plan, không cấu hình runtime.

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ề General Settings qua hai lô.

⚠ Các mục cấu hình chính của App Service: | Mục | Nội dung | |---|---| | ⚠ Configuration | ⚠ app settings, connection strings, general settings | | ⚠ Deployment Center | ⚠ nguồn và phương thức triển khai | | ⚠ Scale up / Scale out | ⚠ bậc và số instance | | ⚠ Deployment slots | | | ⚠ Identity | ⚠ managed identity | | ⚠ Networking | ⚠ VNet integration, private endpoint | | ⚠ TLS/SSL settings | ⚠ chứng chỉ và tên miền |

Từ khoá nhận diện:

"phiên bản runtime" → ⚠ Configuration → General Settings "biến môi trường" → ⚠ Configuration → Application settings "nguồn triển khai" → ⚠ Deployment Center "managed identity" → ⚠ Identity

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phiên bản runtime hiện tại còn được hỗ trợ không | | | Đổi runtime có thử ở slot trước không | | | Ứng dụng có phụ thuộc phiên bản cụ thể không | |

Và thao tác nên làm trước mỗi lần đổi phiên bản runtime trên môi trường thật: thử ở slot staging rồi swap. Đổi trực tiếp trên production nghĩa là khởi động lại ứng dụng với một runtime chưa được kiểm chứng.

Đáp án

D — az container create

Vì sao đúng

⚠ Cấu trúc lệnh Azure CLI luôn là az <nhóm> <hành động>:

⚠ az container create \
⚠   --resource-group myResourceGroup \
⚠   --name mycontainer \
⚠   --image mcr.microsoft.com/azuredocs/aci-helloworld \
⚠   --dns-name-label aci-demo \
⚠   --ports 80

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

• A (create container) và D-sai (delete container) — ⚠ ĐẢO thứ tự: ⚠ Azure CLI luôn là nhóm rồi mới tới hành động.

• C (aci create) — ⚠ nhóm lệnh KHÔNG phải aci; ⚠ đó là tên viết tắt của dịch vụ, không phải tên nhóm CLI.

• B (container aci) — ⚠ không phải lệnh hợp lệ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #21514 trong cùng lô.

⚠ Tên nhóm lệnh CLI không phải lúc nào cũng là tên viết tắt dịch vụ: | Dịch vụ | Nhóm lệnh CLI | |---|---| | ⚠ Container Instances (ACI) | ⚠ az container | | ⚠ Container Registry (ACR) | ⚠ az acr | | ⚠ Kubernetes Service (AKS) | ⚠ az aks | | ⚠ App Service | ⚠ az webapp | | ⚠ Functions | ⚠ az functionapp | | ⚠ Storage | ⚠ az storage | | ⚠ Bẫy | ⚠ ACI dùng container, không dùng aci |

Từ khoá nhận diện:

"tạo container đơn lẻ" → ⚠ az container create "registry" → ⚠ az acr "cụm Kubernetes" → ⚠ az aks "web app" → ⚠ az webapp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhóm lệnh có đúng không | ⚠ container chứ không phải aci | | Restart policy có phù hợp không | | | Biến môi trường nhạy cảm có dùng --secure- không | |

Và cấu hình dễ gây tốn tiền nhất khi chạy tác vụ theo lô trên Container Instances: để restart policy mặc định là Always. Container chạy xong thoát, Azure khởi động lại, và vòng lặp đó tính tiền vô tận.

Đáp án

A — SAI (FALSE).

Vì sao đúng

⚠ Azure Functions KHÔNG có trigger email gốc: | Trigger có sẵn của Functions | Nội dung | |---|---| | ⚠ HTTP | | | ⚠ Timer | | | ⚠ Blob, Queue, Table | | | ⚠ Service Bus, Event Hub, Event Grid | | | ⚠ Cosmos DB change feed | | | ⚠ SignalR, Kafka, RabbitMQ | | | ⚠ KHÔNG có | ⚠ email trigger |

⚠ Muốn phản ứng khi có email
        ↓
⚠ Cách 1: LOGIC APPS
   ⚠ có connector Outlook, Gmail
   ⚠ Logic App bắt email rồi gọi Function
        ↓
⚠ Cách 2: Microsoft Graph
   ⚠ đăng ký webhook subscription
   ⚠ Graph gọi HTTP trigger của Function

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

• B (ĐÚNG) — ⚠ SAI: ⚠ không có tích hợp email gốc nào trong danh sách trigger.

Ghi nhớ

⚠ Functions và Logic Apps — phân công: | Tiêu chí | Functions | Logic Apps | |---|---|---| | ⚠ Cách xây | ⚠ viết MÃ | ⚠ kéo thả | | ⚠ Connector SaaS | ⚠ rất ít | ⚠ hàng trăm | | ⚠ Email, Salesforce, SharePoint | ⚠ KHÔNG có sẵn | ⚠ có connector | | ⚠ Logic phức tạp | ⚠ mạnh | ⚠ hạn chế | | ⚠ Kết hợp | ⚠ Logic App làm cầu nối, Function làm xử lý |

Từ khoá nhận diện:

"email, Salesforce, SharePoint, Teams" → ⚠ Logic Apps connector "blob, queue, HTTP, timer" → ⚠ Functions trigger "webhook từ Microsoft 365" → ⚠ Graph subscription + HTTP trigger "quy trình nghiệp vụ kéo thả" → ⚠ Logic Apps

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nguồn sự kiện là dịch vụ Azure hay ứng dụng SaaS | | | Có connector Logic Apps cho nguồn đó không | | | Graph subscription có cơ chế gia hạn chưa | |

Và quy tắc phân biệt nhanh giữa hai dịch vụ, dùng được cho mọi câu hỏi kiểu này: Functions kết nối với hạ tầng Azure, Logic Apps kết nối với thế giới ứng dụng bên ngoài.

Đáp án

D — Windows, Linux và macOS.

Vì sao đúng

⚠ Azure Files dùng giao thức SMB chuẩn, nên mọi hệ điều hành hỗ trợ SMB đều mount được: | Hệ điều hành | Cách mount | |---|---| | ⚠ Windows | ⚠ net use Z: \\... | | ⚠ Linux | ⚠ mount -t cifs | | ⚠ macOS | ⚠ Finder hoặc mount_smbfs | | ⚠ Ngoài ra | ⚠ NFS 4.1 cho Linux ở bậc Premium |

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

• B (chỉ Windows và Linux) — ⚠ thiếu macOS.

• C (chỉ Windows) — ⚠ quá hẹp: ⚠ SMB là giao thức mở.

• A (chỉ Android và iOS) — ⚠ ngược hoàn toàn: ⚠ đó là các nền tảng ít hỗ trợ nhất.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh chùm về Azure Files cùng #19599, #19641, #21423.

⚠ Hai giao thức của Azure Files: | Giao thức | Đặc điểm | |---|---| | ⚠ SMB 3.x | ⚠ mọi bậc, đa nền tảng, có mã hoá | | ⚠ NFS 4.1 | ⚠ CHỈ bậc Premium, chỉ Linux, KHÔNG mã hoá đường truyền | | ⚠ Chọn NFS khi | ⚠ ứng dụng Linux quen NFS, và mạng đã được bảo vệ |

Từ khoá nhận diện:

"mount như ổ đĩa, đa nền tảng" → ⚠ Azure Files SMB "NFS" → ⚠ chỉ Premium, chỉ Linux "cache cục bộ ở chi nhánh" → ⚠ Azure File Sync "truy cập qua URL" → ⚠ Blob

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cổng 445 có bị chặn không | ⚠ nguyên nhân số một | | Xác thực bằng khoá hay bằng danh tính | | | Cần SMB hay NFS | |

Và điều làm Azure Files khác biệt so với mọi dịch vụ lưu trữ khác của Azure: nó nói giao thức tệp tiêu chuẩn, nên ứng dụng cũ dùng được ngay mà không phải sửa một dòng mã.

Đáp án

B — Soft Delete (xoá mềm).

Vì sao đúng

⚠ Soft delete giữ lại blob đã xoá trong thời gian lưu giữ đặt trước:

⚠ Xoá blob
        ↓ ⚠ soft delete đang BẬT
⚠ Chuyển sang trạng thái "đã xoá mềm"
        ↓ ⚠ trong thời hạn (1-365 ngày)
⚠ Khôi phục được bằng Undelete
        ↓ ⚠ hết hạn
⚠ Xoá vĩnh viễn

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

• A (Immutable blobs) — ⚠ NGĂN xoá ngay từ đầu: ⚠ chính sách WORM cho tuân thủ; ⚠ nó ⚠ phòng ngừa, không ⚠ khôi phục.

• C (Change Feed) — ⚠ nhật ký thay đổi có thứ tự: ⚠ cho biết đã có gì thay đổi, không khôi phục nội dung.

• D (Azure Policy) — ⚠ quản trị và tuân thủ, không liên quan tới khôi phục.

Ghi nhớ

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

⚠ Năm tính năng bảo vệ dữ liệu Blob: | Tính năng | Chức năng | |---|---| | ⚠ Soft delete (blob) | ⚠ khôi phục blob đã xoá | | ⚠ Soft delete (container) | ⚠ khôi phục cả container | | ⚠ Versioning | ⚠ giữ phiên bản khi GHI ĐÈ | | ⚠ Snapshot | ⚠ ảnh chụp thủ công | | ⚠ Point-in-time restore | ⚠ khôi phục container về mốc thời gian | | ⚠ Immutability (WORM) | ⚠ CẤM xoá và sửa |

Từ khoá nhận diện:

"khôi phục tệp đã XOÁ" → ⚠ soft delete "khôi phục nội dung bị GHI ĐÈ" → ⚠ versioning "khôi phục cả container về mốc thời gian" → ⚠ point-in-time restore "cấm xoá vì tuân thủ" → ⚠ immutable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật cả soft delete lẫn versioning chưa | | | Thời hạn giữ là bao nhiêu ngày | | | Có nhầm chữ cái từ lần gặp trước không | |

Và điều năm câu trùng lặp trong lô này nhắc lại một lần nữa: cùng một câu hỏi xuất hiện ở nhiều chứng chỉ với thứ tự phương án khác nhau. Nhớ nội dung, đừng nhớ chữ cái.

Đáp án

A — Bạn KHÔNG THỂ. Muốn chuyển ứng dụng sang vùng khác thì phải nhân bản (clone) hoặc triển khai lại từ đầu.

Vì sao đúng

⚠ Vùng của App Service gắn với App Service Plan, và không đổi được:

⚠ App Service Plan tạo ở West US
        ↓
⚠ Mọi app trên plan đó nằm ở West US
        ↓ ⚠ muốn sang East US
⚠ Tạo plan MỚI ở East US
⚠ Tạo app MỚI trên plan đó
⚠ Triển khai lại mã nguồn
⚠ Chuyển tên miền và cấu hình

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

• D (dùng menu Move trong Portal) — ⚠ menu Move chỉ chuyển giữa RESOURCE GROUP hoặc SUBSCRIPTION, ⚠ KHÔNG chuyển vùng.

• B (chỉ làm được bằng PowerShell hoặc CLI) — ⚠ SAI: ⚠ không công cụ nào chuyển vùng được.

• C (chuyển App Service Plan sang vùng khác) — ⚠ plan cũng KHÔNG chuyển vùng được.

Ghi nhớ

⚠ Những thứ KHÔNG đổi được sau khi tạo trên Azure: | Tài nguyên | Không đổi được | |---|---| | ⚠ App Service Plan | ⚠ vùng, hệ điều hành | | ⚠ Storage Account | ⚠ vùng, namespace phân cấp | | ⚠ Cosmos DB | ⚠ API, partition key | | ⚠ VNet | ⚠ vùng | | ⚠ Hầu hết tài nguyên | ⚠ VÙNG | | ⚠ Quy tắc chung | ⚠ vùng là quyết định gần như vĩnh viễn |

Từ khoá nhận diện:

"chuyển sang vùng khác" → ⚠ hầu như luôn là tạo mới và di chuyển "menu Move" → ⚠ chỉ resource group và subscription "clone app" → ⚠ cần bậc Premium "Azure Resource Mover" → ⚠ công cụ hỗ trợ, nhưng vẫn là tạo mới ở đích

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vùng đã chọn đúng ngay từ đầu chưa | ⚠ quyết định gần như vĩnh viễn | | Hạ tầng có mô tả bằng mã không | ⚠ giúp dựng lại ở vùng mới rất nhanh | | Có kế hoạch chuyển tên miền không | |

Và giá trị của Infrastructure as Code thể hiện rõ nhất đúng vào tình huống này: dựng lại toàn bộ hệ thống ở một vùng khác chỉ là đổi một tham số và chạy lại, thay vì tái tạo thủ công hàng chục cấu hình.

Đáp án

A — 3 bản sao.

Vì sao đúng

⚠ LRS giữ ba bản trong CÙNG một trung tâm dữ liệu:

⚠ Một trung tâm dữ liệu
   ⚠ Bản sao 1 (rack A)
   ⚠ Bản sao 2 (rack B)
   ⚠ Bản sao 3 (rack C)
        ↓
⚠ Chịu được: hỏng ổ đĩa, hỏng rack
⚠ KHÔNG chịu được: mất cả trung tâm dữ liệu

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

• C (1 bản trong mỗi availability zone) — ⚠ đó là mô tả của ZRS.

• D (6 bản) — ⚠ là GRS hoặc GZRS.

• B (1 bản) — ⚠ không có mức nào chỉ giữ một bản.

Ghi nhớ

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

⚠ Bảng nhân bản — chốt lại lần cuối: | Mức | Bản sao | Chịu được | Giá | |---|---|---|---| | ⚠ LRS | ⚠ 3 | ⚠ hỏng ổ, rack | ⚠ rẻ nhất | | ⚠ ZRS | ⚠ 3 | ⚠ mất zone | | | ⚠ GRS | ⚠ 6 | ⚠ mất vùng | | | ⚠ GZRS | ⚠ 6 | ⚠ zone + vùng | ⚠ đắt nhất |

⚠ Mẹo nhớ: | Mẹo | Nội dung | |---|---| | ⚠ Không có chữ G | ⚠ 3 bản | | ⚠ Có chữ G | ⚠ 6 bản | | ⚠ Có chữ Z | ⚠ qua các zone | | ⚠ Có RA- | ⚠ đọc được ở vùng phụ |

Từ khoá nhận diện:

"3 bản, một trung tâm dữ liệu" → ⚠ LRS "3 bản, ba zone" → ⚠ ZRS "6 bản, hai vùng" → ⚠ GRS "rẻ nhất" → ⚠ LRS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Môi trường dev có dùng mức đắt hơn cần thiết không | | | Dữ liệu có tái tạo được không | | | Đã có soft delete và versioning chưa | |

Và con số cần nhớ chắc nhất trong toàn bộ chủ đề lưu trữ Azure, vì nó xuất hiện tới bảy lần qua sáu lô: LRS và ZRS đều là ba bản, GRS và GZRS đều là sáu bản.

Đáp án

B — ARM template.

Vì sao đúng

⚠ Đề mô tả chính xác đặc điểm của ARM template: | Đặc điểm đề nêu | ARM template | |---|---| | ⚠ Định nghĩa trong tệp JSON | ⚠ đúng định dạng | | ⚠ Đưa vào kho mã nguồn | ⚠ quản lý phiên bản như mã | | ⚠ Infrastructure as Code | ⚠ đúng thuật ngữ |

⚠ {
⚠   "$schema": "...",
⚠   "resources": [{
⚠     "type": "Microsoft.DocumentDB/databaseAccounts",
⚠     ...
⚠   }]
⚠ }
        ↓
⚠ git commit → review → triển khai tự động

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

• C (PowerShell script) và D (CLI Bash) — ⚠ script MỆNH LỆNH: ⚠ mô tả các BƯỚC, không phải trạng thái mong muốn.

• A (Azure Portal) — ⚠ thao tác tay, không có tệp nào để lưu.

Ghi nhớ

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

⚠ Bốn cách cấp phát — bảng chốt: | Cách | Đặc điểm | Dùng khi | |---|---|---| | ⚠ Portal | ⚠ thủ công | ⚠ làm một lần | | ⚠ CLI / PowerShell | ⚠ script mệnh lệnh | ⚠ tác vụ vận hành lặp lại | | ⚠ ARM / Bicep | ⚠ khai báo, IaC | ⚠ triển khai nhiều môi trường | | ⚠ SDK | ⚠ nhúng trong ứng dụng | |

Từ khoá nhận diện:

"tệp JSON, Infrastructure as Code" → ⚠ ARM template "script chạy từ dòng lệnh" → ⚠ CLI, PowerShell "chỉ làm một lần" → ⚠ Portal "cú pháp gọn hơn ARM" → ⚠ Bicep

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc này lặp lại bao nhiêu lần | ⚠ quyết định có nên viết mã không | | Dev và prod có dùng chung template không | | | Đã chạy what-if trước khi deploy chưa | |

Và điều ba câu trùng lặp đầu tiên của lô này cho thấy rất rõ: bộ đề dùng chung câu hỏi giữa Data Fundamentals và Azure Developer, và mỗi lần xuất hiện lại xáo thứ tự phương án.

Đáp án

A — Point-in-time restore.

Vì sao đúng

⚠ Point-in-time restore đưa MỘT HOẶC NHIỀU container về trạng thái tại một thời điểm:

⚠ Chọn mốc thời gian trong quá khứ
        ↓
⚠ Azure khôi phục TOÀN BỘ container
   ⚠ về đúng trạng thái lúc đó
        ↓
⚠ Blob bị xoá quay lại
⚠ Blob bị ghi đè quay về bản cũ

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

• B (Soft delete) và C (Soft delete cho container) — ⚠ khôi phục TỪNG đối tượng đã xoá, ⚠ không đưa cả container về một thời điểm.

• D (Azure Backup) — ⚠ có sao lưu blob nhưng ⚠ không phải tính năng nội tại mà đề mô tả.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là bậc cao nhất trong chùm bảo vệ dữ liệu blob.

⚠ Thang bảo vệ dữ liệu blob — từ nhẹ tới mạnh: | Mức | Bảo vệ | |---|---| | ⚠ Soft delete | ⚠ blob đã xoá | | ⚠ Versioning | ⚠ blob bị ghi đè | | ⚠ Point-in-time restore | ⚠ cả container về một mốc thời gian | | ⚠ Azure Backup for Blobs | ⚠ sao lưu theo lịch, quản lý tập trung | | ⚠ Immutability | ⚠ cấm sửa xoá hoàn toàn |

Từ khoá nhận diện:

"khôi phục container về trạng thái trước" → ⚠ point-in-time restore "khôi phục một blob đã xoá" → ⚠ soft delete "khôi phục bản trước khi ghi đè" → ⚠ versioning "cấm xoá vì tuân thủ" → ⚠ immutable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ba tính năng nền đã bật đủ chưa | ⚠ soft delete, versioning, change feed | | Khoảng thời gian khôi phục là bao lâu | | | Đã thử khôi phục thật chưa | |

Và điều kiện tiên quyết dễ bị bỏ sót của point-in-time restore: nó chỉ hoạt động khi soft delete, versioning và change feed đều đã bật trước đó. Bật sau khi sự cố xảy ra thì đã muộn.

Đáp án

A — Ứng dụng LẤY secret từ Key Vault (thông qua App Configuration) thay vì ghi cứng trong tệp app.config.

Vì sao đúng

⚠ Key Vault reference cho phép tách bí mật ra khỏi cấu hình ứng dụng:

⚠ App Configuration
   ⚠ khoá "DbPassword"
   ⚠ giá trị = THAM CHIẾU tới Key Vault
        ↓
⚠ Ứng dụng đọc App Configuration
        ↓
⚠ Runtime tự lấy giá trị thật từ Key Vault
        ↓
⚠ Mã và tệp cấu hình KHÔNG chứa bí mật nào

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

• B (kết nối tới vault bằng mã trong ứng dụng) — ⚠ đó là cách THỦ CÔNG: ⚠ vẫn làm được nhưng phải viết mã; ⚠ reference giúp bạn ⚠ không phải viết gì.

• C (tự tạo Key Vault nếu chưa có) — ⚠ SAI: ⚠ vault phải tồn tại sẵn.

• D (ứng dụng sẽ dùng HTTPS) — ⚠ không liên quan.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21465 và #21428 về quản lý bí mật.

⚠ Ba dịch vụ cấu hình và bí mật: | Dịch vụ | Lưu gì | |---|---| | ⚠ App Settings | ⚠ cấu hình đơn giản của một app | | ⚠ App Configuration | ⚠ cấu hình TẬP TRUNG cho nhiều app, có feature flag | | ⚠ Key Vault | ⚠ BÍ MẬT: mật khẩu, khoá, chứng chỉ | | ⚠ Kết hợp | ⚠ App Configuration giữ cấu hình, tham chiếu Key Vault cho bí mật |

Từ khoá nhận diện:

"tham chiếu tới Key Vault" → ⚠ Key Vault reference "cấu hình tập trung, feature flag" → ⚠ App Configuration "mật khẩu, chứng chỉ" → ⚠ Key Vault "không lưu bí mật nào" → ⚠ managed identity

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn bí mật nào trong tệp cấu hình không | | | Managed identity có quyền đọc vault chưa | | | Có dùng feature flag để bật tắt an toàn không | |

Và mục tiêu cuối cùng của cả chuỗi công cụ này, đáng nhắm tới trong mọi ứng dụng: không còn một mật khẩu nào tồn tại trong mã nguồn, tệp cấu hình hay biến môi trường.