Ngân hàng đề Microsoft Azure Developer

Câu 111 Azure Container Instances

What is the Azure CLI command to delete an Azure Container Instance? Fill in the blank. az ______ _______ --resource-group myResourceGroup --name mycontainer

A delete resource
B container delete
C aci delete
D delete container

Xem giải thích

Đáp án

B — az container delete

Vì sao đúng

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

⚠ az container delete \
⚠   --resource-group myResourceGroup \
⚠   --name mycontainer

Nhóm lệnh `az container`	Hành động
⚠ `create`	⚠ tạo
⚠ `delete`	⚠ xoá
⚠ `show`	⚠ xem chi tiết
⚠ `list`	⚠ liệt kê
⚠ `logs`	⚠ xem log container
⚠ `exec`	⚠ vào shell trong container
⚠ `restart`, `stop`, `start`

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

D (delete container) — ⚠ ĐẢO thứ tự: ⚠ nhóm phải đứng trước.
A (delete resource) — ⚠ cũng đảo thứ tự, và resource là nhóm khác.
C (aci delete) — ⚠ nhóm lệnh không phải aci.

Ghi nhớ

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

Câu	Hành động	Khoá
⚠ #21505	⚠ tạo ACI	⚠ az container create
⚠ #21514 (câu này)	⚠ xoá ACI	⚠ az container delete
⚠ Cặp đối xứng	⚠ cùng nhóm, khác hành động
⚠ Cùng cái bẫy	⚠ cả hai câu đều có phương án ĐẢO thứ tự
⚠ Mẹo	⚠ Azure CLI LUÔN là nhóm trước, hành động sau

⚠ Quy tắc đặt tên của Azure CLI: | Quy tắc | Ví dụ | |---|---| | ⚠ az <nhóm> <hành động> | ⚠ az vm create | | ⚠ Nhóm lồng nhau | ⚠ az vm disk attach | | ⚠ Hành động chuẩn | ⚠ create, delete, show, list, update | | ⚠ Nhất quán | ⚠ gần như mọi dịch vụ đều theo mẫu này |

Từ khoá nhận diện:

"az container ..." → ⚠ Container Instances "az acr ..." → ⚠ Container Registry "az aks ..." → ⚠ Kubernetes Service "động từ đứng trước" → ⚠ luôn SAI

⚠ Lệnh `az container logs` — rất hữu ích	Nội dung
⚠ Xem đầu ra của container
⚠ Không cần vào máy
⚠ Thêm `--follow` để theo dõi liên tục
⚠ Khi container không chạy được	⚠ đây là nơi đầu tiên nên nhìn

⚠ Xoá ACI — lưu ý	Lưu ý
⚠ Xoá là mất hẳn, KHÔNG có thùng rác
⚠ Dữ liệu trong container mất theo	⚠ trừ khi mount volume ngoài
⚠ Mount Azure Files để giữ dữ liệu
⚠ Nguyên tắc	⚠ container là thứ dùng xong bỏ, dữ liệu phải nằm ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thứ tự nhóm và hành động có đúng không | | | Dữ liệu quan trọng có nằm ngoài container không | | | Đã xem log trước khi xoá chưa | |

Và nguyên tắc nền tảng của mọi hệ thống container, thể hiện rõ khi xoá một Container Instance: container là thứ ngắn hạn, dữ liệu cần tồn tại phải nằm ở ngoài nó.

Câu 112 Blob Storage

What Azure command line tool for Windows and Linux is designed to copy data to and from a Blob storage account, across containers, and across storage accounts?

A xcopy
B AzCopy
C Azure Storage Explorer
D bcp

Xem giải thích

Đáp án

B — AzCopy.

Vì sao đúng

⚠ AzCopy là công cụ dòng lệnh chuyên cho việc sao chép dữ liệu lưu trữ: | Sao chép được | Nội dung | |---|---| | ⚠ Máy cục bộ ↔ Blob | | | ⚠ Giữa các container | | | ⚠ Giữa các storage account | | | ⚠ Từ AWS S3 và Google Cloud Storage | | | ⚠ Blob, File, Data Lake Gen2 | |

⚠ azcopy copy \
⚠   "https://src.blob.core.windows.net/c1?<SAS>" \
⚠   "https://dst.blob.core.windows.net/c2?<SAS>" \
⚠   --recursive

Đặc điểm	Nội dung
⚠ Chạy trên Windows, Linux, macOS
⚠ Sao chép SERVER-TO-SERVER	⚠ không qua máy bạn
⚠ Tự thử lại và tiếp tục khi gián đoạn
⚠ Song song hoá cao

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

C (Azure Storage Explorer) — ⚠ công cụ ĐỒ HOẠ, không phải dòng lệnh; ⚠ nó thực ra dùng AzCopy bên dưới.
A (xcopy) — ⚠ lệnh sao chép tệp của Windows, không biết gì về Azure.
D (bcp) — ⚠ công cụ nhập xuất hàng loạt của SQL Server.

Ghi nhớ

⚠ Công cụ di chuyển dữ liệu — chọn theo tình huống: | Tình huống | Công cụ | |---|---| | ⚠ Sao chép blob và file, dòng lệnh | ⚠ AzCopy | | ⚠ Duyệt và quản lý bằng giao diện | ⚠ Storage Explorer | | ⚠ Luồng dữ liệu định kỳ | ⚠ Data Factory | | ⚠ Đồng bộ file server | ⚠ Azure File Sync | | ⚠ Khối lượng rất lớn, mạng chậm | ⚠ Data Box | | ⚠ Di chuyển máy chủ tệp | ⚠ Storage Mover |

Từ khoá nhận diện:

"dòng lệnh, sao chép blob" → ⚠ AzCopy "giao diện đồ hoạ" → ⚠ Storage Explorer "đồng bộ hai chiều liên tục" → ⚠ File Sync "hàng trăm TB" → ⚠ Data Box

⚠ Xác thực với AzCopy	Cách
⚠ `azcopy login`	⚠ dùng Entra ID — KHUYẾN NGHỊ
⚠ SAS token trong URL	⚠ tiện nhưng lộ trong lịch sử lệnh
⚠ Với script tự động	⚠ dùng managed identity hoặc service principal
⚠ Tránh	⚠ dán SAS token vào lệnh — nó nằm lại trong shell history

⚠ Tính năng đáng dùng của AzCopy	Tính năng
⚠ `sync`	⚠ chỉ chép phần khác biệt
⚠ `--recursive`	⚠ chép cả thư mục con
⚠ `--include-pattern`, `--exclude-pattern`
⚠ `jobs resume`	⚠ tiếp tục job bị gián đoạn
⚠ Với dữ liệu lớn	⚠ `sync` tiết kiệm hơn `copy` rất nhiều

⚠ Server-to-server copy — điểm mạnh nhất	Nội dung
⚠ Dữ liệu đi TRỰC TIẾP giữa hai storage account
⚠ Không qua máy chạy lệnh
⚠ Nhanh hơn nhiều, không tốn băng thông của bạn
⚠ Điều kiện	⚠ cả hai đầu đều là URL có xác thực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dùng sync thay copy cho dữ liệu lớn không | | | Xác thực bằng Entra ID hay SAS trong lệnh | | | Sao chép có đi trực tiếp server-to-server không | |

Và tính năng của AzCopy tiết kiệm nhiều thời gian và băng thông nhất khi chuyển dữ liệu giữa hai tài khoản lưu trữ: sao chép trực tiếp giữa hai máy chủ, không đi vòng qua máy của bạn.

Câu 113 Azure App Service

You have one application installed in an App Service Plan Standard S1 Tier. You have manually scaled it out to two instances. This application also has one WebJob running in the background to support it. How many VMs are running to support this?

A Two
B Four
C Three
D One

Xem giải thích

Đáp án

A — Hai.

Vì sao đúng

⚠ WebJob chạy TRÊN CHÍNH app, không tạo máy ảo riêng:

⚠ App Service Plan S1
   ⚠ scale out = 2 instance
        ↓
⚠ HAI máy ảo
        ↓
⚠ Trên mỗi máy chạy:
   ⚠ ứng dụng web
   ⚠ WebJob nền
        ↓
⚠ WebJob KHÔNG cần máy riêng

Quy tắc	Nội dung
⚠ Số VM = số instance của PLAN
⚠ App, slot, WebJob đều dùng chung
⚠ Trả tiền cho PLAN

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

C (ba) — ⚠ bẫy chính: ⚠ cộng thêm một máy cho WebJob.
B (bốn) — ⚠ nhân đôi cho cả app và WebJob.
D (một) — ⚠ bỏ qua việc đã scale out lên hai.

Ghi nhớ

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

Câu	Tình huống	Khoá
⚠ #21493	⚠ 5 app × 2 slot, plan 3 instance	⚠ BA máy ảo
⚠ #21516 (câu này)	⚠ 1 app + 1 WebJob, plan 2 instance	⚠ HAI máy ảo
⚠ Cùng một quy tắc	⚠ số VM chỉ phụ thuộc số instance của PLAN
⚠ Cùng cái bẫy	⚠ cộng thêm máy cho slot hoặc WebJob

⚠ WebJob — điều cần biết: | Điểm | Nội dung | |---|---| | ⚠ Chạy TRONG cùng tiến trình app hoặc tiến trình con | | | ⚠ Hai loại: Continuous và Triggered | | | ⚠ Continuous cần bật ALWAYS ON | ⚠ xem #21482 | | ⚠ Có thể chạy trên MỌI instance hoặc chỉ MỘT | ⚠ singleton | | ⚠ Với scale out | ⚠ WebJob thường chạy trên mọi instance — cẩn thận việc chạy trùng |

Từ khoá nhận diện:

"bao nhiêu VM" → ⚠ số instance của plan "WebJob" → ⚠ không tạo VM riêng "deployment slot" → ⚠ cũng không tạo VM riêng "scale out" → ⚠ tăng số instance, tăng số VM

⚠ Singleton WebJob — vấn đề quan trọng	Vấn đề
⚠ Scale out 2 instance thì WebJob chạy HAI bản
⚠ Có thể xử lý trùng công việc
⚠ Đánh dấu singleton để chỉ chạy MỘT bản	⚠ `settings.job` với `is_singleton: true`
⚠ Không đánh dấu	⚠ sự cố xử lý trùng rất khó chẩn đoán

⚠ WebJob và Azure Functions	So sánh
⚠ WebJob: gắn với App Service, đơn giản
⚠ Functions: xây trên WebJobs SDK, có trigger và binding phong phú
⚠ Với dự án mới	⚠ Functions thường là lựa chọn tốt hơn
⚠ WebJob hợp khi	⚠ đã có App Service và chỉ cần một tác vụ nền nhỏ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WebJob có đánh dấu singleton chưa | ⚠ nếu đã scale out | | Always On đã bật chưa | ⚠ cho WebJob liên tục | | Có nên chuyển sang Functions không | |

Và sự cố khó chẩn đoán nhất khi mở rộng ngang một App Service có WebJob: cùng một công việc nền bị xử lý hai lần vì WebJob chạy trên cả hai instance. Đánh dấu singleton là cách xử lý.

Câu 114 API Apps

What security feature exists for API apps that will either allow or prevent applications running from other domains (external websites) from calling the API?

A Cross Site Scripting (XSS)
B RBAC
C Cross-Origin Resource Sharing (CORS)
D Azure AD

Xem giải thích

Đáp án

C — Cross-Origin Resource Sharing (CORS).

Vì sao đúng

⚠ CORS quyết định trang web ở TÊN MIỀN KHÁC có gọi API của bạn được không:

⚠ Trình duyệt tại https://web-a.com
   ⚠ gọi API tại https://api-b.com
        ↓ ⚠ khác origin
⚠ Trình duyệt gửi preflight OPTIONS
        ↓
⚠ API trả header Access-Control-Allow-Origin
        ↓ ⚠ nếu khớp
⚠ Trình duyệt CHO PHÉP đọc phản hồi

Cấu hình CORS trên App Service	Nội dung
⚠ Danh sách origin được phép
*⚠ `` cho phép mọi origin**	⚠ cẩn trọng
⚠ Bật `Access-Control-Allow-Credentials`	⚠ *không dùng chung với ``**
⚠ Cấu hình ở	⚠ API → CORS trong Portal, hoặc trong mã

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

A (XSS) — ⚠ là một LOẠI TẤN CÔNG, không phải cơ chế kiểm soát.
B (RBAC) — ⚠ phân quyền cho NGƯỜI DÙNG và dịch vụ Azure, không liên quan tới nguồn gốc trang web.
D (Azure AD) — ⚠ xác thực danh tính, không kiểm soát origin.

Ghi nhớ

⚠ CORS — hiểu đúng bản chất: | Sự thật | Nội dung | |---|---| | ⚠ CORS là cơ chế của TRÌNH DUYỆT | | | ⚠ Nó KHÔNG bảo vệ API khỏi tấn công | | | ⚠ Công cụ như curl hay Postman BỎ QUA CORS hoàn toàn | | | ⚠ CORS chỉ ngăn | ⚠ JavaScript trên trang khác ĐỌC được phản hồi | | ⚠ Bảo vệ API thật sự | ⚠ cần xác thực, phân quyền, rate limit |

Từ khoá nhận diện:

"trang web tên miền khác gọi API" → ⚠ CORS "chèn script vào trang" → ⚠ XSS, một loại tấn công "ai được làm gì trên tài nguyên Azure" → ⚠ RBAC "xác thực người dùng" → ⚠ Entra ID

⚠ Lỗi CORS thường gặp	Triệu chứng
⚠ Trình duyệt báo lỗi CORS, Postman thì chạy được	⚠ dấu hiệu kinh điển
⚠ Quên thêm origin của môi trường staging
*⚠ Dùng `` cùng với credentials**	⚠ trình duyệt TỪ CHỐI
⚠ Preflight OPTIONS bị chặn	⚠ do tường lửa hoặc mã

⚠ Đừng dùng `*` cho API riêng tư	Lý do
⚠ Cho phép MỌI trang web gọi API của bạn
⚠ Kết hợp với session cookie có thể gây rủi ro
⚠ Nên	⚠ liệt kê chính xác các origin cần thiết

⚠ Nhắc lại: CORS không phải bảo mật	Nhắc lại
⚠ Nó là cơ chế BẢO VỆ NGƯỜI DÙNG của trình duyệt
⚠ Không phải hàng rào bảo vệ máy chủ
⚠ Ai đó vẫn gọi API được	⚠ bằng công cụ ngoài trình duyệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CORS có đang để * không | | | API có xác thực độc lập với CORS không | | | Origin của staging đã được thêm chưa | |

Và hiểu lầm phổ biến nhất về CORS, khiến nhiều người tưởng API của mình đã được bảo vệ: nó chỉ có tác dụng trong trình duyệt. Một lệnh curl bỏ qua nó hoàn toàn.

Câu 115 Azure Functions

Which of the following is a negative consequence of running Azure Functions in the Consumption service plan?

A It's the most expensive way to run Functions
B The cold start problem
C Performance is not as good as an App Service Plan
D Functions can only be developed inside the Portal and not locally

Xem giải thích

Đáp án

B — Vấn đề COLD START (khởi động nguội).

Vì sao đúng

⚠ Gói Consumption co giãn về 0, và đó chính là nguồn gốc của cold start:

⚠ Không có yêu cầu trong một thời gian
        ↓
⚠ Azure thu hồi mọi instance
        ↓ ⚠ yêu cầu mới tới
⚠ Phải KHỞI TẠO lại từ đầu
   ⚠ cấp phát máy
   ⚠ nạp runtime
   ⚠ nạp mã và thư viện
        ↓
⚠ Yêu cầu đầu tiên CHẬM
   ⚠ vài trăm mili giây tới vài giây

Yếu tố ảnh hưởng cold start	Nội dung
⚠ Ngôn ngữ	⚠ .NET và Java thường chậm hơn Node và Python
⚠ Kích thước gói triển khai	⚠ càng lớn càng chậm
⚠ Số thư viện phụ thuộc
⚠ Có tích hợp VNet không

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

A (cách chạy Functions đắt nhất) — ⚠ NGƯỢC: ⚠ Consumption thường ⚠ rẻ nhất với tải thưa.
C (hiệu năng kém hơn App Service Plan) — ⚠ không chính xác: ⚠ khi đã ấm, hiệu năng tương đương.
D (chỉ phát triển được trong Portal) — ⚠ SAI: ⚠ Core Tools cho phép phát triển cục bộ với mọi gói.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #21440 và #21477 về Azure Functions.

Câu	Hỏi gì	Khoá
⚠ #21440	⚠ ngôn ngữ không hỗ trợ sẵn	⚠ Custom Handlers
⚠ #21477	⚠ hàm gọi hàm	⚠ Durable Functions
⚠ #21518 (câu này)	⚠ nhược điểm gói Consumption	⚠ cold start
⚠ Ba câu	⚠ phân biệt TÍNH NĂNG lập trình và GÓI hạ tầng

⚠ Bốn gói lưu trữ của Functions: | Gói | Cold start | Chi phí | |---|---|---| | ⚠ Consumption | ⚠ CÓ | ⚠ rẻ nhất với tải thưa | | ⚠ Flex Consumption | ⚠ giảm nhiều, có always-ready instance | | | ⚠ Premium | ⚠ KHÔNG — luôn có instance ấm | ⚠ đắt hơn | | ⚠ Dedicated | ⚠ không, nếu bật Always On | ⚠ trả cho plan |

Từ khoá nhận diện:

"yêu cầu đầu tiên chậm" → ⚠ cold start "không muốn cold start, cần VNet" → ⚠ Premium plan "tải thưa, muốn rẻ" → ⚠ Consumption "đã có App Service Plan" → ⚠ Dedicated

⚠ Giảm cold start ở gói Consumption	Cách
⚠ Giảm kích thước gói triển khai
⚠ Giảm số thư viện phụ thuộc
⚠ Chọn ngôn ngữ khởi động nhanh
⚠ Tránh việc nặng trong hàm khởi tạo
⚠ Dùng timer trigger để giữ ấm	⚠ cách thủ công, không lý tưởng
⚠ Giải pháp triệt để	⚠ chuyển sang Premium hoặc Flex Consumption

⚠ Khi nào cold start là vấn đề thật	Khi nào
⚠ API do người dùng gọi trực tiếp	⚠ họ cảm nhận được độ trễ
⚠ Yêu cầu SLA về thời gian phản hồi
⚠ KHÔNG phải vấn đề khi	⚠ xử lý theo lô, tác vụ nền, hàng đợi
⚠ Nghĩa là	⚠ đừng trả tiền cho Premium nếu cold start không ảnh hưởng ai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai chịu ảnh hưởng của cold start | ⚠ người dùng hay chỉ hệ thống nền | | Gói triển khai lớn bao nhiêu | | | Có việc nặng nào trong hàm khởi tạo không | |

Và câu hỏi cần trả lời trước khi trả tiền cho gói Premium chỉ vì cold start: có ai thật sự chờ câu trả lời đó không? Với tác vụ nền xử lý hàng đợi, độ trễ vài giây ở lần đầu là hoàn toàn vô hại.

Câu 116 Azure App Service

You are developing an application that needs to store user preferences in a database. You decide to use Azure App Service Web Apps for hosting your application. Which of the following methods would you use to securely store and manage sensitive application settings, such as connection strings and API keys, without hardcoding them in your application's source code?

A
Store the sensitive information in application code as environment variables.
B
Use Azure Blob Storage to store the sensitive information as text files.
C
Store the sensitive information in a local configuration file within the application's directory.
D
Use Azure App Service Application Settings feature to store sensitive information.

Xem giải thích

Đáp án

D — Dùng Application Settings của Azure App Service

Vì sao đúng

Application Settings được mã hoá khi lưu, và được đưa vào ứng dụng dưới dạng biến môi trường lúc chạy — nên mã nguồn chỉ đọc biến chứ không chứa giá trị. Chúng cũng khai riêng cho từng deployment slot, nên môi trường dàn dựng và production dùng hai bộ giá trị khác nhau.

Với dữ liệu thật sự nhạy cảm thì bước tiếp theo là để giá trị trong Key Vault và trỏ tới nó bằng Key Vault reference.

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

A. Đưa vào mã ứng dụng dưới dạng biến môi trường — nếu giá trị nằm trong mã thì nó nằm luôn trong kho mã, trong lịch sử commit và trong mọi bản sao.
C. Để trong tệp cấu hình cục bộ — cùng vấn đề, và tệp đó thường bị đưa vào gói triển khai.
B. Lưu thành tệp văn bản trên Blob Storage — không có mã hoá theo mặc định cho mục đích này, và bạn lại cần một bí mật khác để truy cập được nó.

Câu 117 Containers

Under which menu item of the Azure Portal can you find the logs for a container instance?

A Monitoring > Metrics
B Settings > Container > Logs
C Overview
D Monitoring > Alerts

Xem giải thích

Đáp án

B — Settings → Container → Logs.

Vì sao đúng

⚠ Log của Container Instance nằm trong chính mục Container của tài nguyên:

⚠ Container Instance
   ⚠ Overview
   ⚠ Settings
      ⚠ Containers
         ⚠ Logs          ← đầu ra của container
         ⚠ Events        ← sự kiện vòng đời
         ⚠ Properties
         ⚠ Connect       ← vào shell

Ba tab của mục Containers	Nội dung
⚠ Logs	⚠ stdout và stderr của container
⚠ Events	⚠ kéo ảnh, khởi động, dừng, lỗi
⚠ Connect	⚠ mở shell bên trong container

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

A (Monitoring → Metrics) — ⚠ hiển thị SỐ LIỆU: ⚠ CPU, bộ nhớ, mạng; ⚠ không phải log.
D (Monitoring → Alerts) — ⚠ quản lý cảnh báo.
C (Overview) — ⚠ thông tin tổng quan: ⚠ trạng thái, IP, FQDN.

Ghi nhớ

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

Câu	Hỏi gì	Khoá
⚠ #21505	⚠ tạo ACI	⚠ az container create
⚠ #21514	⚠ xoá ACI	⚠ az container delete
⚠ #21520 (câu này)	⚠ xem log ở đâu trên Portal	⚠ Settings → Container → Logs
⚠ Ba câu	⚠ vẽ trọn vòng đời quản lý ACI
⚠ Tương đương CLI	⚠ `az container logs`

⚠ Ba nơi xem thông tin khi container gặp vấn đề: | Nơi | Cho biết | |---|---| | ⚠ Logs | ⚠ ứng dụng bên trong nói gì | | ⚠ Events | ⚠ có kéo được ảnh không, có khởi động được không | | ⚠ Metrics | ⚠ có bị hết CPU hay bộ nhớ không | | ⚠ Thứ tự chẩn đoán | ⚠ Events trước, rồi Logs, rồi Metrics |

Từ khoá nhận diện:

"đầu ra của container" → ⚠ Logs "không kéo được ảnh" → ⚠ Events "CPU, bộ nhớ" → ⚠ Metrics "vào bên trong container" → ⚠ Connect hoặc az container exec

⚠ Sự kiện thường thấy ở tab Events	Sự kiện
⚠ `Pulling`	⚠ đang kéo ảnh
⚠ `Pulled`	⚠ kéo xong
⚠ `Started`	⚠ container đã chạy
⚠ `Failed`	⚠ lỗi — thường do sai tên ảnh hoặc thiếu quyền
⚠ Lỗi kéo ảnh	⚠ kiểm tra tên ảnh và thông tin đăng nhập registry

⚠ Giới hạn của log ACI	Giới hạn
⚠ Chỉ giữ đầu ra gần đây
⚠ Container bị xoá là mất log
⚠ Với môi trường thật	⚠ gửi log tới Log Analytics bằng `--log-analytics-workspace`
⚠ Nếu không	⚠ container lỗi rồi bị xoá là mất mọi dấu vết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có gửi log tới Log Analytics không | ⚠ để giữ được sau khi container biến mất | | Tab Events có báo lỗi kéo ảnh không | | | Container có bị hết bộ nhớ không | |

Và cấu hình cần thêm cho mọi Container Instance chạy thật, tránh việc mất dấu vết khi sự cố: gửi log sang Log Analytics workspace. Container biến mất thì log trong nó cũng biến mất theo.

Câu 118 Container

What type of compute is Azure Container Instances considered to be?

A Virtual Machine Scale Set
B Infrastructure as a Service
C Serverless
D Hybrid Compute

Xem giải thích

Đáp án

C — Serverless.

Vì sao đúng

⚠ ACI đáp ứng đủ các tiêu chí của điện toán serverless: | Tiêu chí serverless | ACI | |---|---| | ⚠ KHÔNG quản lý máy chủ hay cụm | ⚠ đúng | | ⚠ Tính tiền theo mức DÙNG THẬT | ⚠ theo giây, theo vCPU và GB | | ⚠ Khởi động nhanh | ⚠ vài giây | | ⚠ Không phải vá lỗi hệ điều hành | ⚠ đúng |

⚠ Bạn chỉ cần: ảnh container
        ↓
⚠ Azure lo: máy chủ, mạng, hệ điều hành
        ↓
⚠ Chạy xong: dừng và ngừng tính tiền

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

B (Infrastructure as a Service) — ⚠ IaaS đòi bạn quản lý HỆ ĐIỀU HÀNH: ⚠ với ACI bạn ⚠ không chạm tới máy chủ nào.
A (Virtual Machine Scale Set) — ⚠ là nhóm máy ảo tự co giãn, hoàn toàn khác.
D (Hybrid Compute) — ⚠ là Azure Arc, quản lý máy chủ ngoài Azure.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bức tranh về ACI cùng #21436, #21450, #21505, #21514, #21520.

Câu	Hỏi gì	Khoá
⚠ #21450	⚠ FQDN của ACI	⚠ có VÙNG ở giữa
⚠ #21505 / #21514	⚠ lệnh tạo và xoá	⚠ az container create/delete
⚠ #21520	⚠ xem log ở đâu	⚠ Settings → Container → Logs
⚠ #21521 (câu này)	⚠ thuộc loại điện toán nào	⚠ serverless
⚠ Sáu câu	⚠ vẽ trọn chủ đề Container Instances qua hai lô

⚠ Thang điện toán trên Azure — từ ít tới nhiều việc quản lý: | Lựa chọn | Bạn quản lý | |---|---| | ⚠ Functions | ⚠ chỉ mã | | ⚠ Container Instances | ⚠ chỉ ảnh container | | ⚠ Container Apps | ⚠ container + cấu hình co giãn | | ⚠ App Service | ⚠ ứng dụng + plan | | ⚠ AKS | ⚠ cụm, node pool, nâng cấp | | ⚠ Virtual Machines | ⚠ toàn bộ hệ điều hành |

Từ khoá nhận diện:

"chạy container không quản lý gì" → ⚠ ACI, serverless "nhóm VM tự co giãn" → ⚠ VM Scale Set "quản lý máy ngoài Azure" → ⚠ Azure Arc "cần Kubernetes đầy đủ" → ⚠ AKS

⚠ Hạn chế của ACI cần biết	Hạn chế
⚠ KHÔNG tự co giãn	⚠ muốn nhiều bản phải tự tạo
⚠ KHÔNG có cân bằng tải sẵn
⚠ Không có cập nhật cuốn chiếu
⚠ Không phù hợp cho dịch vụ chạy dài có tải biến động
⚠ Khi cần những thứ đó	⚠ Container Apps hoặc AKS

⚠ Virtual Nodes — cách kết hợp ACI với AKS	Nội dung
⚠ AKS đẩy pod sang ACI khi cần bùng nổ
⚠ Không phải chờ thêm node vào cụm
⚠ Rất nhanh khi có đợt tải đột biến
⚠ Ý tưởng	⚠ cụm cố định cho tải nền, ACI cho phần đỉnh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần tự co giãn không | ⚠ ACI không có | | Container chạy ngắn hay chạy dài | | | Có cần cân bằng tải không | |

Và ranh giới rõ ràng nhất giữa ACI và các lựa chọn khác: nó tuyệt vời cho những container chạy rồi thoát, và không phù hợp cho dịch vụ cần luôn sẵn sàng với tải biến động.

Câu 119 Security tools and features

You are developing an Azure Function that processes data from an Azure Blob Storage account. You want to ensure that the function has the necessary permissions to read from the Blob Storage without exposing any secrets in the code. What is the best approach to achieve this?

A
Use a connection string stored in the application settings of the Azure Function.
B
Assign a Managed Identity to the Azure Function and grant it the required permissions on the Blob Storage account.
C
Use a Shared Access Signature (SAS) token to grant the Azure Function access to the Blob Storage.
D
Store the storage account key in the Azure Key Vault and retrieve it in the function code.

Xem giải thích

Đáp án

B — Gán managed identity cho Azure Function và cấp quyền cho danh tính đó

Vì sao đúng

Managed identity gỡ bỏ hoàn toàn việc phải giữ bí mật: Azure cấp cho hàm một danh tính do nền tảng quản lý, hàm lấy token từ điểm cuối cục bộ, và bạn cấp cho danh tính đó vai Storage Blob Data Reader. Không có chuỗi kết nối, khoá hay token nào tồn tại ở đâu cả — nên không có gì để rò rỉ và không có gì phải xoay vòng.

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

A. Chuỗi kết nối trong application settings — 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ữ, rộng hơn nhiều so với nhu cầu đọc một container.
C. Dùng SAS token — hẹp hơn chuỗi kết nối nhưng có thời hạn, nên phải có cơ chế tự động tạo lại; quên là hàm chết lúc nửa đêm.
D. Để khoá trong Key Vault rồi lấy ra — an toàn hơn nhưng vẫn là quản lý bí mật; và để lấy được từ Key Vault thì hàm vẫn cần một danh tính, tức là bạn vẫn phải dùng managed identity.

Câu 120 Security tools and features

What is the recommended way within Azure to store secrets such as private cryptographic keys?

A In an Azure Storage account private blob container
B Within the application code
C Azure Advanced Threat Protection (ATP)
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 (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á.
B (trong mã ứng dụng) — ⚠ cách tệ nhất: ⚠ mã nằm trong Git và ai cũng đọc được.
C (Advanced Threat Protection) — ⚠ là công cụ PHÁT HIỆN, không lưu trữ gì.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là mảnh ghép cuối của chùm quản lý bí mật.

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
⚠ #21523 (câu này)	⚠ nơi khuyến nghị lưu bí mật	⚠ Key Vault
⚠ Bốn câu	⚠ vẽ trọn kiến trúc quản lý bí mật trên Azure

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

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Đáp án

Vì sao đúng

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

Ghi nhớ