Ngân hàng đề — Microsoft Azure Data Fundamentals

Tìm thấy 328 câu.

Câu 91 Non-relational DB
You've created a Cosmos DB account named Account1. Inside, you create one database named Db1, and one container named Container1. The data you are storing is document data using the Core (SQL) API. You have a new requirement to add a graph database using the Gremlin API. Can you create another database named Db2 inside Account1 for the graph data?
  1. A No, each account can only contain one type of data
  2. B Yes, each database can use a different API in one account
  3. C Yes, you can use any API to call a Cosmos DB database of any type
Xem giải thích

Đáp án

A — Không, mỗi tài khoản chỉ chứa được MỘT loại dữ liệu (một API).

Vì sao đúng

⚠ API được chọn ở cấp TÀI KHOẢN và không đổi được:

⚠ Cosmos DB Account
   ⚠ API: Core (SQL)     ← chọn lúc TẠO
        ↓
⚠ Mọi database bên trong
⚠ Mọi container bên trong
   ⚠ đều dùng API đó
        ↓
⚠ Muốn Gremlin → phải tạo TÀI KHOẢN MỚI
Cấp Thiết lập cố định
⚠ Account ⚠ API — KHÔNG đổi được
⚠ Container ⚠ partition key — KHÔNG đổi được

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

  • B (mỗi database dùng một API khác nhau trong cùng tài khoản) — ⚠ SAI: ⚠ API nằm ở cấp ⚠ tài khoản, không phải cấp database.

  • C (dùng API nào cũng gọi được database loại nào) — ⚠ SAI: ⚠ mỗi API có giao thức và mô hình dữ liệu riêng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung một chi tiết quan trọng cho #19523 ở lô trước.

Câu Hỏi gì Khoá
⚠ #19523 ⚠ bao nhiêu database trong một tài khoản ⚠ không giới hạn
⚠ #19581 (câu này) ⚠ các database dùng API khác nhau được không ⚠ KHÔNG
⚠ Kết hợp lại ⚠ vô hạn database, nhưng TẤT CẢ cùng một API
⚠ KHÔNG mâu thuẫn ⚠ một hỏi số lượng, một hỏi tính đồng nhất

⚠ Hệ quả thiết kế: | Tình huống | Cần | |---|---| | ⚠ Ứng dụng cần cả tài liệu và đồ thị | ⚠ HAI tài khoản Cosmos DB | | ⚠ Mỗi tài khoản có chi phí riêng | | | ⚠ Cấu hình vùng và nhất quán riêng | | | ⚠ Cân nhắc | ⚠ có thật sự cần đồ thị không, hay mô hình tài liệu là đủ |

Từ khoá nhận diện:

"đổi API sau khi tạo" → ⚠ KHÔNG được "nhiều API trong một tài khoản" → ⚠ KHÔNG được "nhiều database trong một tài khoản" → ⚠ được, không giới hạn "đổi partition key" → ⚠ KHÔNG được

⚠ Ba quyết định vĩnh viễn của Cosmos DB Quyết định
⚠ API của tài khoản
⚠ Partition key của container
⚠ Vùng chính ban đầu ⚠ đổi được nhưng phức tạp
⚠ Nghĩa là ⚠ giai đoạn thiết kế quan trọng hơn nhiều so với CSDL quan hệ
⚠ Nếu lỡ chọn sai API Cách xử lý
⚠ Tạo tài khoản mới với API đúng
⚠ Dùng Data Migration Tool hoặc Data Factory để chuyển
⚠ Cập nhật chuỗi kết nối của ứng dụng
⚠ Chi phí ⚠ thời gian và RU cho việc đọc ghi lại toàn bộ dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình dữ liệu đã chốt chưa | ⚠ trước khi tạo tài khoản | | Có phần dữ liệu nào cần mô hình khác không | | | Partition key đã theo mẫu truy vấn chưa | |

Và điểm khác biệt lớn nhất giữa việc thiết kế trên Cosmos DB so với cơ sở dữ liệu quan hệ: những quyết định quan trọng nhất phải đúng ngay từ lần tạo đầu tiên. Không có lệnh ALTER nào cho API hay partition key.

Câu 92 Relational DB Management
Which of the following tools allow you to query an Azure SQL Database from a command line?
  1. A sqlcmd
  2. B Azure Cloud Shell
  3. C SQL Server Management Studio
  4. D Azure Data Studio
Xem giải thích

Đáp án

A — sqlcmd.

Vì sao đúng

⚠ sqlcmd là công cụ DÒNG LỆNH chuyên để chạy truy vấn SQL:

⚠ sqlcmd -S server.database.windows.net \
⚠   -d MyDatabase -U user -P pass \
⚠   -Q "SELECT COUNT(*) FROM DonHang"
Đặc điểm Nội dung
⚠ Chạy trong terminal hoặc script
⚠ Đưa vào cron, CI/CD được
⚠ Xuất kết quả ra tệp
⚠ Chạy tệp .sql bằng tham số -i
⚠ Có bản đa nền tảng

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

  • C (SQL Server Management Studio) và D (Azure Data Studio) — ⚠ là công cụ ĐỒ HOẠ; ⚠ Azure Data Studio có terminal tích hợp nhưng bản thân nó không phải công cụ dòng lệnh.

  • B (Azure Cloud Shell) — ⚠ bẫy đáng chú ý: ⚠ Cloud Shell ⚠ là MÔI TRƯỜNG dòng lệnh, ⚠ nhưng nó không phải công cụ truy vấn; ⚠ bạn vẫn phải chạy ⚠ sqlcmd hoặc az sql ⚠ bên trong nó.

Ghi nhớ

⚠ Công cụ làm việc với Azure SQL — bảng phân loại: | Công cụ | Loại | |---|---| | ⚠ sqlcmd | ⚠ dòng lệnh, chạy truy vấn | | ⚠ bcp | ⚠ dòng lệnh, nhập/xuất hàng loạt | | ⚠ SSMS | ⚠ đồ hoạ, đầy đủ nhất, chỉ Windows | | ⚠ Azure Data Studio | ⚠ đồ hoạ, đa nền tảng, notebook | | ⚠ Query editor trên Portal | ⚠ trình duyệt, tiện cho việc nhanh | | ⚠ Azure CLI (az sql) | ⚠ quản lý tài nguyên, không chạy truy vấn dữ liệu |

Từ khoá nhận diện:

"dòng lệnh, chạy truy vấn" → ⚠ sqlcmd "nhập xuất dữ liệu hàng loạt" → ⚠ bcp "giao diện đồ hoạ đầy đủ" → ⚠ SSMS "tạo hoặc xoá server, database" → ⚠ az sql, PowerShell

⚠ Phân biệt hai loại thao tác Phân biệt
⚠ Thao tác TÀI NGUYÊN ⚠ tạo server, đổi bậc, thêm luật tường lửa
⚠ Thao tác DỮ LIỆU ⚠ SELECT, INSERT, tạo bảng
⚠ Azure CLI làm cái đầu
⚠ sqlcmd làm cái sau
⚠ Nhầm lẫn này ⚠ rất phổ biến khi mới dùng Azure
⚠ sqlcmd trong tự động hoá Ứng dụng
⚠ Chạy script triển khai schema
⚠ Kiểm tra sức khoẻ trong pipeline CI/CD
⚠ Xuất báo cáo định kỳ ra tệp
⚠ Bảo mật ⚠ dùng xác thực Entra ID thay vì nhúng mật khẩu vào script

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần thao tác tài nguyên hay thao tác dữ liệu | | | Script có nhúng mật khẩu không | ⚠ nên dùng Entra ID hoặc Key Vault | | Công cụ có chạy được trên hệ điều hành đang dùng không | |

Và nhầm lẫn phổ biến khi mới làm việc với Azure SQL từ dòng lệnh: tưởng Azure CLI chạy được truy vấn dữ liệu. Nó quản lý máy chủ và cơ sở dữ liệu như tài nguyên, nhưng để đọc một dòng dữ liệu thì vẫn cần sqlcmd.

Câu 93 Relational data security
How do you disable SQL Database encryption at rest so that the data is stored on the hard disk in a readable format?
  1. A Switch to Customer-Managed Keys using Azure Key Vault.
  2. B The setting is in the security menu of the Azure Portal for SQL Database.
  3. C You cannot. TDE is enabled by default and cannot be disabled.
  4. D It must be disabled on creation of the storage account, not after.
Xem giải thích

Đáp án

C — Bạn KHÔNG THỂ. TDE được bật mặc định và không tắt được.

Vì sao đúng

⚠ Trên Azure SQL Database, mã hoá khi lưu là bắt buộc: | Điểm | Nội dung | |---|---| | ⚠ TDE BẬT mặc định cho database mới | | | ⚠ Không có nút tắt trên Portal | | | ⚠ Không có lệnh T-SQL để tắt | | | ⚠ Áp dụng cho cả bản sao lưu | |

⚠ Microsoft coi mã hoá at rest là
   ⚠ yêu cầu bảo mật NỀN TẢNG
        ↓
⚠ Không cho khách hàng tự làm yếu đi
        ↓
⚠ Storage Account cũng vậy — SSE không tắt được

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

  • B (có thiết lập trong menu bảo mật của Portal) — ⚠ SAI: ⚠ menu đó cho ⚠ đổi cách quản lý khoá, không cho tắt mã hoá.

  • A (chuyển sang khoá do khách hàng quản lý) — ⚠ vẫn là mã hoá, ⚠ chỉ đổi ai giữ khoá.

  • D (phải tắt lúc tạo storage account) — ⚠ nhầm dịch vụ, ⚠ và SSE của Storage cũng không tắt được.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ năm về mã hoá at rest qua hai lô.

Câu Hỏi gì Khoá
⚠ #19538 ⚠ TDE bảo vệ trạng thái nào ⚠ at rest
⚠ #19548 ⚠ at rest là gì ⚠ dữ liệu tĩnh trên đĩa
⚠ #19579 ⚠ bảo vệ at rest bằng gì ⚠ Disk Encryption
⚠ #19583 (câu này) ⚠ tắt TDE thế nào ⚠ không tắt được
⚠ Bốn câu ⚠ cùng một chủ đề, không mâu thuẫn

⚠ Những thứ Azure KHÔNG cho tắt: | Thứ | Dịch vụ | |---|---| | ⚠ TDE | ⚠ Azure SQL Database, Managed Instance | | ⚠ Storage Service Encryption | ⚠ mọi Storage Account | | ⚠ Mã hoá khi lưu | ⚠ Cosmos DB | | ⚠ Lý do | ⚠ bảo mật nền tảng, không phải lựa chọn của khách hàng | | ⚠ Cái BẠN chọn được | ⚠ AI giữ khoá — Microsoft hay bạn |

Từ khoá nhận diện:

"tắt mã hoá" → ⚠ không làm được trên PaaS "tự quản lý khoá" → ⚠ CMK qua Key Vault "mã hoá đường truyền" → ⚠ TLS, cũng bắt buộc "SQL Server trong VM" → ⚠ ở đó TDE là TUỲ CHỌN

⚠ Ngoại lệ: SQL Server trên VM Ngoại lệ
⚠ Đó là IaaS, bạn toàn quyền
⚠ TDE là tuỳ chọn, phải tự bật
⚠ Phải tự quản lý chứng chỉ và khoá
⚠ Đây là ⚠ một ví dụ nữa của đánh đổi IaaS và PaaS
⚠ CMK — khi nào cần Khi nào
⚠ Yêu cầu tuân thủ đòi kiểm soát khoá
⚠ Cần THU HỒI quyền truy cập dữ liệu tức thì
⚠ Cần nhật ký mọi lần dùng khoá
⚠ Rủi ro ⚠ xoá khoá là mất dữ liệu vĩnh viễn
⚠ Bắt buộc ⚠ bật soft delete và purge protection cho Key Vault

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có yêu cầu tuân thủ nào đòi CMK không | | | Nếu dùng CMK, Key Vault đã bảo vệ đủ chưa | | | Ai được phép xoá khoá | ⚠ hạn chế tối đa |

Và câu hỏi này chỉ ra một nguyên tắc thiết kế của nền tảng đám mây: những gì không thể tắt thường là những gì Microsoft đã quyết định không để khách hàng tự làm yếu đi. Bạn chọn được ai giữ chìa khoá, không chọn được việc có khoá cửa hay không.

Câu 94 Non-relational DB
What do you get when you use Premium access tier for Azure Blob Storage?
  1. A Slightly less expensive to store the file per GB, and around double the cost to access the file. No coding changes required compared to the Hot tier.
  2. B More expensive per GB to store the file, and way less expensive to access the file with less delay
  3. C Way less expensive to store the file, and long delay to access the file (perhaps hours)
  4. D Extra data redundancy options, with more copies of your files stored in more places
Xem giải thích

Đáp án

B — ĐẮT HƠN mỗi GB để lưu, nhưng RẺ HƠN NHIỀU và ÍT ĐỘ TRỄ hơn khi truy cập.

Vì sao đúng

⚠ Premium là đầu cực trái của thang đánh đổi: | Tầng | Giá lưu | Giá truy cập | Độ trễ | |---|---|---|---| | ⚠ Premium | ⚠ CAO NHẤT | ⚠ THẤP NHẤT | ⚠ thấp nhất, SSD | | ⚠ Hot | ⚠ cao | ⚠ thấp | ⚠ thấp | | ⚠ Cool | ⚠ thấp | ⚠ cao | ⚠ thấp | | ⚠ Archive | ⚠ thấp nhất | ⚠ cao nhất | ⚠ hàng giờ |

⚠ Premium chạy trên SSD
        ↓
⚠ Độ trễ rất thấp, IOPS cao
        ↓
⚠ Hợp với tệp NHỎ, truy cập RẤT NHIỀU

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

  • A (rẻ hơn chút để lưu, gấp đôi khi truy cập) — ⚠ đó là COOL.

  • C (rẻ hơn nhiều để lưu, chờ hàng giờ) — ⚠ đó là ARCHIVE.

  • D (thêm tuỳ chọn dư thừa, nhiều bản sao hơn) — ⚠ đó là mức NHÂN BẢN (LRS/ZRS/GRS), ⚠ khác hoàn toàn với tầng truy cập.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về tầng lưu trữ blob qua hai lô, ⚠ và ⚠ bốn câu dùng CHUNG bộ phương án.

Câu Hỏi tầng nào Khoá
⚠ #19509 ⚠ Cool ⚠ rẻ hơn khi lưu, đắt hơn khi đọc
⚠ #19536 ⚠ Archive ⚠ rẻ nhất, chờ hàng giờ
⚠ #19584 (câu này) ⚠ Premium ⚠ đắt khi lưu, rẻ và nhanh khi đọc
⚠ Ba câu ⚠ cùng bộ bốn phương án, mỗi câu hỏi một tầng
⚠ Mẹo ⚠ thuộc bảng bốn tầng là ăn trọn cả chùm
⚠ Cảnh giác ⚠ phương án D nói về NHÂN BẢN, không phải tầng — nhiễu ở cả ba câu

⚠ Hai trục hoàn toàn khác nhau — đừng lẫn: | Trục | Lựa chọn | Quyết định | |---|---|---| | ⚠ TẦNG truy cập | ⚠ Premium/Hot/Cool/Cold/Archive | ⚠ giá lưu so với giá đọc | | ⚠ MỨC nhân bản | ⚠ LRS/ZRS/GRS/GZRS | ⚠ chịu được hỏng hóc tới đâu | | ⚠ Độc lập với nhau | ⚠ chọn cả hai cho mỗi tài khoản |

Từ khoá nhận diện:

"SSD, độ trễ thấp, truy cập rất nhiều" → ⚠ Premium "mặc định, truy cập thường xuyên" → ⚠ Hot "ít dùng, giữ trên 30 ngày" → ⚠ Cool "lưu trữ dài hạn, chờ được" → ⚠ Archive "nhiều bản sao ở nhiều nơi" → ⚠ mức nhân bản, KHÔNG phải tầng

⚠ Premium blob — lưu ý riêng Lưu ý
⚠ Phải chọn loại tài khoản PREMIUM ngay khi tạo
⚠ KHÔNG chuyển tầng qua lại như Hot/Cool/Archive
⚠ Hợp với tệp nhỏ, số thao tác rất lớn
⚠ Ví dụ ⚠ dữ liệu tương tác, phân tích thời gian thực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Số lần đọc mỗi GB mỗi tháng là bao nhiêu | ⚠ con số quyết định | | Đang chọn tầng hay chọn mức nhân bản | | | Có cần độ trễ thấp thật sự không | |

Và tỉ số cần tính trước khi chọn tầng lưu trữ, thay vì so giá theo GB: số lần đọc chia cho dung lượng. Tỉ số cao thì trả nhiều cho lưu trữ để tiết kiệm phí thao tác; tỉ số thấp thì làm ngược lại.

Câu 95 Non-relational data management
By what method can you limit who has access to your Cosmos DB account from the Internet?
  1. A Regenerate the primary key
  2. B IP policy-based access control
  3. C Azure Firewall
  4. D Disable public network access to Cosmos DB
Xem giải thích

Đáp án

B — Kiểm soát truy cập dựa trên chính sách IP (IP firewall).

Vì sao đúng

⚠ Cosmos DB có tường lửa IP tích hợp:

⚠ Mặc định: chấp nhận kết nối từ mọi IP
   ⚠ (vẫn cần khoá hoặc token hợp lệ)
        ↓ ⚠ bật IP firewall
⚠ Chỉ IP hoặc dải CIDR trong danh sách
   ⚠ mới kết nối được
        ↓
⚠ Lớp phòng thủ thứ hai bên cạnh khoá
Cấu hình được Nội dung
⚠ Danh sách IP và dải CIDR
⚠ Cho phép từ Azure Portal ⚠ để bạn còn vào quản lý được
⚠ Cho phép từ trung tâm dữ liệu Azure
⚠ Kết hợp với VNet service endpoint

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

  • A (tạo lại khoá chính) — ⚠ là thu hồi khoá cũ, ⚠ không giới hạn được ai kết nối từ đâu.

  • C (Azure Firewall) — ⚠ tường lửa mạng cho lưu lượng RA VÀO VNet, ⚠ không phải cơ chế của Cosmos DB.

  • D (tắt hẳn truy cập mạng công cộng) — ⚠ xem mục chất lượng câu hỏi.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án D ⚠ cũng là biện pháp hợp lệ và còn mạnh hơn.

Phương án Thực tế
⚠ D — tắt truy cập công cộng ⚠ CÓ tồn tại, dùng cùng private endpoint
⚠ Nó chặn HOÀN TOÀN Internet ⚠ mạnh hơn lọc IP
⚠ B (khoá) — lọc theo IP ⚠ vẫn cho phép từ Internet, chỉ giới hạn nguồn
⚠ Vì sao bộ đề chọn B ⚠ đề hỏi "GIỚI HẠN AI truy cập", tức là vẫn cho một số người vào
⚠ D thì ⚠ không phải giới hạn mà là CẤM hoàn toàn từ Internet
⚠ Giữ nguyên khoá ⚠ B theo bộ đề gốc

⚠ Ba lớp bảo vệ mạng cho Cosmos DB: | Lớp | Mức độ | |---|---| | ⚠ IP firewall | ⚠ giới hạn theo nguồn, vẫn qua Internet | | ⚠ VNet service endpoint | ⚠ chỉ subnet chỉ định | | ⚠ Private endpoint | ⚠ IP riêng, KHÔNG qua Internet — mạnh nhất |

Từ khoá nhận diện:

"giới hạn IP nào được vào" → ⚠ IP firewall "chỉ từ mạng ảo của tôi" → ⚠ service endpoint hoặc private endpoint "không qua Internet chút nào" → ⚠ private endpoint + tắt public access "thu hồi khoá" → ⚠ regenerate, việc khác

⚠ Bảo mật nhiều lớp cho Cosmos DB Lớp
⚠ Mạng: IP firewall hoặc private endpoint
⚠ Xác thực: Entra ID thay cho khoá
⚠ Phân quyền: RBAC hoặc resource token
⚠ Dữ liệu: mã hoá at rest (luôn bật)
⚠ Giám sát: nhật ký chẩn đoán
⚠ Không lớp nào ⚠ thay thế được lớp khác
⚠ Cẩn thận khi bật tường lửa IP Cẩn thận
⚠ Nhớ cho phép chính bạn vào
⚠ Nhớ cho phép Azure Portal ⚠ nếu không sẽ không xem dữ liệu được
⚠ IP văn phòng có thể là IP động
⚠ Sự cố hay gặp ⚠ bật tường lửa xong tự khoá mình ở ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã cho phép Portal và chính mình chưa | | | Có thể dùng private endpoint không | ⚠ mạnh hơn lọc IP | | Còn dùng khoá hay đã chuyển sang Entra ID | |

Và sự cố tự gây ra phổ biến nhất khi siết bảo mật mạng cho một dịch vụ dữ liệu: bật tường lửa rồi phát hiện chính mình cũng không vào được nữa. Luôn thêm IP của bạn và của Portal trước khi bật.

Câu 96 Relational Data Security
When a customer wants to manage their own encryption keys for SQL Database Transparent Data Encryption (TDE), where are those keys stored?
  1. A Inside the SQL Database
  2. B On premises
  3. C Azure Blob Storage account
  4. D Azure Key Vault
Xem giải thích

Đáp án

D — Azure Key Vault.

Vì sao đúng

⚠ Key Vault là nơi Azure lưu khoá do khách hàng quản lý:

⚠ Customer-Managed Key (CMK / BYOK)
        ↓
⚠ Khoá bảo vệ TDE nằm trong Key Vault CỦA BẠN
        ↓
⚠ Azure SQL xin phép dùng khoá
   ⚠ qua managed identity
        ↓
⚠ Bạn thu hồi quyền → CSDL không mở được nữa
Bạn kiểm soát được Nội dung
⚠ Vòng đời khoá ⚠ tạo, luân chuyển, vô hiệu
⚠ Nhật ký mọi lần dùng khoá
⚠ Thu hồi quyền truy cập tức thì
⚠ Sao lưu khoá

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

  • A (bên trong chính SQL Database) — ⚠ vô nghĩa về bảo mật: ⚠ để khoá cùng chỗ với dữ liệu thì mã hoá mất tác dụng.

  • B (tại chỗ, on-premises) — ⚠ Azure SQL không lấy khoá từ đó được.

  • C (Azure Blob Storage) — ⚠ không phải kho khoá; ⚠ Key Vault mới có HSM và kiểm soát truy cập chuyên biệt.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #19538 ⚠ TDE bảo vệ gì ⚠ data at rest
⚠ #19583 ⚠ tắt TDE thế nào ⚠ không tắt được
⚠ #19586 (câu này) ⚠ khoá CMK lưu ở đâu ⚠ Key Vault
⚠ Ba câu ⚠ vẽ trọn chủ đề TDE

⚠ Azure Key Vault lưu ba loại thứ: | Loại | Nội dung | |---|---| | ⚠ Keys | ⚠ khoá mã hoá — dùng CHO việc mã hoá, không lấy ra được | | ⚠ Secrets | ⚠ mật khẩu, chuỗi kết nối — lấy ra được | | ⚠ Certificates | ⚠ chứng chỉ TLS, tự gia hạn được |

Từ khoá nhận diện:

"khoá do khách hàng quản lý, BYOK" → ⚠ Key Vault "mật khẩu, chuỗi kết nối" → ⚠ Key Vault secrets "chứng chỉ TLS" → ⚠ Key Vault certificates "không cần lưu bí mật nào" → ⚠ managed identity

⚠ Rủi ro lớn nhất của CMK Rủi ro
⚠ Xoá khoá = MẤT DỮ LIỆU VĨNH VIỄN
⚠ Xoá Key Vault cũng vậy
⚠ Thu hồi quyền nhầm = CSDL ngừng hoạt động
⚠ BẮT BUỘC ⚠ bật soft delete và purge protection
⚠ Nên ⚠ hạn chế tối đa ai có quyền xoá trên Key Vault đó
⚠ Key Vault và Managed HSM Phân biệt
⚠ Key Vault tiêu chuẩn ⚠ khoá lưu bằng phần mềm
⚠ Key Vault Premium ⚠ khoá bảo vệ bằng HSM
⚠ Managed HSM ⚠ HSM đơn nhiệm, tuân thủ FIPS 140-2 Level 3
⚠ Chọn theo ⚠ yêu cầu tuân thủ của ngành

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Key Vault đã bật purge protection chưa | ⚠ bắt buộc với CMK | | Ai có quyền xoá khoá | ⚠ càng ít càng tốt | | Đã có quy trình luân chuyển khoá chưa | |

Và cái giá đi kèm quyền kiểm soát khoá mã hoá, cần cân nhắc nghiêm túc trước khi chọn CMK: bạn cũng nhận luôn trách nhiệm không được làm mất nó. Một thao tác xoá nhầm trên Key Vault có thể khiến toàn bộ cơ sở dữ liệu không bao giờ mở lại được.

Câu 97 Relational data security
Which of the following statements best defines "data in transit" when it comes to securing data?
  1. A Data that a user can read, on a computer screen
  2. B Data while it's being transferred between components, locations or programs such as over a network
  3. C Data that exists statically on the physical media
  4. D Data that still exists in the source location, and has not yet been sent to the destination location
Xem giải thích

Đáp án

B — Dữ liệu trong lúc đang được TRUYỀN giữa các thành phần, vị trí hoặc chương trình, chẳng hạn qua mạng.

Vì sao đúng

⚠ In transit là trạng thái dữ liệu đang DI CHUYỂN:

⚠ Client  ──────────────▶  Server
        ⚠ dữ liệu đang trên đường
        ↓
⚠ Nguy cơ: nghe lén, sửa gói tin,
   ⚠ giả mạo người ở giữa
        ↓
⚠ Bảo vệ bằng TLS/HTTPS
Nơi dữ liệu di chuyển Ví dụ
⚠ Giữa client và server ⚠ trình duyệt tới web
⚠ Giữa các dịch vụ ⚠ App Service tới CSDL
⚠ Giữa các vùng ⚠ nhân bản dữ liệu
⚠ Giữa tại chỗ và đám mây ⚠ VPN, ExpressRoute

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

  • C (dữ liệu tồn tại tĩnh trên phương tiện vật lý) — ⚠ đó là AT REST.

  • A (dữ liệu người dùng đọc được trên màn hình) — ⚠ gần với IN USE.

  • D (dữ liệu vẫn ở nguồn, chưa được gửi đi) — ⚠ đó vẫn là AT REST: ⚠ chưa di chuyển thì chưa phải in transit.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp đối xứng với #19548 ở lô trước.

Câu Hỏi gì Khoá
⚠ #19548 ⚠ data AT REST là gì ⚠ tĩnh trên phương tiện vật lý
⚠ #19587 (câu này) ⚠ data IN TRANSIT là gì ⚠ đang được truyền
⚠ Cặp đối xứng ⚠ dùng chung bộ phương án, hoán đổi khoá
⚠ Cùng với #19560, #19579, #19583 ⚠ sáu câu về ba trạng thái dữ liệu qua hai lô

⚠ Ba trạng thái — bảng chốt cuối: | Trạng thái | Định nghĩa | Bảo vệ | |---|---|---| | ⚠ At rest | ⚠ nằm yên trên đĩa | ⚠ TDE, SSE, Disk Encryption | | ⚠ In transit | ⚠ đang di chuyển | ⚠ TLS, VPN, ExpressRoute | | ⚠ In use | ⚠ đang xử lý trong bộ nhớ | ⚠ Always Encrypted, confidential computing |

Từ khoá nhận diện:

"qua mạng, giữa hai điểm" → ⚠ in transit "trên đĩa, trong file" → ⚠ at rest "trong bộ nhớ, đang tính toán" → ⚠ in use "chưa gửi đi" → ⚠ vẫn là at rest

⚠ Bảo vệ in transit trên Azure Cơ chế
⚠ TLS 1.2+ cho mọi dịch vụ
⚠ Secure transfer required cho Storage
⚠ VPN Gateway cho kết nối site-to-site
⚠ ExpressRoute cho kết nối riêng ⚠ không đi qua Internet công cộng
⚠ Private endpoint ⚠ lưu lượng đi trong mạng Microsoft
⚠ ExpressRoute có mã hoá không Điểm tinh tế
⚠ ExpressRoute KHÔNG tự mã hoá
⚠ Nó chỉ là kết nối RIÊNG, không qua Internet
⚠ Muốn mã hoá phải thêm MACsec hoặc IPsec
⚠ Nhầm lẫn phổ biến ⚠ tưởng riêng tư là đã được mã hoá

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn kết nối nào dùng HTTP không | | | Lưu lượng nội bộ có được mã hoá không | | | ExpressRoute đã có lớp mã hoá chưa | |

Và ngộ nhận đáng chú ý về kết nối riêng tới đám mây: riêng tư không đồng nghĩa với được mã hoá. ExpressRoute tránh Internet công cộng nhưng dữ liệu vẫn đi ở dạng rõ nếu bạn không thêm lớp mã hoá.

Câu 98 Data Processing
Synapse Analytics and Azure Databricks are both Spark-based analytics platforms. What feature does Synapse Analytics offer thatn Databricks currently does not?
  1. A Based on the SQL Engine, familiar for existing SQL Server environments
  2. B Ability to perform parallel processing
  3. C Ability to scale based on business need
  4. D Ability to ingest data from Azure Blob Storage
Xem giải thích

Đáp án

A — Dựa trên engine SQL, quen thuộc với môi trường SQL Server sẵn có.

Vì sao đúng

⚠ Synapse có thứ Databricks không có: một SQL engine đầy đủ: | Synapse có | Nội dung | |---|---| | ⚠ Dedicated SQL pool | ⚠ kho dữ liệu MPP, T-SQL đầy đủ | | ⚠ Serverless SQL pool | ⚠ truy vấn thẳng tệp trên data lake bằng T-SQL | | ⚠ Spark pool | ⚠ giống Databricks | | ⚠ Pipeline | ⚠ giống Data Factory |

⚠ Đội đã quen SQL Server
        ↓
⚠ Dùng ngay T-SQL trên Synapse
   ⚠ không cần học Spark hay Python

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

  • B (xử lý song song), C (co giãn theo nhu cầu), D (nạp dữ liệu từ Blob Storage) — ⚠ CẢ HAI nền tảng đều làm được, ⚠ nên không phải điểm phân biệt.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19558 ở lô trước về nền tảng Spark.

Câu Hỏi gì Khoá
⚠ #19558 ⚠ dịch vụ nào cung cấp Spark ⚠ HDInsight và Databricks
⚠ #19588 (câu này) ⚠ Synapse có gì Databricks không có ⚠ SQL engine
⚠ Bổ sung nhau ⚠ Synapse có CẢ Spark LẪN SQL

⚠ Synapse và Databricks — bảng so sánh: | Tiêu chí | Synapse | Databricks | |---|---|---| | ⚠ SQL engine riêng | ⚠ CÓ — điểm khác biệt | ⚠ KHÔNG (có Spark SQL) | | ⚠ Spark | ⚠ có | ⚠ có, tối ưu hơn | | ⚠ Pipeline điều phối | ⚠ có sẵn | ⚠ dùng ADF bên ngoài | | ⚠ Notebook cộng tác | ⚠ có | ⚠ mạnh hơn | | ⚠ MLflow, Delta Lake | ⚠ hỗ trợ | ⚠ là quê nhà của chúng | | ⚠ Chọn theo | ⚠ kỹ năng của đội: SQL hay Python/Scala |

Từ khoá nhận diện:

"đội quen SQL Server, T-SQL" → ⚠ Synapse "khoa học dữ liệu, Python, ML" → ⚠ Databricks "tất cả trong một không gian làm việc" → ⚠ Synapse "Delta Lake, MLflow" → ⚠ Databricks

⚠ Serverless SQL pool — tính năng đáng nhớ Nội dung
⚠ Truy vấn tệp Parquet, CSV, JSON trên data lake
⚠ Bằng T-SQL, KHÔNG cần nạp vào kho trước
⚠ Trả tiền theo lượng dữ liệu QUÉT
⚠ Hữu ích cho ⚠ khám phá dữ liệu nhanh trước khi dựng pipeline
⚠ Cẩn thận ⚠ quét toàn bộ data lake là hoá đơn lớn — hãy phân vùng dữ liệu
⚠ Microsoft Fabric — bước tiếp theo Nội dung
⚠ Gộp Synapse, Data Factory, Power BI thành một
⚠ OneLake là kho dữ liệu chung
⚠ Xu hướng ⚠ hợp nhất các dịch vụ dữ liệu rời rạc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội thạo SQL hay Python | ⚠ yếu tố quyết định thực tế nhất | | Có cần notebook và ML nâng cao không | | | Serverless SQL pool đang quét bao nhiêu dữ liệu mỗi truy vấn | |

Và yếu tố quyết định thực tế nhất khi chọn giữa hai nền tảng phân tích này, thường quan trọng hơn mọi so sánh tính năng: kỹ năng sẵn có của đội. Một nền tảng mạnh hơn nhưng không ai trong đội dùng thạo sẽ cho ra kết quả kém hơn.

Câu 99 Data Warehouse
Which of the following best describes the concept of data warehouse workloads?
  1. A The data contained in a SQL Data Warehouse
  2. B The processing required to run queries against a SQL Data Warehouse
  3. C The entire process of loading data into the warehouse and all of the data warehouse activities such as analyzing, reporting, managing and exporting data
  4. D The amount of storage required to keep the data in Azure
Xem giải thích

Đáp án

C — TOÀN BỘ quy trình nạp dữ liệu vào kho và mọi hoạt động của kho dữ liệu: phân tích, báo cáo, quản lý và khai thác.

Vì sao đúng

⚠ "Workload" là khối lượng công việc, không phải chỉ dữ liệu hay chỉ truy vấn:

⚠ Nạp dữ liệu từ nhiều nguồn
        ↓
⚠ Làm sạch, chuẩn hoá, tích hợp
        ↓
⚠ Xây mô hình (fact, dimension)
        ↓
⚠ Phân tích và báo cáo
        ↓
⚠ Quản lý, tối ưu, lưu trữ dài hạn
        ↓
⚠ TẤT CẢ hợp thành data warehouse workload

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

  • B (việc xử lý cần thiết để chạy truy vấn) — ⚠ chỉ MỘT phần: ⚠ bỏ qua khâu nạp và quản lý.

  • A (dữ liệu chứa trong kho) — ⚠ là DỮ LIỆU, không phải khối lượng công việc.

  • D (dung lượng lưu trữ cần thiết) — ⚠ là chỉ số hạ tầng.

Ghi nhớ

⚠ Kiến trúc kho dữ liệu hiện đại trên Azure: | Tầng | Dịch vụ | |---|---| | ⚠ Nguồn | ⚠ CSDL vận hành, API, tệp | | ⚠ Nạp | ⚠ Data Factory, Synapse pipeline | | ⚠ Lưu thô | ⚠ Data Lake Gen2 | | ⚠ Biến đổi | ⚠ Spark, SQL pool, Databricks | | ⚠ Phục vụ | ⚠ Synapse dedicated pool, Fabric | | ⚠ Trình bày | ⚠ Power BI |

Từ khoá nhận diện:

"toàn bộ quy trình kho dữ liệu" → ⚠ data warehouse workload "ghi nhận giao dịch" → ⚠ OLTP workload "dòng dữ liệu liên tục" → ⚠ streaming workload "trích tri thức từ tài liệu" → ⚠ knowledge mining

⚠ Star schema — mô hình chuẩn của kho dữ liệu Thành phần
⚠ Bảng FACT ở giữa ⚠ số liệu đo được: doanh thu, số lượng
⚠ Bảng DIMENSION xung quanh ⚠ ngữ cảnh: thời gian, sản phẩm, khách hàng
⚠ Cố ý PHI CHUẨN HOÁ ⚠ giảm số JOIN, tăng tốc đọc
⚠ Khác OLTP ⚠ nơi chuẩn hoá cao để tối ưu ghi
⚠ Slowly Changing Dimension Vấn đề
⚠ Khách hàng chuyển địa chỉ thì sao
⚠ Type 1: ghi đè, mất lịch sử
⚠ Type 2: thêm dòng mới, GIỮ lịch sử ⚠ phổ biến nhất
⚠ Vì sao quan trọng ⚠ báo cáo quá khứ phải phản ánh đúng bối cảnh lúc đó
⚠ Kiến trúc medallion Tầng
⚠ Bronze: dữ liệu thô
⚠ Silver: đã làm sạch
⚠ Gold: đã tổng hợp cho nghiệp vụ
⚠ Ưu điểm ⚠ mỗi tầng dựng lại được từ tầng trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã tính cả khâu nạp và quản lý vào khối lượng công việc chưa | | | Dimension có xử lý thay đổi theo thời gian không | | | Có giữ tầng dữ liệu thô để dựng lại không | |

Và phần chiếm nhiều công sức nhất trong một dự án kho dữ liệu, thường bị đánh giá thấp khi lập kế hoạch: khâu nạp và làm sạch dữ liệu. Việc dựng báo cáo đẹp chỉ là phần nổi rất nhỏ.

Câu 100 Relational data
Which of the following sentences best describes what an INDEX is in SQL Server?
  1. A A special type of stored procedure that automatically runs with INSERT, UPDATE or DELETE statements take place.
  2. B A collection of tables that stores a specific set of structured data.
  3. C A virtual table whose contents are defined by a query.
  4. D A structure associated with a table or a view that speeds up retrieval of rows.
Xem giải thích

Đáp án

D — Một cấu trúc gắn với bảng hoặc view, giúp TĂNG TỐC việc truy xuất các dòng dữ liệu.

Vì sao đúng

⚠ Chỉ mục là cấu trúc tra cứu, giống mục lục của một cuốn sách:

⚠ Không có chỉ mục
   ⚠ Tìm "Nguyễn Văn A"
   ⚠ → QUÉT toàn bộ 10 triệu dòng
        ↓
⚠ Có chỉ mục trên cột tên
   ⚠ → đi thẳng tới đúng chỗ
   ⚠ → vài lần đọc trang
Loại chỉ mục Nội dung
⚠ Clustered ⚠ sắp xếp chính dòng dữ liệu, MỘT cái
⚠ Nonclustered ⚠ cấu trúc riêng có con trỏ, NHIỀU cái
⚠ Columnstore ⚠ lưu theo cột, cho phân tích
⚠ Filtered ⚠ chỉ đánh chỉ mục một phần dòng

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

  • C (bảng ảo định nghĩa bằng truy vấn) — ⚠ đó là VIEW.

  • A (thủ tục đặc biệt tự chạy khi có INSERT/UPDATE/DELETE) — ⚠ đó là TRIGGER.

  • B (tập hợp các bảng lưu dữ liệu có cấu trúc) — ⚠ đó là DATABASE.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư dùng chung bộ định nghĩa trong lô.

Câu Định nghĩa Khoá
⚠ #19563 ⚠ VIEW ⚠ bảng ảo từ truy vấn
⚠ #19565 ⚠ TABLE ⚠ nơi chứa dữ liệu
⚠ #19576 ⚠ STORED PROCEDURE ⚠ nhóm câu lệnh
⚠ #19590 (câu này) ⚠ INDEX ⚠ cấu trúc tăng tốc truy xuất
⚠ Bốn câu ⚠ cùng một bộ phương án xoay vòng
⚠ Mẹo ⚠ thuộc năm định nghĩa là ăn trọn cả chùm bốn câu

⚠ Năm đối tượng — bảng chốt cuối: | Đối tượng | Một câu định nghĩa | |---|---| | ⚠ Table | ⚠ nơi dữ liệu thật nằm | | ⚠ View | ⚠ truy vấn đặt tên, không lưu dữ liệu | | ⚠ Index | ⚠ cấu trúc phụ trợ tăng tốc tìm kiếm | | ⚠ Stored procedure | ⚠ nhóm câu lệnh gọi bằng EXEC | | ⚠ Trigger | ⚠ thủ tục tự chạy theo thao tác dữ liệu |

Từ khoá nhận diện:

"tăng tốc truy xuất" → ⚠ index "bảng ảo" → ⚠ view "tự động chạy" → ⚠ trigger "nhóm câu lệnh" → ⚠ stored procedure

⚠ Đánh đổi của chỉ mục — nhắc lại Đánh đổi
⚠ Đọc NHANH hơn
⚠ Ghi CHẬM hơn ⚠ mỗi chỉ mục phải cập nhật theo
⚠ Tốn dung lượng
⚠ Chỉ mục không dùng tới ⚠ chỉ có hại, không có lợi
⚠ Nên rà soát ⚠ sys.dm_db_index_usage_stats
⚠ Azure SQL tự động điều chỉnh Tính năng
⚠ Tự TẠO chỉ mục thiếu
⚠ Tự BỎ chỉ mục không dùng
⚠ Tự sửa kế hoạch thực thi kém ⚠ plan regression
⚠ Bật ở ⚠ Automatic tuning trong Portal
⚠ Nên bật ⚠ với hầu hết môi trường sản xuất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chỉ mục nào chưa từng được dùng không | | | Truy vấn chậm có thiếu chỉ mục không | | | Automatic tuning đã bật chưa | |

Và tính năng của Azure SQL đáng bật nhất mà nhiều người bỏ qua, vì nó âm thầm làm đúng việc một chuyên gia sẽ làm: automatic tuning. Nó tự thêm chỉ mục còn thiếu, bỏ chỉ mục vô dụng, và quay lui khi thay đổi làm mọi thứ tệ đi.