Ngân hàng đề — Microsoft Azure Fundamentals
Tìm thấy 501 câu.
- A Each Virtual Machine has a Resource Health blade
- B Azure Updates Blog
- C Azure will email you
- D Install the Azure app on your phone
Xem giải thích
Đáp án
A — Mỗi máy ảo có một tab Resource Health riêng.
Vì sao đúng
⚠ Azure có ba tầng thông tin sức khoẻ, từ rộng tới hẹp: | Tầng | Phạm vi | |---|---| | ⚠ Azure Status | ⚠ status.azure.com — sự cố TOÀN CẦU, công khai cho mọi người | | ⚠ Service Health | ⚠ sự cố ảnh hưởng tới CHÍNH các dịch vụ và vùng bạn dùng | | ⚠ Resource Health | ⚠ tình trạng của MỘT tài nguyên cụ thể |
⚠ Azure Status → ⚠ "cả thế giới có sao không"
⚠ Service Health → ⚠ "sự cố nào chạm tới tôi"
⚠ Resource Health → ⚠ "cái máy NÀY có khoẻ không"
⚠ Resource Health nằm ngay trong tab của từng tài nguyên, cho biết máy đang Available, Unavailable, Degraded hay Unknown, kèm lý do và lịch sử.
Vì sao các phương án khác sai
-
C (Azure sẽ gửi email cho bạn) — ⚠ KHÔNG tự động; phải tự tạo Service Health alert kèm Action Group thì mới có thư.
-
B (blog Azure Updates) — ⚠ thông báo tính năng mới, không phải sự cố đang diễn ra.
-
D (cài ứng dụng Azure trên điện thoại) — ⚠ là một cách XEM lại chính những thông tin trên, không phải nguồn thông tin riêng.
Ghi nhớ
⚠ Resource Health phân biệt nguyên nhân — điều rất hữu ích khi gỡ lỗi: | Trạng thái | Nghĩa | |---|---| | ⚠ Available | ⚠ tài nguyên khoẻ | | ⚠ Unavailable — platform initiated | ⚠ do Azure, lỗi nền tảng hoặc bảo trì | | ⚠ Unavailable — user initiated | ⚠ do bạn, ví dụ vừa tắt máy | | ⚠ Degraded | ⚠ chạy nhưng giảm hiệu năng | | ⚠ Unknown | ⚠ không nhận được tín hiệu |
Từ khoá nhận diện:
"một tài nguyên cụ thể có khoẻ không" → ⚠ Resource Health "sự cố nào ảnh hưởng tới dịch vụ tôi dùng" → ⚠ Service Health "trang trạng thái công khai" → ⚠ Azure Status "chỉ số và nhật ký chi tiết" → ⚠ Azure Monitor
| ⚠ Bốn loại thông báo trong Service Health | Loại |
|---|---|
| ⚠ Service issues | ⚠ sự cố đang xảy ra |
| ⚠ Planned maintenance | ⚠ bảo trì đã lên lịch |
| ⚠ Health advisories | ⚠ thay đổi cần bạn hành động, ví dụ dịch vụ sắp ngừng |
| ⚠ Security advisories | ⚠ cảnh báo bảo mật |
| ⚠ Việc nên làm ngay | Việc |
|---|---|
| ⚠ Tạo Service Health alert | ⚠ cho các dịch vụ và vùng đang dùng |
| ⚠ Gắn Action Group | ⚠ email, SMS, webhook tới hệ thống trực |
| ⚠ Đưa vào quy trình xử lý sự cố | ⚠ kiểm tra Resource Health TRƯỚC khi đổ lỗi cho ứng dụng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã có Service Health alert chưa | ⚠ mặc định KHÔNG có | | Cảnh báo có tới đúng người đang trực không | | | Khi có sự cố, ai là người kiểm tra Resource Health đầu tiên | |
Và mẹo tiết kiệm thời gian nhất khi hệ thống có sự cố: mở Resource Health trước khi bắt đầu gỡ lỗi ứng dụng. Nếu nền tảng đang có vấn đề thì mọi phút bỏ ra đọc log ứng dụng đều lãng phí.
Which concept describes the ability to run your applications and access data in another environment quickly after an outage or failure?
- A Business Continuity / Disaster Recovery (BC/DR)
- B Azure Devops
-
C
Reproducible deployments
-
D
Azure Policy
Xem giải thích
Đáp án
A — Business Continuity / Disaster Recovery (BC/DR) — liên tục kinh doanh và khôi phục sau thảm hoạ.
Vì sao đúng
⚠ BC/DR là hai vế của cùng một câu chuyện: | Vế | Nội dung | |---|---| | ⚠ Business Continuity | ⚠ làm sao GIỮ hoạt động kinh doanh chạy tiếp | | ⚠ Disaster Recovery | ⚠ làm sao KHÔI PHỤC hệ thống sau sự cố lớn |
⚠ Hai chỉ tiêu định lượng của BC/DR: | Chỉ tiêu | Câu hỏi | |---|---| | ⚠ RTO — Recovery Time Objective | ⚠ chấp nhận ngừng bao LÂU | | ⚠ RPO — Recovery Point Objective | ⚠ chấp nhận mất bao nhiêu DỮ LIỆU |
⚠ Sự cố xảy ra
← ⚠ RPO → | ← ⚠ RTO →
⚠ Bản sao cuối ⚠ Sự cố ⚠ Hoạt động trở lại
Vì sao các phương án khác sai
-
B (Azure DevOps) — ⚠ bộ công cụ phát triển phần mềm.
-
C (triển khai lặp lại được) — ⚠ là một KỸ THUẬT hỗ trợ BC/DR, không phải khái niệm được hỏi.
-
D (Azure Policy) — ⚠ áp luật lên cấu hình tài nguyên.
Ghi nhớ
⚠ Công cụ BC/DR trên Azure: | Công cụ | Việc | |---|---| | ⚠ Azure Backup | ⚠ sao lưu VM, file, CSDL — quyết định RPO | | ⚠ Azure Site Recovery | ⚠ sao chép và chuyển đổi dự phòng sang vùng khác — quyết định RTO | | ⚠ Geo-redundant storage (GRS) | ⚠ dữ liệu tự sao sang vùng ghép đôi | | ⚠ Geo-replication của CSDL | ⚠ bản sao đọc được ở vùng khác | | ⚠ Region pairs | ⚠ Azure không cập nhật hai vùng cặp cùng lúc |
Từ khoá nhận diện:
"chạy tiếp ở môi trường khác sau sự cố" → ⚠ BC/DR "mất bao nhiêu dữ liệu là chấp nhận được" → ⚠ RPO, giải bằng tần suất sao lưu "ngừng bao lâu là chấp nhận được" → ⚠ RTO, giải bằng cơ chế chuyển đổi dự phòng "chịu lỗi thành phần, không phải thảm hoạ" → ⚠ high availability, KHÁC DR
| ⚠ Ba mức dự phòng lưu trữ | Mức |
|---|---|
| ⚠ LRS | ⚠ 3 bản trong MỘT trung tâm dữ liệu |
| ⚠ ZRS | ⚠ 3 bản qua nhiều Availability Zone |
| ⚠ GRS | ⚠ thêm 3 bản ở vùng ghép đôi cách hàng trăm dặm |
| ⚠ GZRS | ⚠ kết hợp ZRS và GRS |
| ⚠ Sai lầm phổ biến nhất về DR | Sai lầm |
|---|---|
| ⚠ Có kế hoạch nhưng CHƯA BAO GIỜ diễn tập | |
| ⚠ Sao lưu nhưng chưa từng thử khôi phục | |
| ⚠ Không ai biết ai có quyền quyết định chuyển đổi dự phòng | |
| ⚠ Kết quả | ⚠ đến lúc cần thì kế hoạch không dùng được |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | RTO và RPO đã được lãnh đạo duyệt chưa | ⚠ bằng văn bản | | Lần cuối diễn tập khôi phục là khi nào | | | Bản sao lưu đã từng được khôi phục thử chưa | ⚠ sao lưu chưa thử là chưa có sao lưu |
Và điều duy nhất chứng minh được kế hoạch DR có tác dụng: đã từng chạy thử nó. Một kế hoạch nằm trong tài liệu chưa bao giờ được diễn tập chỉ là một mong ước có định dạng đẹp.
Your company manages access to several Software-as-a-Service (SaaS) applications like Salesforce and ServiceNow. They want employees to sign in once and then access all apps without re-entering passwords.
Which Microsoft Entra ID feature should the company implement?
-
A
Privileged Identity Management
-
B
Conditional Access
-
C
Single Sign-On (SSO)
-
D
Identity Protection
Xem giải thích
Đáp án
C — Single Sign-On (SSO)
Vì sao đúng
Đề mô tả đúng định nghĩa của SSO: đăng nhập một lần rồi truy cập nhiều ứng dụng — kể cả ứng dụng SaaS của bên thứ ba như Salesforce hay ServiceNow — mà không phải nhập lại thông tin đăng nhập.
Entra ID làm được điều này với ứng dụng bên ngoài nhờ các giao thức liên kết danh tính chuẩn: SAML, OpenID Connect, OAuth. Ứng dụng SaaS tin token do Entra ID phát ra thay vì tự quản lý mật khẩu.
Lợi ích quản trị lớn nhất: nhân viên nghỉ việc thì vô hiệu hoá ở một chỗ là mất quyền ở mọi ứng dụng.
Vì sao các phương án khác sai
- B. Conditional Access — quyết định điều kiện cho phép đăng nhập, nhưng không tự tạo ra trải nghiệm đăng nhập một lần.
- A. PIM — quản lý nâng quyền tạm thời cho vai quản trị.
- D. Identity Protection — phát hiện đăng nhập rủi ro.
- A A server runs in your own environment, but places files in the cloud so that it can extend the amount of storage it has access to.
- B Your code is a mobile app that runs on iOS and Android phones, but it uses a database in the cloud.
- C Your users are inside your corporate network but your applications and data are in the cloud.
-
D
Technology that allows you to grow living tissue on top of an exoskeleton, making Terminators impossible to spot among humans.
Xem giải thích
Đáp án
A — Một máy chủ chạy trong môi trường của bạn, nhưng đặt file lên đám mây để mở rộng dung lượng lưu trữ.
Vì sao đúng
⚠ Đám mây lai = tài nguyên TẠI CHỖ kết hợp với tài nguyên ĐÁM MÂY, hoạt động cùng nhau: | Yếu tố có mặt | Trong phương án A | |---|---| | ⚠ Hạ tầng tại chỗ | ⚠ máy chủ chạy trong môi trường của bạn | | ⚠ Tài nguyên đám mây | ⚠ lưu trữ trên đám mây | | ⚠ Hai bên phối hợp | ⚠ đám mây mở rộng năng lực cho máy tại chỗ |
⚠ Azure File Sync là ví dụ đúng nghĩa nhất cho tình huống này: máy chủ file tại chỗ giữ dữ liệu nóng, phần còn lại đẩy lên Azure Files.
Vì sao các phương án khác sai
-
C (người dùng trong mạng công ty, còn ứng dụng và dữ liệu ở đám mây) — ⚠ KHÔNG phải lai; không có tài nguyên tính toán hay lưu trữ nào ở tại chỗ, đây là đám mây công cộng thuần.
-
B (ứng dụng di động dùng CSDL trên đám mây) — ⚠ điện thoại là thiết bị người dùng, không phải hạ tầng của bạn; đây cũng là đám mây công cộng.
-
D (nuôi mô sống trên bộ xương ngoài) — ⚠ phương án đùa, không liên quan.
Ghi nhớ
⚠ Đối chiếu trong lô: ⚠ câu #22065 hỏi mô hình nào mô tả việc dùng Azure mở rộng cho trung tâm dữ liệu tại chỗ (đáp án hybrid); câu này hỏi ví dụ nào là đám mây lai. ⚠ Hai câu bổ sung nhau, giữ nguyên cả hai khoá.
⚠ Ba mô hình triển khai: | Mô hình | Nội dung | |---|---| | ⚠ Public cloud | ⚠ hạ tầng dùng chung, nhà cung cấp sở hữu | | ⚠ Private cloud | ⚠ hạ tầng riêng cho một tổ chức | | ⚠ Hybrid cloud | ⚠ kết hợp cả hai, có kết nối giữa chúng |
Từ khoá nhận diện:
"vừa có tại chỗ vừa có đám mây, phối hợp" → ⚠ hybrid "người dùng ở văn phòng, mọi thứ khác trên đám mây" → ⚠ public cloud, KHÔNG phải hybrid "dùng nhiều nhà cung cấp đám mây" → ⚠ multi-cloud "quản lý máy ngoài Azure như tài nguyên Azure" → ⚠ Azure Arc
| ⚠ Câu hỏi kiểm tra nhanh có phải hybrid không | Câu hỏi |
|---|---|
| ⚠ Có tài nguyên TÍNH TOÁN hoặc LƯU TRỮ nào ở tại chỗ không | |
| ⚠ Chúng có PHỐI HỢP với phần trên đám mây không | |
| ⚠ Cả hai đều CÓ | ⚠ thì mới là hybrid |
| ⚠ Chỉ có người dùng ở văn phòng | ⚠ KHÔNG tính là hybrid |
| ⚠ Lý do thực tế chọn mô hình lai | Lý do |
|---|---|
| ⚠ Quy định buộc giữ dữ liệu tại chỗ | |
| ⚠ Hệ thống cũ chưa chuyển lên được | |
| ⚠ Đã đầu tư lớn vào phần cứng hiện có | |
| ⚠ Cần độ trễ cực thấp tại nhà máy hoặc cửa hàng | |
| ⚠ Muốn chuyển đổi dần, giảm rủi ro |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phần nào bắt buộc phải ở tại chỗ và vì sao | ⚠ viết lý do ra, xem lại định kỳ | | Kết nối giữa hai bên là gì và có dự phòng không | | | Ai quản lý phần tại chỗ | ⚠ nó không tự vá lỗi |
Và điểm hay bị hiểu sai nhất về đám mây lai: có nhân viên ngồi trong văn phòng không làm cho hệ thống trở thành hybrid. Phải có hạ tầng thật của bạn tham gia vào việc chạy hệ thống thì mới tính.
- A Azure Department of Defence
- B Azure is not available for government officials
- C Azure Government
- D Azure Public Portal
Xem giải thích
Đáp án
C — Azure Government.
Vì sao đúng
⚠ Azure Government là đám mây RIÊNG cho khu vực công của Mỹ: | Đặc điểm | Nội dung | |---|---| | ⚠ Hạ tầng tách biệt vật lý | ⚠ trung tâm dữ liệu riêng, chỉ trong lãnh thổ Mỹ | | ⚠ Nhân sự vận hành được sàng lọc | ⚠ công dân Mỹ đã kiểm tra lý lịch | | ⚠ Đối tượng đủ điều kiện | ⚠ liên bang, bang, địa phương, bộ lạc, và nhà cung cấp giải pháp cho họ | | ⚠ Chứng nhận tuân thủ riêng | ⚠ FedRAMP High, DoD IL2–IL6, CJIS, ITAR |
⚠ Azure công cộng → ⚠ mọi khách hàng toàn cầu
⚠ Azure Government → ⚠ khu vực công Mỹ, tách biệt
⚠ Azure China 21Vianet → ⚠ do đối tác Trung Quốc vận hành
Vì sao các phương án khác sai
-
A (Azure Department of Defence) — ⚠ không phải tên sản phẩm; nhu cầu của Bộ Quốc phòng nằm trong Azure Government ở các mức Impact Level.
-
D (Azure Public Portal) — ⚠ không phải tên sản phẩm.
-
B (Azure không dành cho cơ quan nhà nước) — ⚠ SAI hoàn toàn.
Ghi nhớ
⚠ Ba đám mây tách biệt của Azure: | Đám mây | Ai vận hành | Ai dùng | |---|---|---| | ⚠ Azure công cộng | ⚠ Microsoft | ⚠ mọi người | | ⚠ Azure Government | ⚠ Microsoft, nhân sự đã sàng lọc | ⚠ khu vực công Mỹ | | ⚠ Azure China | ⚠ 21Vianet | ⚠ khách hàng tại Trung Quốc |
⚠ Ba đám mây này KHÔNG nối với nhau — tài khoản, cổng quản trị, và điểm cuối API đều riêng.
Từ khoá nhận diện:
"cơ quan chính phủ Mỹ" → ⚠ Azure Government "vận hành tại Trung Quốc bởi đối tác" → ⚠ Azure China 21Vianet "tải báo cáo kiểm toán và chứng nhận" → ⚠ Service Trust Portal "theo dõi mức tuân thủ của tổ chức mình" → ⚠ Purview Compliance Manager
| ⚠ Chủ quyền dữ liệu — ba khái niệm | Khái niệm |
|---|---|
| ⚠ Data residency | ⚠ dữ liệu nằm ở đâu về mặt địa lý |
| ⚠ Data sovereignty | ⚠ luật nước nào áp lên dữ liệu đó |
| ⚠ Data privacy | ⚠ quy tắc xử lý dữ liệu cá nhân |
| ⚠ Ba thứ | ⚠ liên quan nhưng KHÔNG đồng nghĩa |
| ⚠ Công cụ giữ dữ liệu đúng nơi | Công cụ |
|---|---|
| ⚠ Azure Policy | ⚠ giới hạn vùng được phép triển khai |
| ⚠ Chọn vùng khi tạo tài nguyên | ⚠ quyết định nơi dữ liệu nằm |
| ⚠ Region pairs | ⚠ cặp vùng thường trong cùng khu vực địa lý |
| ⚠ Lưu ý | ⚠ một số dịch vụ toàn cầu không gắn với vùng nào |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy định của ngành có buộc dữ liệu ở đâu không | | | Đã dùng Azure Policy khoá vùng chưa | | | Dịch vụ đang dùng có mặt ở đám mây đó không | ⚠ Government và China có danh mục HẸP hơn |
Và điều thực tế cần biết trước khi chọn một đám mây tách biệt: danh mục dịch vụ ở đó luôn hẹp hơn và ra sau Azure công cộng. Phải kiểm tra dịch vụ mình cần có mặt chưa trước khi thiết kế.
- A They are available in the marketplace. You simply use them.
- B You cannot use private preview services.
- C You must apply to use them.
- D You must agree to a terms of use first.
Xem giải thích
Đáp án
C — Bạn phải nộp đơn xin để được dùng.
Vì sao đúng
⚠ Private Preview là giai đoạn chỉ dành cho khách hàng ĐƯỢC CHỌN: | Đặc điểm | Nội dung | |---|---| | ⚠ Phải đăng ký và được duyệt | ⚠ thường qua biểu mẫu hoặc qua đội ngũ Microsoft | | ⚠ Số lượng khách hàng hạn chế | | | ⚠ Không thấy trong Portal hay Marketplace | ⚠ phải được bật cho subscription của bạn | | ⚠ Mục đích | ⚠ lấy phản hồi sớm cho nhóm sản phẩm | | ⚠ Không có SLA, có thể đổi hoặc bị bỏ | |
⚠ Private Preview → ⚠ Public Preview → ⚠ General Availability
⚠ nộp đơn xin ⚠ ai cũng bật được ⚠ dùng cho sản xuất
Vì sao các phương án khác sai
-
A (có sẵn trong Marketplace, cứ thế dùng) — ⚠ mô tả PUBLIC Preview hoặc GA, không phải Private.
-
D (chỉ cần đồng ý điều khoản sử dụng) — ⚠ đúng với PUBLIC Preview; Private còn phải được duyệt.
-
B (không dùng được dịch vụ private preview) — ⚠ SAI; dùng được nếu được chọn.
Ghi nhớ
⚠ Đối chiếu: ⚠ câu #22096 ở lô trước hỏi ba giai đoạn của vòng đời dịch vụ (Private Preview → Public Preview → GA); câu này hỏi cách tiếp cận giai đoạn đầu. ⚠ Hai câu bổ sung nhau.
⚠ Ba giai đoạn — khác nhau ở CÁCH VÀO và CAM KẾT: | Giai đoạn | Cách vào | SLA | |---|---|---| | ⚠ Private Preview | ⚠ nộp đơn, được mời | ⚠ không | | ⚠ Public Preview | ⚠ tự bật, chấp nhận điều khoản | ⚠ không | | ⚠ General Availability | ⚠ dùng ngay | ⚠ có |
Từ khoá nhận diện:
"phải nộp đơn xin" → ⚠ Private Preview "ai cũng thử được, chưa có SLA" → ⚠ Public Preview "dùng cho sản xuất được" → ⚠ GA "điều khoản riêng cho bản xem trước" → ⚠ Azure Preview Terms
| ⚠ Vì sao Microsoft làm Private Preview | Lý do |
|---|---|
| ⚠ Kiểm chứng ý tưởng với vài khách hàng thật | |
| ⚠ Sửa lỗi lớn trước khi mở rộng | |
| ⚠ Giữ tải nhỏ trong lúc còn chưa ổn định | |
| ⚠ Đổi lại người tham gia | ⚠ được tiếp cận sớm và ảnh hưởng tới sản phẩm |
| ⚠ Rủi ro khi tham gia Preview | Rủi ro |
|---|---|
| ⚠ Tính năng có thể bị bỏ hẳn | |
| ⚠ API có thể đổi, phải viết lại mã | |
| ⚠ Không có hỗ trợ chính thức | |
| ⚠ Có thể không có ở mọi vùng | |
| ⚠ Vì thế | ⚠ đừng để hệ thống sản xuất phụ thuộc vào nó |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tính năng Preview nào đang chạy trong sản xuất không | | | Đã đọc Azure Preview Terms chưa | | | Có kế hoạch dự phòng nếu tính năng bị bỏ không | |
Và điều làm nên khác biệt giữa hai loại preview: Public Preview là "bạn tự chịu rủi ro", còn Private Preview là "chúng tôi chọn bạn cùng làm". Giai đoạn đầu là quan hệ hai chiều với nhóm sản phẩm, không chỉ là quyền dùng sớm.
A startup is experimenting with Azure but wants to avoid unexpected costs while testing services. They plan to deploy and delete resources frequently.
Which statement best describes how Azure charges for resource usage?
-
A
Azure charges for inactive virtual machines at a reduced rate.
-
B
Azure charges only for the resources that are provisioned and running.
-
C
Azure requires a one-time setup fee when creating a new account.
-
D
Azure bills a fixed monthly fee for each subscription, even if no resources are used.
Xem giải thích
Đáp án
B — Azure chỉ tính tiền cho tài nguyên đã được cấp phát và đang chạy
Vì sao đúng
Đây là mô hình trả theo mức dùng: tạo tài nguyên thì bắt đầu tính tiền, xoá đi thì ngừng. Với đội khởi nghiệp hay tạo rồi xoá tài nguyên để thử nghiệm, điều này nghĩa là chi phí bám sát thời gian thực dùng.
Một điểm cần lưu ý thực tế: "chạy" không đồng nghĩa với "đang xử lý việc". Máy ảo bật mà nhàn rỗi vẫn tính tiền đủ; phải dừng và giải phóng thì mới ngừng tính vCPU và bộ nhớ. Và đĩa vẫn tính tiền kể cả khi máy đã tắt.
Vì sao các phương án khác sai
- A. Máy ảo không hoạt động được tính giá rẻ hơn — không có cơ chế nào như vậy.
- C. Có phí thiết lập một lần — Azure không thu phí mở tài khoản.
- D. Thu phí cố định hằng tháng cho mỗi subscription — subscription tự nó không phát sinh phí.
You're using the Azure CLI from a command prompt to manage Azure resources. Which command do you run to sign in interactively to your Azure account using the Azure CLI?
-
A
az account connect
-
B
az login
-
C
az connect
-
D
az account login
Xem giải thích
Đáp án
B — az login.
Vì sao đúng
⚠ az login là lệnh xác thực chuẩn của Azure CLI: | Cách chạy | Nội dung | |---|---| | ⚠ az login | ⚠ mở trình duyệt để đăng nhập tương tác | | ⚠ az login --use-device-code | ⚠ khi máy không có trình duyệt | | ⚠ az login --service-principal | ⚠ cho kịch bản tự động | | ⚠ az login --identity | ⚠ dùng managed identity trên VM Azure |
⚠ az login
↓ ⚠ mở trình duyệt, chọn tài khoản
⚠ az account show → ⚠ đang ở subscription nào
⚠ az account set -s <id> → ⚠ đổi subscription
⚠ az group create ... → ⚠ bắt đầu làm việc
Vì sao các phương án khác sai
- A (
az account connect), C (az connect), D (az account login) — ⚠ không tồn tại;az accountchỉ dùng để xem và đổi subscription.
Ghi nhớ
⚠ Cấu trúc lệnh Azure CLI — luôn là az <nhóm> <lệnh>: | Lệnh | Việc | |---|---| | ⚠ az group create | ⚠ tạo resource group | | ⚠ az vm create | ⚠ tạo máy ảo | | ⚠ az vm list | ⚠ liệt kê máy ảo | | ⚠ az storage account create | ⚠ tạo tài khoản lưu trữ | | ⚠ az --help | ⚠ trợ giúp ở bất kỳ cấp nào |
⚠ Azure CLI và Azure PowerShell — cùng làm được việc, khác cú pháp: | Việc | Azure CLI | Azure PowerShell | |---|---|---| | ⚠ Đăng nhập | ⚠ az login | ⚠ Connect-AzAccount | | ⚠ Tạo nhóm | ⚠ az group create | ⚠ New-AzResourceGroup | | ⚠ Liệt kê VM | ⚠ az vm list | ⚠ Get-AzVM | | ⚠ Phong cách | ⚠ danh từ–động từ, giống Bash | ⚠ Động từ-DanhTừ |
Từ khoá nhận diện:
"az ..." → ⚠ Azure CLI "Verb-AzNoun" → ⚠ Azure PowerShell "chạy dòng lệnh trong trình duyệt, đã đăng nhập sẵn" → ⚠ Cloud Shell "khai báo trạng thái mong muốn" → ⚠ ARM template hoặc Bicep
| ⚠ Vì sao dùng dòng lệnh | Lý do |
|---|---|
| ⚠ Lặp lại chính xác được | |
| ⚠ Đưa vào kịch bản và CI/CD được | |
| ⚠ Lưu vào Git để xem lại lịch sử | |
| ⚠ Làm hàng loạt nhanh hơn bấm chuột |
| ⚠ Mẹo hay dùng với Azure CLI | Mẹo |
|---|---|
⚠ --output table |
⚠ kết quả dễ đọc hơn JSON |
⚠ --query |
⚠ lọc bằng JMESPath |
⚠ az interactive |
⚠ chế độ gợi ý lệnh |
⚠ az configure |
⚠ đặt mặc định cho nhóm và vùng |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang đăng nhập vào subscription nào | ⚠ az account show | | Kịch bản có khai rõ subscription không | ⚠ đừng dựa vào mặc định | | Tự động hoá có dùng service principal hoặc managed identity chưa | |
Và sai lầm hay gặp nhất khi mới dùng CLI: chạy lệnh mà quên kiểm tra đang ở subscription nào. Tài nguyên được tạo đúng lệnh nhưng ở sai nơi, và thường chỉ phát hiện ra khi nhận hoá đơn.
Which Azure pricing option provides significant discounts for committing to a specific amount of resource usage for a 1-year or 3-year term?
-
A
Free Tier
-
B
Pay-As-You-Go
-
C
Reserved Instances
-
D
Spot Pricing
Xem giải thích
Đáp án
C — Reserved Instances
Vì sao đúng
Reserved Instance là cam kết dùng một lượng tài nguyên nhất định trong 1 năm hoặc 3 năm để đổi lấy mức giảm giá sâu — thường tới khoảng 70% so với trả theo mức dùng. Nó hợp với khối lượng công việc chạy liên tục và đoán trước được.
Vì sao các phương án khác sai
- D. Spot Pricing — cũng giảm giá rất sâu nhưng theo cơ chế khác hẳn: bạn dùng năng lực dư thừa của Azure và bị thu hồi bất cứ lúc nào. Không có cam kết thời hạn nào.
- B. Pay-As-You-Go — không cam kết, không giảm giá.
- A. Free Tier — hạn mức miễn phí có giới hạn cho người mới, không phải mô hình cam kết.
Which Azure database service is specifically designed to provide extremely low-latency responses for small, frequent read/write requests?
- A SQL Server in a VM
- B SQL Database
-
C
Synapse Analytics
- D Cosmos DB
Xem giải thích
Đáp án
D — Cosmos DB.
Vì sao đúng
⚠ Cosmos DB sinh ra cho độ trễ cực thấp ở quy mô toàn cầu: | Cam kết | Con số | |---|---| | ⚠ Độ trễ đọc và ghi | ⚠ dưới 10 mili giây ở phân vị 99 | | ⚠ SLA khả dụng | ⚠ 99,999% khi cấu hình nhiều vùng | | ⚠ Phân phối toàn cầu | ⚠ thêm vùng chỉ bằng một thao tác | | ⚠ Co giãn tự động | ⚠ theo throughput, đơn vị RU/s |
⚠ Phù hợp nhất với: ⚠ đọc ghi NHỎ và LIÊN TỤC — hồ sơ người dùng, giỏ hàng, IoT, game, danh mục sản phẩm.
Vì sao các phương án khác sai
-
B (Azure SQL Database) — ⚠ CSDL quan hệ tốt, nhưng KHÔNG cam kết độ trễ dưới 10 ms và không phân phối toàn cầu theo cách của Cosmos DB.
-
C (Synapse Analytics) — ⚠ kho dữ liệu phân tích, tối ưu cho truy vấn LỚN quét nhiều dữ liệu, ngược hẳn với yêu cầu đề bài.
-
A (SQL Server trong VM) — ⚠ IaaS, mọi thứ về hiệu năng và mở rộng bạn phải tự lo.
Ghi nhớ
⚠ Chọn kho dữ liệu theo HÌNH DẠNG truy vấn: | Nhu cầu | Dịch vụ | |---|---| | ⚠ Đọc ghi nhỏ, rất nhiều, độ trễ thấp | ⚠ Cosmos DB | | ⚠ Quan hệ, giao dịch, SQL chuẩn | ⚠ Azure SQL Database | | ⚠ Phân tích trên khối dữ liệu lớn | ⚠ Synapse Analytics, Microsoft Fabric | | ⚠ File và blob phi cấu trúc | ⚠ Blob Storage | | ⚠ Bộ nhớ đệm siêu nhanh | ⚠ Azure Cache for Redis |
Từ khoá nhận diện:
"độ trễ mili giây, phân tán toàn cầu" → ⚠ Cosmos DB "quan hệ, quản lý hoàn toàn" → ⚠ Azure SQL Database "kho dữ liệu, phân tích, báo cáo" → ⚠ Synapse "chỉ cần cache tạm" → ⚠ Redis
| ⚠ Cosmos DB hỗ trợ nhiều API | API |
|---|---|
| ⚠ NoSQL (Core) | ⚠ mặc định, tài liệu JSON |
| ⚠ MongoDB | ⚠ chuyển ứng dụng Mongo sang |
| ⚠ Cassandra | ⚠ tương thích CQL |
| ⚠ Gremlin | ⚠ CSDL đồ thị |
| ⚠ Table | ⚠ tương thích Table Storage |
| ⚠ Năm mức nhất quán của Cosmos DB | Mức |
|---|---|
| ⚠ Strong | ⚠ nhất quán nhất, độ trễ cao nhất |
| ⚠ Bounded staleness | |
| ⚠ Session | ⚠ MẶC ĐỊNH, hợp với hầu hết ứng dụng |
| ⚠ Consistent prefix | |
| ⚠ Eventual | ⚠ nhanh nhất, rẻ nhất, yếu nhất |
| ⚠ Đây là | ⚠ đánh đổi giữa nhất quán, độ trễ và chi phí |
Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá phân vùng có phân bố đều không | ⚠ chọn sai là nghẽn nóng | | Mức nhất quán có cần mạnh đến thế không | ⚠ mạnh hơn là đắt hơn | | Đang dùng throughput cấp sẵn hay tự co giãn | |
Và quyết định ảnh hưởng lớn nhất tới Cosmos DB, lớn hơn cả việc chọn API: khoá phân vùng. Chọn sai thì dữ liệu dồn vào một phân vùng, và không đổi được sau khi container đã tạo.