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

Câu 51 Relational data security

What types of threats does Advanced Threat Protection protect your SQL Database against?

A SQL Injection, Potential data infiltration, and brute force attacks
B Network security threats such as access from unknown IP addresses
C Long running queries that slow down data performance
D Queries that update too many rows at once

Xem giải thích

Đáp án

A — Tấn công SQL Injection, nguy cơ rò rỉ dữ liệu, và tấn công dò mật khẩu (brute force).

Vì sao đúng

⚠ Advanced Threat Protection phân tích hành vi bất thường và cảnh báo: | Loại cảnh báo | Nội dung | |---|---| | ⚠ SQL injection | ⚠ truy vấn có dấu hiệu chèn mã | | ⚠ SQL injection vulnerability | ⚠ ứng dụng có lỗ hổng dù chưa bị tấn công | | ⚠ Data exfiltration | ⚠ truy xuất khối lượng bất thường | | ⚠ Brute force | ⚠ nhiều lần đăng nhập thất bại | | ⚠ Đăng nhập từ vị trí lạ | | | ⚠ Đăng nhập bởi người dùng bất thường | |

⚠ ATP quan sát HÀNH VI
        ↓
⚠ So với mẫu bình thường
        ↓
⚠ Bất thường → cảnh báo email và Defender

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

B (mối đe doạ mạng như truy cập từ IP lạ) — ⚠ gần đúng nhưng thiếu: ⚠ ATP ⚠ có cảnh báo vị trí lạ, ⚠ nhưng đề hỏi các loại đe doạ chính, ⚠ và ATP không phải công cụ bảo vệ tầng mạng.
C (truy vấn chạy lâu làm chậm hệ thống) và D (truy vấn cập nhật quá nhiều dòng) — ⚠ là vấn đề HIỆU NĂNG, không phải bảo mật.

Ghi nhớ

⚠ Ba lớp bảo mật của Azure SQL — phân biệt: | Lớp | Việc | |---|---| | ⚠ Tường lửa và private endpoint | ⚠ ai được kết nối | | ⚠ Xác thực và phân quyền | ⚠ ai là ai, được làm gì | | ⚠ Advanced Threat Protection | ⚠ PHÁT HIỆN hành vi bất thường | | ⚠ Auditing | ⚠ ghi lại để điều tra sau | | ⚠ ATP là lớp | ⚠ PHÁT HIỆN, không phải NGĂN CHẶN |

Từ khoá nhận diện:

"phát hiện SQL injection, brute force" → ⚠ Advanced Threat Protection "ghi lại mọi truy vấn" → ⚠ SQL Auditing "tìm cột chứa dữ liệu nhạy cảm" → ⚠ Data Discovery & Classification "quét cấu hình sai" → ⚠ Vulnerability Assessment

⚠ Bộ Defender for SQL gồm gì	Gồm
⚠ Advanced Threat Protection	⚠ cảnh báo hành vi
⚠ Vulnerability Assessment	⚠ quét cấu hình sai, quyền thừa
⚠ Kết hợp	⚠ một cái phát hiện tấn công, một cái phòng ngừa

⚠ Cách phòng SQL injection thật sự	Cách
⚠ Dùng THAM SỐ HOÁ truy vấn	⚠ biện pháp quan trọng nhất
⚠ KHÔNG nối chuỗi SQL từ đầu vào người dùng
⚠ Kiểm tra và giới hạn đầu vào
⚠ Tài khoản ứng dụng có quyền tối thiểu
⚠ ATP	⚠ chỉ BÁO cho bạn biết, không sửa lỗ hổng

⚠ Xử lý cảnh báo	Cách
⚠ Cảnh báo gửi tới email và Defender for Cloud
⚠ Cần có người thật sự đọc và xử lý
⚠ Sai lầm	⚠ bật ATP rồi để cảnh báo rơi vào hòm thư không ai xem

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn trong mã có tham số hoá không | ⚠ gốc rễ của vấn đề | | Ai nhận và xử lý cảnh báo ATP | | | Tài khoản ứng dụng có quyền quá rộng không | |

Và điều cần nói rõ về mọi công cụ phát hiện đe doạ: nó cho bạn biết mình đang bị tấn công, không làm cho bạn hết bị tấn công. Truy vấn tham số hoá mới là thứ thật sự đóng cánh cửa lại.

Câu 52 Non-relational DB Management

You have a small 25MB database currently hosted in AWS DynamoDB that you'd like to move to Azure Cosmos DB. You've chosen Core SQL API as the database type. Which is the best database migration tool or technique to get data from AWS DynamoDB to Azure CosmosDB?

A When creating the SQL Database in the Azure Portal, choose "DynamoDB" as the source of the new database
B Export the DB using bcp and import into Azure using the same tool
C Export the DB using a database backup (BACPAC) and create a new SQL DB using that file
D Data Migration Tool

Xem giải thích

Đáp án

D — Data Migration Tool (công cụ di chuyển dữ liệu của Azure Cosmos DB).

Vì sao đúng

⚠ Data Migration Tool sinh ra để nạp dữ liệu vào Cosmos DB từ nhiều nguồn: | Nguồn hỗ trợ | Nội dung | |---|---| | ⚠ JSON, CSV | | | ⚠ SQL Server | | | ⚠ MongoDB | | | ⚠ Azure Table Storage | | | ⚠ Amazon DynamoDB | ⚠ đề này | | ⚠ Chính Cosmos DB | |

⚠ DynamoDB (25MB — rất nhỏ)
        ↓ ⚠ Data Migration Tool
⚠ Cosmos DB Core (SQL) API
        ↓
⚠ Công cụ miễn phí, có giao diện và dòng lệnh

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

A (chọn "DynamoDB" làm nguồn khi tạo CSDL trong Portal) — ⚠ không có tính năng này.
B (dùng bcp) — ⚠ bcp là công cụ của SQL SERVER, ⚠ không làm việc với DynamoDB hay Cosmos DB.
C (BACPAC) — ⚠ định dạng của Azure SQL Database, ⚠ không dùng cho CSDL phi quan hệ.

Ghi nhớ

⚠ Công cụ di chuyển theo ĐÍCH — bảng phải thuộc: | Đích | Công cụ | |---|---| | ⚠ Cosmos DB | ⚠ Data Migration Tool, Data Factory | | ⚠ Azure SQL | ⚠ DMS, BACPAC, bcp | | ⚠ Máy ảo | ⚠ Azure Migrate | | ⚠ Blob / Data Lake | ⚠ AzCopy, Storage Mover, Data Box |

Từ khoá nhận diện:

"nạp dữ liệu vào Cosmos DB" → ⚠ Data Migration Tool "BACPAC, bcp" → ⚠ SQL Server và Azure SQL "khối lượng rất lớn, đường truyền chậm" → ⚠ Data Box "luồng chạy định kỳ" → ⚠ Data Factory

⚠ Kích thước quyết định cách làm	Kích thước
⚠ 25MB — rất nhỏ	⚠ công cụ đơn giản là đủ
⚠ Hàng trăm GB	⚠ Data Factory với song song hoá
⚠ Hàng chục TB	⚠ Data Box hoặc ExpressRoute
⚠ Đề nêu con số	⚠ thường là gợi ý để loại phương án nặng nề

⚠ Điều cần chuẩn bị khi nạp vào Cosmos DB	Điều
⚠ Chọn PARTITION KEY trước	⚠ không sửa được sau
⚠ Tăng RU tạm thời trong lúc nạp	⚠ rồi hạ xuống sau
⚠ Xem xét tắt bớt chỉ mục trong lúc nạp
⚠ Xử lý lỗi 429 khi bị điều tiết
⚠ Quên tăng RU	⚠ quá trình nạp rất chậm vì liên tục bị điều tiết

⚠ Khác biệt mô hình DynamoDB và Cosmos	Khác biệt
⚠ DynamoDB: partition key + sort key
⚠ Cosmos NoSQL: partition key + id
⚠ Cần ánh xạ lại thiết kế khoá
⚠ Đừng	⚠ bê nguyên thiết kế khoá cũ mà không xem lại mẫu truy vấn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Partition key đã chọn theo mẫu truy vấn chưa | | | Đã tăng RU tạm thời cho lúc nạp chưa | | | Kích thước dữ liệu có đúng như ước tính không | |

Và bước chuẩn bị dễ bị bỏ qua nhất khi nạp dữ liệu vào Cosmos DB, khiến việc nạp kéo dài hàng giờ không cần thiết: tăng RU tạm thời trong lúc nạp rồi hạ xuống sau.

Câu 53 Power BI

What is the purpose of a data dashboard, particularly in Microsoft Power BI?

A A dashboard is entirely visual elements such as charts and graphs, with no numbers
B A dashboard breaks up reports into pages
C A dashboard shows the detailed data of what happened historically, such as the full log file
D A dashboard tells a story of what is going on, and contains the most important elements of that story in one page

Xem giải thích

Đáp án

D — Dashboard kể câu chuyện về những gì đang diễn ra, và đặt các yếu tố quan trọng nhất của câu chuyện đó trên MỘT trang.

Vì sao đúng

⚠ Dashboard là màn hình tổng quan, không phải nơi xem chi tiết: | Đặc điểm | Nội dung | |---|---| | ⚠ MỘT trang duy nhất | ⚠ không phân trang | | ⚠ Ghim ô từ NHIỀU báo cáo | ⚠ thậm chí nhiều tập dữ liệu | | ⚠ Chỉ có trên Power BI Service | ⚠ không có trong Desktop | | ⚠ Đặt cảnh báo trên ô | ⚠ khi vượt ngưỡng | | ⚠ Bấm vào ô để nhảy sang báo cáo nguồn | |

⚠ Dashboard trả lời
   ⚠ "Mọi thứ CÓ ỔN không?"
⚠ Báo cáo trả lời
   ⚠ "VÌ SAO lại như vậy?"

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

C (hiển thị dữ liệu chi tiết lịch sử, như toàn bộ log) — ⚠ đó là báo cáo phân trang.
B (chia báo cáo thành các trang) — ⚠ NGƯỢC: ⚠ dashboard ⚠ gộp lại một trang.
A (hoàn toàn là hình ảnh, không có số) — ⚠ SAI: ⚠ dashboard ⚠ có ô số liệu, KPI, thẻ.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ hoàn chỉnh bộ ba loại nội dung Power BI cùng #19491 và #19522.

Câu	Loại	Khoá
⚠ #19491	⚠ cần lọc, sắp xếp, drill-through	⚠ Interactive report
⚠ #19522	⚠ hàng nghìn dòng để in	⚠ Paginated report
⚠ #19543 (câu này)	⚠ dashboard để làm gì	⚠ tổng quan một trang
⚠ Ba câu	⚠ vẽ đủ bức tranh Power BI

⚠ Ba loại nội dung — bảng chốt: | Loại | Số trang | Có trong Desktop | |---|---|---| | ⚠ Dashboard | ⚠ 1 | ⚠ KHÔNG — chỉ Service | | ⚠ Interactive report | ⚠ nhiều | ⚠ CÓ | | ⚠ Paginated report | ⚠ nhiều, để in | ⚠ Report Builder |

Từ khoá nhận diện:

"một trang, tổng quan, ghim từ nhiều nguồn" → ⚠ Dashboard "khám phá, lọc, drill-through" → ⚠ Report "in ra, mỗi dòng một bản ghi" → ⚠ Paginated "cảnh báo khi vượt ngưỡng" → ⚠ Dashboard tile alert

⚠ Điều CHỈ dashboard làm được	Điều
⚠ Ghim ô từ NHIỀU báo cáo khác nhau
⚠ Ghim từ nhiều tập dữ liệu khác nhau
⚠ Đặt cảnh báo dữ liệu trên ô
⚠ Hỏi bằng ngôn ngữ tự nhiên (Q&A)
⚠ Đổi lại	⚠ không có bộ lọc và slicer như báo cáo

⚠ Thiết kế dashboard tốt	Nguyên tắc
⚠ Chỉ số quan trọng nhất ở GÓC TRÊN BÊN TRÁI
⚠ Không quá nhiều ô	⚠ quá tải thì không ai nhìn
⚠ Mỗi ô trả lời một câu hỏi
⚠ Bấm được để đi sâu
⚠ Sai lầm	⚠ nhồi mọi thứ vào rồi không ai biết nhìn đâu trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người xem cần tổng quan hay chi tiết | | | Dashboard có quá nhiều ô không | | | Có đặt cảnh báo cho chỉ số quan trọng chưa | |

Và tiêu chí đánh giá một dashboard đã tốt hay chưa, đơn giản mà khắt khe: nhìn năm giây có biết mọi thứ ổn hay không? Nếu phải đọc kỹ từng ô mới hiểu, đó là một báo cáo bị đặt nhầm chỗ.

Câu 54 Data processing

In an Azure Data Factory, a ___________ is a logical grouping of activities that together perform a task. Fill in the blank.

A Pipeline
B Node
C Cluster
D Package

Xem giải thích

Đáp án

A — Pipeline.

Vì sao đúng

⚠ Pipeline là đơn vị tổ chức công việc trong Data Factory:

⚠ Pipeline "Nạp dữ liệu bán hàng hằng ngày"
   ⚠ Activity 1: Lookup danh sách tệp
   ⚠ Activity 2: ForEach từng tệp
      ⚠ Activity 2a: Copy vào staging
      ⚠ Activity 2b: Data Flow làm sạch
   ⚠ Activity 3: Stored Procedure cập nhật
        ↓
⚠ Chạy như MỘT đơn vị, có lịch, có giám sát

Pipeline cho phép	Nội dung
⚠ Chạy chung một lịch
⚠ Giám sát như một đơn vị
⚠ Tham số hoá để tái dùng
⚠ Gọi pipeline khác	⚠ Execute Pipeline

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

C (Cluster) — ⚠ là nhóm MÁY TÍNH: ⚠ khái niệm của Spark, Kubernetes.
B (Node) — ⚠ là một MÁY trong cụm.
D (Package) — ⚠ là khái niệm của SSIS (gói dtsx), ⚠ tiền thân của ADF nhưng không phải thuật ngữ ADF.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về Data Factory trong lô.

Câu	Hỏi gì	Khoá
⚠ #19514	⚠ hoạt động nào là control flow	⚠ If Condition
⚠ #19517	⚠ dịch vụ nào chuyển và biến đổi dữ liệu	⚠ Data Factory
⚠ #19544 (câu này)	⚠ nhóm logic các hoạt động gọi là gì	⚠ Pipeline
⚠ Ba câu	⚠ cùng một dịch vụ, ba tầng khái niệm

⚠ Từ vựng Data Factory — bảng chốt: | Thuật ngữ | Nghĩa | |---|---| | ⚠ Activity | ⚠ một BƯỚC công việc | | ⚠ Pipeline | ⚠ NHÓM các activity | | ⚠ Dataset | ⚠ mô tả dữ liệu ở nguồn hoặc đích | | ⚠ Linked service | ⚠ kết nối tới hệ thống | | ⚠ Integration runtime | ⚠ hạ tầng thực thi | | ⚠ Trigger | ⚠ thứ khởi động pipeline |

Từ khoá nhận diện:

"nhóm hoạt động thực hiện một tác vụ" → ⚠ pipeline "một bước cụ thể" → ⚠ activity "chuỗi kết nối" → ⚠ linked service "khởi động theo lịch" → ⚠ trigger

⚠ Ba loại trigger	Loại
⚠ Schedule	⚠ theo lịch cố định
⚠ Tumbling window	⚠ theo cửa sổ liên tiếp, có phụ thuộc và chạy bù
⚠ Event-based	⚠ khi có tệp mới trong blob
⚠ Tumbling window mạnh ở	⚠ khả năng CHẠY BÙ cho khoảng thời gian đã bỏ lỡ

⚠ Tham số hoá pipeline	Lợi ích
⚠ Một pipeline dùng cho nhiều nguồn
⚠ Truyền tên bảng, đường dẫn, ngày qua tham số
⚠ Giảm số pipeline phải bảo trì
⚠ Không tham số hoá	⚠ dễ có hàng chục pipeline gần giống hệt nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các pipeline có bị trùng lặp logic không | ⚠ nên tham số hoá | | Trigger có chạy bù được khi lỗi không | | | Có cảnh báo khi pipeline thất bại chưa | |

Và cách giữ một hệ thống Data Factory không phình ra mất kiểm soát sau vài tháng: tham số hoá thay vì nhân bản pipeline. Hai mươi pipeline gần giống nhau nghĩa là hai mươi chỗ phải sửa khi logic thay đổi.

Câu 55 Relational data security

What type of malicious attack attempts to read database values using form fields on a web site?

A Brute Force Attack
B Distributed Denial of Service (DDoS) Attack
C SQL Injection Attack
D XSS (Cross Site Scripting)

Xem giải thích

Đáp án

C — Tấn công SQL Injection.

Vì sao đúng

⚠ SQL injection lợi dụng chính ô nhập liệu để chèn câu lệnh SQL:

⚠ Mã ứng dụng NỐI CHUỖI
   ⚠ "SELECT * FROM users WHERE name='" + input + "'"

⚠ Người dùng nhập
   ⚠ ' OR '1'='1
        ↓
⚠ Câu lệnh thành
   ⚠ WHERE name='' OR '1'='1'
        ↓
⚠ Trả về TOÀN BỘ bảng

Kẻ tấn công làm được gì	Nội dung
⚠ Đọc dữ liệu không được phép
⚠ Vượt qua đăng nhập
⚠ Sửa hoặc xoá dữ liệu
⚠ Trong trường hợp xấu, chạy lệnh hệ điều hành

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

D (XSS) — ⚠ gần nhất về hình thức: ⚠ cũng qua ô nhập, ⚠ nhưng chèn ⚠ JavaScript tấn công NGƯỜI DÙNG khác, ⚠ không đọc cơ sở dữ liệu.
A (brute force) — ⚠ thử mật khẩu liên tục.
B (DDoS) — ⚠ làm ngập hệ thống để gây gián đoạn, không đọc dữ liệu.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19541 trong cùng lô — ⚠ #19541 hỏi ATP phát hiện gì, ⚠ câu này hỏi bản chất tấn công.

⚠ Bốn kiểu tấn công web hay bị hỏi lẫn: | Tấn công | Mục tiêu | Cách | |---|---|---| | ⚠ SQL Injection | ⚠ CƠ SỞ DỮ LIỆU | ⚠ chèn SQL qua ô nhập | | ⚠ XSS | ⚠ NGƯỜI DÙNG khác | ⚠ chèn JavaScript | | ⚠ Brute force | ⚠ tài khoản | ⚠ thử mật khẩu liên tục | | ⚠ DDoS | ⚠ tính sẵn sàng | ⚠ làm ngập lưu lượng |

Từ khoá nhận diện:

"đọc dữ liệu qua ô nhập trên web" → ⚠ SQL injection "chèn script chạy trên trình duyệt người khác" → ⚠ XSS "thử hàng nghìn mật khẩu" → ⚠ brute force "làm ngập bằng lưu lượng" → ⚠ DDoS

⚠ Phòng SQL injection — theo thứ tự hiệu quả	Biện pháp
⚠ Truy vấn THAM SỐ HOÁ	⚠ biện pháp gốc, hiệu quả nhất
⚠ Stored procedure có tham số
⚠ ORM dùng đúng cách
⚠ Kiểm tra và giới hạn đầu vào	⚠ lớp bổ sung
⚠ Tài khoản ứng dụng quyền tối thiểu	⚠ giới hạn thiệt hại
⚠ WAF	⚠ lớp ngoài, không thay thế mã đúng

⚠ Vì sao lọc ký tự KHÔNG đủ	Lý do
⚠ Có rất nhiều cách mã hoá và né bộ lọc
⚠ Bộ lọc dễ chặn nhầm dữ liệu hợp lệ	⚠ tên O'Brien
⚠ Tham số hoá làm dữ liệu KHÔNG BAO GIỜ được hiểu là mã
⚠ Đó là	⚠ khác biệt căn bản, không phải mức độ

⚠ Phòng thủ nhiều lớp	Lớp
⚠ Mã: tham số hoá
⚠ Quyền: tài khoản hạn chế
⚠ Mạng: WAF
⚠ Phát hiện: ATP và audit log
⚠ Không lớp nào	⚠ thay thế được lớp đầu tiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Còn chỗ nào nối chuỗi SQL không | | | Tài khoản ứng dụng có quyền db_owner không | ⚠ thường là quá rộng | | WAF đã bật chưa | ⚠ lớp bổ sung |

Và khác biệt căn bản giữa lọc đầu vào và tham số hoá truy vấn, giải thích vì sao chỉ cái sau mới thật sự an toàn: tham số hoá khiến dữ liệu không bao giờ có cơ hội được hiểu là câu lệnh, thay vì cố đoán xem chuỗi nào là nguy hiểm.

Câu 56 Non-relational DB

What type of data does Azure Table Storage store?

A Graph data
B Relational data
C Unstructured data
D Key-value data

Xem giải thích

Đáp án

D — Dữ liệu KHOÁ-GIÁ TRỊ.

Vì sao đúng

⚠ Table Storage định danh mỗi thực thể bằng cặp khoá:

⚠ PartitionKey + RowKey → thực thể
        ↓
⚠ Thuộc tính linh hoạt theo từng thực thể
⚠ Chỉ mục CHỈ trên khoá chính
⚠ Không JOIN, không giao dịch chéo phân vùng

Đặc điểm	Nội dung
⚠ Phi quan hệ
⚠ Schema linh hoạt
⚠ Rất rẻ
⚠ Co giãn lớn
⚠ Tên "Table"	⚠ dễ gây nhầm là quan hệ — KHÔNG phải

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

B (dữ liệu quan hệ) — ⚠ bẫy do TÊN GỌI: ⚠ "Table" nghe như bảng SQL, ⚠ nhưng không có schema, khoá ngoại hay JOIN.
C (phi cấu trúc) — ⚠ đó là Blob.
A (đồ thị) — ⚠ đó là Gremlin API.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ tư về Table Storage qua hai lô.

Câu	Hỏi gì	Khoá
⚠ #19508	⚠ Table Storage thuộc loại lưu trữ nào	⚠ khoá-giá trị
⚠ #19521	⚠ kho khoá-giá trị rẻ nhất	⚠ Table Storage
⚠ #19539	⚠ API Cosmos nào cho khoá-giá trị	⚠ Table API
⚠ #19546 (câu này)	⚠ Table Storage lưu loại dữ liệu gì	⚠ khoá-giá trị
⚠ Bốn câu	⚠ cùng một khoá kiến thức, không mâu thuẫn
⚠ Nhận xét	⚠ bộ đề Data Fundamentals lặp rất dày ở nhóm này

⚠ Bảng phân loại dịch vụ lưu trữ Azure — chốt lại: | Dịch vụ | Loại dữ liệu | |---|---| | ⚠ Blob Storage | ⚠ phi cấu trúc, đối tượng | | ⚠ Table Storage | ⚠ khoá-giá trị | | ⚠ Queue Storage | ⚠ tin nhắn | | ⚠ File Storage | ⚠ chia sẻ tệp SMB/NFS | | ⚠ Azure SQL | ⚠ quan hệ | | ⚠ Cosmos DB | ⚠ tài liệu, đồ thị, cột rộng, khoá-giá trị |

Từ khoá nhận diện:

"PartitionKey, RowKey" → ⚠ Table Storage "JOIN, khoá ngoại, schema" → ⚠ quan hệ "ảnh, video" → ⚠ Blob "hàng đợi tin nhắn" → ⚠ Queue Storage

⚠ Bốn dịch vụ trong một Storage Account	Dịch vụ
⚠ Blob	⚠ đối tượng
⚠ File	⚠ chia sẻ tệp
⚠ Queue	⚠ hàng đợi đơn giản
⚠ Table	⚠ khoá-giá trị
⚠ Chung	⚠ cùng tài khoản, cùng cấu hình nhân bản và bảo mật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn có luôn dùng khoá không | | | Có cần JOIN hay ràng buộc không | ⚠ thì phải dùng CSDL quan hệ | | Table Storage hay Cosmos Table API | ⚠ cân nhắc chi phí và SLA |

Và cái bẫy đặt tên đáng nhớ nhất trong hệ sinh thái lưu trữ của Azure: Azure Table Storage không phải là bảng quan hệ. Nó chỉ mượn từ "table", còn mọi thứ khác đều thuộc thế giới NoSQL.

Câu 57 Non-relational DB

What type of data is stored in Azure Blob Storage?

A Key-value data
B Unstructured data
C Structured data
D Partitioned data

Xem giải thích

Đáp án

B — Dữ liệu PHI CẤU TRÚC.

Vì sao đúng

⚠ Blob Storage nhận mọi thứ dưới dạng chuỗi byte, không quan tâm nội dung: | Nội dung điển hình | Loại | |---|---| | ⚠ Ảnh, video, âm thanh | ⚠ phi cấu trúc | | ⚠ Tài liệu, PDF | ⚠ phi cấu trúc | | ⚠ Tệp sao lưu, ảnh đĩa | ⚠ phi cấu trúc | | ⚠ Log dạng văn bản | ⚠ phi cấu trúc |

⚠ Azure KHÔNG hiểu bên trong blob là gì
        ↓
⚠ Không truy vấn theo trường được
⚠ Chỉ lấy nguyên đối tượng theo tên

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

C (có cấu trúc) — ⚠ là dữ liệu bảng có schema: ⚠ Azure SQL.
A (khoá-giá trị) — ⚠ là Table Storage.
D (dữ liệu phân vùng) — ⚠ không phải một LOẠI dữ liệu; ⚠ phân vùng là kỹ thuật tổ chức.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ đây là câu ⚠ thứ ba về Blob và loại dữ liệu qua hai lô.

Câu	Hỏi gì	Khoá
⚠ #19507	⚠ cái nào là dữ liệu phi cấu trúc	⚠ nội dung blob
⚠ #19526	⚠ tệp nhị phân lớn thuộc mô hình nào	⚠ object data
⚠ #19547 (câu này)	⚠ Blob lưu loại dữ liệu gì	⚠ phi cấu trúc
⚠ Ba câu	⚠ cùng một kiến thức, ba cách hỏi
⚠ Lưu ý	⚠ "object data" và "phi cấu trúc" là hai cách gọi cùng một thứ ở đây

⚠ Ba loại dữ liệu — bảng chốt cuối: | Loại | Đặc điểm | Dịch vụ | |---|---|---| | ⚠ Có cấu trúc | ⚠ schema cố định | ⚠ Azure SQL | | ⚠ Bán cấu trúc | ⚠ có khoá, schema linh hoạt | ⚠ Cosmos, Table | | ⚠ Phi cấu trúc | ⚠ không schema | ⚠ Blob, Data Lake |

Từ khoá nhận diện:

"ảnh, video, tệp bất kỳ" → ⚠ Blob, phi cấu trúc "JSON có khoá" → ⚠ bán cấu trúc "bảng có cột cố định" → ⚠ có cấu trúc "phân tích dữ liệu lớn" → ⚠ Data Lake Gen2

⚠ Blob và Data Lake Gen2	Quan hệ
⚠ Data Lake Gen2 LÀ Blob Storage	⚠ có bật namespace phân cấp
⚠ Cùng giá lưu trữ
⚠ Gen2 thêm thư mục thật và ACL
⚠ Bật khi tạo	⚠ không bật được sau

⚠ Metadata và index tags	Nội dung
⚠ Blob không truy vấn được NỘI DUNG
⚠ Nhưng gắn được thẻ và tìm theo thẻ
⚠ Index tags: tối đa 10 thẻ mỗi blob
⚠ Dùng để	⚠ phân loại, lifecycle theo thẻ, tìm nhanh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cần truy vấn nội dung không | ⚠ thì không dùng blob thuần | | Có bật namespace phân cấp không | | | Đã dùng thẻ để phân loại chưa | |

Và cách nhớ dứt điểm ba loại dữ liệu, thay vì học thuộc danh sách ví dụ: hỏi máy tính có hiểu được cấu trúc bên trong không — hiểu hoàn toàn là có cấu trúc, hiểu một phần là bán cấu trúc, không hiểu gì là phi cấu trúc.

Câu 58 Relational data management

Which of the following items best defines "data at rest" when it comes to securing data?

A Data as it exists in a computer's memory
B Data as it's travelling over a network
C Data that has yet to be physically written to the hard disk
D Data that exists statically on the physical media

Xem giải thích

Đáp án

D — Dữ liệu tồn tại TĨNH trên phương tiện lưu trữ vật lý.

Vì sao đúng

⚠ Ba trạng thái của dữ liệu, mỗi trạng thái cần một cơ chế bảo vệ: | Trạng thái | Ở đâu | Bảo vệ bằng | |---|---|---| | ⚠ At rest | ⚠ đĩa cứng, SSD, băng từ | ⚠ TDE, mã hoá lưu trữ | | ⚠ In transit | ⚠ trên đường truyền | ⚠ TLS, HTTPS, VPN | | ⚠ In use | ⚠ trong bộ nhớ khi xử lý | ⚠ Always Encrypted, confidential computing |

⚠ Dữ liệu ĐANG NẰM YÊN trên đĩa
        ↓
⚠ Nguy cơ: ai lấy được đĩa hoặc file
        ↓
⚠ Chống bằng mã hoá khi lưu

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

B (đang di chuyển trên mạng) — ⚠ đó là data IN TRANSIT.
A (trong bộ nhớ máy tính) — ⚠ đó là data IN USE.
C (chưa được ghi xuống đĩa) — ⚠ vẫn là in use hoặc đang trong bộ đệm, ⚠ chưa phải at rest.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp với #19538 trong cùng lô — ⚠ câu kia hỏi TDE bảo vệ trạng thái nào, khoá cũng là data at rest.

Câu	Hỏi gì	Khoá
⚠ #19538	⚠ TDE bảo vệ gì	⚠ data at rest
⚠ #19548 (câu này)	⚠ data at rest là gì	⚠ dữ liệu tĩnh trên phương tiện vật lý
⚠ Bổ sung nhau	⚠ một hỏi cơ chế, một hỏi khái niệm

⚠ Mã hoá at rest trên Azure — mặc định: | Dịch vụ | Mã hoá at rest | |---|---| | ⚠ Storage Account | ⚠ BẬT sẵn, KHÔNG tắt được | | ⚠ Azure SQL | ⚠ TDE bật mặc định | | ⚠ Cosmos DB | ⚠ bật sẵn | | ⚠ Managed Disks | ⚠ bật sẵn | | ⚠ Nghĩa là | ⚠ bạn được bảo vệ ở mức cơ bản mà không cần làm gì |

Từ khoá nhận diện:

"tĩnh trên đĩa, file, bản sao lưu" → ⚠ at rest "trên đường truyền, giữa client và server" → ⚠ in transit "đang xử lý trong bộ nhớ" → ⚠ in use "ai lấy được ổ cứng" → ⚠ mối đe doạ của at rest

⚠ Khoá do ai quản lý	Lựa chọn
⚠ Microsoft-managed key	⚠ mặc định, không phải làm gì
⚠ Customer-managed key (CMK)	⚠ khoá trong Key Vault của bạn
⚠ Customer-provided key	⚠ gửi khoá theo từng yêu cầu
⚠ CMK cho phép	⚠ thu hồi khoá để vô hiệu hoá dữ liệu ngay
⚠ CMK đòi hỏi	⚠ quy trình quản lý khoá nghiêm túc

⚠ Confidential computing — bảo vệ in use	Nội dung
⚠ Dữ liệu mã hoá NGAY CẢ trong bộ nhớ
⚠ Xử lý trong vùng bảo vệ phần cứng (enclave)
⚠ Nhà cung cấp đám mây cũng không đọc được
⚠ Dùng cho	⚠ dữ liệu cực nhạy cảm, tính toán đa bên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ba trạng thái đã được bảo vệ đủ chưa | | | Khoá do Microsoft hay do bạn quản lý | | | Bản sao lưu có được mã hoá không | ⚠ hay bị quên |

Và mắt xích hay bị bỏ sót nhất khi bàn về mã hoá dữ liệu khi lưu: các bản sao lưu và bản xuất dữ liệu. Cơ sở dữ liệu được mã hoá kỹ càng mà file xuất ra để đâu đó thì công sức đó không còn nhiều ý nghĩa.

Câu 59 Non-relational deployment

What is the impact of allocating too many Request Units per second (RU/s) to a Cosmos DB database or container?

A You will have to pay for the amount allocated regardless of how many are used
B Queries will scale in performance to the number of RU/s you have allocated
C Cosmos DB will scale the RU/s to what you use, regardless of what you provision
D The provisioned RU/s doesn't impact anything

Xem giải thích

Đáp án

A — Bạn vẫn phải TRẢ TIỀN cho lượng đã cấp phát, bất kể dùng bao nhiêu.

Vì sao đúng

⚠ Ở chế độ provisioned, RU/s là tài nguyên ĐẶT TRƯỚC:

⚠ Cấp 10.000 RU/s
        ↓
⚠ Thực tế chỉ dùng 500 RU/s
        ↓
⚠ Vẫn trả tiền cho 10.000
        ↓
⚠ Tính theo GIỜ, suốt ngày đêm

Điều này nghĩa là	Nội dung
⚠ Cấp dư = lãng phí trực tiếp
⚠ Cấp thiếu = bị điều tiết, lỗi 429
⚠ Phải theo dõi và điều chỉnh

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

C (Cosmos DB tự co giãn về mức bạn dùng) — ⚠ chỉ đúng với AUTOSCALE hoặc SERVERLESS, ⚠ không đúng với provisioned thủ công.
B (truy vấn tự nhanh lên theo số RU cấp) — ⚠ hiểu sai: ⚠ RU là ⚠ hạn mức thông lượng, ⚠ không làm một truy vấn đơn lẻ chạy nhanh hơn.
D (không ảnh hưởng gì) — ⚠ SAI rõ ràng: ⚠ ảnh hưởng trực tiếp tới hoá đơn.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ bổ sung cho #19520 trong cùng lô — ⚠ #19520 hỏi mức tối thiểu, ⚠ câu này hỏi hệ quả của cấp dư.

⚠ Ba chế độ thông lượng — chọn theo hình dạng tải: | Chế độ | Phù hợp | |---|---| | ⚠ Provisioned thủ công | ⚠ tải ĐỀU, dự đoán được | | ⚠ Autoscale | ⚠ tải THẤT THƯỜNG, co giãn 10%–100% mức đỉnh | | ⚠ Serverless | ⚠ tải THƯA, dev/test |

Từ khoá nhận diện:

"trả cho phần đã cấp" → ⚠ provisioned "tự co giãn trong khoảng" → ⚠ autoscale "trả theo lượt dùng" → ⚠ serverless "lỗi 429" → ⚠ cấp thiếu hoặc truy vấn tốn RU

⚠ Autoscale — cơ chế và cái giá	Nội dung
⚠ Bạn đặt mức TỐI ĐA, hệ thống co xuống 10% mức đó
⚠ Đơn giá mỗi RU CAO HƠN provisioned	⚠ khoảng 1,5 lần
⚠ Lợi khi tải thay đổi mạnh
⚠ Không lợi khi	⚠ tải đều — provisioned rẻ hơn

⚠ Cách tối ưu chi phí Cosmos DB	Cách
⚠ Xem chỉ số Normalized RU Consumption	⚠ biết đang dùng bao nhiêu phần trăm
⚠ Hạ mức cấp phát nếu luôn dưới 30%
⚠ Bật autoscale nếu tải thất thường
⚠ Dùng serverless cho môi trường dev
⚠ Xem lại partition key và chỉ mục	⚠ giảm RU tiêu thụ tận gốc

⚠ Cấp phát ở mức database hay container	Cân nhắc
⚠ Mức database: nhiều container DÙNG CHUNG	⚠ rẻ khi có nhiều container nhỏ
⚠ Mức container: riêng biệt, đảm bảo hơn
⚠ Rủi ro dùng chung	⚠ một container ngốn hết RU của cả nhóm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỉ lệ RU thật sự dùng là bao nhiêu phần trăm | | | Môi trường dev có đang cấp phát dư không | | | Tải đều hay thất thường | ⚠ quyết định provisioned hay autoscale |

Và chỉ số cần nhìn đầu tiên khi muốn giảm hoá đơn Cosmos DB: tỉ lệ tiêu thụ RU chuẩn hoá. Nếu nó thường xuyên dưới ba mươi phần trăm, bạn đang trả tiền cho một năng lực chưa từng cần tới.

Câu 60 Relational data security

You have a SQL Database Server named SQLDB, and two SQL Databases named DB1 and DB2. SQLDB has a server-level firewall that allows IP addresses in the range 123.123.123.0-123.123.123.255 and denies all other traffic. DB1 has a database level firewall rule that allows IPs in the range 123.123.123.0-123.123.123.10. When a client using the IP address 123.123.123.25 attempts to access DB1, are they successful?

A No, the connection will not succeed
B Yes, the connection will succeed

Xem giải thích

Đáp án

B — Có, kết nối sẽ thành công.

Vì sao đúng

⚠ Lần theo đúng thứ tự xét luật:

⚠ Client: 123.123.123.25 → DB1
        ↓
⚠ 1. Luật DATABASE của DB1
   ⚠ cho phép 123.123.123.0 - .10
   ⚠ → .25 KHÔNG nằm trong
        ↓ ⚠ không khớp, xét tiếp
⚠ 2. Luật SERVER
   ⚠ cho phép 123.123.123.0 - .255
   ⚠ → .25 NẰM TRONG
        ↓
⚠ CHO PHÉP

Nguyên tắc	Nội dung
⚠ Luật database không khớp KHÔNG có nghĩa là từ chối
⚠ Nó chỉ có nghĩa là "xét tiếp luật server"
⚠ Khớp BẤT KỲ luật nào là cho vào
⚠ Chỉ từ chối khi KHÔNG khớp luật nào

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

A (Không) — ⚠ hiểu nhầm phổ biến: ⚠ nghĩ rằng luật database ⚠ thu hẹp luật server; ⚠ thực tế hai tập luật ⚠ CỘNG với nhau chứ không giao nhau.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ là cặp bổ sung hoàn hảo với #19499 ở lô trước — ⚠ hai câu cùng kịch bản, cùng khoá, ⚠ nhưng minh hoạ hai chiều khác nhau của cùng một quy tắc.

Câu	Luật database	Client	Kết quả	Vì sao
⚠ #19499	⚠ RỘNG hơn server (tới .124.255)	⚠ .124.25	⚠ Yes	⚠ khớp luật DATABASE ngay
⚠ #19550 (câu này)	⚠ HẸP hơn server (chỉ tới .10)	⚠ .123.25	⚠ Yes	⚠ rơi xuống luật SERVER
⚠ Cùng khoá Yes	⚠ nhưng ĐƯỜNG ĐI khác nhau
⚠ Bài học	⚠ luật database MỞ RỘNG được, KHÔNG thu hẹp được luật server
⚠ KHÔNG mâu thuẫn	⚠ cùng một quy tắc, hai tình huống

⚠ Quy tắc tường lửa Azure SQL — chốt lại: | Quy tắc | Nội dung | |---|---| | ⚠ Xét luật DATABASE trước | | | ⚠ Khớp → cho vào, dừng | | | ⚠ Không khớp → xét luật SERVER | | | ⚠ Không khớp cả hai → TỪ CHỐI | | | ⚠ Hệ quả | ⚠ không thể dùng luật database để CHẶN IP mà luật server cho phép |

Từ khoá nhận diện:

"luật database rộng hơn" → ⚠ vào được, khớp ở bước một "luật database hẹp hơn" → ⚠ vẫn vào được nhờ luật server "muốn CHẶN thật sự" → ⚠ phải thu hẹp luật SERVER "cách ly hoàn toàn" → ⚠ private endpoint hoặc tách server

⚠ Hệ quả thiết kế quan trọng	Hệ quả
⚠ Muốn cách ly hai nhóm khách hàng
⚠ Phải BỎ luật server rộng
⚠ Chỉ dùng luật cấp database cho từng nhóm
⚠ Nếu để luật server rộng	⚠ mọi luật database chỉ là mở thêm, không cách ly được
⚠ Đối chiếu	⚠ #19531 trong cùng lô về cách ly hai nhóm khách

⚠ Cách kiểm tra luật hiện có	Cách
⚠ `sys.firewall_rules`	⚠ luật cấp server
⚠ `sys.database_firewall_rules`	⚠ luật cấp database
⚠ Nên rà soát	⚠ định kỳ, xoá luật của IP không còn dùng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Luật server có đang quá rộng không | ⚠ nó vô hiệu hoá mọi nỗ lực cách ly | | Còn luật nào của IP cũ không | | | Có thể chuyển sang private endpoint không | |

Và điểm cốt lõi mà cặp câu hỏi này dạy được, quan trọng hơn việc nhớ thứ tự xét: luật cấp database chỉ MỞ THÊM chứ không thu hẹp được luật cấp server. Muốn cách ly thật sự thì phải siết ở tầng server trước.

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

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ

Đáp án

Vì sao đúng

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

Ghi nhớ