Ngân hàng đề — AWS Certified Data Engineer Associate

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

Đề mô tả một công ty đang dùng Amazon EBS Provisioned IOPS SSD (io1) và muốn chuyển sang thế hệ mới hơn là io2. Có ba ràng buộc được cài trong đề, và ràng buộc thứ ba mới là cụm từ quyết định:

• "does not disrupt their running Amazon EC2 instances" — không được làm gián đoạn instance đang chạy.
• "risk data loss" — không được có rủi ro mất dữ liệu.
• "with minimal operational effort" — đây là cụm phân biệt. Cả bốn phương án đều "chuyển được dữ liệu từ io1 sang io2" nếu làm cẩn thận; cái khác nhau nằm ở số bước thủ công, số dịch vụ phải dựng thêm, và số chỗ có thể sai.

Khi đề hỏi "minimal operational effort" mà EBS đã có sẵn một thao tác gốc làm đúng việc đó, thì mọi phương án dạng "provision volume mới → copy dữ liệu → detach/attach" đều bị loại vì chúng tự dựng lại bằng tay một tính năng đã có sẵn.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — Modify volume type của chính volume io1 hiện có sang io2 bằng AWS Management Console hoặc CLI, không cần detach khỏi EC2 instance.

EBS hỗ trợ volume modification ngay trên volume đang gắn và đang phục vụ: đổi volume type, đổi kích thước, đổi mức provisioned IOPS mà không cần tháo volume ra và không cần dừng instance. Vì io1 và io2 đều là dòng Provisioned IOPS SSD, việc chuyển từ io1 sang io2 nằm gọn trong khả năng đổi type này.

Cách này thoả cả ba ràng buộc trong đề:

• Không detach → instance vẫn chạy, không gián đoạn.
• Không copy dữ liệu qua lại → không có bước nào có thể làm lệch hoặc mất dữ liệu; dữ liệu vẫn nằm nguyên trên chính volume đó.
• Một thao tác duy nhất trên Console/CLI → operational effort thấp nhất trong bốn phương án.

❌ Vì sao các phương án còn lại sai

A — Dùng Amazon EBS direct APIs để copy dữ liệu sang io2 mới rồi swap volume. Đây là phương án gần đúng nhất về mặt kỹ thuật: EBS direct APIs thật sự đọc được nội dung snapshot theo từng block, kể cả phần chênh lệch giữa hai snapshot. Nhưng nó hỏng ở chỗ khối lượng công việc: phải tự viết script, tự gọi và xử lý từng lời gọi API, tự quản lý tiến trình copy, rồi vẫn phải swap volume trên instance. So với một thao tác đổi type có sẵn thì đây là làm khó mình, trái thẳng với "minimal operational effort". Thêm nữa bước swap volume vẫn là một điểm chạm vào instance đang chạy.

B — Provision io2 mới, copy dữ liệu bằng công cụ copy file chạy trên EC2, rồi detach io1 / attach io2. Vừa tốn thời gian vừa nhiều bước thủ công, và mỗi bước là một chỗ có thể sai. Copy ở mức file trên máy đang chạy còn có rủi ro dữ liệu không nhất quán nếu ứng dụng vẫn đang ghi trong lúc copy — đúng cái "risk data loss" mà đề yêu cầu tránh. Bước detach/attach cũng là gián đoạn thật sự đối với instance.

C — Dùng AWS Storage Gateway để chuyển dữ liệu giữa io1 và io2. Đây là phương án sai lệch nhất về mục đích dịch vụ. Storage Gateway sinh ra cho kịch bản hybrid: nối hệ thống lưu trữ tại chỗ (on-premises) với storage trên AWS. Ở đây cả nguồn lẫn đích đều là EBS volume nằm sẵn trong AWS, không có phía on-premises nào cả. Kéo Storage Gateway vào chỉ thêm một dịch vụ phải dựng, phải cấu hình và phải trả tiền, mà không giải quyết được gì hơn thao tác đổi type.

📌 Điểm cần nhớ

• EBS volume modification cho phép đổi volume type, dung lượng và provisioned IOPS ngay trên volume đang gắn vào instance đang chạy — không detach, không stop. Gặp câu hỏi "đổi io1 → io2", "đổi gp2 → gp3", "tăng dung lượng volume" mà kèm ràng buộc không downtime thì đây gần như luôn là đáp án.
• Cụm "minimal operational effort" / "least operational overhead" là tín hiệu chọn tính năng có sẵn (managed) thay vì quy trình tự dựng bằng script, kể cả khi quy trình tự dựng vẫn chạy được.
• Mọi phương án dạng "tạo volume mới → copy dữ liệu → detach/attach" đều mang theo cả downtime lẫn rủi ro dữ liệu; chỉ chọn khi thật sự không có đường nâng cấp tại chỗ.
• AWS Storage Gateway là dịch vụ hybrid (nối on-premises với AWS). Thấy nó xuất hiện trong bài toán mà cả hai đầu đều nằm trong AWS thì đó là distractor.

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

Đề mô tả một công ty marketing dùng Amazon Redshift để quản lý dữ liệu chiến dịch. Bảng Campaigns có cột CampaignName, và yêu cầu là chọn ra tất cả chiến dịch có tên kết thúc bằng "Spring" hoặc "Summer".

Cụm từ quyết định đáp án là "names ending with" — tức đây là bài toán so khớp mẫu (pattern matching) ở cuối chuỗi, không phải so khớp chính xác (exact match). Chỉ riêng cụm này đã loại được mọi phương án dùng toán tử = thuần túy.

Ràng buộc phụ, nhưng cũng quan trọng không kém: đề đưa ra hai từ khoá có độ dài khác nhau — "Spring" 6 ký tự, "Summer" 6 ký tự... nhưng cách viết truy vấn cần đúng về mặt ngữ nghĩa "kết thúc bằng" chứ không phải "cắt N ký tự cuối rồi so bằng". Đây chính là chỗ mà một phương án nhìn có vẻ hợp lý bị hỏng.

Cuối cùng: Redshift dựa trên nền PostgreSQL và tuân theo cú pháp SQL chuẩn, nên mọi toán tử dùng trong truy vấn phải là toán tử SQL thật sự tồn tại.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C:

SELECT * FROM Campaigns WHERE CampaignName LIKE '%Spring' OR CampaignName LIKE '%Summer';

LIKE là toán tử so khớp mẫu chuẩn của SQL, và Amazon Redshift hỗ trợ đầy đủ. Trong mẫu của LIKE, ký tự % là wildcard đại diện cho số ký tự bất kỳ (kể cả không có ký tự nào).

Vì vậy mẫu '%Spring' có nghĩa: "bất kỳ chuỗi ký tự nào, rồi kết thúc bằng đúng chữ Spring" — đây chính xác là định nghĩa của "ending with". Đặt % ở đầu mẫu và để từ khoá ở cuối là cách diễn đạt "kết thúc bằng"; ngược lại 'Spring%' sẽ là "bắt đầu bằng".

Hai điều kiện nối bằng OR để lấy cả chiến dịch kết thúc bằng Spring lẫn kết thúc bằng Summer. Cách viết này ngắn gọn, đúng cú pháp, và không phụ thuộc vào độ dài của từ khoá.

❌ Vì sao các phương án còn lại sai

A. WHERE CampaignName = '%Spring' OR CampaignName = '%Summer'

Toán tử = trong SQL là so khớp chính xác, nó không diễn giải wildcard. Với =, chuỗi '%Spring' được hiểu theo nghĩa đen: dấu % là một ký tự phần trăm bình thường. Truy vấn này chỉ trả về những dòng mà CampaignName đúng bằng chuỗi bảy ký tự %Spring — gần như chắc chắn là không dòng nào. Đây là lỗi kinh điển: viết đúng mẫu nhưng dùng nhầm toán tử. Wildcard chỉ có tác dụng khi đi cùng LIKE (hoặc ILIKE, SIMILAR TO).

B. WHERE RIGHT(CampaignName, 6) = 'Spring' OR RIGHT(CampaignName, 6) = 'Summer'

Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Hàm RIGHT() cắt N ký tự từ bên phải chuỗi, nên về mặt ý tưởng nó có thể diễn đạt "kết thúc bằng". Vấn đề là cách viết này cứng nhắc phụ thuộc vào con số độ dài: nó buộc bạn phải đếm tay số ký tự cho từng từ khoá, và một khi danh sách từ khoá có độ dài khác nhau thì cùng một con số 6 không thể phục vụ cả hai điều kiện — bạn phải viết RIGHT(..., n) riêng cho mỗi từ. Truy vấn thành ra mong manh: thêm một từ khoá mới hoặc gõ nhầm một con số là kết quả sai âm thầm, không có lỗi cú pháp nào báo. So với LIKE — vốn diễn đạt trực tiếp ý "kết thúc bằng" mà không cần biết độ dài — thì đây là cách phức tạp hơn mức cần thiết cho cùng một việc.

D. WHERE CampaignName ENDS WITH 'Spring' OR CampaignName ENDS WITH 'Summer'

Phương án này đọc lên nghe rất "tự nhiên" và khớp y hệt ngôn từ của đề bài — chính vì thế nó dễ được chọn. Nhưng ENDS WITH không phải là toán tử SQL hợp lệ. Nó không tồn tại trong SQL chuẩn, không tồn tại trong Amazon Redshift. Chạy truy vấn này sẽ lỗi cú pháp, không trả về dòng nào cả. Bài học: đề bài viết bằng tiếng Anh đời thường, đừng dịch thẳng cụm tiếng Anh đó thành toán tử SQL.

📌 Điểm cần nhớ

• Wildcard chỉ sống cùng LIKE, không sống cùng =. Thấy % hoặc _ đứng cạnh dấu = trong một phương án thì loại ngay — đó là dấu hiệu phương án mồi.
• Vị trí của % quyết định ngữ nghĩa: '%abc' = kết thúc bằng, 'abc%' = bắt đầu bằng, '%abc%' = chứa. Đây là chi tiết bị hỏi đi hỏi lại trong các câu về LIKE.
• Cẩn thận với phương án nghe giống hệt lời văn của đề. Cụm như ENDS WITH, STARTS WITH, CONTAINS đọc rất thuận tai nhưng không phải toán tử SQL — hãy tự hỏi "cú pháp này có thật không?" trước khi chọn.
• Redshift theo cú pháp SQL chuẩn (nền PostgreSQL), nên các toán tử so khớp mẫu quen thuộc như LIKE dùng được bình thường; đừng nghĩ đây là một phương ngữ SQL đặc biệt với cú pháp riêng.
• Giải pháp phụ thuộc vào hằng số độ dài thì mong manh. RIGHT(col, n) chạy được nhưng gắn chặt vào con số n; khi danh sách từ khoá có độ dài khác nhau, LIKE là lựa chọn vừa gọn vừa không thể sai vì đếm nhầm.

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

Đề mô tả một workflow AWS Step Functions điều phối một chuỗi tác vụ tính toán trên một tập dữ liệu lớn. Câu hỏi yêu cầu chọn loại state phù hợp, chứ không phải chọn dịch vụ hay kiến trúc.

Cụm từ quyết định là "The workflow should execute these tasks sequentially for each data element" — nhấn mạnh vào tính tuần tự của chuỗi tác vụ áp lên từng phần tử. Cụm thứ hai hỗ trợ nó là "Each data element must be processed through the same sequence of tasks": mỗi phần tử đi qua cùng một chuỗi, và chuỗi đó phải giữ đúng thứ tự.

Đây chính là chỗ dễ mất điểm: bốn phương án là bốn state cơ bản của Amazon States Language, và hai trong số đó (Parallel, Map) đều liên quan tới việc chạy nhiều nhánh. Phải bám vào chữ sequentially để tách chúng ra.

✅ Vì sao đáp án đúng là đúng

Đáp án theo tệp là C — Parallel.

Parallel state định nghĩa nhiều nhánh (branches) tường minh, mỗi nhánh là một state machine con riêng. Điểm mấu chốt: bên trong một nhánh, các state chạy nối tiếp nhau theo đúng thứ tự khai báo — nhánh chỉ kết thúc khi state cuối cùng của nó xong.

Theo cách lập luận của nguồn: mỗi data element được giao cho một nhánh của Parallel, và trong nhánh đó chuỗi tác vụ được thực thi tuần tự đúng như đề yêu cầu. Nhiều phần tử có thể được xử lý cùng lúc ở các nhánh khác nhau, nhưng ràng buộc "cùng một sequence of tasks, chạy theo thứ tự" vẫn được giữ nguyên cho từng phần tử. Vì vậy Parallel vừa đáp ứng yêu cầu tuần tự trong phạm vi một phần tử, vừa xử lý hiệu quả tập dữ liệu lớn.

❌ Vì sao các phương án còn lại sai

A — Wait: Wait chỉ tạm dừng execution trong một khoảng thời gian, hoặc đến một mốc thời gian cụ thể (Seconds, Timestamp, hoặc lấy từ input). Nó không thực thi tác vụ nào, không nhận dữ liệu để xử lý. Dùng khi cần chờ một tài nguyên bên ngoài sẵn sàng, hoàn toàn không liên quan đến việc điều phối chuỗi tác vụ.

B — Choice: Choice là state rẽ nhánh theo điều kiện — so sánh giá trị trong input rồi quyết định đi tiếp sang state nào. Nó chỉ chọn đường, không chạy tác vụ, và cũng không lặp qua các phần tử của tập dữ liệu. Có thể xuất hiện bên trong một luồng xử lý, nhưng bản thân nó không giải quyết yêu cầu của đề.

D — Map — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Map đúng là state chuyên để áp cùng một chuỗi tác vụ lên từng phần tử của một mảng, nghe rất khớp với "each data element must be processed through the same sequence of tasks". Nhưng theo lập luận của nguồn, Map xử lý các item song song với nhau, trong khi đề nhấn mạnh yêu cầu sequential execution; vì vậy nguồn cho rằng Map không khớp với ràng buộc tuần tự mà đề đặt ra, và loại nó.

(Lưu ý khi ôn: cách lập luận này của nguồn khá gây tranh cãi, vì Map vẫn giữ đúng thứ tự các tác vụ bên trong mỗi lần lặp và còn có thể giới hạn mức đồng thời. Nhưng với câu này, hãy nhớ đáp án được chấm là Parallel.)

📌 Điểm cần nhớ

• Nhớ đúng vai trò bốn state cơ bản: Task làm việc, Choice rẽ nhánh theo điều kiện, Wait trì hoãn, Parallel chạy nhiều nhánh khai báo sẵn, Map lặp qua một mảng.
• Bên trong một nhánh của Parallel, các state luôn chạy nối tiếp theo thứ tự — tính song song chỉ tồn tại giữa các nhánh, không phải bên trong nhánh.
• Khác biệt cốt lõi Parallel vs Map: Parallel có số nhánh cố định, mỗi nhánh logic khác nhau; Map có số lần lặp động theo độ dài mảng đầu vào, cùng một logic.
• Với dạng câu hỏi "chọn state", hãy tìm trạng từ ràng buộc trong đề (sequentially, concurrently, conditionally, after a delay) — nó thường là chìa khoá duy nhất tách các phương án gần giống nhau.

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

Đề mô tả một công ty phân tích dữ liệu y tế phải bảo đảm các instance Amazon RDS tuân thủ một bộ cấu hình bắt buộc theo quy định pháp lý. Yêu cầu gồm ba phần dính liền nhau: liên tục theo dõi và ghi lại (continuously monitor and record) cấu hình, đánh giá xem cấu hình có lệch khỏi chuẩn tuân thủ hay không, và gửi cảnh báo khi có thay đổi vi phạm.

Cụm từ quyết định là "compliance standards" đi kèm "continuously monitor and record the configurations". Đây không phải chuyện đo hiệu năng, cũng không phải chỉ ghi nhật ký ai đã làm gì, mà là bài toán configuration compliance: phải có nơi lưu lại trạng thái cấu hình theo thời gian và có luật để chấm "đạt / không đạt". Chỉ cần bám vào hai chữ configuration + compliance là loại được ba phương án còn lại.

✅ Vì sao đáp án đúng là đúng

D — AWS Config với AWS Config rules là đáp án đúng.

AWS Config sinh ra đúng để đánh giá, kiểm toán và theo dõi cấu hình tài nguyên AWS. Nó liên tục ghi lại cấu hình của tài nguyên (ở đây là các RDS instance) và lưu lịch sử thay đổi, nên trả lời được câu hỏi "cấu hình này trông thế nào tại thời điểm đó". Trên nền dữ liệu ấy, AWS Config rules tự động so cấu hình đã ghi với cấu hình mong muốn và kết luận tài nguyên là COMPLIANT hay NON_COMPLIANT.

Phần cảnh báo cũng nằm sẵn trong dịch vụ: AWS Config phát thông báo qua Amazon SNS, nên khi một RDS instance bị đổi sang trạng thái lệch chuẩn thì quản trị viên nhận được thông báo. Đúng cả ba vế mà đề đòi — ghi cấu hình, chấm tuân thủ, báo động — trong một dịch vụ.

❌ Vì sao các phương án còn lại sai

A — Amazon RDS Performance Insights. Đây là công cụ tinh chỉnh hiệu năng: nó giúp nhìn nhanh tải của database, câu SQL nào nặng, đang chờ ở đâu. Nó không có khái niệm "cấu hình mong muốn" và không đánh giá tuân thủ. Phương án cố tình gài thêm chữ "and configuration data" để nghe giống, nhưng nhiệm vụ của dịch vụ này là hiệu năng chứ không phải compliance.

B — AWS CloudTrail. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. CloudTrail ghi lại hành động do người dùng, role hay dịch vụ AWS thực hiện — tức là "ai gọi API nào, lúc nào". Nó rất hợp cho điều tra và truy vết, nhưng nó ghi sự kiện, không ghi trạng thái cấu hình hiện tại, và bản thân nó không có cơ chế đánh giá tuân thủ. Chính chữ "analyze the logs" trong phương án đã tự tố cáo: bạn phải tự dựng thêm phần phân tích và tự định nghĩa thế nào là vi phạm, trong khi AWS Config làm sẵn việc đó bằng rules.

C — Amazon CloudWatch Events. Phương án này bắt được vế "phản ứng với thay đổi trạng thái và báo cho quản trị viên", nên nghe khá thuyết phục. Nhưng nó chỉ dừng ở đó: CloudWatch Events phản ứng với state change và bắn thông báo, chứ không đánh giá xem cấu hình có đạt chuẩn hay không. Kết quả là quản trị viên bị báo mọi thay đổi, kể cả thay đổi hoàn toàn hợp lệ, mà vẫn không biết cái nào là vi phạm. Nó cũng không giữ lịch sử cấu hình để kiểm toán như đề yêu cầu ở vế "record".

📌 Điểm cần nhớ

• Thấy "configuration compliance", "evaluate against desired configuration" hay "continuously record configurations" → nghĩ ngay AWS Config; đây là dịch vụ duy nhất trong nhóm này vừa ghi cấu hình vừa chấm tuân thủ bằng rules.
• Phân biệt ba dịch vụ hay bị lẫn: CloudTrail = ai đã làm gì (nhật ký hành động, phục vụ audit); CloudWatch/CloudWatch Events = số liệu và phản ứng theo sự kiện; AWS Config = tài nguyên đang được cấu hình ra sao và có đạt chuẩn không.
• Một phương án "phát hiện thay đổi rồi báo" không tương đương với "đánh giá tuân thủ". Đề nào có chữ compliance standards thì đòi hỏi phần chấm đạt/không đạt, không chỉ phần thông báo.
• Performance Insights luôn thuộc nhóm hiệu năng database, không bao giờ là câu trả lời cho câu hỏi về bảo mật hay quản trị dữ liệu.
• AWS Config gửi cảnh báo qua SNS, nên khi đề yêu cầu "monitor + evaluate + notify", một mình AWS Config đã phủ trọn chuỗi đó.

Đáp án

A — Dùng AWS DataSync để tự động hoá và lên lịch việc chuyển tệp

Vì sao đúng

Hai dữ kiện quyết định: 10 TB và một phần dữ liệu được cập nhật hằng tuần. Vế thứ hai loại bỏ mọi giải pháp chuyển một lần.

DataSync là dịch vụ được quản lý cho việc đồng bộ định kỳ: chạy theo lịch, chỉ chuyển phần thay đổi, tự thử lại khi lỗi, kiểm tra toàn vẹn dữ liệu, và chạy nhanh hơn nhiều so với công cụ chép thông thường nhờ giao thức tối ưu riêng.

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

• B. AWS Snowball — thiết bị vật lý cho việc chuyển một lần khối lượng rất lớn; dùng cho cập nhật hằng tuần là không khả thi.
• C. Transfer for SFTP — cung cấp điểm cuối SFTP để bên ngoài đẩy tệp lên; nó không tự đi quét và đồng bộ.
• D. Storage Gateway — cho ứng dụng tại chỗ truy cập dữ liệu trên S3 như lưu trữ cục bộ; đó là bài toán truy cập, không phải bài toán di trú.

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

Đề mô tả một cluster Amazon Redshift provisioned gồm bốn node ra3.4xlarge, đang dùng even distribution. Triệu chứng: lúc tải cao, một node CPU rất cao còn ba node kia gần như rảnh — đây là dấu hiệu kinh điển của dữ liệu (hoặc công việc xử lý dữ liệu) bị dồn lệch về một slice/node, tức data skew khi xử lý query.

Hai cụm từ trong đề quyết định đáp án:

• "optimize the workload distribution across all nodes" — vấn đề nằm ở cách dữ liệu nằm trên các node, không phải ở việc query nào được ưu tiên hay dữ liệu được sắp xếp thế nào.
• "without altering the cluster size" — cấm mọi phương án đụng tới số lượng node. Cụm này một mình đã loại thẳng phương án C.

Kết hợp lại: cần một thay đổi về distribution style để dữ liệu và phần việc join trải đều trên bốn node, giữ nguyên bốn node.

✅ Vì sao đáp án đúng là đúng

D — Redefine the distribution style to KEY using a column with high cardinality that is frequently joined on.

Trong Redshift, DISTSTYLE KEY băm giá trị của cột được chọn (DISTKEY) để quyết định mỗi hàng nằm trên slice nào. Hai điều kiện trong phương án được nêu rất có chủ đích:

• High cardinality (nhiều giá trị phân biệt): hàm băm trải giá trị ra nhiều slice khác nhau. Chọn cột ít giá trị phân biệt thì phần lớn hàng rơi vào cùng một slice — đúng là tình trạng "một node nóng" mà đề đang than phiền.
• Frequently joined on: khi hai bảng cùng phân bố theo cột join, các hàng cần ghép nhau đã nằm sẵn trên cùng slice, Redshift không phải phát tán lại dữ liệu qua mạng lúc chạy join. Đây là điểm khác biệt thật sự so với EVEN — EVEN rải hàng theo vòng tròn nên trên giấy tờ mỗi node có số hàng xấp xỉ nhau, nhưng khi join thì dữ liệu phải được chuyển đi giữa các node, và công việc xử lý dồn lệch.

Bản giải thích của nguồn nói đúng ý này: đặt DISTKEY vào một cột cardinality cao và hay được join giúp cân bằng phân bố dữ liệu giữa các node, giảm nút thắt trên một node, cải thiện hiệu năng query mà không cần tăng số node.

❌ Vì sao các phương án còn lại sai

A — Adjust the WLM configuration to prioritize queries differently across the nodes. WLM quản lý hàng đợi query: mức ưu tiên, mức đồng thời, phần bộ nhớ cấp cho mỗi query. Nó không hề can thiệp vào việc hàng dữ liệu nằm ở node nào. Ngoài ra, cách diễn đạt "prioritize queries differently across the nodes" đã sai về mô hình: WLM chia theo queue, không phải theo node. Chỉnh WLM có thể làm query quan trọng chạy trước, nhưng node đang nóng vẫn nóng vì dữ liệu vẫn nằm đúng chỗ cũ.

B — Transition to using a compound sort key based on the columns most frequently used in JOIN clauses. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì sort key đúng là công cụ tối ưu hiệu năng của Redshift và nó cũng nhắc tới cột trong JOIN. Chỗ nó hỏng: sort key quyết định thứ tự các hàng bên trong mỗi slice, còn distribution key quyết định hàng thuộc slice nào. Sort key giúp bỏ qua bớt block khi quét (zone map) và có ích cho merge join, nhưng nếu dữ liệu đã dồn về một node thì sắp xếp lại bên trong node đó không chuyển được một byte nào sang ba node đang rảnh. Đề hỏi về phân bố tải, chứ không hỏi về tốc độ quét.

C — Convert the cluster to use Elastic Resize to add more nodes during peak loads and remove them when not needed. Vi phạm trực tiếp ràng buộc của đề: Elastic Resize chính là thao tác thay đổi số node, trong khi đề yêu cầu "without altering the cluster size". Và ngay cả khi bỏ qua ràng buộc đó, thêm node vào một cluster đang skew không sửa được nguyên nhân: dữ liệu vẫn tập trung ở nơi cũ, chỉ là mua thêm node để chúng cùng nhàn rỗi.

📌 Điểm cần nhớ

• Distribution style = dữ liệu nằm ở node nào. Sort key = dữ liệu xếp thế nào trong node. Triệu chứng "một node nóng, các node khác rảnh" luôn dẫn về distribution, không dẫn về sort key.
• EVEN rải đều số hàng nhưng không giúp join cục bộ; KEY trên đúng cột join giúp Redshift ghép dữ liệu tại chỗ, giảm truyền dữ liệu giữa các node.
• Chọn DISTKEY phải là cột cardinality cao và hay dùng trong JOIN. Cột ít giá trị phân biệt sẽ tạo ra chính cái skew mà ta muốn chữa.
• Đọc kỹ ràng buộc phủ định trong đề ("without altering the cluster size", "without adding nodes"): nó thường loại thẳng phương án scale/resize trước khi cần phân tích kỹ thuật.

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

Đề đặt ra tình huống một công ty y tế cần đưa hồ sơ bệnh nhân nhạy cảm lên một bucket Amazon S3. Câu hỏi là: nên dùng phương pháp nào để tải dữ liệu đó lên một cách an toàn?

Có hai cụm từ trong đề quyết định đáp án, và phải thoả cả hai:

1. "encrypted before leaving the company's internal network" — dữ liệu phải được mã hoá trước khi rời khỏi mạng nội bộ. Cụm này loại thẳng mọi hình thức server-side encryption: server-side nghĩa là dữ liệu được mã hoá sau khi đã tới S3, tức là nó đã đi qua đường truyền ở dạng chưa mã hoá ở tầng ứng dụng.
2. "manage the encryption keys themselves" — công ty tự quản lý khoá mã hoá.

Nhiều người học chỉ đọc vế thứ hai rồi chọn SSE-KMS vì thấy chữ "customer-managed key" quen thuộc. Nhưng vế thứ nhất mới là ràng buộc phân biệt: nó nói về nơi diễn ra việc mã hoá, không phải về ai giữ khoá. Chỉ một phương án thoả cả hai.

✅ Vì sao đáp án đúng là đúng

C — Use client-side encryption with a customer-managed key before uploading the data to S3.

Client-side encryption nghĩa là việc mã hoá xảy ra ngay tại phía client, tức là bên trong mạng nội bộ của công ty, trước khi object được gửi đi. Khi dữ liệu rời mạng nội bộ, nó đã ở dạng ciphertext. Điều này khớp chính xác với yêu cầu "encrypted before leaving the company's internal network".

Đồng thời, khoá là customer-managed key do chính công ty tạo và giữ, nên họ toàn quyền kiểm soát vòng đời khoá theo chính sách của mình — thoả nốt yêu cầu thứ hai. Đây là mức kiểm soát cao nhất trong các lựa chọn: S3 chỉ lưu một khối byte đã mã hoá mà bản thân dịch vụ không có khả năng giải.

❌ Vì sao các phương án còn lại sai

A — SSE-S3 (Amazon S3-managed keys). Sai ở cả hai ràng buộc. Thứ nhất, đây là server-side encryption: S3 mã hoá dữ liệu ở phía dịch vụ, sau khi object đã được truyền lên — dữ liệu rời mạng nội bộ ở dạng chưa được công ty mã hoá. Thứ hai, khoá do chính Amazon S3 tạo và quản lý, công ty không hề nắm khoá. Đây là lựa chọn đơn giản nhất nhưng cũng ít kiểm soát nhất.

B — SSE-KMS (AWS KMS-managed keys). Đây là phương án gần đúng nhất và dễ bẫy nhất. Nó thật sự cải thiện so với A ở vế quản lý khoá: KMS cho phép dùng key do khách hàng tạo, gắn key policy, bật audit log, xoay vòng khoá. Nếu đề chỉ hỏi "muốn kiểm soát khoá" thì B là đáp án. Nhưng nó hỏng ở đúng vế thứ nhất: chữ "SSE" — server-side encryption — có nghĩa việc mã hoá vẫn diễn ra ở phía S3, sau khi dữ liệu đã rời mạng nội bộ. Ràng buộc "before leaving the internal network" không được thoả, nên B bị loại dù nghe rất hợp lý.

D — Configure the S3 bucket to use AWS Shield for encrypting data. Sai về bản chất dịch vụ. AWS Shield là dịch vụ chống tấn công DDoS cho ứng dụng chạy trên AWS; nó bảo vệ tính sẵn sàng, hoàn toàn không phải là cơ chế mã hoá và không có chức năng nào mã hoá object trong S3. Phương án này chỉ ghép một tên dịch vụ AWS quen thuộc vào một việc nó không làm.

📌 Điểm cần nhớ

• Cụm "trước khi rời khỏi mạng nội bộ / on-premises" trong đề gần như luôn là tín hiệu chọn client-side encryption. Mọi biến thể SSE (SSE-S3, SSE-KMS) đều mã hoá ở phía dịch vụ nên tự động bị loại.
• Phân biệt rạch ròi hai câu hỏi khác nhau: "mã hoá ở đâu?" (client-side vs server-side) và "ai giữ khoá?" (S3-managed vs KMS vs customer-managed). Đề thi hay trộn hai vế để tạo ra phương án gần đúng như B.
• Thang kiểm soát tăng dần trong nhóm này: SSE-S3 (ít nhất) → SSE-KMS (kiểm soát và audit được khoá) → client-side với customer-managed key (nhiều nhất, S3 không giải được dữ liệu).
• Cẩn thận với phương án gán sai chức năng cho một dịch vụ có tên quen thuộc. AWS Shield thuộc nhóm bảo vệ chống DDoS, không liên quan gì tới mã hoá dữ liệu.

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

Đề mô tả một startup có dữ liệu bán hàng đang nằm sẵn trong Amazon S3 và cần một công cụ để visualize và analyze dữ liệu đó. Ba ràng buộc được nêu rõ: user-friendly, minimal setup, và interactive dashboards and insights.

Cụm từ quyết định là "interactive dashboards" kết hợp với "visualize". Đây không phải câu hỏi về nơi lưu trữ dữ liệu, cũng không phải câu hỏi về cách truy vấn hay biến đổi dữ liệu — dữ liệu đã nằm ở S3 rồi. Đề đang hỏi về tầng trình bày (BI / presentation layer): thứ vẽ ra biểu đồ cho người dùng nhìn.

Đây chính là chỗ dễ nhầm: cả bốn phương án đều là dịch vụ analytics hợp lệ trên AWS và đều "làm việc với dữ liệu". Nhưng chỉ một trong số đó tự nó sinh ra biểu đồ và dashboard; ba cái còn lại là engine truy vấn, kho dữ liệu, hoặc công cụ ETL — chúng làm ra kết quả dạng bảng, không phải hình ảnh trực quan. Ràng buộc "minimal setup" là gợi ý thứ hai, loại tiếp những dịch vụ đòi dựng cluster hoặc viết job trước khi có thể dùng.

✅ Vì sao đáp án đúng là đúng

B — Amazon QuickSight là dịch vụ business intelligence (BI) chạy trên cloud của AWS, sinh ra đúng thứ đề bài đòi: biểu đồ, phân tích ad-hoc, và interactive dashboard để người dùng tự bấm, lọc, khoan sâu vào số liệu.

Ba yêu cầu của đề khớp trực tiếp:

• Kết nối được thẳng tới S3 — không cần bê dữ liệu sang chỗ khác trước, dữ liệu bán hàng đang ở đâu thì đọc ở đó.
• Minimal setup — QuickSight là dịch vụ managed, không có server nào để dựng, vá hay quản lý. Startup không phải bỏ công vận hành hạ tầng chỉ để xem báo cáo doanh thu.
• User-friendly — giao diện được thiết kế cho người dùng nghiệp vụ ở mọi mức kỹ năng, không bắt buộc phải biết SQL hay lập trình mới dựng được dashboard.

Nói ngắn gọn: trong danh sách này, QuickSight là dịch vụ duy nhất mà đầu ra cuối cùng là một dashboard cho con người nhìn.

❌ Vì sao các phương án còn lại sai

A — Amazon Athena. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Athena đúng là dịch vụ truy vấn tương tác chạy thẳng trên dữ liệu trong S3 bằng SQL chuẩn, cũng serverless, cũng "minimal setup" — nó thoả được vế analyze. Nhưng nó hỏng ở vế visualize: Athena trả về kết quả dạng bảng, không vẽ biểu đồ, không có khái niệm dashboard. Trong kiến trúc thực tế, Athena thường đóng vai trò nguồn dữ liệu cho QuickSight, chứ không thay thế được QuickSight. Đề hỏi công cụ để trực quan hoá, nên Athena thiếu đúng nửa quan trọng.

C — Amazon Redshift. Là data warehouse được quản lý, dùng để lưu trữ và phân tích tập dữ liệu rất lớn. Hai vấn đề: thứ nhất, giống Athena, Redshift không phải công cụ trực quan hoá — nó là nơi dữ liệu nằm và được truy vấn, có thể làm data source cho QuickSight nhưng tự nó không sinh ra biểu đồ nào. Thứ hai, nó đi ngược ràng buộc minimal setup: dữ liệu đã ở S3 rồi, chọn Redshift nghĩa là phải nạp dữ liệu vào warehouse và quản lý thêm một tầng hạ tầng — công sức không nhỏ với một startup chỉ muốn xem báo cáo bán hàng.

D — AWS Glue. Đây là dịch vụ tích hợp dữ liệu serverless, phục vụ việc discover, prepare và combine dữ liệu: chạy ETL (extract, transform, load) và làm data catalog. Nó nằm ở giai đoạn trước khi phân tích — chuẩn bị và làm sạch dữ liệu để công cụ khác dùng. Glue hoàn toàn không có chức năng vẽ dashboard hay phân tích tương tác cho người dùng cuối, nên lệch hẳn khỏi câu hỏi. Chọn Glue là nhầm giữa "xử lý dữ liệu" và "trình bày dữ liệu".

📌 Điểm cần nhớ

• Khi đề nhắc tới dashboard, visualization, biểu đồ hay business insights cho người dùng nghiệp vụ, phản xạ trên AWS là QuickSight — đó là dịch vụ BI duy nhất trong bộ analytics.
• Phân biệt rõ ba tầng vai trò để không bị bẫy: Glue chuẩn bị/biến đổi dữ liệu (ETL, catalog) → Athena / Redshift truy vấn và phân tích (trả về bảng) → QuickSight trực quan hoá (trả về biểu đồ). Chúng bổ sung cho nhau chứ không thay thế nhau.
• Athena và QuickSight rất hay xuất hiện cùng nhau trong đề. Mẹo tách: đề nhấn "query bằng SQL trên S3" → Athena; đề nhấn "visualize / dashboard / insights" → QuickSight. Nếu đề đòi cả hai thì Athena là nguồn, QuickSight là mặt trước.
• Cụm "minimal setup" hay "no servers to manage" trong đề thường dùng để loại các dịch vụ đòi dựng và vận hành hạ tầng như Redshift, ưu tiên các dịch vụ serverless/managed.
• Dữ liệu đã nằm ở S3 thì đừng vội chọn phương án phải di chuyển dữ liệu sang nơi khác, trừ khi đề nêu lý do rõ ràng (khối lượng cực lớn, join phức tạp, yêu cầu hiệu năng warehouse).

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

Một công ty truyền thông số có kho ảnh rất lớn trong một Amazon S3 bucket. Họ muốn trả về ảnh đã resize theo kích thước mà ứng dụng yêu cầu, ngay tại thời điểm người dùng lấy ảnh.

Đề bài cài sẵn ba ràng buộc, và ba ràng buộc này mới là thứ quyết định đáp án chứ không phải chuyện "resize ảnh bằng Lambda":

• "on-the-fly" — biến đổi ngay lúc có yêu cầu, không phải xử lý sẵn từ trước.
• "without storing multiple variants" — không được sinh và lưu nhiều bản sao của cùng một ảnh trong S3.
• "integrated directly within the S3 object retrieval flow" — cụm từ quyết định. Phép biến đổi phải nằm bên trong chính luồng GET object của S3, chứ không phải một tầng riêng đặt phía trước hay phía sau S3.

Cụm thứ ba loại được gần hết các phương án: bất kỳ kiến trúc nào phải dựng thêm một cổng vào riêng (API endpoint, CDN distribution) hoặc phản ứng theo sự kiện ghi dữ liệu đều không phải là "trong luồng lấy object của S3".

✅ Vì sao đáp án đúng là đúng

C — Amazon S3 Object Lambda.

S3 Object Lambda cho phép gắn mã tuỳ biến vào chính request GET tới S3: ứng dụng gọi qua một Object Lambda Access Point, S3 nạp object gốc, chuyển qua hàm Lambda của bạn, và trả về dữ liệu đã được hàm đó biến đổi. Object gốc trong bucket không bị thay đổi, và bản đã resize không cần lưu lại ở đâu cả.

Đối chiếu với ba ràng buộc của đề:

• Biến đổi xảy ra đúng lúc đọc → thoả "on-the-fly".
• Chỉ có một object gốc trong bucket, các kích thước khác nhau được sinh ra lúc trả về → thoả "without storing multiple variants", giảm cả chi phí lưu trữ lẫn công quản lý.
• Mã chạy như một phần của đường trả dữ liệu từ S3 → thoả đúng chữ "directly within the S3 object retrieval flow".

Đây chính là kịch bản mà tài liệu AWS về transforming objects mô tả, và resize ảnh là ví dụ kinh điển của nó.

❌ Vì sao các phương án còn lại sai

A — S3 Event Notifications kích hoạt Lambda mỗi khi có request lấy ảnh. Sai ở tiền đề kỹ thuật, không chỉ sai ở kiến trúc. S3 Event Notifications phát sự kiện khi object thay đổi — được tạo, bị xoá, bị khôi phục — chứ không phát sự kiện khi có ai đó GET object. Nên "trigger upon each image retrieval request" là điều S3 Event Notifications không làm được. Kiểu event-driven này hợp với hướng tạo sẵn thumbnail lúc upload, mà hướng đó lại vi phạm luôn ràng buộc "không lưu nhiều biến thể".

B — Lambda@Edge với CloudFront. Đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. Lambda@Edge thật sự resize được ảnh và còn có lợi thế về độ trễ vì chạy ở edge location gần người dùng. Nhưng nó chạy để phản hồi sự kiện của CloudFront, tức là phép biến đổi nằm ở tầng CDN đặt trước S3, không nằm trong luồng lấy object của S3. Mô hình này cũng hoạt động dựa trên việc cache kết quả tại edge, tức là vẫn tồn tại các bản đã resize được giữ lại. Với đề bài nhấn mạnh "integrated directly within the S3 object retrieval flow", B lệch đúng ở chỗ đó — nó là giải pháp tốt cho một bài toán khác (phân phối toàn cầu), không phải bài toán đang hỏi.

D — API Gateway + Lambda. Cũng chạy được về mặt chức năng: dựng một endpoint, mỗi request gọi Lambda, Lambda đọc ảnh từ S3, resize rồi trả về. Nhưng cái giá là bạn phải dựng và vận hành thêm hai thành phần (API Gateway và Lambda) chỉ để làm việc mà S3 đã có sẵn khả năng làm. Quan trọng hơn, client giờ phải gọi vào một API riêng thay vì gọi S3 — luồng lấy object không còn là luồng S3 nữa. Đây là bỏ qua tính năng có sẵn để tự lắp lại một tầng trung gian.

📌 Điểm cần nhớ

• S3 Object Lambda = gắn mã tuỳ biến vào request GET của S3. Thấy đề nói "transform data as it is returned", "on-the-fly khi retrieve", "không lưu nhiều bản sao" → nghĩ tới nó đầu tiên.
• S3 Event Notifications phản ứng với thay đổi object (PUT/DELETE), không phản ứng với việc đọc object. Phương án nào nói event notification kích hoạt khi có GET là sai ngay từ tiền đề.
• Lambda@Edge và S3 Object Lambda đều "biến đổi lúc trả về" nhưng ở hai tầng khác nhau: Lambda@Edge ở tầng CloudFront (tối ưu độ trễ toàn cầu, dựa vào cache), Object Lambda ở tầng S3 (tích hợp thẳng vào luồng lấy object). Đề nhắc CloudFront/edge/global thì chọn cái trước; đề nhắc "trong luồng S3" thì chọn cái sau.
• Khi một dịch vụ đã có sẵn khả năng cần dùng, phương án tự lắp API Gateway + Lambda gần như luôn là mồi nhử — nó chạy được nhưng thêm thành phần phải cấu hình và vận hành.

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

Đề mô tả một nhóm phân tích dữ liệu dùng Amazon Redshift cho các truy vấn phức tạp, và họ muốn theo dõi khi query optimizer đánh dấu những chỗ có khả năng kém hiệu quả.

Cụm từ quyết định đáp án là "optimizer-generated performance alerts" — cảnh báo do chính query optimizer sinh ra. Đây là ràng buộc phân biệt được cả bốn phương án, vì cả bốn đều là system view hợp lệ của Redshift và cả bốn đều liên quan tới hiệu năng truy vấn theo cách nào đó. Sự khác nhau nằm ở loại dữ liệu mà view đó ghi lại:

• ghi cảnh báo/chẩn đoán từ optimizer, hay
• ghi số đo (thời gian chạy, thời gian xếp hàng, số dòng), hay
• ghi văn bản SQL.

Đề không hỏi "xem truy vấn nào chậm", cũng không hỏi "xem truy vấn nào bị queue" — mà hỏi nơi Redshift chủ động cảnh báo rằng kế hoạch thực thi có vấn đề. Chỉ có một view làm đúng việc đó.

✅ Vì sao đáp án đúng là đúng

Đáp án B — STL_ALERT_EVENT_LOG.

Đây là system view được thiết kế riêng để ghi lại các alert do query optimizer của Amazon Redshift phát ra. Nó không đo hiệu năng chung chung, mà ghi các sự kiện cảnh báo cho thấy kế hoạch thực thi có vấn đề — ví dụ truy vấn tiêu tốn bộ nhớ quá mức, hoặc thực hiện nested loop join vốn rất kém hiệu quả.

Nói cách khác, STL_ALERT_EVENT_LOG là nơi Redshift nói cho bạn biết vấn đề là gì, thay vì đưa số liệu để bạn tự suy ra. Theo dõi view này cho phép đội data engineering phát hiện sớm và xử lý chủ động các vấn đề hiệu năng truy vấn — đúng nhu cầu mà đề bài nêu.

❌ Vì sao các phương án còn lại sai

A — STL_WLM_QUERY. View này thuộc mảng WLM (Workload Management): nó cho biết truy vấn chạy trong queue nào, chờ bao lâu, chạy bao lâu. Đây là thông tin thật sự hữu ích khi nghi ngờ vấn đề nằm ở cấu hình queue và tranh chấp tài nguyên. Nhưng nó không ghi alert hay warning về query plan hay về việc tối ưu hoá — nó không nói "join này là nested loop", nó chỉ nói "truy vấn này chờ 8 giây". Hỏng ở chỗ: sai loại dữ liệu so với cụm "optimizer-generated alerts".

C — SVL_QUERY_SUMMARY. Đây là phương án gần đúng nhất, và cũng là cái dễ chọn nhầm nhất. Nó cung cấp bản tóm tắt quá trình thực thi truy vấn — thời gian trôi qua, số dòng xử lý — nên thật sự dùng để hiểu hiệu năng tổng thể và khoanh vùng bước nào tốn kém. Chỗ nó hỏng: đó là số đo (metrics), không phải cảnh báo (alerts). Bạn phải tự đọc và tự kết luận; view này không phát ra warning cụ thể như STL_ALERT_EVENT_LOG. Đề hỏi nơi tìm alert, không hỏi nơi tìm số liệu tóm tắt.

D — STL_QUERYTEXT. View này chứa văn bản của từng câu lệnh SQL đã chạy. Nó có ích khi cần xem lại, debug, hoặc đối chiếu xem truy vấn nào tương ứng với query id nào. Nhưng nó thuần tuý là nội dung SQL — không có bất kỳ thông tin chẩn đoán hay cảnh báo nào từ góc nhìn của optimizer. Đây là phương án xa đề nhất trong bốn phương án.

📌 Điểm cần nhớ

• Trong Redshift, phân biệt ba nhóm system view theo loại dữ liệu: alert/chẩn đoán (STL_ALERT_EVENT_LOG), số đo thực thi (SVL_QUERY_SUMMARY, STL_WLM_QUERY), và nội dung SQL (STL_QUERYTEXT). Câu hỏi thường xoay quanh đúng sự phân biệt này.
• Từ khoá "alert", "warning", "optimizer flags" trong đề → nghĩ ngay tới STL_ALERT_EVENT_LOG. Đó là view duy nhất trong nhóm này phát ra cảnh báo thay vì cung cấp số liệu.
• Từ khoá "queue", "queueing time", "WLM" → STL_WLM_QUERY. Từ khoá "text of SQL statement" → STL_QUERYTEXT.
• Cẩn thận với các phương án "gần đúng" kiểu SVL_QUERY_SUMMARY: có số liệu để suy ra vấn đề khác hẳn với có hệ thống báo vấn đề cho bạn. Khi đề nhấn mạnh tính chủ động (proactive), hãy chọn view ghi alert.
• Tiền tố cũng là gợi ý: STL_ là log lịch sử ghi xuống đĩa, SVL_ là view tổng hợp (thường join sẵn nhiều bảng) — biết tiền tố giúp loại nhanh khi đề nói rõ "log" hay "summary".