Ngân hàng đề — AWS Certified Generative AI Developer Pro

Đáp án

A — Dựng lại TOÀN BỘ vector store bằng Bedrock Knowledge Bases với MỘT model Titan Embeddings duy nhất và luật tiền xử lý đồng nhất để loại bỏ lệch phiên bản; chạy kiểm tra độ liên quan và test đánh giá drift để xác nhận mọi vector đã khớp với kho tài liệu mới.

Vì sao đúng

Đề mô tả một tình trạng cụ thể: một phần kho đã re-embed bằng model mới và logic tiền xử lý mới, phần còn lại vẫn dùng vector cũ.

Đây không phải vấn đề "dữ liệu hơi cũ" — nó là lỗi về tính hợp lệ của phép đo:

Vector từ hai model embedding khác nhau không so sánh được với nhau. Khoảng cách giữa chúng là một con số vô nghĩa.

Mỗi embedding model ánh xạ văn bản vào không gian vector riêng của nó. Hai model khác nhau đặt cùng một câu ở hai vị trí hoàn toàn khác nhau. Nên khi index chứa cả hai loại:

Truy vấn (mã hoá bằng model MỚI)
    ↓ so khoảng cách
vector mới  → khoảng cách có nghĩa   ✅
vector cũ   → khoảng cách VÔ NGHĨA   ❌ nhưng vẫn ra một con số

Và vì nó vẫn ra một con số, hệ thống không báo lỗi — nó chỉ xếp hạng sai một cách âm thầm. Đó là lý do triệu chứng là "gợi ý lỗi thời" chứ không phải "hệ thống hỏng".

Cách chữa duy nhất là dựng lại toàn bộ với một model và một bộ luật tiền xử lý. Không có cách vá cục bộ nào hợp lệ.

Và vế thứ hai của đáp án cũng cần thiết: sau khi rebuild, chạy kiểm tra độ liên quan với bộ câu hỏi chuẩn để xác nhận vấn đề đã hết — nếu không, bạn chỉ đang hy vọng.

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

• B. Giữ hỗn hợp vector cũ và mới, dùng metadata filter đẩy bài mới lên, dựa vào reranking của Bedrock để bù cho sự khác biệt giữa hai thế hệ embedding — reranking không sửa được vector không so sánh được: reranker chỉ sắp xếp lại những gì được truy xuất, mà tầng truy xuất đã sai ngay từ đầu. Nếu tài liệu đúng không lọt vào top-K thì reranker không thấy nó.
• D. Re-embed chỉ phần liên quan tới bước xử lý sự cố mới, giữ nguyên embedding cũ, kiểm chứng bằng test có mục tiêu thay vì rebuild toàn bộ — giữ nguyên vấn đề gốc, và test có mục tiêu sẽ không phát hiện ra vì nó chỉ kiểm những câu hỏi bạn nghĩ tới.
• C. Re-embed chỉ tài liệu thay đổi, giữ vector cũ, chỉnh tham số ANN của OpenSearch để giảm gợi ý lỗi thời — chỉnh ANN là chỉnh tốc độ và recall, không sửa được ngữ nghĩa. Tinh chỉnh ef_search cho một index có vector không đồng nhất chỉ làm nó tìm nhanh hơn trong không gian sai.

Ghi nhớ

Quy tắc bất di bất dịch của vector store:

Một index — một model embedding — một bộ luật tiền xử lý.

Ba tình huống buộc phải rebuild toàn bộ: | Tình huống | Vì sao | |---|---| | Đổi embedding model | không gian vector khác nhau | | Đổi phiên bản model (v1 → v2) | cũng là model khác | | Đổi logic tiền xử lý | cùng model nhưng đầu vào khác ⇒ vector khác |

Dòng giữa hay bị bỏ sót: Titan Embed v1 và v2 không tương thích với nhau, dù cùng tên.

Cách rebuild không gián đoạn — mẫu blue/green cho index:

1. Tạo index mới: tai-lieu-v2 (model mới, luật mới)
2. Nạp TOÀN BỘ kho vào v2
3. Chạy bộ câu hỏi chuẩn, so kết quả v1 với v2
4. Chuyển alias "tai-lieu" sang v2       ← nguyên tử
5. Giữ v1 vài ngày rồi xoá

Ứng dụng luôn truy vấn qua alias, nên nó không biết gì về việc chuyển đổi, và rollback chỉ là chuyển alias ngược lại.

Ba loại drift cần theo dõi trong hệ thống RAG: | Loại | Nghĩa | |---|---| | Embedding drift | vector sinh bởi model hoặc luật khác nhau ← câu này | | Content drift | tài liệu nguồn đổi nhưng index chưa cập nhật | | Query drift | dạng câu hỏi của người dùng đổi theo thời gian |

Và cách phát hiện sớm loại thứ nhất: ghi model ID và phiên bản luật tiền xử lý vào metadata của MỖI vector. Sau đó một truy vấn đơn giản là đủ để biết index có bị trộn hay không — thay vì phát hiện qua lời phàn nàn của người dùng như tình huống trong đề.

Đáp án

B — Dùng Bedrock streaming đẩy các bước suy luận trung gian ngay khi chúng được sinh ra và hiển thị bằng thành phần giao diện chuyên cho chuỗi suy luận; cấu hình prompt đầu ra có cấu trúc trong Prompt Flows để trích ra chuỗi lập luận và chỉ báo độ tin cậy.

Vì sao đúng

Đề nêu ba thứ bác sĩ muốn thấy, và đáp án phải cho đủ ba: | Bác sĩ muốn | Cơ chế trong B | |---|---| | Các bước trung gian | streaming + hiển thị chuỗi suy luận | | Chỉ báo độ tin cậy | prompt đầu ra có cấu trúc | | Trình tự các quyết định | chuỗi lập luận được trích ra theo thứ tự |

Điểm mấu chốt là hai cơ chế phải đi cùng nhau:

Đầu ra có cấu trúc ép model bộc lộ lập luận thành dữ liệu chứ không phải văn xuôi:

{
  "cac_buoc": [
    {"buoc": 1, "noi_dung": "Bệnh nhân có sốt kéo dài và ho khan",
     "nguon": "ghi chú khám 12/03", "do_tin_cay": 0.95},
    {"buoc": 2, "noi_dung": "Xét nghiệm loại trừ nhiễm khuẩn",
     "nguon": "kết quả CBC", "do_tin_cay": 0.88}
  ],
  "chan_doan_phan_biet": [
    {"ten": "Viêm phổi không điển hình", "do_tin_cay": 0.72}
  ]
}

Streaming làm cho các bước đó hiện dần ngay khi được sinh ra, thay vì bác sĩ nhìn màn hình trống rồi đột nhiên thấy toàn bộ kết luận. Với bác sĩ đang đứng cạnh bệnh nhân, khác biệt này rất thật.

Và hiển thị bằng thành phần chuyên dụng là vế cuối: một khối văn bản dài không phải là "minh bạch" — bác sĩ cần thấy từng bước tách rời, kèm nguồn và độ tin cậy để đánh giá bước nào đáng tin, bước nào cần kiểm lại.

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

• A. Dùng streaming trả toàn bộ câu trả lời cuối cùng theo từng đoạn nhỏ, dùng CloudWatch metric theo dõi độ tin cậy ở phía sau thay vì hiển thị cho bác sĩ — đây là phương án gần nhất và sai ở điểm quan trọng nhất: stream câu trả lời cuối không phải stream quá trình suy luận. Bác sĩ vẫn chỉ thấy kết luận, chỉ là thấy dần dần. Và để độ tin cậy trong CloudWatch là đưa nó cho người vận hành, không phải cho người cần nó.
• C. Dùng Guardrails chặn đầu ra chưa hoàn chỉnh hoặc độ tin cậy thấp, chỉ hiện câu trả lời đã được xác thực đầy đủ — đi ngược yêu cầu: bác sĩ muốn thấy nhiều hơn, còn phương án này giấu đi nhiều hơn. Và giấu những kết luận độ tin cậy thấp là nguy hiểm trong y khoa — bác sĩ cần biết chính xác chỗ nào hệ thống không chắc.
• D. Lambda hậu xử lý thêm tuyên bố miễn trừ chung chung và điểm tin cậy TĨNH, lưu vào CloudWatch Logs — điểm tin cậy tĩnh là con số bịa: nó không phản ánh gì về từng câu trả lời cụ thể. Đây là minh bạch giả, và trong y khoa thì tệ hơn không có gì vì nó tạo cảm giác an tâm sai.

Ghi nhớ

Ba tầng minh bạch cho ứng dụng AI hỗ trợ quyết định: | Tầng | Cho biết | |---|---| | Chuỗi suy luận | hệ thống đi tới kết luận bằng đường nào | | Trích dẫn nguồn | mỗi khẳng định dựa trên tài liệu nào | | Chỉ báo độ tin cậy | hệ thống chắc chắn tới đâu ở từng bước |

Cả ba đều cần thiết, và ba tầng trả lời ba câu hỏi khác nhau — thiếu tầng nào thì bác sĩ mất một cách kiểm tra.

Ba cách lấy được chuỗi suy luận từ model: | Cách | Chi tiết | |---|---| | Chain-of-thought + đầu ra có cấu trúc | yêu cầu model ghi từng bước vào trường riêng ← câu này | | Bedrock agent trace | agent tự ghi lại các bước gọi công cụ | | Extended thinking | một số model bộc lộ quá trình suy nghĩ riêng biệt |

Ba lưu ý riêng cho lĩnh vực y tế:

1. Độ tin cậy do model tự khai không phải xác suất đã hiệu chỉnh — model thường quá tự tin. Nên trình bày nó như chỉ báo tương đối, kèm ghi chú, chứ không như một con số thống kê.
2. Luôn hiển thị nguồn — bác sĩ cần đọc được chính ghi chú hoặc hướng dẫn mà hệ thống dựa vào.
3. Nói rõ đây là công cụ hỗ trợ, không thay thế phán đoán lâm sàng — không phải để miễn trừ trách nhiệm, mà vì nó đúng.

Điểm đầu tiên đáng nhớ nhất: một con số tin cậy chưa hiệu chỉnh trông rất giống một con số đã hiệu chỉnh, và người đọc không có cách nào phân biệt. Nếu hiển thị nó, phải nói rõ nó là gì.

Đáp án

B — Dùng Bedrock Knowledge Bases lưu và index tài liệu của mỗi khách hàng trong data store CÁCH LY, cấu hình resource-based policy sao cho chỉ trợ lý của khách hàng đó truy xuất được; dựa vào cam kết riêng tư sẵn có của Bedrock rằng dữ liệu khách hàng không được dùng để huấn luyện hay cải tiến foundation model.

Vì sao đúng

Đề nêu ba yêu cầu, và cả ba đều được đáp ứng ở tầng hạ tầng, không phải tầng ứng dụng: | Yêu cầu | Cơ chế | |---|---| | Cách ly tuyệt đối giữa các tenant | data store riêng + resource-based policy | | Không dùng dữ liệu để huấn luyện model | cam kết dựng sẵn của Bedrock | | Trả lời có căn cứ | grounding từ chính KB của khách hàng đó |

Vế đầu là điểm phân biệt quan trọng nhất, và nó là một nguyên tắc bảo mật chứ không phải sở thích kiến trúc:

Cách ly ở tầng tài nguyên mạnh hơn cách ly ở tầng ứng dụng.

Với data store riêng và policy riêng, một lỗi trong mã ứng dụng KHÔNG THỂ làm lộ dữ liệu chéo — vì role của trợ lý khách hàng A đơn giản là không có quyền đọc kho của khách hàng B:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::123456789012:role/TroLyKhachHangA"},
  "Action": ["bedrock:Retrieve", "bedrock:RetrieveAndGenerate"],
  "Resource": "arn:aws:bedrock:ap-northeast-1:123456789012:knowledge-base/KB-A"
}

Còn nếu lọc ở tầng ứng dụng, toàn bộ an toàn phụ thuộc vào việc mã luôn luôn đúng — mà mã thì có bug, và bug trong bộ lọc tenant là loại bug im lặng nhất: nó không gây lỗi, nó chỉ trả về dữ liệu của người khác.

Và cam kết của Bedrock đáp ứng yêu cầu pháp lý: prompt và dữ liệu gửi tới Bedrock không được dùng để huấn luyện foundation model, kể cả model của bên thứ ba trên nền tảng.

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

• A. Index riêng cho từng khách hàng nhưng backend dùng CHUNG một retrieval role truy cập được MỌI index; dựa vào tầng ứng dụng lọc theo customer ID — đây là phương án gần nhất và sai ở đúng chỗ trên: có index riêng nhưng không có ranh giới quyền. Một dòng mã sai là lộ dữ liệu, và không có lớp nào chặn lại.
• C. Index logic riêng nhưng dùng chung một nơi lưu trữ và một access policy thống nhất, dựa vào định tuyến ở tầng ứng dụng — cùng lỗi như A, và tệ hơn vì chung cả nơi lưu trữ. "Simplified management" là lý do sai để hy sinh ranh giới bảo mật khi khách hàng là các doanh nghiệp cạnh tranh nhau.
• D. Đưa tài liệu thẳng vào model lúc chạy, kiểm soát bằng KMS key riêng cho từng khách hàng; dựa vào hậu xử lý đầu ra để tránh rò rỉ — KMS bảo vệ dữ liệu lúc lưu, không bảo vệ lúc dùng: sau khi giải mã và đưa vào prompt thì key không còn tác dụng gì. Và hậu xử lý đầu ra để chặn rò rỉ là phòng tuyến cuối cùng và yếu nhất.

Ghi nhớ

Ba mức cách ly multi-tenant, theo độ mạnh tăng dần: | Mức | Cơ chế | Rủi ro | |---|---|---| | Lọc ở tầng ứng dụng | WHERE tenant_id = ? | một bug là lộ dữ liệu | | Metadata filter ở tầng dịch vụ | filter trong truy vấn vector | tốt hơn, vẫn phụ thuộc truy vấn đúng | | Tài nguyên riêng + IAM | KB riêng, policy riêng | mạnh nhất — bug không vượt qua được |

Cách chọn: | Bối cảnh | Mức phù hợp | |---|---| | Nhiều tenant nhỏ, dữ liệu không nhạy cảm | metadata filter | | Khách hàng doanh nghiệp, sở hữu trí tuệ, đối thủ của nhau | tài nguyên riêng ← câu này | | Yêu cầu tuân thủ nghiêm ngặt | tài nguyên riêng, có thể cả tài khoản AWS riêng |

Đánh đổi cần biết: tài nguyên riêng tốn công quản lý hơn — mỗi tenant là một KB, một policy. Với hàng nghìn tenant, cần tự động hoá việc tạo và thu hồi. Nhưng với "highly customized runbooks" của khách hàng doanh nghiệp như đề mô tả, số lượng tenant thường vừa phải và giá trị dữ liệu rất cao.

Ba điều cần biết về quyền riêng tư dữ liệu trên Bedrock: | Điểm | Chi tiết | |---|---| | Không dùng để huấn luyện | prompt và phản hồi không đi vào việc cải tiến model | | Không lưu lại | Bedrock không giữ dữ liệu sau khi xử lý xong (trừ khi bạn bật invocation logging) | | Không rời Region | trừ khi bạn dùng cross-Region inference |

Dòng cuối là điều cần kiểm tra riêng nếu khách hàng có ràng buộc chủ quyền dữ liệu.

Đáp án

A — Triển khai luồng suy luận dựa trên Bedrock ở hai Region, phơi mỗi Region qua endpoint riêng đăng ký trong Route 53 với failover hoặc latency-based routing; cấu hình Route 53 health check giám sát từng endpoint và tự động chuyển traffic sang Region khoẻ khi có sự cố.

Vì sao đúng

Đề nêu ba yêu cầu, và chỉ A có đủ: | Yêu cầu | Cơ chế | |---|---| | Hoạt động được khi một Region mất kéo dài | triển khai ở hai Region | | Định tuyến theo quy định vùng | latency-based hoặc geolocation routing | | Health check tự động và chuyển hướng an toàn | Route 53 health check + failover |

Health check là điểm phân biệt duy nhất giữa A và ba phương án còn lại — cả bốn đều nhắc tới Route 53, nhưng chỉ A bật health check.

Không có health check, Route 53 không biết endpoint nào đang hỏng — nó vẫn tiếp tục gửi traffic tới Region đã chết:

Không health check: DNS trả về IP của Region hỏng → client timeout → thử lại → timeout
Có health check:    Route 53 phát hiện trong ~30 giây → gỡ bản ghi → traffic sang Region khoẻ

Cấu hình:

aws route53 create-health-check --health-check-config '{
  "Type": "HTTPS", "ResourcePath": "/health",
  "FullyQualifiedDomainName": "api-tokyo.example.com",
  "RequestInterval": 30, "FailureThreshold": 3
}'

Và hai kiểu routing trong đáp án phục vụ hai kiến trúc khác nhau: | Kiểu | Kiến trúc | Đặc điểm | |---|---|---| | Failover routing | active-passive | primary nhận hết, secondary chỉ nhận khi primary hỏng | | Latency-based routing | active-active | mỗi khách tới Region gần nhất, cả hai đều phục vụ |

Đề nói hệ thống phải hỗ trợ cả hai kiểu — và đáp án A nêu đúng cả hai.

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

• C. Endpoint ở nhiều Region nhưng weighted routing LUÔN ưu tiên Region chính bất kể tình trạng sức khoẻ; chỉ chuyển về sau khi quản trị viên sửa trọng số thủ công — không có tự động hoá nào: "regardless of health status" nghĩa là traffic vẫn đổ vào Region đã chết. Và chờ người sửa trọng số là thời gian ngừng dịch vụ.
• D. Triển khai ở hai Region nhưng một bản ghi Route 53 simple routing, KHÔNG health check; dựa vào client tự phát hiện lỗi và tự chuyển thủ công — simple routing chỉ trả về một giá trị cố định, nó không có khái niệm dự phòng. Và đẩy trách nhiệm failover sang client là bỏ qua yêu cầu "automated health checks".
• B. Chạy ở một Region và bật cross-Region replication cho dữ liệu, vẫn gửi mọi request qua một bản ghi simple; dựa vào DNS caching để lo failover — replicate dữ liệu không phải triển khai đa Region: khi Region chính mất, không có gì để chạy. Và "DNS caching để lo failover" là hiểu sai cơ chế — cache DNS làm chậm failover chứ không thực hiện nó.

Ghi nhớ

Các chính sách định tuyến của Route 53: | Chính sách | Dùng khi | |---|---| | Simple | một endpoint duy nhất | | Failover | active-passive, có primary rõ ràng | | Latency-based | active-active, tối ưu độ trễ | | Geolocation | tuân thủ theo vùng — dữ liệu EU ở lại EU | | Geoproximity | như geolocation nhưng có bias điều chỉnh được | | Weighted | thử nghiệm A/B, chuyển dần traffic | | Multivalue answer | trả nhiều IP, có health check |

Với yêu cầu "routed according to regional compliance rules" trong đề, geolocation routing đáng cân nhắc bên cạnh latency-based: nó đảm bảo request từ một quốc gia luôn tới Region được phép, không phụ thuộc vào độ trễ mạng lúc đó.

So sánh hai kiến trúc đa Region: | | Active-active | Active-passive | |---|---|---| | Cả hai Region phục vụ | ✅ | ❌ (một chờ) | | Thời gian phục hồi | gần như tức thì | vài chục giây tới vài phút | | Chi phí | cao — hai Region đều chạy đủ tải | thấp hơn | | Độ phức tạp dữ liệu | cao — cần đồng bộ hai chiều | thấp hơn |

Ba chi tiết vận hành hay bị bỏ sót:

1. TTL thấp cho bản ghi DNS (60 giây) — TTL cao làm client giữ IP cũ rất lâu sau khi failover.
2. Health check phải kiểm tra đường đi thật, không chỉ /health trả 200 — nên gọi thử một truy vấn Bedrock nhẹ.
3. Kiểm thử failover định kỳ — một cơ chế dự phòng chưa bao giờ được thử là một cơ chế chưa biết có chạy hay không.

Và lưu ý riêng cho Bedrock: danh sách model khả dụng khác nhau giữa các Region. Trước khi thiết kế đa Region, xác nhận model bạn dùng có mặt ở cả hai — nếu không, failover sẽ chuyển sang một Region không chạy được workload.

Đáp án

A và C.

• C — Sensitive information filter của Guardrails phát hiện và chặn email, số điện thoại, mã định danh tài chính trong cả prompt lẫn phản hồi; cấu hình che hoặc từ chối, áp tự động lúc gọi model
• A — Word filter của Guardrails khai các từ và cụm từ cấm; chặn hoặc thay thế khi phát hiện; quản lý danh sách tập trung

Vì sao đúng

Đề mô tả hai loại rủi ro khác hẳn nhau, và Guardrails có hai bộ lọc riêng cho chúng: | Rủi ro | Bản chất | Bộ lọc | |---|---|---| | Số điện thoại, email, chuỗi thanh toán | mẫu có cấu trúc, nhận diện được bằng luật | sensitive information filter | | Tên đối thủ, tiếng lóng, mã nội bộ | danh sách từ cụ thể của tổ chức | word filter |

Dùng đúng bộ lọc cho đúng loại là toàn bộ ý của câu hỏi.

C — sensitive information filter có sẵn các loại PII được định nghĩa trước, không cần bạn viết regex:

{"sensitiveInformationPolicyConfig": {
  "piiEntitiesConfig": [
    {"type": "EMAIL",              "action": "ANONYMIZE"},
    {"type": "PHONE",              "action": "ANONYMIZE"},
    {"type": "CREDIT_DEBIT_CARD_NUMBER", "action": "BLOCK"},
    {"type": "US_BANK_ACCOUNT_NUMBER",   "action": "BLOCK"}
  ]
}}

Hai hành động khác nhau có ý nghĩa khác nhau: ANONYMIZE che đi rồi vẫn cho tiếp tục (email trong ticket được thay bằng {EMAIL}), còn BLOCK từ chối hẳn (số thẻ tín dụng thì không nên xử lý tiếp).

A — word filter cho danh sách từ mà chỉ tổ chức của bạn mới biết:

{"wordPolicyConfig": {
  "wordsConfig": [{"text": "Ten-Doi-Thu"}, {"text": "ma-noi-bo-XYZ"}],
  "managedWordListsConfig": [{"type": "PROFANITY"}]
}}

Dòng managedWordListsConfig đáng biết: AWS cung cấp sẵn danh sách tục tĩu được quản lý, nên bạn không phải tự duy trì nó.

Và cả hai đều đáp ứng ba yêu cầu vận hành của đề: áp tự động lúc gọi model, quản lý tập trung (một guardrail cho nhiều ứng dụng), và hành vi đoán trước được.

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

• B. Word filter cho từ cấm, nhưng dựa vào chỉ dẫn trong prompt để hạn chế thông tin cá nhân; theo dõi vi phạm bằng log và hậu xử lý — chỉ dẫn trong prompt không phải cơ chế thực thi: model có thể bỏ qua, và người dùng dán dữ liệu thẳng vào thì chỉ dẫn không ngăn được gì. Đề yêu cầu "applied automatically during model invocation".
• D. Dùng sensitive information filter với pattern tuỳ chỉnh để bắt cả cụm từ thương hiệu và cách nói thân mật — dùng sai bộ lọc: sensitive information filter dành cho định danh có cấu trúc; tên đối thủ và tiếng lóng là danh sách từ, và word filter làm việc đó trực tiếp và rõ ràng hơn.
• E. Step Functions và Lambda quét prompt tìm chuỗi số và từ cấm, tự duy trì regex và allow list trong mã — tự dựng lại thứ Guardrails làm sẵn, và vi phạm yêu cầu "operationally efficient" cùng "centrally managed": mỗi lần đổi danh sách từ là một lần sửa mã và triển khai lại.

Ghi nhớ

Sáu chính sách của Bedrock Guardrails — nhớ đúng cái nào chặn cái gì: | Chính sách | Chặn gì | |---|---| | Content filters | ngôn ngữ độc hại theo mức độ | | Denied topics | chủ đề cấm, nhận diện theo ngữ nghĩa | | Word filters | danh sách từ và cụm từ cụ thể | | Sensitive information filters | PII và định danh có cấu trúc | | Contextual grounding | câu trả lời không dựa trên nguồn | | Prompt attacks | jailbreak, injection |

Cách phân biệt hai bộ lọc dễ nhầm nhất: | Đầu vào | Bộ lọc | |---|---| | nguyen.van.a@congty.vn | sensitive information — mẫu có cấu trúc | | "Ten-Doi-Thu" | word filter — danh sách cụ thể | | "đồ ngu" | content filter (INSULTS) hoặc managed profanity list | | "Anh nghĩ tôi nên mua cổ phiếu nào?" | denied topics — theo ngữ nghĩa |

Ba hành động của sensitive information filter: | Hành động | Kết quả | |---|---| | ANONYMIZE | thay bằng nhãn {EMAIL} rồi tiếp tục | | BLOCK | từ chối cả request hoặc response | | (không khai) | bỏ qua loại đó |

Và hai đặc điểm vận hành khiến Guardrails là lựa chọn đúng cho yêu cầu "centrally managed":

1. Guardrail có version — cập nhật danh sách từ ở một chỗ, mọi ứng dụng dùng chung được hưởng; rollback bằng cách trỏ về version cũ.
2. ApplyGuardrail API cho phép kiểm tra nội dung mà không gọi model — hữu ích khi muốn lọc dữ liệu từ nguồn khác, hoặc kiểm thử chính sách trước khi áp dụng.

Đáp án

D — Cấu hình Lake Formation với quyền mức cột, mức dòng và mức ô trên dữ liệu lâm sàng, cấp quyền chi tiết chỉ cho nhóm tuân thủ với mã chẩn đoán và định danh bệnh nhân; nhóm khoa học dữ liệu truy cập cột đã khử định danh và dòng tổng hợp, còn Bedrock Knowledge Base chỉ truy vấn được các view được phép.

Vì sao đúng

Đề mô tả hai nhóm người dùng với hai mức quyền khác nhau trên CÙNG một tập dữ liệu: | Nhóm | Được thấy | |---|---| | Nhóm tuân thủ (nhỏ) | mã chẩn đoán + định danh bệnh nhân | | Nhóm khoa học dữ liệu | chỉ dữ liệu đã khử định danh và tổng hợp |

Đây là bài toán kiểm soát truy cập chi tiết, và Lake Formation có đúng ba mức cần thiết:

              ma_benh_nhan   chan_doan   tuoi   vung   ket_qua
Nhóm tuân thủ      ✓            ✓         ✓      ✓       ✓
Nhóm KHDL          ✗            ✗         ✓      ✓       ✓   ← ẩn cột
                                                             + lọc dòng

# Cho nhóm khoa học dữ liệu: ẩn cột nhạy cảm, chỉ dòng đã khử định danh
aws lakeformation create-data-cells-filter --table-data '{
  "DatabaseName": "du_lieu_lam_sang", "TableName": "ho_so",
  "Name": "loc_khoa_hoc_du_lieu",
  "RowFilter": {"FilterExpression": "trang_thai_khu_dinh_danh = true"},
  "ColumnWildcard": {"ExcludedColumnNames": ["ma_benh_nhan", "chan_doan_chi_tiet"]}
}'

Điểm mấu chốt cho vế cuối: Bedrock Knowledge Base truy xuất qua role đã được cấp quyền Lake Formation, nên giới hạn được thực thi ở tầng dữ liệu — không phụ thuộc vào việc ứng dụng nhớ lọc.

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

• A. Lake Formation với quyền mức BẢNG, dùng Athena view che trường nhạy cảm; cấp cho CẢ HAI nhóm quyền trên CÙNG bảng rồi dùng SQL filter loại bỏ bản ghi hạn chế lúc truy xuất — đây là phương án gần nhất và sai ở chỗ quan trọng: quyền mức bảng nghĩa là ai có quyền thì thấy toàn bộ bảng. Bảo mật chuyển sang phụ thuộc SQL filter được viết đúng ở mọi truy vấn — một chỗ quên là lộ dữ liệu bệnh nhân.
• C. Lake Formation với quyền mức bảng và hai Data Catalog tách sẵn dữ liệu nhạy cảm và không nhạy cảm; Bedrock Knowledge Bases tự lọc ô hạn chế lúc truy xuất — hai lỗi: tách thành hai catalog nghĩa là nhân bản và đồng bộ dữ liệu, và Knowledge Bases KHÔNG có tính năng tự lọc ô — đó là việc của Lake Formation.
• B. Lưu trên S3 với quyền mức bucket, dùng IAM identity policy hạn chế truy cập mã chẩn đoán; để Knowledge Base đọc thẳng object S3 — IAM policy làm việc ở mức object, không ở mức cột hay dòng. Không có cách nào diễn đạt "được đọc file này nhưng không được thấy cột chan_doan".

Ghi nhớ

Bốn mức kiểm soát của Lake Formation: | Mức | Giới hạn | |---|---| | Table | thấy hay không thấy cả bảng | | Column | ẩn một số cột | | Row | chỉ thấy dòng thoả điều kiện | | Cell | giao của hai mức trên ← câu này |

Các engine tự động tôn trọng quyền Lake Formation: Athena, Redshift Spectrum, Glue ETL, EMR, QuickSight — và SageMaker cùng Bedrock qua Glue catalog. Đó là lý do đáp án nói Knowledge Base "chỉ truy vấn được các view được phép": bạn cấu hình một lần, mọi nơi tuân theo.

Nguyên tắc thiết kế rút ra:

Thực thi ở tầng gần dữ liệu nhất mà bạn có thể.

Càng xa dữ liệu thì càng nhiều chỗ để quên: một truy vấn ad-hoc, một notebook, một job mới viết. Lake Formation đặt ranh giới ở catalog, nên mọi đường vào đều đi qua nó.

LF-Tags là cách mở rộng đáng biết khi số bảng lớn — gắn thẻ cho cột thay vì cấp quyền từng cái:

Gắn: do_nhay_cam = cao   →  ma_benh_nhan, chan_doan_chi_tiet
Cấp: nhóm KHDL được đọc  →  do_nhay_cam = thap

Cách này giảm số policy phải quản lý từ hàng trăm xuống vài chục, và cột mới thêm vào tự động thừa hưởng chính sách nếu được gắn thẻ đúng — quan trọng với dữ liệu lâm sàng vốn hay có trường mới.

Và ba lưu ý riêng cho dữ liệu y tế:

1. Khử định danh không phải ẩn danh hoàn toàn — kết hợp tuổi, vùng và ngày khám vẫn có thể tái định danh. Cân nhắc tổng quát hoá (nhóm tuổi thay vì tuổi chính xác).
2. Ghi vết mọi truy cập — CloudTrail cộng với Lake Formation audit log.
3. Kiểm tra bằng chính engine, không tin vào giao diện: quyền có thể trông đúng trong Console mà sai ở tầng thực thi.

Đáp án

D — Dùng Bedrock Knowledge Bases với hierarchical chunking và chunk có chồng lấn, cấu hình gắn metadata để phần sửa đổi mới nhận điểm truy xuất cao hơn; dùng chẩn đoán cửa sổ ngữ cảnh và metric hiệu năng RAG để xác nhận phần cuối tài liệu được giữ lại.

Vì sao đúng

Đề nêu triệu chứng rất cụ thể: câu trả lời bỏ qua các sửa đổi mới nhất nằm gần CUỐI tài liệu, và pipeline hiện dùng chunking cố định, ngây thơ, áp cho mọi loại tài liệu.

Có hai nguyên nhân riêng biệt, và đáp án phải xử lý cả hai: | Nguyên nhân | Cách chữa | |---|---| | Chia cố định cắt ngang cấu trúc tài liệu | hierarchical chunking + overlap | | Không có gì ưu tiên nội dung mới | metadata tagging để tăng điểm cho sửa đổi mới |

Hierarchical chunking giữ được quan hệ cha–con của tài liệu HR dài:

[Cha: Chương "Chính sách nghỉ phép"]
   ├── [Con: Mục 1 — quy định chung]
   ├── [Con: Mục 2 — trường hợp đặc biệt]
   └── [Con: Phụ lục — SỬA ĐỔI tháng 3/2026]   ← nằm cuối, không bị cắt rời

Tìm bằng chunk con (chính xác), đưa vào model bằng chunk cha (đủ ngữ cảnh).

Overlap xử lý vấn đề biên: chunk cố định cắt giữa một điều khoản làm cả hai nửa đều mất nghĩa; chồng lấn khiến mỗi chunk mang theo một phần ngữ cảnh của chunk kề bên.

Metadata tagging là vế thứ hai, và nó là thứ trực tiếp sửa triệu chứng "bỏ qua sửa đổi mới nhất":

{"metadataAttributes": {
  "ngay_hieu_luc": "2026-03-15",
  "loai_noi_dung": "sua-doi",
  "uu_tien": 10
}}

Rồi lọc hoặc tăng điểm lúc truy vấn để bản sửa đổi mới được ưu tiên hơn văn bản gốc.

Và vế cuối — chẩn đoán và metric — là cách xác nhận đã sửa được thật, thay vì hy vọng.

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

• A. Knowledge Bases với chunking phẳng đơn giản, lọc chỉ theo timestamp tài liệu, dựa vào top-K lớn hơn để bù cho phần bị bỏ sót — đây là phương án gần nhất và sai ở hai chỗ: giữ nguyên chunking phẳng tức là giữ nguyên nguyên nhân gốc, và tăng top-K là bù trừ chứ không phải sửa — nó lấy về nhiều nhiễu hơn, làm loãng ngữ cảnh. Lọc theo timestamp tài liệu cũng không đủ: một tài liệu cũ có phụ lục mới vẫn mang timestamp cũ.
• C. Glue định dạng lại thành chunk lớn đồng nhất, dùng Kendra không xếp hạng theo metadata, tăng max token để nhồi thêm nội dung mà không đổi chiến lược nạp — cụm cuối là điểm loại. Và chunk lớn đồng nhất làm vấn đề tệ hơn: nhiều nội dung không liên quan bị kéo vào cùng, làm loãng phần quan trọng.
• B. Dùng Textract chuyển đổi tài liệu, dựa vào streaming mặc định của Bedrock để tự điều chỉnh ngữ cảnh, thêm few-shot trong system prompt bảo model chú ý phần cuối — streaming không liên quan gì tới việc chọn ngữ cảnh (nó chỉ ảnh hưởng cách trả về token). Và bảo model "hãy chú ý phần cuối" không giúp được gì khi phần cuối chưa bao giờ được truy xuất vào prompt.

Ghi nhớ

Bốn chiến lược chunking của Bedrock Knowledge Bases: | Chiến lược | Cách chia | Hợp với | |---|---|---| | Fixed-size | đếm token | tài liệu ngắn, đồng nhất | | Fixed-size + overlap | cố định, có chồng lấn | giảm mất ngữ cảnh ở biên | | Semantic | theo ranh giới ý nghĩa | văn bản tự do | | Hierarchical | cha–con theo cấu trúc | tài liệu dài có chương mục ← câu này |

Cấu hình hierarchical:

{"chunkingStrategy": "HIERARCHICAL",
 "hierarchicalChunkingConfiguration": {
   "levelConfigurations": [{"maxTokens": 1500}, {"maxTokens": 300}],
   "overlapTokens": 60}}

Hai mức: chunk cha 1.500 token, chunk con 300 token. Tìm bằng con, đưa vào model bằng cha.

Ba lý do tài liệu dài hay bị bỏ sót phần cuối: | Lý do | Cách chữa | |---|---| | Chunk cuối bị cắt cụt | overlap + chia theo cấu trúc | | Không có tín hiệu ưu tiên | metadata: ngày hiệu lực, loại nội dung | | Top-K lấy toàn chunk đầu tài liệu | metadata filter, hoặc reranking |

Và một mẹo thực dụng cho tài liệu có sửa đổi như HR policy: tách bản sửa đổi thành tài liệu riêng khi nạp, gắn metadata thay_the: <id tài liệu gốc>. Cách này làm cho sửa đổi có trọng lượng ngang tài liệu gốc trong truy xuất, thay vì là một đoạn nhỏ chìm ở cuối một văn bản dài.

Đáp án

A và B.

• A — Cấu hình các Strands Agent chuyên biệt cho phân tích cảm biến, đọc nhật ký bảo trì, và lập kế hoạch khắc phục; gắn định nghĩa vai trò rõ ràng và công cụ riêng cho từng agent
• B — Dùng Agent Squad điều phối cộng tác để các agent trao đổi kết quả trung gian và uỷ thác nhiệm vụ con động trong quá trình phân tích sự cố

Vì sao đúng

Đề mô tả rõ ba đặc điểm mà một hệ đa agent phải có:

1. Nhiều agent chuyên biệt với chuyên môn khác nhau
2. Trao đổi kết quả giữa các agent
3. Uỷ thác nhiệm vụ ĐỘNG dựa trên chuyên môn

A cung cấp các agent, B cung cấp tầng điều phối — hai mảnh của cùng một kiến trúc:

                  Agent Squad (điều phối)
                  ├─ chọn agent phù hợp cho từng nhiệm vụ con
                  ├─ chuyển kết quả giữa các agent
                  └─ giữ trạng thái chung của cuộc điều tra
                            ↓
   Agent cảm biến  ←→  Agent nhật ký  ←→  Agent khắc phục
   (đọc telemetry)     (tra lịch sử)      (đề xuất phương án)

Vì sao cần tầng điều phối riêng — đây là điểm phân biệt với phương án C: chẩn đoán nguyên nhân gốc là quá trình lộ dần. Agent cảm biến phát hiện rung động bất thường ở trục X, và chỉ khi đó mới biết cần hỏi agent nhật ký về lịch sử bảo trì của đúng bộ phận đó. Không thể lên kịch bản trước thứ tự gọi.

Strands Agents là SDK mã nguồn mở của AWS cho việc xây agent, cho phép khai vai trò và công cụ theo kiểu khai báo:

from strands import Agent
agent_cam_bien = Agent(
    system_prompt="Bạn là chuyên gia phân tích dữ liệu cảm biến công nghiệp...",
    tools=[doc_telemetry, phat_hien_bat_thuong, so_sanh_duong_co_so]
)

Agent Squad (trước đây là Multi-Agent Orchestrator) là framework mã nguồn mở của AWS cho việc điều phối nhiều agent — nó lo phần định tuyến, giữ ngữ cảnh chung, và chuyển giao giữa các agent.

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

• C. Ba Strands Agent chuyên biệt nhưng chạy độc lập KHÔNG có tầng điều phối; ứng dụng gọi tuần tự rồi gộp đầu ra thủ công, không cho cộng tác hay chia sẻ trạng thái — đây là phương án gần nhất và bị loại bởi chính mô tả của nó: đề yêu cầu "exchange findings and dynamically delegate", mà gọi tuần tự cố định thì không có uỷ thác động nào.
• D. MỘT Bedrock Agent với nhiều action group, thêm luật prompt để nó tự điều phối chuyên môn mà không dùng tính năng multi-agent — một agent không phải nhiều agent: nó không có ranh giới chuyên môn, không có trao đổi giữa các bên, và system prompt phải gánh cả ba vai cùng lúc — thường dẫn tới chất lượng kém ở mọi vai.
• E. Strands Agent cho từng chuyên môn, dùng API Gateway tự viết để các agent trao đổi kết quả — tự dựng lại tầng điều phối: bạn phải tự lo định tuyến, trạng thái chung, xử lý lỗi, và giới hạn số vòng. Đó chính là thứ Agent Squad làm sẵn.

Ghi nhớ

Ba lựa chọn xây agent trên AWS: | Lựa chọn | Đặc điểm | |---|---| | Bedrock Agents | dịch vụ được quản lý, ReAct dựng sẵn, ít mã nhất | | Strands Agents | SDK mã nguồn mở, kiểm soát chi tiết, chạy ở đâu cũng được | | Agent Squad | framework điều phối NHIỀU agent |

(Ghi chú: Strands Agents và Agent Squad là framework mã nguồn mở do AWS phát hành, không phải dịch vụ được quản lý như Bedrock Agents. Đề gọi chúng là "AWS Strands Agents" và "AWS Agent Squad" — cách gọi này hơi gây hiểu nhầm là dịch vụ có endpoint riêng. Bạn tự chạy chúng trên Lambda, ECS hoặc EC2.)

Bốn mẫu điều phối đa agent: | Mẫu | Cách hoạt động | |---|---| | Supervisor | một agent điều phối phân việc cho các agent chuyên môn | | Sequential | chuỗi cố định, đầu ra agent này là đầu vào agent kia | | Swarm | agent tự chuyển giao cho nhau khi thấy cần | | Hierarchical | nhiều tầng điều phối |

Với chẩn đoán sự cố như đề mô tả, supervisor hoặc swarm phù hợp vì đường điều tra không đoán trước được.

Khi nào KHÔNG nên dùng đa agent: | Tình huống | Lý do | |---|---| | Quy trình cố định, biết trước các bước | Step Functions đơn giản hơn và rẻ hơn | | Một lĩnh vực chuyên môn duy nhất | một agent là đủ | | Yêu cầu độ trễ rất thấp | mỗi lần chuyển giao là thêm một lời gọi model |

Dòng cuối là đánh đổi thật: hệ đa agent chậm hơn và tốn hơn đáng kể. Nó đáng giá khi bài toán thật sự cần nhiều chuyên môn phối hợp — như phân tích nguyên nhân gốc trong đề — chứ không phải mặc định cho mọi ứng dụng.

Và ba biện pháp an toàn bắt buộc: giới hạn số vòng chuyển giao, timeout tổng, và ghi vết đầy đủ ai đã làm gì — không có chúng, hai agent có thể chuyền qua chuyền lại vô tận.

Đáp án

A — Dùng Bedrock Prompt Management để lưu, đánh version và phê duyệt prompt template, cho người kiểm tra tuân thủ so sánh phiên bản cũ với phiên bản mới; dùng nó để triển khai quy trình phê duyệt có kiểm soát và đề bạt cấu hình prompt qua các môi trường dev, staging, production.

Vì sao đúng

Đề nêu năm yêu cầu, và điểm quyết định nằm ở ba chữ cuối: "with minimum overhead".

bedrock_agent.create_prompt_version(promptIdentifier='PROMPT_ID',
                                    description='Bổ sung kiểm tra rủi ro tín dụng')
# Ứng dụng gọi bằng ARN có version cụ thể
bedrock_runtime.converse(
    modelId='arn:aws:bedrock:...:prompt/PROMPT_ID:3',   # ← khoá vào version 3
    ...)

Điểm hay nhất về mặt vận hành: ứng dụng trỏ vào một version cố định, nên việc đề bạt chỉ là đổi số version mà môi trường đó dùng — không build lại, không triển khai lại. Và rollback là trỏ ngược về version cũ.

Và vế "which version is active in each environment" được đáp ứng vì mỗi môi trường ghi rõ ARN kèm version nó đang dùng.

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

• B. Quy trình dựa trên Git lưu tệp JSON cấu hình và prompt template, dùng CodePipeline triển khai vào Lambda; dùng Git tag và pull request làm điểm phê duyệt, dùng nhánh riêng cho từng môi trường — đây là phương án gần nhất và hoạt động tốt về mặt kỹ thuật. Nó thua ở đúng tiêu chí đề nêu: "minimum overhead". Bạn phải dựng và duy trì pipeline, quản lý nhánh, và mỗi lần đổi prompt là một lần build và triển khai Lambda — trong khi Prompt Management đổi version mà không đụng tới mã. (Mô hình nhánh theo môi trường cũng là mẫu hay gây trôi cấu hình.)
• D. DynamoDB làm registry cấu hình, mỗi cấu hình là một item có số version và nhãn môi trường; cập nhật thủ công các dòng theo môi trường; lưu trữ bản cũ để so sánh — tự dựng lại toàn bộ: bạn phải tự viết logic version, tự làm giao diện so sánh, tự ghi vết ai phê duyệt. Và "manually update" trái yêu cầu quy trình có kiểm soát.
• C. Dùng Bedrock Prompt Router định tuyến request theo persona hoặc theo yêu cầu tuân thủ tới cấu hình model định sẵn; dùng metadata định tuyến để theo dõi môi trường nào dùng cấu hình nào — sai công cụ: Prompt Router là tính năng chọn model theo độ phức tạp của prompt để tối ưu chi phí, không phải công cụ quản lý phiên bản hay phê duyệt.

Ghi nhớ

Ba công cụ prompt của Bedrock — hay bị lẫn: | Công cụ | Việc | |---|---| | Prompt Management | lưu, đánh version, quản lý vòng đời prompt | | Prompt Flows | điều phối nhiều bước thành workflow | | Prompt Router | tự chọn model theo độ phức tạp — tối ưu chi phí |

Ba thứ Prompt Management cho sẵn: | Tính năng | Chi tiết | |---|---| | Version bất biến | tạo rồi không sửa được — đúng yêu cầu kiểm toán | | Biến trong template | {{ten_khach_hang}} — tái dùng cho nhiều ngữ cảnh | | Gắn với model và tham số | version lưu cả modelId, temperature, maxTokens |

Dòng cuối đáng chú ý: version prompt không chỉ là văn bản — nó là toàn bộ cấu hình suy luận. Nên "cấu hình model theo từng môi trường" mà đề yêu cầu được đáp ứng trong cùng một cơ chế.

Ghi chú về chất lượng câu hỏi. Đáp án nói Prompt Management dùng để "implement controlled approval workflows". Trên thực tế, Prompt Management cung cấp version bất biến, bản nháp, và vết kiểm toán qua CloudTrail — nhưng không có tính năng quy trình phê duyệt nhiều bước dựng sẵn kiểu "người A duyệt rồi mới tới người B". Quy trình đó thường được ghép thêm bằng IAM (chỉ một nhóm được gọi create_prompt_version) hoặc bằng một pipeline bên ngoài. Đáp án A vẫn là lựa chọn đúng nhất trong bốn phương án — nó đúng về nền tảng version và đề bạt, và đúng về tiêu chí "minimum overhead" — nhưng đừng đọc nó thành "Bedrock có sẵn màn hình phê duyệt". Ba câu khác trong cùng bộ đề (#6402, #6417) cũng nói tương tự về "approval workflow"; hiểu chúng theo cùng một cách.

Đáp án

C — Tạo vector collection hoặc namespace RIÊNG cho từng tenant trên OpenSearch Serverless, thực thi cách ly bằng resource policy, mã hoá mặc định và IAM chi tiết; định tuyến mọi truy vấn qua tầng truy xuất nhận biết tenant chọn đúng collection theo danh tính đã xác thực.

Vì sao đúng

Đề nêu bốn yêu cầu, và C là lựa chọn duy nhất thoả hết: | Yêu cầu | Cơ chế | |---|---| | Cách ly dữ liệu nghiêm ngặt | collection riêng + resource policy | | Mã hoá | OpenSearch Serverless mã hoá mặc định | | Kiểm soát truy cập chéo tenant | IAM chi tiết theo danh tính | | Hiệu năng đoán trước được cho mỗi khách | tài nguyên riêng, không tranh chấp |

Vế cuối là điểm hay bị bỏ qua nhưng đề nêu rõ: "predictable performance for each customer". Với kho dùng chung, một tenant có 10 triệu tài liệu sẽ làm chậm truy vấn của tenant có 1.000 tài liệu — hiện tượng noisy neighbour. Namespace riêng loại bỏ chuyện đó.

Và nguyên tắc bảo mật nền tảng:

Cách ly ở tầng tài nguyên mạnh hơn cách ly ở tầng ứng dụng.

{
  "Rules": [{"ResourceType": "collection", "Resource": ["collection/tenant-abc"],
             "Permission": ["aoss:*"]}],
  "Principal": ["arn:aws:iam::123456789012:role/TroLyTenantAbc"]
}

Với policy này, một bug trong mã ứng dụng không thể đọc dữ liệu tenant khác — role đơn giản là không có quyền.

Tầng truy xuất nhận biết tenant là mảnh còn lại: nó lấy tenant ID từ token đã xác thực (không phải từ tham số do client gửi) rồi chọn collection tương ứng:

tenant_id = claims['custom:tenantId']       # từ Cognito, không từ request body
client = lay_client_opensearch(f'tenant-{tenant_id}')

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

• B. Một collection dùng chung, gắn tenant ID cho từng vector để lọc; dựa vào logic phía client loại bỏ kết quả không khớp — tệ nhất trong bốn: lọc ở phía client nghĩa là dữ liệu của tenant khác đã ra khỏi kho và đã tới máy khách rồi mới bị bỏ. Đó là rò rỉ, không phải cách ly.
• A. Xuất mọi tài liệu ra S3 và dùng một Knowledge Base tập trung, áp metadata filter để chỉ trả kết quả của đúng tenant — khá hơn B nhưng vẫn là cách ly ở tầng truy vấn: toàn bộ an toàn phụ thuộc vào việc mọi truy vấn đều có filter đúng. Và nó không giải quyết được vấn đề hiệu năng dùng chung.
• D. Một cụm Aurora PostgreSQL riêng cho MỖI tenant với pgvector — cách ly rất mạnh nhưng không mở rộng được tới quy mô đề nêu: đề nói "scale to thousands of tenants", mà hàng nghìn cụm Aurora là chi phí và gánh nặng vận hành khổng lồ (mỗi cụm có chi phí tối thiểu, kể cả khi rảnh).

Ghi nhớ

Ba mô hình cách ly multi-tenant, và cách chọn: | Mô hình | Cách ly | Chi phí | Mở rộng | |---|---|---|---| | Silo (tài nguyên riêng hoàn toàn) | mạnh nhất | cao nhất | kém với số tenant lớn | | Pool (dùng chung, lọc logic) | yếu nhất | thấp nhất | tốt nhất | | Bridge (namespace riêng, hạ tầng chung) | mạnh | vừa | tốt ← câu này |

Đáp án C là mô hình bridge: OpenSearch Serverless quản lý hạ tầng chung, nhưng mỗi tenant có collection riêng với policy riêng. Đó là điểm cân bằng đúng cho "hàng nghìn tenant với dữ liệu độc quyền".

Ba nguyên tắc bảo mật multi-tenant: | Nguyên tắc | Chi tiết | |---|---| | Tenant ID lấy từ token đã xác thực | KHÔNG BAO GIỜ từ tham số client gửi lên | | Thực thi ở tầng gần dữ liệu nhất | resource policy, không phải mã ứng dụng | | Kiểm thử chéo tenant | test tự động thử đọc dữ liệu tenant khác và phải thất bại |

Nguyên tắc thứ ba hay bị bỏ: nên có test trong CI cố tình dùng token của tenant A để đọc dữ liệu tenant B, và coi test đó thất bại nếu nó thành công.

Và ba đặc điểm của OpenSearch Serverless đáng biết cho trường hợp này:

1. Mã hoá at-rest bằng KMS mặc định — dùng key riêng cho mỗi tenant được nếu cần.
2. Co giãn tự động theo OCU — không phải quản lý node hay shard.
3. Chi phí tối thiểu cho mỗi collection — với hàng nghìn tenant nhỏ, cân nhắc namespace/index trong ít collection hơn thay vì mỗi tenant một collection, và bù bằng fine-grained access control.

Điểm thứ ba là đánh đổi thực tế: cách ly tuyệt đối tốn tiền, và với tenant rất nhỏ thì gộp có kiểm soát là hợp lý — miễn là ranh giới vẫn nằm ở tầng dịch vụ, không phải tầng mã.