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

Đáp án

A — Microsoft Excel Workbook (.xlsx)

Vì sao đúng

Câu này tìm thứ không phải định dạng thông dụng để lưu trữ tệp dữ liệu trong ngữ cảnh kỹ thuật dữ liệu. Ba định dạng kia đều là định dạng văn bản mở: đọc được bằng bất kỳ công cụ nào, không phụ thuộc phần mềm cụ thể, và là chuẩn trao đổi dữ liệu giữa các hệ thống.

.xlsx thì khác: đó là định dạng riêng của một ứng dụng, thực chất là một tệp nén chứa nhiều tệp XML bên trong, kèm công thức, định dạng ô và biểu đồ. Nó dựng cho con người xem, không dựng cho hệ thống trao đổi dữ liệu.

Vì sao các phương án khác sai (chúng đều là định dạng thông dụng)

• D. CSV — đơn giản nhất cho dữ liệu dạng bảng.
• B. JSON — chuẩn cho dữ liệu phân cấp và API.
• C. XML — chuẩn lâu đời cho trao đổi dữ liệu giữa các hệ thống.

Đáp án

D — Parquet

Vì sao đúng

Parquet là định dạng nhị phân, lưu theo cột, và chính hai đặc điểm đó khiến nó thống trị trong phân tích dữ liệu lớn:

• Lưu theo cột — truy vấn chỉ đọc những cột nó cần, bỏ qua phần còn lại. Với bảng trăm cột mà truy vấn chỉ dùng ba cột thì lượng dữ liệu đọc giảm hàng chục lần.
• Nén rất tốt — dữ liệu cùng cột có kiểu giống nhau nên nén hiệu quả hơn hẳn định dạng theo dòng.

Nó cũng lưu kèm lược đồ trong chính tệp, nên công cụ đọc biết ngay kiểu của từng cột.

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

Ba định dạng còn lại đều là văn bản thuần và lưu theo dòng:

• A. CSV — đọc một cột vẫn phải quét cả tệp, và không có thông tin kiểu dữ liệu.
• B. XML và C. JSON — nặng hơn nữa vì mỗi bản ghi lặp lại tên trường.

Đáp án

C — Khoá ngoại (foreign key)

Vì sao đúng

Khoá ngoại là cơ chế thực thi toàn vẹn tham chiếu: nó bắt buộc giá trị trong một bảng phải tồn tại ở bảng được tham chiếu. Nhờ vậy không thể tạo đơn hàng cho một khách hàng không có thật, và không thể xoá khách hàng khi vẫn còn đơn hàng trỏ tới họ.

Điểm quan trọng: ràng buộc này được cơ sở dữ liệu bảo đảm, không phụ thuộc vào việc ứng dụng có kiểm tra hay không — nên mọi đường vào dữ liệu đều bị chặn như nhau.

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

• D. Trigger — có thể dùng để thực thi quy tắc, nhưng đó là mã bạn tự viết, khó bảo trì hơn và dễ sai hơn ràng buộc khai báo. Đây là phương án nhiễu gần nhất.
• A. View — truy vấn được đặt tên, không thực thi ràng buộc gì.
• B. Stored procedure — mã được lưu sẵn, cũng không tự tạo ra ràng buộc.

Đáp án

D — Kho khoá–giá trị với thiết kế không lược đồ, cho phép lưu dữ liệu linh hoạt và phi quan hệ

Vì sao đúng

Đây là mô tả đúng bản chất của Azure Table Storage: mỗi thực thể được định danh bằng cặp PartitionKey và RowKey, và các thực thể trong cùng bảng có thể có tập thuộc tính khác nhau — không có lược đồ bắt buộc.

Điểm cần nhớ về thiết kế: PartitionKey quyết định hiệu năng. Thực thể cùng partition nằm cùng chỗ nên truy vấn trong một partition rất nhanh, còn truy vấn xuyên partition thì chậm hẳn.

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

• C. Dữ liệu được tổ chức thành partition, và partition được lưu trong một tập thực thể — đảo ngược quan hệ: thực thể nằm trong partition, không phải partition nằm trong thực thể.
• B. Dựng để lưu đối tượng nhị phân lớn như video và ảnh — đó là Blob Storage.
• A. Hỗ trợ tự phân mảnh và phân tầng nóng/lạnh — phân tầng truy cập là tính năng của Blob Storage, không có ở Table Storage.

Đáp án

D — UPDATE

Vì sao đúng

UPDATE là lệnh sửa dữ liệu đã có trong bảng, thường kèm mệnh đề WHERE để giới hạn những dòng bị ảnh hưởng:

UPDATE KhachHang SET Email = 'moi@vidu.com' WHERE Id = 42;

Một điều đáng nhớ: quên WHERE thì lệnh sửa toàn bộ bảng. Đây là tai nạn kinh điển trên môi trường sản xuất, và là lý do nên chạy SELECT với cùng điều kiện trước để xem sẽ đụng vào bao nhiêu dòng.

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

• A. SELECT — chỉ đọc, không sửa gì.
• C. CREATE — tạo cấu trúc (bảng, chỉ mục, view), không đụng tới dữ liệu.
• B. DESC — không phải lệnh sửa dữ liệu; nó là từ khoá sắp xếp giảm dần trong ORDER BY.

Đáp án

B — CSV (Comma-Separated Values)

Vì sao đúng

CSV là định dạng đơn giản nhất cho dữ liệu dạng bảng: mỗi dòng là một bản ghi, các trường ngăn bằng dấu phẩy. Chính sự đơn giản đó làm nên độ phổ biến — mọi công cụ đều đọc được, và tệp có kích thước nhỏ hơn hẳn so với định dạng có thẻ bao quanh.

Đổi lại là những hạn chế thật: không có thông tin kiểu dữ liệu, không biểu diễn được cấu trúc lồng nhau, và phần xử lý dấu phẩy hay xuống dòng bên trong giá trị rất dễ sai.

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

• A. XML và D. JSON — dựng cho dữ liệu phân cấp; dùng cho bảng phẳng thì mỗi bản ghi phải lặp lại tên trường, làm tệp phình lên nhiều lần.
• C. HTML — ngôn ngữ trình bày trang web, không phải định dạng lưu trữ dữ liệu.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc kỳ thi chứng chỉ Microsoft Azure Data Fundamentals (DP-900), tập trung vào các loại replication (sao chép dữ liệu) trong Azure Storage account.

Yêu cầu cụ thể của câu hỏi:

• Tạo một Azure Storage account sao cho dữ liệu phải được sao chép tự động ra ngoài vùng Azure (region).
• Đây là câu hỏi multi-select (chọn nhiều đáp án), mỗi lựa chọn đúng đáng 1 điểm.
• Khái niệm chính: Replication trong Azure Storage đảm bảo tính sẵn sàng cao (high availability) và độ bền (durability) bằng cách sao chép dữ liệu. "Outside the Azure region" nghĩa là dữ liệu phải được replicate sang vùng thứ cấp (secondary region) khác, không chỉ trong cùng một region.

Bối cảnh kiến thức (cập nhật đến 2026): Theo tài liệu Azure Storage redundancy mới nhất (phiên bản 2024+), Azure hỗ trợ các loại replication khác nhau. Replication geo (GRS/RA-GRS) tự động sao chép dữ liệu bất đồng bộ (asynchronous) sang vùng thứ cấp (paired region), cách xa hàng trăm km, để chống lại sự cố toàn vùng. Các loại khác chỉ replicate trong cùng region.
📘 Tài liệu tham khảo:

• Azure Storage redundancy options
• Choose the right redundancy for Azure Blob Storage

✅ Đáp án đúng

Hai loại replication đáp ứng yêu cầu sao chép tự động ra ngoài region là:
read-access geo-redundant storage (RA-GRS) và geo-redundant storage (GRS).

Lý do lựa chọn:
🛠️ Cả hai đều replicate dữ liệu từ primary region sang secondary region (vùng ghép đôi tự động như East US → West US), đảm bảo tự động và geo-scale. RA-GRS còn cho phép đọc từ secondary, nhưng cả hai đều "outside the region". Đây là giải pháp hoàn chỉnh theo yêu cầu câu hỏi.

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn giữ nguyên văn bản gốc tiếng Anh, với lý do đúng/sai bằng tiếng Việt:

• zone-redundant storage (ZRS) ❌ SAI
  🧩 ZRS sao chép dữ liệu đồng bộ (synchronous) qua 3 Availability Zones (AZs) trong cùng một region, không replicate ra ngoài region. Nó chỉ bảo vệ chống sự cố zone/datacenter cục bộ, không đáp ứng "outside the Azure region".

• read-access geo-redundant storage (RA-GRS) ✅ ĐÚNG
  🛠️ RA-GRS = GRS + quyền read từ secondary region. Dữ liệu được replicate bất đồng bộ sang vùng thứ cấp xa xôi, tự động và hoàn toàn "outside the region". Đây là lựa chọn mạnh mẽ cho disaster recovery với read access.

• locally-redundant storage (LRS) ❌ SAI
  🧩 LRS chỉ sao chép 3 bản sao trong cùng một data center (không qua AZs), hoàn toàn giới hạn trong region. Không có cơ chế replicate ra ngoài, nên không đáp ứng yêu cầu.

• geo-redundant storage (GRS) ✅ ĐÚNG
  🛠️ GRS replicate dữ liệu bất đồng bộ từ primary sang secondary region (outside the region), với độ bền 99.999999999% (16 9's) trong 1 năm. Hoàn chỉnh cho yêu cầu tự động replicate geo.

Kết luận 🎯: Chọn RA-GRS và GRS để đạt điểm tối đa. Nếu cần tùy chỉnh, dùng Azure Portal/CLI để chọn replication khi tạo storage account!

🧩 Giải thích nội dung câu hỏi

Câu hỏi này xoay quanh việc xử lý một truy vấn SQL (SQL query) kết hợp dữ liệu khách hàng (customer data) và dữ liệu đơn hàng (order data), đồng thời bao gồm các cột được tính toán (calculated columns). 📊 Mục tiêu là tạo một đối tượng cơ sở dữ liệu (database object) cho phép người dùng khác có thể chạy lại chính xác cùng một truy vấn SQL đó mà không cần viết lại mã.

🛠️ Đây là tình huống phổ biến trong các hệ quản trị cơ sở dữ liệu quan hệ (RDBMS) như SQL Server trên Azure SQL Database hoặc AWS RDS for SQL Server (phiên bản mới nhất 2023-2026 vẫn giữ nguyên khái niệm cốt lõi). Câu hỏi kiểm tra kiến thức về các đối tượng cơ sở dữ liệu giúp tái sử dụng và chia sẻ truy vấn phức tạp một cách an toàn, hiệu quả, thay vì lưu trữ dữ liệu vật lý hoặc tối ưu hóa truy cập.

✅ Đáp án đúng: a view

Lý do lựa chọn:
Một view là đối tượng cơ sở dữ liệu lý tưởng vì nó lưu trữ định nghĩa của truy vấn SQL (query definition) dưới dạng một "cửa sổ ảo" lên dữ liệu thực tế, cho phép người dùng khác chạy lại truy vấn giống hệt mà không cần biết mã SQL gốc. View hỗ trợ JOIN giữa các bảng (customer và order data), calculated columns (như tổng hợp số lượng đơn hàng), và tự động cập nhật khi dữ liệu nguồn thay đổi. 🪟 Trong Azure SQL Database hoặc AWS RDS (2026), view là lựa chọn chuẩn cho việc chia sẻ truy vấn mà không sao chép dữ liệu, giúp tiết kiệm tài nguyên và đảm bảo tính nhất quán.
Nguồn tham khảo:

• Microsoft Learn: Views in Azure SQL Database (cập nhật 2024).
• AWS RDS Documentation: Working with Views in SQL Server on RDS (hỗ trợ đầy đủ đến 2026).

📋 Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên chức năng trong RDBMS hiện đại (Azure SQL/AWS RDS 2026). 🧐

• ❌ an index
  Sai vì: Index chỉ dùng để tối ưu hóa tốc độ truy vấn bằng cách tạo cấu trúc dữ liệu hỗ trợ tìm kiếm nhanh (như B-tree hoặc hash), không lưu trữ hay cho phép chạy lại toàn bộ truy vấn SQL phức tạp với JOIN và calculated columns. Nếu tạo index, người dùng khác vẫn phải viết lại query từ đầu. 🚫 Không phù hợp cho mục tiêu chia sẻ truy vấn.

• ✅ a view
  Đúng vì: Như đã giải thích ở trên, view đóng gói truy vấn SQL hoàn chỉnh thành một đối tượng có thể truy vấn như bảng ảo (SELECT * FROM view_name). Hỗ trợ calculated columns qua biểu thức SQL, và các user khác chỉ cần SELECT từ view để rerun query. Hoàn hảo cho dữ liệu kết hợp customer/order! ✨ Tính năng này không thay đổi trong các bản cập nhật 2023-2026.

• ❌ a scalar function
  Sai vì: Scalar function chỉ trả về một giá trị đơn (scalar value) từ đầu vào (như tính tổng đơn hàng cho một khách hàng), không thể lưu trữ truy vấn phức tạp với nhiều cột JOIN và calculated columns. Người dùng khác không thể dùng nó để rerun toàn bộ query như một tập kết quả. ⚠️ Phù hợp cho hàm tính toán nhỏ, không phải chia sẻ query đầy đủ.

• ❌ a table
  Sai vì: Table lưu trữ dữ liệu vật lý tĩnh (dữ liệu thực tế), không phải định nghĩa truy vấn SQL. Nếu tạo table từ query, dữ liệu sẽ là snapshot tại thời điểm tạo (không tự cập nhật), và không hỗ trợ rerun query động với calculated columns khi dữ liệu nguồn thay đổi. 💾 Gây lãng phí lưu trữ và mất tính thời gian thực.

Kết luận tổng quát 🎯: View là giải pháp tối ưu nhất cho việc tái sử dụng truy vấn SQL trong môi trường đám mây như Azure/AWS, giúp tuân thủ nguyên tắc DRY (Don't Repeat Yourself) và bảo mật dữ liệu. Nếu áp dụng thực tế, hãy test trên Azure SQL Edge hoặc RDS free tier!

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

Câu hỏi gốc (bằng tiếng Anh):
What are two characteristics of real-time data processing? Each correct answer presents a complete solution.
NOTE: Each correct selection is worth one point.

✅ Giải thích nội dung câu hỏi một cách chi tiết:
Câu hỏi này tập trung vào hai đặc trưng chính của xử lý dữ liệu thời gian thực (real-time data processing) trong môi trường đám mây, đặc biệt liên quan đến AWS. Xử lý dữ liệu thời gian thực là quy trình phân tích và xử lý dữ liệu ngay lập tức khi dữ liệu được tạo ra, thường áp dụng cho các ứng dụng như giám sát IoT, phát hiện gian lận tài chính, hoặc phân tích streaming dữ liệu (ví dụ: sử dụng Amazon Kinesis Data Streams hoặc AWS Lambda). Câu hỏi yêu cầu chọn hai đáp án đúng, mỗi đáp án độc lập và hoàn chỉnh, với mỗi lựa chọn đúng chiếm 1 điểm. Đây là dạng câu hỏi "multi-select" phổ biến trong các kỳ thi chứng chỉ AWS như AWS Certified Data Engineer hoặc AWS Certified Big Data.

🛠️ Đáp án đúng (hai lựa chọn):

• Low latency is expected
• Data is processed as it is created

📘 Lý do lựa chọn đáp án đúng (theo kiến thức AWS cập nhật đến 2026):
Theo tài liệu AWS mới nhất (AWS Well-Architected Framework - Data Analytics Lens, phiên bản 2023+ và các cập nhật Kinesis 2025), xử lý dữ liệu thời gian thực đòi hỏi độ trễ thấp (low latency) để đảm bảo dữ liệu được xử lý trong mili-giây hoặc giây, và xử lý ngay khi dữ liệu được tạo (as it is created) để hỗ trợ streaming liên tục. Điều này khác biệt với batch processing (xử lý theo lô định kỳ).

📋 Giải thích tất cả các phương án (đúng và sai)

• ❌ Data is processed periodically
  Phân tích sai: Phương án này mô tả xử lý dữ liệu theo chu kỳ định kỳ (batch processing), như sử dụng Amazon EMR hoặc AWS Glue cho các job chạy hàng giờ/ngày. Trong real-time processing trên AWS (Kinesis, Flink), dữ liệu không chờ đợi chu kỳ mà phải xử lý ngay lập tức. Sai vì trái ngược định nghĩa real-time.

• ✅ Low latency is expected
  Phân tích đúng: Đây là đặc trưng cốt lõi của real-time processing trên AWS. Ví dụ, Amazon Kinesis Data Streams hỗ trợ độ trễ dưới 70ms (cập nhật 2025 với Enhanced Fan-Out). Low latency đảm bảo ứng dụng phản hồi nhanh, như trong fraud detection hoặc live dashboards.

• ❌ High latency is acceptable
  Phân tích sai: High latency (độ trễ cao, như vài phút/giờ) phù hợp với near-real-time hoặc batch processing (ví dụ: AWS Athena query), nhưng không chấp nhận được trong real-time. AWS nhấn mạnh low latency là yêu cầu bắt buộc cho streaming services như MSK (Managed Streaming for Apache Kafka).

• ✅ Data is processed as it is created
  Phân tích đúng: Real-time processing trên AWS xử lý dữ liệu ngay khi nó được tạo ra (stream processing), không lưu trữ chờ đợi. Dịch vụ như Kinesis Data Firehose hoặc Apache Flink trên AWS xử lý event-by-event, hỗ trợ volume cao đến hàng triệu records/giây (cập nhật scalability 2026).

🔗 Tài liệu tham khảo (AWS cập nhật mới nhất):

• AWS Documentation: Real-time Data Processing with Kinesis (2025 edition).
• AWS Well-Architected: Data Analytics - Real-time Workloads (v3.0, 2024+).
• Amazon Kinesis Features - Low latency & real-time ingestion.

Hy vọng phân tích này giúp bạn nắm vững khái niệm! 🚀 Nếu cần thêm ví dụ AWS thực tế, hãy hỏi nhé!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc chủ đề phân tích dữ liệu (data analytics) trong môi trường đám mây, cụ thể liên quan đến các loại phân tích dữ liệu cơ bản. Nội dung mô tả: Công ty vừa báo cáo doanh số bán hàng của quý 3 (third quarter). Biểu đồ hiển thị doanh số theo quý (Sales by Quarter) với trục hoành (X) là các quý từ 1 đến 4, trục tung (Y) là giá trị doanh số từ khoảng 45k đến 75k (đơn vị nghìn).

📊 Phân tích hình ảnh biểu đồ (dựa trên mô tả chi tiết và dữ liệu hình ảnh cung cấp):

• Đường xanh dương (blue line): Đại diện cho dữ liệu thực tế (historical data) của các quý đã xảy ra:
  • Quý 1 (Q1): Khoảng 45k (điểm thấp nhất).
  • Quý 2 (Q2): Tăng nhẹ lên khoảng 48-50k.
  • Quý 3 (Q3): Tiếp tục tăng lên khoảng 55k (điểm cuối của đường thực tế).
• Phần quý 4 (Q4):
  • Không có dữ liệu thực tế (vì công ty chỉ báo cáo đến Q3).
  • Hiển thị đường đen (black line) kéo dài từ Q3, dự báo xu hướng tăng lên khoảng 60k.
  • Vùng shaded xám (gray shaded area): Đại diện cho khoảng tin cậy (confidence interval) hoặc độ không chắc chắn của dự báo, mở rộng hình nón từ Q3 sang Q4, cho thấy các kịch bản có thể từ 55k đến 65k+.

Biểu đồ này sử dụng xu hướng lịch sử (trend line) từ Q1-Q3 để dự báo (forecast) giá trị Q4, nhấn mạnh vào phân tích dự đoán tương lai. Câu hỏi tập trung vào loại phân tích được thể hiện ở quý 4.

🛠️ Mục tiêu câu hỏi: Kiểm tra sự hiểu biết về 4 loại phân tích dữ liệu chính (descriptive, diagnostic, predictive, prescriptive) – khái niệm cốt lõi trong AWS (áp dụng qua các dịch vụ như Amazon QuickSight, Amazon Forecast, SageMaker), cập nhật đến phiên bản mới nhất 2026 (không thay đổi cơ bản từ AWS Data Analytics framework).

✅ Đáp án đúng: predictive

Lý do lựa chọn (bằng tiếng Việt):
Phần quý 4 hiển thị dự báo tương lai (forecasting) dựa trên dữ liệu lịch sử Q1-Q3, với đường trend line và vùng uncertainty shaded. Đây chính là phân tích dự đoán (predictive analytics), sử dụng mô hình thống kê/ML để ước lượng "điều gì sẽ xảy ra" (what will happen) trong tương lai. Trong AWS, điều này tương ứng với Amazon Forecast hoặc QuickSight ML insights (cập nhật 2026 vẫn giữ nguyên định nghĩa). ✅

📋 Giải thích tất cả các phương án (đúng/sai)

• predictive ✅
  Đúng vì: Như phân tích trên, Q4 là dự báo dựa trên trend lịch sử, không phải dữ liệu đã xảy ra. Đây là predictive analytics – dự đoán tương lai bằng mô hình (ví dụ: regression, time-series forecasting). Trong AWS, hỗ trợ qua Amazon Forecast (autoML forecasting, cập nhật 2026 với tích hợp generative AI).

• prescriptive ❌
  Sai vì: Prescriptive analytics không chỉ dự đoán mà còn gợi ý hành động cụ thể (what to do/next best action), như "tăng quảng cáo để đạt mục tiêu". Biểu đồ chỉ dự báo số, không đưa recommendation. AWS ví dụ: Amazon Personalize hoặc SageMaker Clarify cho prescriptive.

• descriptive ❌
  Sai vì: Descriptive chỉ mô tả những gì đã xảy ra (what happened), như tổng hợp KPI từ dữ liệu quá khứ (Q1-Q3 ở đây). Q4 là tương lai, không phải mô tả thực tế. AWS: Amazon QuickSight dashboards cho descriptive.

• diagnostic ❌
  Sai vì: Diagnostic giải thích lý do tại sao (why it happened), như root cause analysis (ví dụ: doanh số Q3 tăng do marketing?). Biểu đồ không drill-down nguyên nhân, chỉ trend dự báo. AWS: Amazon Lookout for Metrics hoặc SageMaker Model Monitor cho diagnostic.

📘 Tài liệu tham khảo

• AWS Official: What is Analytics? & Amazon QuickSight User Guide (cập nhật 2026: Tích hợp AI/ML forecasting).
• AWS Well-Architected Framework – Data Analytics Lens (2024-2026 editions).
• Exam reference: AWS Certified Data Engineer/Analytics – Specialty (Exam Topics ID: 04277, verified 2026).
• Khái niệm chung: Gartner Analytics Maturity Model (descriptive → diagnostic → predictive → prescriptive).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần thêm ví dụ AWS thực tế, hãy hỏi nhé!