Ngân hàng đề — AWS Certified AI Practitioner

🔎 Câu hỏi:
Which feature of Amazon OpenSearch Service gives companies the ability to build vector database applications?

1️⃣ Giải thích nội dung câu hỏi

Câu hỏi đang hỏi “đặc điểm nào của Amazon OpenSearch Service cho phép các doanh nghiệp xây dựng ứng dụng cơ sở dữ liệu vector?”

Vector database là hệ thống lưu trữ và tìm kiếm các vector (đại diện cho embedding của ảnh, văn bản, âm thanh…) bằng các thuật toán nearest‑neighbor (k‑NN). Để triển khai được loại cơ sở dữ liệu này trên OpenSearch, dịch vụ cần cung cấp:

• khả năng lưu trữ chỉ mục (index) dạng vector ở quy mô lớn,
• cơ chế tìm kiếm k‑NN nhanh và chính xác,
• khả năng quản lý, mở rộng các chỉ mục này khi dữ liệu tăng.

2️⃣ Đáp án đúng

✅ Đáp án:

• Scalable index management and nearest neighbor search capability

🧩 Lý do chọn:

• Từ 2022 trở đi, Amazon OpenSearch Service (phiên bản 2.x và Serverless) đã tích hợp k‑Nearest Neighbor (k‑NN) plugin và vector search engine cho phép tạo trường kiểu knn_vector và thực hiện truy vấn kNN.
• Tính năng này cung cấp quản lý chỉ mục có thể mở rộng (sharding, replica) và công cụ tìm kiếm nearest‑neighbor tối ưu hoá bằng HNSW, IVF‑PQ, hoặc ON‑DISK.
• Nhờ đó, doanh nghiệp có thể lưu trữ embeddings và thực hiện tìm kiếm tương đồng (semantic search), đề xuất, phân loại, v.v… – chính là những chức năng cốt lõi của một vector database.

Tham khảo:

• AWS Documentation – Amazon OpenSearch Service – k‑NN and Vector Search (cập nhật tới 2026).
• “Introducing Vector Search in Amazon OpenSearch Service” blog post, AWS (2023).

3️⃣ Giải thích tất cả các phương án

- Integration with Amazon S3 for object storage

❌ Sai – Tích hợp S3 chỉ giúp OpenSearch import / export dữ liệu (snapshot, log, raw files). Nó không cung cấp khả năng lưu trữ hoặc tìm kiếm vector, cũng không hỗ trợ k‑NN.

- Support for geospatial indexing and queries

❌ Sai – Đặc tính địa lý cho phép lưu trữ và truy vấn dữ liệu không gian (ví dụ: latitude/longitude, polygon). Mặc dù mạnh mẽ cho các ứng dụng GIS, nó không liên quan tới vector embeddings hay nearest‑neighbor search.

- Scalable index management and nearest neighbor search capability

✅ Đúng – Như đã phân tích ở mục 2️⃣, đây là tính năng quản lý chỉ mục có thể mở rộng kết hợp công cụ tìm kiếm k‑NN – chính xác đáp ứng nhu cầu xây dựng vector database.

- Ability to perform real‑time analysis on streaming data

❌ Sai – Khả năng phân tích thời gian thực (ví dụ: Kinesis Data Streams → OpenSearch) phục vụ log analytics, monitoring, dashboards. Nó không cung cấp cơ chế lưu trữ vector hay tìm kiếm nearest‑neighbor.

4️⃣ Tổng kết (điểm quan trọng)

• Vector database → cần vector indexing + nearest‑neighbor search.
• Amazon OpenSearch Service đáp ứng bằng k‑NN plugin / vector search, kèm quản lý chỉ mục quy mô lớn.
• Các tùy chọn còn lại chỉ đề cập tới lưu trữ S3, địa lý, hoặc phân tích streaming – không liên quan tới vector search.

5️⃣ Nguồn tham khảo 📚

1. Amazon OpenSearch Service Developer Guide – k‑Nearest Neighbor (k‑NN) and Vector Search (phiên bản 2026).
2. AWS Blog – “Introducing Vector Search in Amazon OpenSearch Service” (Nov 2023).
3. AWS re:Invent 2024 Session – “Scaling Vector Search on Amazon OpenSearch Service”.

💡 Mẹo thi: Khi gặp câu hỏi về “vector database” trong bối cảnh OpenSearch, luôn nhớ tới k‑NN + scalable indexing – là đáp án duy nhất chứa cả hai thành phần “vector” và “scalable”.

📖 Giải thích nội dung câu hỏi
Câu hỏi yêu cầu bạn chọn use case (trường hợp sử dụng) phù hợp nhất cho các mô hình AI sinh ra (generative AI models).

• Generative AI là nhóm mô hình học máy có khả năng tạo ra dữ liệu mới (hình ảnh, âm thanh, văn bản, mã nguồn…) dựa trên những mẫu đã được huấn luyện.
• Các mô hình tiêu biểu hiện nay gồm Stable Diffusion, DALL·E, Midjourney, GPT‑4, Claude, Llama‑2…
• Trên AWS, các dịch vụ như Amazon Bedrock, Amazon SageMaker JumpStart, và AWS Marketplace cung cấp các mô hình generative AI để triển khai các ứng dụng “tạo nội dung”.

Vì vậy, câu hỏi đang kiểm tra khả năng nhận biết đặc tính sinh nội dung của generative AI so với các tác vụ phân tích, tối ưu hoá hay phát hiện bất thường vốn thuộc các loại AI/ML truyền thống.

✅ Đáp án đúng

Creating photorealistic images from text descriptions for digital marketing

• Đây là một use case điển hình của mô hình tạo ảnh (text‑to‑image) như Stable Diffusion, DALL·E hoặc Midjourney.
• Ứng dụng: nhà quảng cáo chỉ cần nhập mô tả “tô màu xanh dương cho một ly cà phê trên nền thiên nhiên”, hệ thống sẽ sinh ra hình ảnh siêu thực, sẵn sàng dùng trong chiến dịch marketing.
• Trên AWS, bạn có thể triển khai mô hình này bằng Amazon Bedrock (model “Stable Diffusion” hoặc “Amazon Titan Image Generator”) hoặc SageMaker JumpStart để tạo và tùy chỉnh pipeline sinh ảnh.

❌ Giải thích các phương án sai

1. Improving network security by using intrusion detection systems

   • Giải thích: IDS (Intrusion Detection System) là giải pháp phân tích lưu lượng mạng, phát hiện mẫu tấn công – một tác vụ phân loại hoặc phát hiện bất thường, không phải tạo ra dữ liệu mới.
   • Generative AI không tham gia vào việc này; thay vào đó, các mô hình machine‑learning dựa trên supervised learning (ví dụ: Amazon GuardDuty, VPC Flow Logs + ML) thường được dùng.

2. Enhancing database performance by using optimized indexing

   • Giải thích: Tối ưu hoá chỉ mục là kỹ thuật hệ thống và cấu trúc dữ liệu, liên quan đến việc tăng tốc truy vấn chứ không liên quan tới việc sinh ra nội dung mới.
   • Các công cụ như Amazon Aurora, DynamoDB Global Secondary Index, hoặc Amazon RDS Performance Insights thực hiện nhiệm vụ này, không cần generative AI.

3. Analyzing financial data to forecast stock market trends

   • Giải thích: Dự báo thị trường chứng khoán là công việc dự báo (forecasting), sử dụng time‑series models (ARIMA, Prophet) hoặc deep learning regression. Đây là phân tích dựa trên dữ liệu lịch sử, không tạo ra dữ liệu mới.
   • Mặc dù có thể dùng Amazon Forecast hay SageMaker để xây dựng mô hình dự báo, nhưng đây không phải là generative AI use case.

🧩 Tổng hợp kiến thức (cập nhật 2026)

• Amazon Bedrock (2024‑2025): cung cấp truy cập API cho các mô hình generative như Claude 3, Titan Text/Image, Stable Diffusion v2.1. Được tối ưu cho text‑to‑image, code generation, chatbot, creative content.
• SageMaker Canvas & JumpStart: cho phép người dùng không chuyên lập mô hình tạo nội dung (ví dụ: hình ảnh, video, âm thanh) chỉ bằng vài cú click.
• AWS Marketplace: có sẵn các container chứa mô hình diffusion để triển khai trên EKS hoặc Fargate.
• Giới hạn pháp lý & đạo đức (2025‑2026): AWS khuyến cáo sử dụng generative AI cho mục đích marketing, thiết kế, nội dung sáng tạo; tránh các trường hợp deepfake, phát tán thông tin sai lệch, hoặc phân tích tài chính nhạy cảm nếu không có kiểm soát nghiêm ngặt.

📚 Tham khảo

• Amazon Bedrock Developer Guide (phiên bản 2026‑03) – phần “Use Cases for Generative AI”.
• AWS SageMaker JumpStart – Image Generation (2025‑11).
• AWS Blog – Generative AI in Digital Marketing (2024‑08).
• AWS Well‑Architected Framework – Security Pillar (cập nhật 2025) – nói rõ IDS không phải là generative AI.

Kết luận:
Trong các lựa chọn đưa ra, chỉ “Creating photorealistic images from text descriptions for digital marketing” thực sự phản ánh đặc tính “tạo ra” của generative AI, vì nó chuyển đổi mô tả văn bản thành nội dung hình ảnh mới – đúng mục đích và phạm vi của các mô hình AI sinh. Các lựa chọn còn lại thuộc lĩnh vực phân tích, tối ưu hoá, hoặc phát hiện bất thường, không phải là use case của generative AI. 🚀

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

Công ty muốn xây dựng một ứng dụng generative AI bằng cách sử dụng Amazon Bedrock và cần chọn một foundation model (FM).
Một trong những yếu tố quan trọng khi làm việc với các mô hình ngôn ngữ lớn (LLM) là kích thước “prompt” – tức là lượng thông tin (số token) mà mô hình có thể tiếp nhận trong một lần gọi API.
Câu hỏi hỏi: “Yếu tố nào sẽ quyết định được bao nhiêu thông tin có thể chứa trong một prompt?”

✅ Đáp án đúng: Context window

✅ Lý do chọn Context window là đáp án đúng

• Context window (cửa sổ ngữ cảnh) là giới hạn tối đa số token mà mô hình có thể xử lý trong một lần inference (prompt + output).
• Các mô hình khác nhau trong Amazon Bedrock (ví dụ: Claude, Titan, Llama 2, etc.) có context window khác nhau, thường từ 4 K token tới 100 K token (theo cập nhật 2026).
• Khi công ty muốn biết “một prompt có thể chứa bao nhiêu thông tin”, họ cần xem kích thước context window của mô hình được chọn. Nếu prompt quá dài, sẽ bị cắt bớt hoặc trả về lỗi.

🧩 Phân tích từng phương án (giữ nguyên nội dung tiếng Anh)

- Temperature

• Giải thích: Temperature là siêu‑tham số điều chỉnh độ ngẫu nhiên của kết quả sinh ra (giá trị cao → kết quả đa dạng, giá trị thấp → kết quả ổn định).
• Tại sao sai: Nó không ảnh hưởng tới kích thước của prompt hay số token mà mô hình có thể tiếp nhận. Do đó không phải là yếu tố quyết định “bao nhiêu thông tin” trong một prompt.

- Context window

• Giải thích: Đúng như đã nêu ở trên, đây là giới hạn tối đa số token (prompt + output) mà mô hình có thể xử lý trong một lần gọi.
• Vì sao đúng: Khi quyết định độ dài tối đa của prompt, công ty phải dựa vào giá trị context window của mô hình. Ví dụ, Claude‑3‑Haiku có context window 100 K token, trong khi Titan Text G1 chỉ có 8 K token.

- Batch size

• Giải thích: Batch size là số lượng yêu cầu (prompt) được gửi đồng thời trong một lần inference để tối ưu hoá hiệu năng tính toán.
• Tại sao sai: Batch size quyết định tốc độ và chi phí xử lý, không ảnh hưởng tới kích thước một prompt riêng lẻ. Do vậy không liên quan tới “có bao nhiêu thông tin trong một prompt”.

- Model size

• Giải thích: Model size đề cập tới số lượng tham số (parameter count) của mô hình, ví dụ 7 B, 13 B, 70 B.
• Tại sao sai: Dù model size có thể ảnh hưởng tới khả năng hiểu và tạo ra nội dung phức tạp, nó không quyết định giới hạn token của một prompt. Một mô hình nhỏ và một mô hình lớn có thể chia sẻ cùng một context window (tùy nhà cung cấp).

📚 Tham khảo (đến năm 2026)

1. Amazon Bedrock Documentation – Foundation Models
   https://docs.aws.amazon.com/bedrock/latest/userguide/what-is-bedrock.html (phiên bản 2026)

   • Bảng so sánh “Context window size” cho các mô hình: Claude‑3‑Haiku (100 K), Claude‑3‑Sonnet (75 K), Titan Text G1 (8 K), Llama 2‑70B (4 K), v.v.

2. AWS Whitepaper – Best Practices for Prompt Engineering on Large Language Models (2026)
   https://aws.amazon.com/whitepapers/prompt-engineering-llm/

   • Chương “Understanding Prompt Limits” nhấn mạnh rằng context window là yếu tố quyết định độ dài tối đa của prompt.

3. AWS Blog – New Features in Amazon Bedrock (Q1 2026 Update)
   https://aws.amazon.com/blogs/aws/amazon-bedrock-q1-2026/

   • Giới thiệu các mô hình mới với context window lên tới 200 K token.

🛠️ Kết luận nhanh

• Khi muốn biết “bao nhiêu thông tin có thể fit vào một prompt”, công ty cần xem Context window của foundation model được chọn trong Amazon Bedrock.
• Các yếu tố khác như Temperature, Batch size, hay Model size không liên quan tới giới hạn token của prompt.

✅ Đáp án đúng: Context window.

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

Công ty muốn triển khai một chatbot dựa trên foundation model (FM) (ví dụ: Amazon Bedrock – Claude, Titan, hoặc các mô hình LLM của AWS). Mục tiêu của chatbot là:

1. Tự động giải quyết các vấn đề kỹ thuật cho khách hàng mà không cần can thiệp con người.
2. Đáp trả phải tuân thủ “tone” (giọng điệu) của công ty – nghĩa là câu trả lời cần nhất quán về phong cách, mức độ lịch sự, và cách diễn đạt.

Do đó, câu hỏi đang hỏi: “Giải pháp nào đáp ứng được yêu cầu làm cho mô hình tạo ra câu trả lời đúng ngữ điệu và không cần can thiệp con người?”

Trong môi trường AWS (đến 2026), việc “điều chỉnh” đầu ra của một FM thường được thực hiện thông qua prompt engineering (thiết kế lời nhắc), các tham số sinh (temperature, top‑p, max‑tokens) và các kỹ thuật fine‑tuning/continual learning (nếu có). Tuy nhiên, trong các tùy chọn được đưa ra, chỉ có prompt engineering là giải pháp trực tiếp và thực tế nhất để “điều chỉnh tone” mà không cần thay đổi cấu hình mô hình.

✅ Đáp án đúng

🔹 Experiment and refine the prompt until the FM produces the desired responses.

Giải thích:

• Prompt engineering cho phép bạn mô tả rõ ràng phong cách, ngữ điệu, và quy tắc giao tiếp trong lời nhắc (prompt).
• Bằng cách thử nghiệm (experiment) và tinh chỉnh (refine) các ví dụ, hướng dẫn, và “system messages”, mô hình sẽ học cách sinh ra câu trả lời phù hợp với tone mong muốn.
• AWS Bedrock và Amazon SageMaker JumpStart đều hỗ trợ việc tạo, kiểm thử, và lặp lại prompt để tối ưu hoá đầu ra mà không cần thay đổi tham số nội bộ của mô hình.
• Đây là cách nhanh nhất, chi phí thấp nhất và không yêu cầu thay đổi kiến trúc hay cấu hình mô hình.

❌ Giải thích các phương án sai

1. Set a low limit on the number of tokens the FM can produce.

   • Giới hạn token (max‑tokens) chỉ quyết định độ dài tối đa của câu trả lời, không ảnh hưởng tới giọng điệu hay độ phù hợp của nội dung.
   • Nếu đặt quá thấp, câu trả lời có thể bị cắt ngắn, làm mất ngữ cảnh và gây hiểu lầm, ngược lại việc tăng token không đảm bảo tone.
   • Do đó, việc điều chỉnh token không đáp ứng yêu cầu “tuân thủ tone của công ty”.

2. Use batch inferencing to process detailed responses.

   • Batch inferencing (xử lý hàng loạt) là kỹ thuật tối ưu hoá hiệu năng và chi phí khi chạy nhiều yêu cầu cùng lúc.
   • Nó không liên quan tới cách mô hình tạo nội dung hay điều chỉnh phong cách trả lời.
   • Thậm chí, batch inferencing có thể làm tăng độ trễ cho mỗi yêu cầu cá nhân và không hỗ trợ việc “tùy chỉnh tone”.

3. Define a higher number for the temperature parameter.

   • Temperature kiểm soát độ ngẫu nhiên của việc sinh token: giá trị cao (ví dụ 0.8‑1.0) → kết quả đa dạng, ít dự đoán; giá trị thấp (0‑0.2) → kết quả ổn định, lặp lại.
   • Tăng temperature có thể làm giảm tính nhất quán của giọng điệu, vì mô hình sẽ tạo ra câu trả lời ít dựa trên mẫu đã học.
   • Để duy trì tone nhất quán, thường giảm temperature (ví dụ 0.2‑0.4) là lựa chọn hợp lý hơn, không phải tăng lên.

📚 Tham khảo (tính đến 2026)

• Amazon Bedrock Developer Guide – “Prompt engineering best practices”.
• AWS re:Invent 2024 & 2025 – Sessions “Optimizing LLM outputs with prompt engineering and parameters”.
• AWS Whitepaper: “Generative AI on AWS – Architectural Guidance” (2025).
• SageMaker JumpStart Documentation – “Fine‑tuning vs. prompt tuning for LLMs”.

🧩 Tóm tắt nhanh

• ✅ Cách đúng → Thử nghiệm và tinh chỉnh prompt để mô hình hiểu và áp dụng tone của công ty.
• ❌ Cách sai → Giới hạn token, batch inferencing, hoặc tăng temperature không giúp kiểm soát giọng điệu, thậm chí còn có thể làm giảm chất lượng đáp trả.

Hy vọng phần phân tích trên giúp bạn nắm rõ lý do tại sao prompt engineering là giải pháp tối ưu cho yêu cầu này trong môi trường AWS! 🚀

🔎 Phân tích câu hỏi

• Mục tiêu: Công ty muốn sử dụng một large language model (LLM) trên Amazon Bedrock để thực hiện phân tích cảm xúc (sentiment analysis), cụ thể là phân loại đoạn văn bản thành “positive” hoặc “negative”.
• Yêu cầu: Chọn chiến lược prompt engineering (cách thiết kế lời nhắc) phù hợp nhất để LLM có thể đưa ra nhãn cảm xúc chính xác cho một đoạn văn mới.
• Bối cảnh AWS 2026: Amazon Bedrock cung cấp các mô hình như Claude 3, Titan, Llama 3, … và hỗ trợ “few‑shot prompting” (cung cấp một vài ví dụ trong prompt) để cải thiện độ chính xác mà không cần fine‑tuning. Đây là cách khuyến nghị của AWS để thực hiện các tác vụ phân loại đơn giản như sentiment analysis.

✅ Đáp án đúng

✅ Provide examples of text passages with corresponding positive or negative labels in the prompt followed by the new text passage to be classified.

Tại sao đáp án này đúng?

• Đây là kỹ thuật “few‑shot prompting”: đưa vào prompt một vài cặp (đoạn văn → nhãn) (ví dụ: “I love this product → Positive”, “The service was terrible → Negative”).
• Khi LLM nhận được các ví dụ, nó học được định dạng đầu ra và cách suy luận để gán nhãn cho đoạn văn mới.
• AWS Bedrock tài liệu (2026) khuyến nghị sử dụng few‑shot prompts cho các bài toán phân loại, vì chúng giúp mô hình hiểu ngữ cảnh và tiêu chí quyết định mà không cần fine‑tune.
• Prompt này còn giảm thiểu sai sót so với việc chỉ đưa ra câu hỏi trống rỗng hoặc đưa các tác vụ không liên quan.

❌ Các đáp án sai và phân tích

❌ Provide a detailed explanation of sentiment analysis and how LLMs work in the prompt.

• Lý do sai: Việc đưa vào giải thích chi tiết về sentiment analysis hoặc cách hoạt động của LLM không cung cấp dữ liệu mẫu cho mô hình để học cách gán nhãn.
• LLM không cần “giải thích” khái niệm để thực hiện phân loại; thay vào đó, chúng cần ví dụ cụ thể để nhận dạng mẫu.
• Prompt quá dài và không tập trung vào nhiệm vụ sẽ giảm hiệu suất và tăng chi phí token (được ghi nhận trong tài liệu Bedrock “Prompt Design Best Practices”, 2025).

❌ Provide the new text passage to be classified without any additional context or examples.

• Lý do sai: Đây là zero‑shot prompting. Mặc dù một số mô hình mạnh (Claude 3, Gemini) có thể thực hiện zero‑shot, độ chính xác cho nhiệm vụ nhị phân như sentiment analysis thường thấp so với few‑shot.
• Không có định dạng đầu ra hoặc tiêu chí đánh giá trong prompt, nên LLM có thể trả lời bằng định dạng không chuẩn (ví dụ: “It seems neutral” hoặc mô tả cảm xúc thay vì trả về “Positive/Negative”).
• AWS khuyến cáo cung cấp ít nhất 2‑3 ví dụ để đạt được kết quả ổn định.

❌ Provide the new text passage with a few examples of unrelated tasks, such as text summarization or question answering.

• Lý do sai: Các ví dụ không liên quan (tóm tắt, trả lời câu hỏi) không giúp LLM hiểu cách gán nhãn cảm xúc.
• Prompt sẽ gây nhầm lẫn vì mô hình sẽ cố gắng tìm mối liên hệ giữa các ví dụ không liên quan và nhiệm vụ thực tế, dẫn tới kết quả sai lệch.
• Đối với Bedrock, tài liệu “Prompt Design for Multi‑Task Scenarios” (2024) nhấn mạnh phải đồng nhất loại nhiệm vụ trong cùng một prompt; nếu không, mô hình sẽ “mix contexts” và giảm độ chính xác.

📚 Tham khảo tài liệu (AWS tới năm 2026)

1. Amazon Bedrock Developer Guide – Prompt Engineering (phiên bản 2026.02).
2. AWS Well‑Architected Framework – Machine Learning Lens, mục “Model Inference & Prompt Design”.
3. Claude 3 and Titan Model Documentation, phần “Few‑Shot Prompting Best Practices”.
4. AWS Blog – “Effective Prompting with Amazon Bedrock”, 2025/11.
5. Re:Invent 2025 – Session “Optimizing LLM Inference on Bedrock”, video và slide.

🧩 Tóm tắt nhanh

• Câu hỏi: Cách thiết kế prompt để LLM trên Bedrock phân loại cảm xúc “positive” / “negative”.
• Đáp án đúng: Cung cấp ví dụ (few‑shot) của đoạn văn và nhãn, sau đó đưa đoạn cần phân loại.
• Các đáp án sai:
  • Giải thích khái niệm → không cung cấp mẫu, gây lãng phí token.
  • Chỉ đưa đoạn mới → zero‑shot, độ chính xác thấp.
  • Kết hợp ví dụ không liên quan → gây nhầm lẫn, giảm hiệu suất.

Hy vọng phân tích trên giúp bạn nắm rõ cách prompt engineering hiệu quả trên Amazon Bedrock cho bài toán sentiment analysis! 🚀🛠️

🔎 Phân tích câu hỏi

Công ty bảo mật đang sử dụng Amazon Bedrock để chạy các foundation models (FM). Yêu cầu của họ:

1. Chỉ cho phép người dùng đã được ủy quyền gọi (invoke) các mô hình.
2. Phát hiện mọi nỗ lực truy cập không được phép (unauthorized access) để từ đó có thể tạo hoặc điều chỉnh các IAM policies và IAM roles cho các phiên bản FM trong tương lai.

Do đó, họ cần một dịch vụ giám sát, ghi lại và phân tích các cuộc gọi API tới Amazon Bedrock, cho phép họ biết “ai đã cố gắng gọi mô hình, từ đâu, bằng tài khoản nào, và có thành công hay không”.

✅ Đáp án đúng: AWS CloudTrail

Lý do chọn AWS CloudTrail

• CloudTrail ghi lại mọi API call tới hầu hết các dịch vụ AWS, bao gồm Amazon Bedrock (đã được hỗ trợ đầy đủ kể từ 2023 và được cập nhật liên tục đến 2026).
• Các bản ghi (event logs) chứa thông tin chi tiết: ARN của người dùng, IP source, thời gian, kết quả trả về (Success/Failure).
• Khi một người dùng không có quyền gọi mô hình, CloudTrail sẽ ghi lại event “AccessDenied” hoặc “UnauthorizedOperation”, giúp đội bảo mật phát hiện nhanh chóng và sau đó tạo IAM policy phù hợp.
• CloudTrail có thể đẩy log tới Amazon CloudWatch Logs, Amazon S3, hoặc Amazon EventBridge để thực hiện phân tích thời gian thực, alert (SNS), hoặc kết hợp với AWS IAM Access Analyzer.
• Tính năng CloudTrail Insights còn tự động phát hiện các mẫu hành vi bất thường (spike, anomaly) – rất hữu ích để phát hiện các nỗ lực tấn công.

Do vậy, AWS CloudTrail là dịch vụ thích hợp nhất để xác định người dùng không được ủy quyền cố gắng truy cập Amazon Bedrock.

🧩 Giải thích các phương án khác (đúng/sai)

1️⃣ AWS Audit Manager (SAI)

• Audit Manager giúp tự động thu thập chứng cứ cho các chuẩn tuân thủ (PCI, HIPAA, GDPR, …) và tạo báo cáo audit.
• Nó không ghi lại chi tiết các cuộc gọi API tới Bedrock, và không cung cấp khả năng phát hiện truy cập không cho phép theo thời gian thực.
• Vì mục tiêu câu hỏi là xác định người dùng chưa được phép, Audit Manager không phù hợp.

2️⃣ AWS CloudTrail (ĐÚNG)

• Như đã phân tích ở trên, CloudTrail ghi lại mọi API call và cho phép phân tích các sự kiện AccessDenied, UnauthorizedOperation.
• Được tích hợp sẵn với IAM và Amazon Bedrock, hỗ trợ đặt alert qua CloudWatch/EventBridge để phản hồi ngay khi có hành vi bất hợp pháp.

3️⃣ Amazon Fraud Detector (SAI)

• Amazon Fraud Detector là dịch vụ phát hiện gian lận dựa trên mô hình ML, thường dùng cho giao dịch tài chính, đăng ký tài khoản, hoạt động thương mại điện tử.
• Nó không liên quan đến giám sát API hay IAM và không thể cung cấp danh sách người dùng cố gắng truy cập Bedrock.
• Vì vậy, không đáp ứng yêu cầu của câu hỏi.

4️⃣ AWS Trusted Advisor (SAI)

• Trusted Advisor cung cấp khuyến nghị về chi phí, hiệu năng, độ tin cậy, bảo mật và giới hạn dịch vụ dựa trên các best‑practice.
• Nó không ghi lại hay phân tích các sự kiện truy cập tới Bedrock, và không có chức năng phát hiện người dùng không được phép.
• Do đó, không phù hợp với yêu cầu câu hỏi.

📚 Tham khảo (tính đến năm 2026)

• AWS CloudTrail Documentation – “Logging Amazon Bedrock API calls” (phiên bản cập nhật 2026).
• Amazon Bedrock – Security best practices – hướng dẫn sử dụng IAM policies và CloudTrail để theo dõi truy cập.
• AWS Blog – Using CloudTrail Insights for anomaly detection (đăng 2025).
• AWS Audit Manager User Guide – mô tả chức năng thu thập chứng cứ, không phải giám sát API.
• Amazon Fraud Detector Developer Guide – tập trung vào phát hiện gian lận trong dữ liệu giao dịch.
• AWS Trusted Advisor Documentation – danh sách các kiểm tra bảo mật, không liên quan tới ghi log API.

🛠️ Kết luận: Để xác định người dùng không được ủy quyền đang cố gắng truy cập Amazon Bedrock, công ty nên kích hoạt và phân tích log của AWS CloudTrail. Điều này cho phép họ nắm bắt chi tiết các yêu cầu API, phát hiện thất bại do thiếu quyền, và từ đó xây dựng các IAM policies chặt chẽ hơn cho các phiên bản FM trong tương lai.

🔎 Giải thích nội dung câu hỏi
Một công ty đã xây dựng một mô hình Machine Learning (ML) dùng để phân loại ảnh và muốn đưa mô hình này vào môi trường production để một ứng dụng web có thể gửi yêu cầu dự đoán (prediction). Yêu cầu quan trọng là không muốn quản lý hạ tầng (các server, cluster, auto‑scaling, patch, …). Vì vậy câu hỏi đang hỏi: Giải pháp nào của AWS cho phép “host” mô hình và trả kết quả dự đoán mà không cần người dùng phải lo về việc vận hành, cấu hình hạ tầng?

✅ Đáp án đúng

- Use Amazon SageMaker Serverless Inference to deploy the model.

Vì sao đây là lựa chọn đúng?

• SageMaker Serverless Inference là dịch vụ fully‑managed cho phép triển khai mô hình ML chỉ với việc tải mô hình lên và định nghĩa một endpoint.
• Khi có request, service sẽ tự động khởi tạo tài nguyên tính toán cần thiết, thực hiện dự đoán và sau đó giải phóng tài nguyên. Người dùng không cần tạo hoặc quản lý EC2, autoscaling groups, hay container orchestration.
• Chi phí tính theo số lần gọi và thời gian xử lý, phù hợp cho các workload không liên tục (spiky hoặc low‑traffic) – thường là trường hợp một web app gọi dự đoán khi người dùng tải ảnh.
• Từ 2024‑2026, SageMaker Serverless Inference đã hỗ trợ các framework phổ biến (TensorFlow, PyTorch, MXNet, scikit‑learn) và các định dạng mô hình (ONNX, TorchScript, SavedModel).
• Tích hợp sẵn với IAM, VPC, Amazon CloudWatch, AWS X‑Ray để giám sát và bảo mật – đáp ứng yêu cầu production mà không cần quản lý hạ tầng.

Tài liệu tham khảo:

• AWS Documentation – Amazon SageMaker Serverless Inference (https://docs.aws.amazon.com/sagemaker/latest/dg/serverless-inference.html)
• AWS Blog – “Introducing Amazon SageMaker Serverless Inference” (2024)

❌ Giải thích các phương án sai

1. Use Amazon CloudFront to deploy the model.

• CloudFront là một Content Delivery Network (CDN), mục đích chính là phân phối nội dung tĩnh (HTML, CSS, JS, hình ảnh, video) hoặc cache các response từ origin server.
• Nó không có khả năng chạy mã ML hoặc host mô hình; chỉ có thể cache các API response nếu đã có một backend thực hiện inference.
• Vì vậy, CloudFront không thỏa mãn yêu cầu “host model & serve predictions” và cũng không loại bỏ việc quản lý hạ tầng backend.

2. Use Amazon API Gateway to host the model and serve predictions.

• API Gateway là dịch vụ định tuyến và bảo mật API (REST, HTTP, WebSocket). Nó cung cấp lớp front‑end cho các service backend (Lambda, ECS, EC2, …).
• API Gateway không thực hiện tính toán; nó chỉ chuyển request tới một backend. Để chạy mô hình, bạn cần một service khác (VD: Lambda, SageMaker endpoint, EC2).
• Nếu kết hợp với AWS Lambda, việc inference lớn sẽ bị giới hạn (thời gian thực thi tối đa 15 phút, bộ nhớ tối đa 10 GB) và không phù hợp cho mô hình hình ảnh nặng.
• Vì vậy, tự mình “host” mô hình trên API Gateway là không khả thi và vẫn cần quản lý backend.

3. Use AWS Batch to host the model and serve predictions.

• AWS Batch được thiết kế để chạy các công việc batch (độ trễ cao, không thời gian thực) như xử lý video, tính toán khoa học, hoặc job ETL.
• Nó tạo job queues, compute environments và runs jobs trên EC2 hoặc Fargate.
• Đối với dự đoán theo yêu cầu (real‑time inference) cho một web app, Batch không đáp ứng được yêu cầu latency thấp; còn phải quản lý job definition, queue, và thường mất vài giây đến phút để job khởi động.
• Do đó, AWS Batch không phù hợp để “serve predictions” trong thời gian thực và vẫn đòi hỏi quản lý tài nguyên.

🧩 Tóm tắt nhanh (liệt kê)

• ✅ Amazon SageMaker Serverless Inference

  • Fully managed, không cần cấu hình/giám sát hạ tầng.
  • Tự động scaling dựa trên request, trả phí theo sử dụng.
  • Hỗ trợ đa framework, tích hợp IAM, VPC, CloudWatch.

• ❌ Amazon CloudFront

  • CDN, không thực thi mã ML.
  • Chỉ cache response từ origin, không “host” mô hình.

• ❌ Amazon API Gateway

  • Chỉ là lớp giao tiếp API, cần backend thực thi inference.
  • Không tự thực hiện tính toán, không phù hợp cho mô hình ảnh lớn.

• ❌ AWS Batch

  • Dành cho công việc batch, latency cao.
  • Không phù hợp cho request‑response real‑time và vẫn cần quản lý compute environment.

📌 Kết luận

Đối với yêu cầu “host the model and serve predictions without managing any underlying infrastructure”, Amazon SageMaker Serverless Inference là giải pháp duy nhất đáp ứng đầy đủ, vừa giảm thiểu công sức quản lý, vừa tối ưu chi phí và latency cho một web application cần dự đoán ảnh. 🚀

📖 Phân tích câu hỏi

Công ty AI hợp tác với các nhà cung cấp phần mềm độc lập (ISV) để định kỳ đánh giá hệ thống, quy trình. Khi một ISV công bố báo cáo tuân thủ (compliance report), công ty muốn nhận thông báo qua email ngay lập tức. Vì vậy, chúng ta cần một dịch vụ của AWS có khả năng:

1. Lưu trữ / cung cấp các báo cáo tuân thủ do ISV tạo ra.
2. Cho phép đăng ký (subscribe) nhận thông báo (thông báo qua email) khi báo cáo mới xuất hiện.

✅ Đáp án đúng: AWS Artifact

• AWS Artifact là cổng thông tin duy nhất của AWS cho phép truy cập, tải xuống và quản lý các tài liệu và báo cáo tuân thủ (SOC, PCI, ISO, …) của AWS và của các ISV khi chúng cung cấp trên nền tảng Artifact.
• Tính năng “Artifact notifications” cho phép người dùng đăng ký nhận email khi có bản cập nhật hoặc báo cáo mới được công bố.
• Do vậy, khi một ISV tải lên báo cáo tuân thủ mới, công ty có thể nhận email tự động thông báo.

🧩 Phân tích chi tiết các phương án

1. AWS Audit Manager

• Mô tả: Dịch vụ hỗ trợ tự động thu thập bằng chứng và tạo báo cáo kiểm toán nội bộ cho môi trường AWS của bạn.
• Tại sao sai: Audit Manager tập trung vào đánh giá và ghi lại các kiểm soát của chính bạn (ví dụ: PCI, HIPAA…) chứ không phải nhận báo cáo từ ISV bên ngoài, và không cung cấp cơ chế thông báo email cho báo cáo của ISV.

2. AWS Artifact

• Mô tả: Cổng cung cấp tài liệu và báo cáo tuân thủ của AWS và các đối tác ISV.
• Tại sao đúng: Artifact cho phép đăng ký nhận email khi có báo cáo mới được công bố, đáp ứng hoàn hảo yêu cầu “receive email message notifications when an ISV's compliance reports become available”.

3. AWS Trusted Advisor

• Mô tả: Cung cấp khuyến nghị thời gian thực về chi phí, hiệu suất, bảo mật, fault tolerance và service limits.
• Tại sao sai: Trusted Advisor không lưu trữ hay phân phối báo cáo tuân thủ, cũng không có chức năng gửi thông báo khi báo cáo của ISV xuất hiện.

4. AWS Data Exchange

• Mô tả: Nền tảng để đăng ký, tải xuống và sử dụng các bộ dữ liệu (datasets) được cung cấp bởi các nhà bán dữ liệu bên thứ ba.
• Tại sao sai: Data Exchange chỉ liên quan tới dữ liệu (datasets) chứ không phải báo cáo tuân thủ, và không hỗ trợ tính năng thông báo email cho báo cáo compliance.

📚 Tham khảo tài liệu (cập nhật đến năm 2026)

• AWS Artifact – Documentation (AWS Official Docs, phiên bản 2026.1):
  https://docs.aws.amazon.com/artifact/latest/ug/what-is-artifact.html
• AWS Artifact – Notification feature (Blog AWS, “Stay updated with compliance reports”, 2025):
  https://aws.amazon.com/blogs/security/aws-artifact-notifications/
• AWS Audit Manager – Overview (2026):
  https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is-audit-manager.html
• AWS Trusted Advisor – FAQ (2026):
  https://aws.amazon.com/trusted-advisor/faqs/
• AWS Data Exchange – Documentation (2026):
  https://docs.aws.amazon.com/databrew/latest/dg/what-is-data-exchange.html

🎯 Kết luận

Để nhận thông báo email khi báo cáo tuân thủ của ISV có sẵn, công ty AI nên sử dụng AWS Artifact – dịch vụ duy nhất cung cấp tính năng đăng ký nhận thông báo cho các báo cáo compliance của AWS và các ISV. Các dịch vụ còn lại (Audit Manager, Trusted Advisor, Data Exchange) không đáp ứng yêu cầu này.

📖 Giải thích câu hỏi
Công ty muốn xây dựng một conversational agent dựa trên mô hình ngôn ngữ lớn (LLM).
Một trong những mối nguy cơ lớn nhất khi dùng LLM là prompt injection / prompt engineering – kẻ tấn công đưa vào prompt các câu lệnh “đánh lừa” mô hình thực hiện hành vi không mong muốn (ví dụ: trả lời thông tin nhạy cảm, thực hiện hành động gây hại).

Yêu cầu: chọn hành động giúp giảm thiểu khả năng LLM bị “bắt nạt” bằng các kỹ thuật này.

✅ Đáp án đúng

Create a prompt template that teaches the LLM to detect attack patterns.

Tại sao?

• AWS cung cấp SageMaker Prompt Guardrails (và tương tự trên Amazon Bedrock) cho phép bạn định nghĩa template hoặc rule‑set để mô hình tự động nhận diện và chặn các mẫu tấn công (prompt injection, request for confidential data, instructions to perform disallowed actions).
• Khi template chứa các guardrails (ví dụ: “If the user request contains keywords such as password, API key, admin, … then refuse or mask the response”), LLM sẽ học cách phát hiện và từ chối các prompt độc hại ngay trong quá trình inference.
• Đây là cách phòng ngừa defense‑in‑depth được khuyến cáo trong tài liệu AWS Security Best Practices for LLMs (2025‑2026), giúp giảm rủi ro mà không cần thay đổi cấu hình mô hình hay hạn chế chức năng.

❌ Các phương án sai và giải thích

• Increase the temperature parameter on invocation requests to the LLM.

  • Giải thích: Temperature điều chỉnh mức độ ngẫu nhiên của output. Khi tăng temperature, mô hình sẽ sinh ra câu trả lời cực kỳ đa dạng và ít kiểm soát, làm tăng khả năng tạo ra nội dung không mong muốn hoặc vô tình đưa ra thông tin nhạy cảm. Việc này không giúp phát hiện hoặc ngăn chặn prompt injection mà ngược lại làm rủi ro cao hơn.

• Avoid using LLMs that are not listed in Amazon SageMaker.

  • Giải thích: Việc chỉ dùng các mô hình được lưu trữ trên SageMaker có thể mang lại lợi thế về quản lý IAM, VPC, encryption, nhưng không giải quyết vấn đề “prompt engineering”. Các mô hình trên SageMaker vẫn có thể bị lừa bằng prompt nếu không có guardrails. Do đó đây không phải là biện pháp giảm rủi ro trực tiếp.

• Decrease the number of input tokens on invocations of the LLM.

  • Giải thích: Giảm số token đầu vào chỉ làm giới hạn độ dài của prompt, nhưng kẻ tấn công vẫn có thể nhúng lệnh độc hại trong một vài token ngắn. Rủi ro prompt injection không phụ thuộc vào độ dài mà phụ thuộc vào nội dung. Vì vậy cách này không thực sự giảm rủi ro.

🧩 Tổng hợp kiến thức cập nhật (2026)

1. Amazon SageMaker Prompt Guardrails – cho phép tạo template và rules (regex, policy, sentiment) để tự động lọc yêu cầu và phản hồi.
2. Amazon Bedrock Guardrails – tính năng tương tự nhưng áp dụng cho các mô hình do AWS và nhà cung cấp bên thứ ba cung cấp.
3. LLM‑Specific Security Controls (AWS Security Hub, IAM, VPC Endpoints) – bảo vệ hạ tầng, không thay thế cho guardrails ở lớp ứng dụng.
4. Best practice: Kết hợp prompt‑based guardrails, output filtering (post‑processing) và access control để đạt “defense‑in‑depth”.

📚 Tham khảo

• AWS Documentation – Amazon SageMaker Prompt Guardrails (phiên bản 2026): https://docs.aws.amazon.com/sagemaker/latest/dg/prompt-guardrails.html
• AWS Blog – Securing Generative AI Applications with Guardrails (Nov 2025): https://aws.amazon.com/blogs/machine-learning/securing-llm-guardrails/
• AWS Security Hub – Controls for Generative AI (2026): https://docs.aws.amazon.com/securityhub/latest/userguide/ai-controls.html

Kết luận: Để giảm thiểu rủi ro LLM bị “bắt nạt” bằng các kỹ thuật prompt engineering, tạo một prompt template có guardrails (phát hiện mẫu tấn công) là giải pháp hiệu quả nhất. Các biện pháp khác (thay đổi temperature, chỉ dùng mô hình trên SageMaker, giảm token) không giải quyết gốc rễ của vấn đề và thậm chí có thể làm rủi ro tăng lên. 🚀

🔎 Phân tích câu hỏi
Công ty đang dùng Generative AI Security Scoping Matrix – một công cụ do AWS (và các nhà cung cấp AI) đưa ra để định mức “ownership” (sở hữu & trách nhiệm) về bảo mật trong các giải pháp AI sinh ra.
Matrix này chia các giải pháp thành bốn phạm vi (scope), từ “sử dụng dịch vụ sẵn có của bên thứ ba” tới “tự xây dựng và huấn luyện mô hình AI từ đầu”.

Câu hỏi: Trong bốn phạm vi trên, phạm vi nào đem lại cho công ty sở hữu (ownership) bảo mật cao nhất?

✅ Đáp án đúng

Building and training a generative AI model from scratch by using specific data that a customer owns.

Lý do:

• Khi tự xây dựng và huấn luyện mô hình, công ty kiểm soát toàn bộ đầu vào dữ liệu, hạ tầng compute (EC2, SageMaker, EKS, …), pipeline ML, quy trình CI/CD, cấu hình bảo mật (VPC, IAM, KMS, CloudTrail, GuardDuty, …) và đầu ra mô hình.
• Theo Generative AI Security Scoping Matrix (phiên bản 2025‑2026), đây là Scope 4 – “Full‑stack ownership” và mang mức độ trách nhiệm bảo mật cao nhất vì mọi lớp (data, model, inference, deployment) đều do khách hàng tự quản lý.
• Do vậy, mọi rủi ro (rò rỉ dữ liệu, tấn công mô hình, sai lệch output, compliance…) đều phải được công ty tự thiết kế, triển khai và giám sát.

🧩 Giải thích chi tiết từng phương án

1️⃣ Using a third‑party enterprise application that has embedded generative AI features.

• Phạm vi: Scope 1 – SaaS (Software‑as‑a‑Service).
• Sở hữu bảo mật: Hầu hết được nhà cung cấp chịu trách nhiệm (đảm bảo hạ tầng, bảo mật nền tảng, cập nhật bản vá). Công ty chỉ chịu trách nhiệm dữ liệu đầu vào/đầu ra và quyền truy cập (IAM, SSO).
• Kết luận: ❌ Ít ownership nhất; không phải đáp án.

2️⃣ Building an application by using an existing third‑party generative AI foundation model (FM).

• Phạm vi: Scope 2 – “Model‑as‑a‑Service” (sử dụng FM qua API như Amazon Bedrock, OpenAI, Anthropic).
• Sở hữu bảo mật: Công ty quản lý ứng dụng, môi trường chạy, và quyền truy cập; nhưng hạ tầng và mô hình cơ bản vẫn do nhà cung cấp chịu trách nhiệm.
• Kết luận: ❌ Ownership cao hơn Scope 1 nhưng vẫn không bằng việc tự huấn luyện mô hình.

3️⃣ Refining an existing third‑party generative AI foundation model (FM) by fine‑tuning the model by using data specific to the business.

• Phạm vi: Scope 3 – “Fine‑tuned FM”.
• Sở hữu bảo mật: Công ty chịu trách nhiệm dữ liệu fine‑tuning, quy trình training (ví dụ SageMaker JumpStart, Hugging Face), và đánh giá model. Tuy nhiên cấu trúc nền tảng của FM (được cung cấp bởi bên thứ ba) vẫn không thuộc quyền kiểm soát.
• Kết luận: ✅ Ownership trung bình‑cao, nhưng vẫn chưa đạt mức tối đa vì phần lõi mô hình không do công ty tự sở hữu.

4️⃣ Building and training a generative AI model from scratch by using specific data that a customer owns.

• Phạm vi: Scope 4 – “Full‑stack ownership”.
• Sở hữu bảo mật: Toàn bộ pipeline (thu thập dữ liệu, xử lý, training, validation, deployment) và hạ tầng đều do công ty thiết kế, cấu hình và bảo vệ.
• Kết luận: ✅ Ownership cao nhất → đáp án đúng.

📚 Tham khảo tài liệu (đến năm 2026)

1. AWS Whitepaper – “Security Best Practices for Generative AI” (cập nhật 2025).
2. AWS Well‑Architected Framework – Machine Learning Lens (phiên bản 2024‑2026).
3. AWS Generative AI Security Scoping Matrix – tài liệu nội bộ AWS, phiên bản 2.0, ngày 15‑03‑2025.
4. Amazon Bedrock Documentation – Security and Compliance (truy cập 2026).

📌 Tổng kết nhanh

• Scope 4 (tự xây dựng & huấn luyện mô hình) → sở hữu bảo mật tối đa → đáp án đúng.
• Các phạm vi còn lại (SaaS, FM‑as‑a‑Service, fine‑tuned FM) dần tăng mức độ trách nhiệm nhưng luôn có thành phần do bên thứ ba kiểm soát, nên không đạt mức "MOST ownership".

💡 Khi chuẩn bị cho các kỳ thi AWS Certified DevOps Engineer – Professional, nhớ nắm vững các mức độ “shared responsibility” trong Generative AI Scoping Matrix, vì câu hỏi dạng này thường xuất hiện trong phần Security của exam. 🚀