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

Tìm thấy 328 câu.

Câu 41 Relational data security
Your company has one SQL Database server that has two SQL Databases on it. You would like to allow connections over the public internet to these databases. Each database has a different set of clients with no overlap. You would like clients of one company to be able to access one database but not the other. How do you configure your firewall to enable this?
  1. A Server-level IP firewall
  2. B Network Security Group (NSG)
  3. C Database-level IP firewall
  4. D Azure Firewall service
Xem giải thích

Đáp án

C — Tường lửa IP ở cấp DATABASE.

Vì sao đúng

⚠ Yêu cầu quan trọng nhất: hai nhóm khách KHÔNG được truy cập chéo:

⚠ Luật cấp SERVER
   ⚠ áp cho MỌI database trên server
        ↓
⚠ Khách của DB1 sẽ vào được DB2
        ↓
⚠ VI PHẠM yêu cầu

⚠ Luật cấp DATABASE
   ⚠ áp cho ĐÚNG database đó
        ↓
⚠ Mỗi nhóm khách chỉ vào được DB của mình
Cấp luật Phạm vi
⚠ Server-level ⚠ mọi database trên server
⚠ Database-level ⚠ CHỈ database đó

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

  • A (tường lửa cấp SERVER) — ⚠ quá rộng: ⚠ cho phép IP nào là IP đó vào được ⚠ cả hai database.

  • B (Network Security Group) — ⚠ áp cho subnet và card mạng trong VNet, ⚠ không áp cho endpoint công khai của Azure SQL.

  • D (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 Azure SQL.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bộ ba với #19499 và #19511 ở lô trước.

Câu Hỏi gì Khoá
⚠ #19499 ⚠ luật nào được xét trước ⚠ database trước server
⚠ #19511 ⚠ vì sao không kết nối được từ nhà ⚠ chưa thêm IP vào tường lửa
⚠ #19531 (câu này) ⚠ cách cách ly hai nhóm khách ⚠ luật cấp database
⚠ Ba câu ⚠ cùng một chủ đề tường lửa Azure SQL

⚠ Vì sao luật cấp database mạnh hơn về bảo mật: | Điểm | Nội dung | |---|---| | ⚠ Phạm vi hẹp nhất | ⚠ đúng nguyên tắc đặc quyền tối thiểu | | ⚠ Được xét TRƯỚC luật server | | | ⚠ Đi theo database khi khôi phục hoặc sao chép | ⚠ lưu trong chính database | | ⚠ Khuyến nghị của Microsoft | ⚠ ưu tiên luật cấp database |

Từ khoá nhận diện:

"mỗi database một nhóm khách riêng" → ⚠ database-level firewall "cả server dùng chung một danh sách IP" → ⚠ server-level "chặn hẳn truy cập công cộng" → ⚠ private endpoint "lọc lưu lượng trong VNet" → ⚠ NSG

⚠ Cách tạo luật cấp database Cách
⚠ Kết nối VÀO chính database đó
⚠ Chạy sp_set_database_firewall_rule
⚠ Không tạo được từ Portal như luật server ⚠ điểm hay vướng
⚠ Xem lại bằng ⚠ sys.database_firewall_rules
⚠ Nếu muốn cách ly triệt để hơn Cách
⚠ Private endpoint cho từng nhóm khách
⚠ Hoặc tách hẳn thành hai server
⚠ Tường lửa IP ⚠ là lớp đầu, không thay thế phân quyền trong database

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có luật cấp server nào đang quá rộng không | | | Người dùng của DB1 có tài khoản trên DB2 không | ⚠ phân quyền cũng phải tách | | Có thể dùng private endpoint không | |

Và điều cần nhớ ngay cả khi tường lửa đã cấu hình chuẩn: tường lửa chỉ quyết định ai được GÕ CỬA, không quyết định ai được VÀO. Phân quyền tài khoản bên trong từng database mới là lớp cách ly thật sự.

Câu 42 Relational DB management
You have a SQL Server running inside your own environment, and you'd like to migrate it into the cloud. You happen to know that the settings on the database has been customized for a business reason. You need to be sure that absolutely NO code will have to change when you move this database - only the connection string. Which is the best way to migrate a SQL Server to Azure to ensure absolutely guaranteed no coding or SQL database schema changes required?
  1. A Migrate to Azure Table Storage
  2. B Migrate to Azure SQL Database
  3. C Migrate to Azure Managed SQL Instance
  4. D Migrate to SQL Server in a VM
Xem giải thích

Đáp án

D — Chuyển sang SQL Server chạy trên máy ảo (VM).

Vì sao đúng

⚠ Yêu cầu tuyệt đối của đề: KHÔNG được đổi một dòng mã nào, chỉ đổi chuỗi kết nối: | Lựa chọn | Rủi ro phải sửa mã | |---|---| | ⚠ SQL Server trong VM | ⚠ KHÔNG — cùng một sản phẩm | | ⚠ Managed Instance | ⚠ rất tương thích nhưng CÓ khác biệt | | ⚠ Azure SQL Database | ⚠ nhiều tính năng không hỗ trợ | | ⚠ Table Storage | ⚠ đổi hoàn toàn mô hình dữ liệu |

⚠ Đề nhấn mạnh
   ⚠ "cài đặt đã TUỲ CHỈNH vì lý do nghiệp vụ"
   ⚠ "TUYỆT ĐỐI không đổi mã"
        ↓
⚠ Chỉ có bản SQL Server ĐẦY ĐỦ mới bảo đảm

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

  • C (Managed Instance) — ⚠ bẫy mạnh nhất: ⚠ tương thích ⚠ gần như hoàn toàn, ⚠ nhưng vẫn có khác biệt về cấu hình cấp instance, tính năng hệ thống và một số cài đặt tuỳ chỉnh; ⚠ đề nói ⚠ TUYỆT ĐỐI không đổi mã nên chỉ VM mới bảo đảm chắc chắn.

  • B (Azure SQL Database) — ⚠ thiếu nhiều thứ: ⚠ SQL Agent, cross-database query, một số cấu hình cấp server.

  • A (Table Storage) — ⚠ đổi hẳn sang phi quan hệ, phải viết lại toàn bộ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #19533 trong cùng lô — ⚠ câu kia hỏi cái nào là IaaS, cũng dẫn về SQL Server trong VM.

⚠ Thang tương thích khi di chuyển SQL Server: | Đích | Tương thích | Công vận hành | |---|---|---| | ⚠ SQL Server trong VM | ⚠ 100% | ⚠ cao nhất — bạn tự vá, tự sao lưu | | ⚠ Managed Instance | ⚠ rất cao | ⚠ trung bình | | ⚠ SQL Database | ⚠ trung bình | ⚠ thấp nhất | | ⚠ Nguyên tắc | ⚠ càng tương thích càng nhiều việc vận hành |

Từ khoá nhận diện:

"không đổi một dòng mã" → ⚠ SQL Server trong VM "lift and shift, tương thích cao, giảm vận hành" → ⚠ Managed Instance "ứng dụng mới, hiện đại hoá" → ⚠ Azure SQL Database "cần SQL Agent và cross-database query" → ⚠ Managed Instance trở lên

⚠ Tính năng chỉ có ở VM Tính năng
⚠ Toàn quyền hệ điều hành
⚠ Cài thêm phần mềm bên thứ ba lên máy chủ
⚠ Cấu hình cấp instance tuỳ ý
⚠ Phiên bản SQL Server cũ
⚠ SSRS, SSAS cài cùng máy
⚠ Cái giá của VM Cái giá
⚠ Bạn tự vá hệ điều hành và SQL Server
⚠ Bạn tự cấu hình HA (Always On)
⚠ Bạn tự lo sao lưu ⚠ có Azure Backup hỗ trợ
⚠ SQL IaaS Agent extension ⚠ giúp tự động vá và sao lưu một phần
⚠ Cách đánh giá trước khi di chuyển Cách
⚠ Chạy Data Migration Assistant ⚠ liệt kê tính năng không tương thích
⚠ Xem báo cáo rồi mới chọn đích
⚠ Đừng ⚠ chọn đích trước rồi mới phát hiện không chạy được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chạy đánh giá tương thích chưa | | | Có tính năng nào chỉ VM mới có không | | | Đội vận hành có sẵn sàng tự vá máy chủ không | |

Và đánh đổi xuyên suốt mọi quyết định di chuyển cơ sở dữ liệu lên đám mây: tương thích càng cao thì công vận hành càng nhiều. Chọn VM là mua sự chắc chắn bằng chính thời gian của đội vận hành.

Câu 43 Relational data services
Which of the following Azure databases is considered Infrastructure as a Service (Iaas)?
  1. A SQL Server in a VM
  2. B SQL Database
  3. C Cosmos DB
  4. D Managed SQL Instance
Xem giải thích

Đáp án

A — SQL Server chạy trên máy ảo (VM).

Vì sao đúng

⚠ Chỉ có một lựa chọn mà bạn phải quản lý hệ điều hành: | Dịch vụ | Mô hình | Bạn quản lý | |---|---|---| | ⚠ SQL Server trong VM | ⚠ IaaS | ⚠ hệ điều hành, vá lỗi, SQL Server | | ⚠ Azure SQL Database | ⚠ PaaS | ⚠ chỉ database | | ⚠ Managed Instance | ⚠ PaaS | ⚠ chỉ instance logic | | ⚠ Cosmos DB | ⚠ PaaS | ⚠ chỉ dữ liệu |

⚠ Câu hỏi phân biệt
   ⚠ "Ai cài bản vá Windows tháng này?"
        ↓ ⚠ BẠN
⚠ IaaS

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

  • B, C, D — ⚠ đều là PaaS: ⚠ Microsoft lo hạ tầng, hệ điều hành và bản vá.

Ghi nhớ

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

Câu Hỏi gì Khoá
⚠ #19530 ⚠ Cosmos DB thuộc mô hình nào ⚠ PaaS
⚠ #19532 ⚠ di chuyển không đổi mã thì chọn gì ⚠ SQL Server trong VM
⚠ #19533 (câu này) ⚠ cái nào là IaaS ⚠ SQL Server trong VM
⚠ Ba câu ⚠ cùng một bảng phân loại, không mâu thuẫn

⚠ Bảng phân chia trách nhiệm — học một lần: | Tầng | IaaS | PaaS | SaaS | |---|---|---|---| | ⚠ Dữ liệu | ⚠ bạn | ⚠ bạn | ⚠ bạn | | ⚠ Ứng dụng | ⚠ bạn | ⚠ bạn | ⚠ MS | | ⚠ Runtime | ⚠ bạn | ⚠ MS | ⚠ MS | | ⚠ Hệ điều hành | ⚠ bạn | ⚠ MS | ⚠ MS | | ⚠ Máy chủ, mạng, DC | ⚠ MS | ⚠ MS | ⚠ MS |

Từ khoá nhận diện:

"máy ảo, tự cài, tự vá" → ⚠ IaaS "dịch vụ được quản lý" → ⚠ PaaS "phần mềm dùng ngay" → ⚠ SaaS "dữ liệu" → ⚠ LUÔN là bạn, ở mọi mô hình

⚠ Khi nào IaaS vẫn là lựa chọn đúng Khi nào
⚠ Cần phiên bản SQL Server cũ
⚠ Cần cài phần mềm bên thứ ba lên máy chủ
⚠ Cần cấu hình cấp instance mà PaaS không cho
⚠ Yêu cầu tuân thủ đòi kiểm soát hoàn toàn
⚠ Ngoài các trường hợp đó ⚠ PaaS gần như luôn hợp lý hơn
⚠ Chi phí ẩn của IaaS Chi phí
⚠ Thời gian vá lỗi và bảo trì
⚠ Thiết lập và kiểm thử HA
⚠ Xây dựng quy trình sao lưu
⚠ Giám sát hệ điều hành
⚠ Thường bị bỏ qua ⚠ khi so sánh giá theo giờ giữa VM và PaaS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai vá hệ điều hành | ⚠ câu hỏi phân biệt | | Có lý do bắt buộc phải dùng VM không | | | Đã tính chi phí vận hành vào so sánh chưa | |

Và sai lệch phổ biến khi so sánh chi phí giữa máy ảo và dịch vụ được quản lý: chỉ so giá theo giờ mà quên thời gian con người. Vá lỗi, sao lưu và dựng HA đều là chi phí thật, chỉ không nằm trên hoá đơn.

Câu 44 Analytics Workload
Which of the following database models is optimized for deep, complex queries that might take hours to run or tie up the computer from handling other tasks?
  1. A Data Lake storage
  2. B Azure Stream Analytics
  3. C OLAP (online analytical processing)
  4. D OLTP (online transaction processing)
Xem giải thích

Đáp án

C — OLAP (xử lý phân tích trực tuyến).

Vì sao đúng

⚠ OLAP thiết kế cho truy vấn phân tích sâu, quét khối lượng lớn: | Đặc điểm OLAP | Nội dung | |---|---| | ⚠ Đọc RẤT nhiều, ghi ít | | | ⚠ Truy vấn tổng hợp phức tạp | ⚠ nhiều chiều, nhiều bảng | | ⚠ Chạy lâu là bình thường | | | ⚠ Dữ liệu thường PHI CHUẨN HOÁ | ⚠ star schema | | ⚠ Lưu theo CỘT | ⚠ columnstore |

⚠ OLTP
   ⚠ "Ghi đơn hàng này" — mili giây
⚠ OLAP
   ⚠ "Doanh thu theo vùng, sản phẩm, quý,
      5 năm qua" — phút tới giờ

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

  • D (OLTP) — ⚠ NGƯỢC: ⚠ tối ưu cho nhiều giao dịch NGẮN, phải trả lời trong mili giây.

  • A (Data Lake storage) — ⚠ là nơi LƯU dữ liệu, không phải mô hình xử lý.

  • B (Stream Analytics) — ⚠ xử lý dòng thời gian thực, ngược hẳn với truy vấn chạy hàng giờ.

Ghi nhớ

⚠ OLTP và OLAP — bảng đối chiếu: | Tiêu chí | OLTP | OLAP | |---|---|---| | ⚠ Mục đích | ⚠ ghi nhận giao dịch | ⚠ phân tích, báo cáo | | ⚠ Thao tác | ⚠ nhiều, ngắn | ⚠ ít, dài | | ⚠ Chuẩn hoá | ⚠ cao | ⚠ thấp, star schema | | ⚠ Lưu trữ | ⚠ theo DÒNG | ⚠ theo CỘT | | ⚠ Dữ liệu | ⚠ hiện tại | ⚠ lịch sử dài | | ⚠ Dịch vụ Azure | ⚠ Azure SQL, Cosmos | ⚠ Synapse, Fabric, Analysis Services |

Từ khoá nhận diện:

"truy vấn sâu, chạy hàng giờ, phân tích" → ⚠ OLAP "ghi đơn hàng, cập nhật tồn kho" → ⚠ OLTP "cảnh báo trong vài giây" → ⚠ stream processing "kho chứa mọi định dạng" → ⚠ data lake

⚠ Vì sao lưu theo CỘT tốt cho phân tích Lý do
⚠ Truy vấn phân tích thường chỉ dùng vài cột
⚠ Lưu theo cột chỉ đọc đúng cột cần
⚠ Giá trị cùng cột giống nhau nên nén rất tốt
⚠ Ngược lại OLTP ⚠ cần cả DÒNG nên lưu theo dòng nhanh hơn
⚠ Vì sao tách hai hệ thống Lý do
⚠ Truy vấn phân tích nặng sẽ làm chậm hệ giao dịch
⚠ Hai bên tối ưu theo hai hướng đối nghịch
⚠ Cách nối ⚠ ETL/ELT chuyển dữ liệu từ OLTP sang OLAP
⚠ Xu hướng mới ⚠ HTAP — Synapse Link cho phép phân tích gần thời gian thực mà không đụng hệ giao dịch
⚠ Synapse Link — đáng biết Nội dung
⚠ Nhân bản dữ liệu từ Cosmos DB hoặc SQL sang kho phân tích
⚠ Gần thời gian thực, KHÔNG tốn RU của hệ giao dịch
⚠ Giải quyết ⚠ nhu cầu phân tích mà không dựng luồng ETL riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn này ghi hay đọc là chính | | | Có làm chậm hệ giao dịch không | | | Có cần dữ liệu lịch sử dài không | |

Và lý do các tổ chức tách kho phân tích ra khỏi cơ sở dữ liệu vận hành, dù nghe như trùng lặp công sức: hai loại tải này tối ưu theo hai hướng đối nghịch nhau. Ép chúng chung một hệ thống thì cả hai đều chậm.

Câu 45 SQL
Which of the following are examples of Data Manipulation Language (DML) SQL statements?
  1. A CREATE, DROP, ALTER
  2. B GRANT, REVOKE
  3. C SELECT, INSERT, UPDATE
  4. D COMMIT, ROLLBACK
Xem giải thích

Đáp án

C — SELECT, INSERT, UPDATE.

Vì sao đúng

⚠ Ba câu lệnh này đều thao tác trên DỮ LIỆU bên trong bảng: | Câu lệnh | Việc | |---|---| | ⚠ SELECT | ⚠ đọc dữ liệu | | ⚠ INSERT | ⚠ thêm dòng | | ⚠ UPDATE | ⚠ sửa dòng | | ⚠ DELETE | ⚠ xoá dòng — cũng là DML |

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

  • A (CREATE, DROP, ALTER) — ⚠ DDL: ⚠ thao tác trên CẤU TRÚC.

  • B (GRANT, REVOKE) — ⚠ DCL: ⚠ thao tác trên QUYỀN.

  • D (COMMIT, ROLLBACK) — ⚠ TCL: ⚠ thao tác trên GIAO DỊCH.

⚠ Bốn phương án chính là bốn nhóm — ⚠ đề trình bày rất gọn gàng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về phân nhóm câu lệnh SQL trong hai lô liền nhau.

Câu Hỏi gì Khoá
⚠ #19493 ⚠ SELECT thuộc nhóm nào ⚠ DML
⚠ #19529 ⚠ DDL làm gì ⚠ định nghĩa cấu trúc
⚠ #19535 (câu này) ⚠ ví dụ nào là DML ⚠ SELECT, INSERT, UPDATE
⚠ Ba câu ⚠ cùng một bảng, ba chiều hỏi, không mâu thuẫn
⚠ Kết luận ⚠ thuộc bảng bốn nhóm là ăn cả ba câu

⚠ Bảng bốn nhóm — chốt lại: | Nhóm | Câu lệnh | Tác động | |---|---|---| | ⚠ DDL | ⚠ CREATE, ALTER, DROP, TRUNCATE | ⚠ cấu trúc | | ⚠ DML | ⚠ SELECT, INSERT, UPDATE, DELETE | ⚠ dữ liệu | | ⚠ DCL | ⚠ GRANT, REVOKE, DENY | ⚠ quyền | | ⚠ TCL | ⚠ COMMIT, ROLLBACK, SAVE | ⚠ giao dịch |

Từ khoá nhận diện:

"đọc, thêm, sửa, xoá dữ liệu" → ⚠ DML "tạo bảng, sửa cột" → ⚠ DDL "cấp quyền" → ⚠ DCL "chốt hay huỷ giao dịch" → ⚠ TCL

⚠ Bốn tính chất ACID của giao dịch Tính chất
⚠ Atomicity ⚠ tất cả hoặc không gì cả
⚠ Consistency ⚠ CSDL luôn ở trạng thái hợp lệ
⚠ Isolation ⚠ các giao dịch không giẫm lên nhau
⚠ Durability ⚠ đã commit là còn mãi, kể cả mất điện
⚠ TCL ⚠ là nhóm câu lệnh thực thi các tính chất này
⚠ Vì sao DELETE nằm cùng nhóm SELECT Lý do
⚠ Cả hai đều thao tác trên NỘI DUNG bảng
⚠ Không đụng tới định nghĩa bảng
⚠ Rollback được trong giao dịch
⚠ Trong khi TRUNCATE ⚠ là DDL vì nó thao tác ở mức trang dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lệnh đụng cấu trúc hay nội dung | | | Có trong giao dịch để rollback không | | | DELETE hay TRUNCATE phù hợp hơn | |

Và cách nhớ dứt điểm nhóm câu lệnh SQL, thay vì học thuộc từng danh sách: hỏi câu lệnh này thay đổi CÁI GÌ — cấu trúc, nội dung, quyền, hay trạng thái giao dịch.

Câu 46 Non-relational DB
What do you get when you use Archive access tier for Azure Blob Storage?
  1. A The fastest way to retrieve files in Azure for high-performance needs
  2. B 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.
  3. C The default level of access, set when you first create the storage account as default.
  4. D Way less expensive to store the file, and long delay to access the file (perhaps hours)
Xem giải thích

Đáp án

D — RẺ HƠN RẤT NHIỀU khi lưu tệp, và có ĐỘ TRỄ DÀI khi truy cập (có thể hàng giờ).

Vì sao đúng

⚠ Archive là tầng lạnh nhất, và đánh đổi rất rõ ràng: | Đặc điểm Archive | Nội dung | |---|---| | ⚠ Giá lưu rẻ nhất | ⚠ thấp hơn Hot nhiều lần | | ⚠ Blob ở trạng thái OFFLINE | ⚠ không đọc trực tiếp được | | ⚠ Phải RÃ ĐÔNG trước | ⚠ rehydrate | | ⚠ Standard: tới 15 giờ | | | ⚠ High priority: dưới 1 giờ | ⚠ đắt hơn | | ⚠ Thời gian tối thiểu | ⚠ 180 ngày |

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

  • B (rẻ hơn một chút, đắt gấp đôi khi truy cập, không cần đổi mã) — ⚠ đó là mô tả tầng COOL.

  • C (mức mặc định khi tạo tài khoản) — ⚠ đó là HOT.

  • A (cách lấy tệp nhanh nhất) — ⚠ ngược hoàn toàn: ⚠ Archive là chậm nhất.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bộ ba về tầng lưu trữ cùng #19509 và #19528.

Câu Hỏi gì Khoá
⚠ #19509 ⚠ tầng Cool cho gì ⚠ rẻ hơn khi lưu, đắt hơn khi đọc
⚠ #19528 ⚠ giảm chi phí 10TB log cũ ⚠ lifecycle policy
⚠ #19536 (câu này) ⚠ tầng Archive cho gì ⚠ rẻ nhất, chờ hàng giờ
⚠ Ba câu ⚠ cùng một trục kiến thức
⚠ Điểm phân biệt Cool và Archive ⚠ Cool đọc NGAY, Archive phải RÃ ĐÔNG

⚠ Bốn tầng blob — bảng chốt: | Tầng | Giá lưu | Truy cập | Tối thiểu | |---|---|---|---| | ⚠ Hot | ⚠ cao nhất | ⚠ ngay, rẻ nhất | ⚠ không | | ⚠ Cool | ⚠ thấp hơn | ⚠ ngay, đắt hơn | ⚠ 30 ngày | | ⚠ Cold | ⚠ thấp hơn nữa | ⚠ ngay, đắt hơn nữa | ⚠ 90 ngày | | ⚠ Archive | ⚠ thấp nhất | ⚠ PHẢI RÃ ĐÔNG | ⚠ 180 ngày |

Từ khoá nhận diện:

"rẻ nhất, chờ hàng giờ" → ⚠ Archive "rẻ hơn, đọc vẫn ngay" → ⚠ Cool hoặc Cold "mặc định khi tạo tài khoản" → ⚠ Hot "không được xoá trước hạn" → ⚠ immutable, khác hoàn toàn

⚠ Rã đông — chi tiết cần nhớ Chi tiết
⚠ Đổi tầng blob sang Hot hoặc Cool
⚠ Hoặc sao chép sang blob mới ở tầng nóng hơn ⚠ giữ nguyên bản gốc ở Archive
⚠ Standard priority: tới 15 giờ
⚠ High priority: dưới 1 giờ, đắt hơn nhiều
⚠ Trong lúc rã đông ⚠ blob KHÔNG đọc được
⚠ Archive phù hợp với gì Phù hợp
⚠ Lưu trữ tuân thủ nhiều năm
⚠ Sao lưu dài hạn
⚠ Dữ liệu y tế, tài chính phải giữ theo luật
⚠ Băng ghi hình cũ
⚠ Điều kiện chung ⚠ gần như chắc chắn không cần đọc, và nếu cần thì chờ được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chấp nhận chờ hàng giờ không | ⚠ điều kiện tiên quyết | | Sẽ giữ đủ 180 ngày chứ | ⚠ tránh phí rút sớm | | Ai biết rằng dữ liệu này ở Archive | ⚠ để không hứa nhầm thời gian khôi phục |

Và câu hỏi phải trả lời dứt khoát trước khi đẩy dữ liệu xuống Archive: nếu ngày mai cần gấp, chờ mười lăm tiếng có chấp nhận được không? Nếu không, mọi khoản tiết kiệm đều vô nghĩa.

Câu 47 Analytics workload
Which type of data analytics workload is best for processing time-sensitive data that arrives from an external source every few seconds?
  1. A Event-based messaging
  2. B Batch processing
  3. C Real-time processing
  4. D Azure Blob Storage
Xem giải thích

Đáp án

C — Xử lý thời gian thực (real-time processing).

Vì sao đúng

⚠ Hai dấu hiệu trong đề đều chỉ về xử lý dòng: | Dấu hiệu | Kết luận | |---|---| | ⚠ Dữ liệu về VÀI GIÂY một lần | ⚠ dòng liên tục | | ⚠ NHẠY VỚI THỜI GIAN | ⚠ kết quả phải có ngay |

⚠ Dữ liệu chảy liên tục
        ↓ ⚠ Event Hubs / IoT Hub
⚠ Stream Analytics xử lý trên CỬA SỔ thời gian
        ↓
⚠ Cảnh báo, bảng điều khiển cập nhật ngay

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

  • B (batch) — ⚠ NGƯỢC: ⚠ xử lý theo lô có độ trễ hàng giờ, ⚠ không hợp với dữ liệu nhạy thời gian.

  • A (nhắn tin theo sự kiện) — ⚠ là cơ chế TRUYỀN TIN giữa các thành phần, ⚠ không phải mô hình phân tích.

  • D (Azure Blob Storage) — ⚠ là nơi LƯU dữ liệu, không phải mô hình xử lý.

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 #19516 trong cùng lô.

Câu Tần suất dữ liệu Khoá
⚠ #19516 ⚠ một lần MỖI NGÀY ⚠ batch
⚠ #19537 (câu này) ⚠ vài GIÂY một lần, nhạy thời gian ⚠ real-time
⚠ KHÔNG mâu thuẫn ⚠ tần suất và độ nhạy quyết định mô hình
⚠ Cách đọc đề ⚠ tìm hai chi tiết: dữ liệu về BAO LÂU MỘT LẦN, và chậm có sao không

⚠ Kiến trúc xử lý dòng trên Azure: | Tầng | Dịch vụ | |---|---| | ⚠ Nhập | ⚠ Event Hubs, IoT Hub | | ⚠ Xử lý | ⚠ Stream Analytics, Functions, Databricks Structured Streaming | | ⚠ Lưu | ⚠ Cosmos DB, Data Lake, SQL | | ⚠ Hiển thị | ⚠ Power BI streaming dataset |

Từ khoá nhận diện:

"vài giây, nhạy thời gian, cảnh báo ngay" → ⚠ real-time / stream "mỗi ngày, cuối tháng" → ⚠ batch "hàng đợi tin nhắn giữa dịch vụ" → ⚠ Service Bus, Queue Storage "sự kiện thay đổi tài nguyên" → ⚠ Event Grid

⚠ Event Hubs, Event Grid, Service Bus — phân biệt Phân biệt
⚠ Event Hubs ⚠ DÒNG sự kiện khối lượng lớn — telemetry
⚠ Event Grid ⚠ sự kiện rời rạc, phản ứng theo sự kiện
⚠ Service Bus ⚠ tin nhắn nghiệp vụ, đảm bảo thứ tự và giao nhận
⚠ Ba cái này ⚠ rất hay bị hỏi lẫn nhau
⚠ Cửa sổ thời gian trong Stream Analytics Loại
⚠ Tumbling ⚠ cửa sổ liền kề, không chồng nhau
⚠ Hopping ⚠ có chồng lấn
⚠ Sliding ⚠ trượt theo sự kiện
⚠ Session ⚠ gom theo khoảng lặng
⚠ Vì sao cần ⚠ dòng dữ liệu vô hạn, phải cắt thành khối để tổng hợp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kết quả chậm bao lâu thì mất giá trị | | | Dữ liệu về theo đợt hay chảy liên tục | | | Có cần xử lý sự kiện đến muộn không | ⚠ cấu hình late arrival |

Và chi tiết trong xử lý dòng thường gây rắc rối nhất khi triển khai thật: sự kiện đến muộn hoặc sai thứ tự. Mạng và thiết bị không bảo đảm gì, và mọi phép tổng hợp theo cửa sổ đều phải có chính sách cho tình huống đó.

Câu 48 Relational data security
What type of security does Transparent Data Encryption (TDE) provide?
  1. A Data-at-rest encryption
  2. B Data-in-transit encryption
  3. C End-to-end (E2E) encryption
  4. D Secure storage of secrets, keys and certificates
Xem giải thích

Đáp án

A — Mã hoá dữ liệu KHI LƯU TRỮ (data-at-rest encryption).

Vì sao đúng

⚠ TDE mã hoá tệp dữ liệu ở tầng lưu trữ, hoàn toàn trong suốt với ứng dụng:

⚠ Dữ liệu trong bộ nhớ: BẢN RÕ
        ↓ ⚠ ghi xuống đĩa
⚠ TDE mã hoá
        ↓
⚠ Tệp .mdf, .ldf, bản sao lưu: MÃ HOÁ
        ↓
⚠ Ai lấy được file cũng không đọc được
Đặc điểm Nội dung
⚠ Trong suốt với ứng dụng ⚠ không đổi một dòng mã
⚠ Mã hoá cả bản sao lưu ⚠ lợi ích lớn
⚠ BẬT MẶC ĐỊNH trên Azure SQL
⚠ Khoá do Microsoft hoặc bạn quản lý ⚠ BYOK qua Key Vault

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

  • B (mã hoá khi TRUYỀN) — ⚠ đó là TLS/SSL.

  • C (mã hoá đầu-cuối) — ⚠ đó là Always Encrypted: ⚠ dữ liệu chỉ giải mã ở client.

  • D (lưu trữ an toàn bí mật, khoá, chứng chỉ) — ⚠ đó là Azure Key Vault.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bộ ba cơ chế mã hoá cùng #19492 và #19494 ở lô trước.

Câu Cơ chế Bảo vệ khỏi
⚠ #19492 ⚠ Dynamic Data Masking ⚠ lộ dữ liệu vô ý khi hiển thị
⚠ #19494 ⚠ Always Encrypted ⚠ chính DBA
⚠ #19538 (câu này) ⚠ TDE ⚠ người lấy được FILE
⚠ Ba cơ chế ⚠ bổ sung nhau, không thay thế nhau

⚠ Ba trạng thái của dữ liệu — bảng phải thuộc: | Trạng thái | Bảo vệ bằng | |---|---| | ⚠ At rest (khi lưu) | ⚠ TDE, Storage Service Encryption | | ⚠ In transit (khi truyền) | ⚠ TLS, HTTPS | | ⚠ In use (khi xử lý) | ⚠ Always Encrypted, confidential computing |

Từ khoá nhận diện:

"mã hoá file trên đĩa, bản sao lưu" → ⚠ TDE "mã hoá đường truyền" → ⚠ TLS "client mã hoá, server không đọc được" → ⚠ Always Encrypted "kho lưu khoá và bí mật" → ⚠ Key Vault

⚠ TDE bảo vệ và KHÔNG bảo vệ gì Nội dung
⚠ BẢO VỆ: ai lấy được file .mdf hoặc file sao lưu
⚠ KHÔNG bảo vệ: người đăng nhập hợp lệ vào CSDL
⚠ KHÔNG bảo vệ: DBA
⚠ Vì sao ⚠ giải mã diễn ra tự động khi CSDL đọc dữ liệu
⚠ Muốn chặn DBA ⚠ phải dùng Always Encrypted
⚠ BYOK — quản lý khoá của riêng bạn Nội dung
⚠ Khoá bảo vệ TDE lưu trong Key Vault của bạn
⚠ Bạn kiểm soát vòng đời và việc thu hồi
⚠ Xoá khoá = CSDL không mở được nữa ⚠ rủi ro thật
⚠ 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 | |---|---| | TDE có đang bật không | ⚠ mặc định bật trên Azure SQL | | Khoá do Microsoft hay do bạn quản lý | | | Nếu tự quản lý, Key Vault có purge protection chưa | |

Và giới hạn của TDE cần nói rõ với bên nghiệp vụ, để không tạo cảm giác an toàn sai lệch: nó bảo vệ dữ liệu khỏi người lấy được tệp, không bảo vệ khỏi người đăng nhập được vào cơ sở dữ liệu.

Câu 49 Non-relational DB
Which CosmosDB API format works best with key-value data?
  1. A Cassandra API
  2. B MongoDB API
  3. C Table API
  4. D Gremlin API
Xem giải thích

Đáp án

C — Table API.

Vì sao đúng

⚠ Mỗi API của Cosmos DB ứng với một mô hình dữ liệu: | API | Mô hình | |---|---| | ⚠ Table API | ⚠ KHOÁ-GIÁ TRỊ | | ⚠ MongoDB API | ⚠ tài liệu | | ⚠ Cassandra API | ⚠ cột rộng | | ⚠ Gremlin API | ⚠ đồ thị | | ⚠ NoSQL (SQL) API | ⚠ tài liệu — API gốc |

⚠ PartitionKey + RowKey → Thực thể
        ↓
⚠ Tra theo khoá: rất nhanh
⚠ Truy vấn theo trường khác: kém

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

  • B (MongoDB API) và ngầm là NoSQL API — ⚠ mô hình TÀI LIỆU, ⚠ hợp JSON lồng nhau truy vấn nhiều trường.

  • A (Cassandra API) — ⚠ cột rộng, cho khối lượng ghi rất lớn.

  • D (Gremlin API) — ⚠ đồ thị, cho quan hệ nhiều tầng.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về khoá-giá trị trong hai lô liền nhau.

Câu Hỏi gì Khoá
⚠ #19496 ⚠ những dịch vụ nào là khoá-giá trị ⚠ Table Storage, Redis, Cosmos Table API
⚠ #19521 ⚠ kho khoá-giá trị rẻ nhất ⚠ Table Storage
⚠ #19539 (câu này) ⚠ API Cosmos nào cho khoá-giá trị ⚠ Table API
⚠ Ba câu ⚠ cùng bảng kiến thức, không mâu thuẫn

⚠ Chọn API Cosmos DB — bảng quyết định: | Tình huống | API | |---|---| | ⚠ Ứng dụng mới, tài liệu JSON | ⚠ NoSQL | | ⚠ Khoá-giá trị đơn giản | ⚠ Table | | ⚠ Di chuyển từ MongoDB | ⚠ MongoDB | | ⚠ Di chuyển từ Cassandra | ⚠ Cassandra | | ⚠ Dữ liệu quan hệ nhiều tầng | ⚠ Gremlin |

Từ khoá nhận diện:

"khoá-giá trị" → ⚠ Table API "JSON, truy vấn nhiều trường" → ⚠ NoSQL API "đỉnh và cạnh" → ⚠ Gremlin "ghi rất nhiều, chuỗi thời gian" → ⚠ Cassandra

⚠ Table API và Table Storage — nên chọn cái nào So sánh
⚠ Cùng API lập trình, đổi qua lại dễ
⚠ Table Storage: rẻ hơn nhiều
⚠ Cosmos Table API: SLA độ trễ, toàn cầu, chỉ mục mọi trường
⚠ Bắt đầu bằng ⚠ Table Storage, nâng cấp khi thật sự cần
⚠ Nhắc lại: API không đổi được Nhắc lại
⚠ Chọn lúc TẠO tài khoản
⚠ Đổi phải tạo mới và di chuyển dữ liệu
⚠ Cùng với ⚠ partition key — hai quyết định vĩnh viễn của Cosmos DB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mô hình dữ liệu thật sự là gì | | | Có đang di chuyển từ hệ thống nào không | | | Table Storage đã đủ chưa | ⚠ rẻ hơn nhiều |

Và nguyên tắc chọn API Cosmos DB gọn nhất: API tương thích là để DI CHUYỂN hệ thống cũ, ứng dụng mới nên bắt đầu bằng API gốc trừ khi mô hình dữ liệu đòi hỏi khác.

Câu 50 Data processing
Every day, car dealers upload their sales and service reports into your web portal. Your web portal stores these files in a Blob Storage container. The data is formatted exactly as your Cosmos DB data needs it. You don't anticipdate needing to modify it before getting it into the database. Which data ingestion model seems to work best for this scenario?
  1. A ETL
  2. B ELT
Xem giải thích

Đáp án

B — ELT.

Vì sao đúng

⚠ Chi tiết quyết định nằm ở câu "dữ liệu đã đúng định dạng, không cần sửa trước khi vào CSDL": | Mô hình | Thứ tự | Khi nào | |---|---|---| | ⚠ ETL | ⚠ trích → BIẾN ĐỔI → nạp | ⚠ cần làm sạch trước | | ⚠ ELT | ⚠ trích → NẠP → biến đổi (nếu cần) | ⚠ đề này |

⚠ Đại lý tải báo cáo lên
        ↓
⚠ Blob Storage
        ↓ ⚠ dữ liệu đã đúng định dạng
⚠ NẠP THẲNG vào Cosmos DB
        ↓
⚠ Không có bước biến đổi ở giữa → ELT

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

  • A (ETL) — ⚠ thừa một bước: ⚠ dựng tầng biến đổi cho dữ liệu ⚠ vốn đã đúng định dạng là tốn công và tốn tiền vô ích.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19517 trong cùng lô — ⚠ #19517 hỏi dịch vụ nào làm ETL/ELT, ⚠ câu này hỏi chọn mô hình nào.

⚠ ETL và ELT — bảng đối chiếu: | Tiêu chí | ETL | ELT | |---|---|---| | ⚠ Biến đổi ở đâu | ⚠ tầng trung gian riêng | ⚠ tại ĐÍCH | | ⚠ Phù hợp khi | ⚠ dữ liệu bẩn, cần chuẩn hoá | ⚠ đích đủ mạnh, dữ liệu sạch | | ⚠ Giữ dữ liệu thô | ⚠ thường không | ⚠ CÓ — nạp thô trước | | ⚠ Xu hướng đám mây | ⚠ cũ hơn | ⚠ phổ biến hơn |

Từ khoá nhận diện:

"dữ liệu đã đúng định dạng" → ⚠ ELT "phải làm sạch, chuẩn hoá trước" → ⚠ ETL "nạp thô rồi xử lý sau" → ⚠ ELT "kho đích mạnh, tự biến đổi được" → ⚠ ELT

⚠ Vì sao ELT thắng thế trên đám mây Lý do
⚠ Kho đích (Synapse, Databricks) rất mạnh
⚠ Lưu trữ rẻ nên giữ được dữ liệu thô
⚠ Giữ thô cho phép XỬ LÝ LẠI khi phát hiện lỗi logic ⚠ lợi ích lớn nhất
⚠ Không phải chạy lại từ nguồn
⚠ ETL truyền thống ⚠ biến đổi rồi vứt bản thô, sai là mất luôn
⚠ Kiến trúc medallion — mở rộng của ELT Tầng
⚠ Bronze ⚠ dữ liệu THÔ, y như nguồn
⚠ Silver ⚠ đã làm sạch và chuẩn hoá
⚠ 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
⚠ Kiểm tra chất lượng dữ liệu Kiểm
⚠ Ngay cả khi "đã đúng định dạng" vẫn nên kiểm
⚠ Đếm số dòng, kiểm trường bắt buộc
⚠ Cảnh báo khi lệch bất thường
⚠ Vì ⚠ nguồn dữ liệu bên ngoài có thể đổi định dạng bất cứ lúc nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dữ liệu nguồn có cần làm sạch không | | | Có giữ bản thô để xử lý lại không | | | Có kiểm tra chất lượng khi nạp không | |

Và lợi ích của ELT lớn nhất lại không nằm ở hiệu năng mà ở khả năng sửa sai: giữ bản thô nghĩa là khi phát hiện logic xử lý sai, bạn chạy lại được mà không cần xin dữ liệu từ nguồn lần nữa.