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

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

Câu hỏi tập trung vào việc thiết kế giải pháp lưu trữ và truy xuất dữ liệu cho thư mục nhân viên nội bộ khi di chuyển ứng dụng legacy sang AWS. Cụ thể:

• Yêu cầu chính: Lưu trữ chi tiết liên lạc nhân viên (như tên, email, số điện thoại) và ảnh high-resolution (ảnh chất lượng cao, thường có kích thước lớn).
• Mục tiêu: Hỗ trợ tìm kiếm (search) và truy xuất (retrieval) thông tin từng nhân viên cá nhân bằng AWS APIs (như API của DynamoDB hoặc S3).
• Ngữ cảnh: Sử dụng native AWS services để rewrite ứng dụng, đảm bảo hiệu suất cao, scalable, và chi phí tối ưu cho dữ liệu không cấu trúc (photos) và dữ liệu có cấu trúc (contact details).
• Thách thức: Ảnh high-res cần lưu trữ object storage (không phải database thông thường vì kích thước lớn), trong khi contact info cần index nhanh cho search (NoSQL phù hợp hơn SQL).

Giải pháp phải kết hợp lưu trữ metadata/contact trong database hỗ trợ query nhanh + tham chiếu đến ảnh ở object storage, sử dụng AWS APIs như GetItem, Query cho DynamoDB và GetObject cho S3.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Store each employee's contact information in an Amazon DynamoDB table along with the object keys for the photos stored in Amazon S3.

Lý do 🛠️:

• DynamoDB (NoSQL database) lý tưởng cho search nhanh theo employee ID (partition key) hoặc attributes khác (GSI/LSI), lưu contact info + S3 object keys (như s3://bucket/employee123/photo.jpg).
• S3 chuyên lưu binary large objects như ảnh high-res (hỗ trợ unlimited scale, low cost, durable 99.999999999%).
• Quy trình truy xuất: AWS API gọi Query DynamoDB lấy contact + key → GetObject S3 lấy ảnh → hoàn hảo cho app.
• Ưu điểm: Serverless, auto-scale, tích hợp IAM cho security. Phù hợp best practice AWS Well-Architected Framework (Reliability & Performance pillars) đến 2026.
• Chi phí: DynamoDB RCU/WCU + S3 storage cheap cho photos.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên tính khả thi, hiệu suất và phù hợp AWS APIs (cập nhật 2026).

• ❌ [SAI] Encode each employee's contact information and photos using Base64. Store the information in an Amazon DynamoDB table using a sort key.
  Lý do sai: Base64 encoding làm phồng dữ liệu (tăng 33% kích thước), ảnh high-res (MBs) sẽ vượt DynamoDB item limit 400KB → lỗi. Không hiệu quả cho search/retrieve binary data (DynamoDB không tối ưu blob storage). Sort key chỉ hỗ trợ query range, không giải quyết vấn đề core. Vi phạm best practice "offload blobs to S3".

• ✅ [ĐÚNG] Store each employee's contact information in an Amazon DynamoDB table along with the object keys for the photos stored in Amazon S3.
  Lý do đúng: Như đã giải thích ở trên. Kết hợp hoàn hảo: DynamoDB cho metadata/search (API: Query/Scan), S3 cho photos (API: GetObject). Scalable, low-latency (<10ms), hỗ trợ Global Tables/ S3 Intelligent-Tiering (2026 updates). Đây là pattern chuẩn AWS cho directory apps (ví dụ: employee portals).

• ❌ [SAI] Use Amazon Cognito user pools to implement the employee directory in a fully managed software-as-a-service (SaaS) method.
  Lý do sai: Cognito User Pools dành cho authentication/authorization (login, MFA), KHÔNG phải storage/search directory. Attributes hạn chế (max 200 custom), không lưu photos high-res hoặc query phức tạp. Không phải "SaaS method" cho directory (Cognito là managed identity service, không thay thế database). Sử dụng sai sẽ phức tạp hóa app.

• ❌ [SAI] Store employee contact information in an Amazon RDS DB instance with the photos stored in Amazon Elastic File System (Amazon EFS).
  Lý do sai: RDS (SQL như MySQL/PostgreSQL) KHÔNG tối ưu cho high-scale search so với DynamoDB (provisioned capacity, vertical scale limit). EFS là file system NFS cho EC2 shared storage, KHÔNG hỗ trợ AWS APIs trực tiếp cho object retrieval như S3 (GetObject). Photos ở EFS kém durable/costly cho static assets, không scalable cho web apps (latency cao). Vi phạm "use purpose-built services".

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• DynamoDB Developer Guide: docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html – Patterns cho hybrid storage với S3.
• S3 User Guide: docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html – Object storage cho media.
• AWS Well-Architected Framework: aws.amazon.com/architecture/well-architected – Reliability pillar khuyến nghị DynamoDB + S3.
• DOP-C02 Exam Guide (2026): Employee directory patterns trong "Design for Storage" domain.

Giải pháp này đảm bảo 0 downtime migration và future-proof cho app scale! 🚀

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

Câu hỏi mô tả một ứng dụng web/mobile cho phép hàng chục nghìn người dùng (tens of thousands of users) lưu trữ ảnh từ điện thoại lên cloud AWS. Ứng dụng sử dụng Amazon API Gateway REST API kết nối với AWS Lambda để xử lý ảnh, và Amazon DynamoDB lưu metadata (chi tiết ảnh).

📋 Yêu cầu chính của ứng dụng:

• Người dùng phải tạo tài khoản (sign-up) để truy cập.
• Hỗ trợ upload ảnh (kích thước 300 KB đến 5 MB) và retrieve ảnh đã upload.
• Giải pháp phải có LEAST operational overhead (chi phí vận hành thấp nhất, nghĩa là sử dụng các dịch vụ managed, ít tự quản lý code/custom logic).

🛠️ Thách thức kỹ thuật:

• Authentication & Authorization: Cần cơ chế xác thực user an toàn, scalable cho hàng nghìn user.
• Lưu trữ ảnh: Ảnh là binary data lớn → Không phù hợp lưu trực tiếp vào DynamoDB (giới hạn 400KB/item). Nên dùng Amazon S3 (optimized cho object storage).
• Integration: API Gateway + Lambda xử lý request, nhưng Lambda có giới hạn payload (6MB sync invocation), nên tốt nhất generate presigned URL cho S3 upload trực tiếp (dù option không chi tiết, nhưng S3 là best practice).
• Least overhead: Ưu tiên dịch vụ fully managed như Cognito thay vì tự build auth system.

⚡ Kiến thức AWS cập nhật 2026: API Gateway hỗ trợ Cognito authorizer native (không cần Lambda custom). S3 bucket versioning/policy tự động scale. DynamoDB global tables cho multi-region nếu cần. (Không thay đổi core từ 2023-2026).

✅ Đáp án đúng: Phương án thứ 2

Use Amazon Cognito user pools to manage user accounts. Create an Amazon Cognito user pool authorizer in API Gateway to control access to the API. Use the Lambda function to store the photos in Amazon S3. Store the object's S3 key as part of the photo details in the DynamoDB table. Retrieve previously uploaded photos by querying DynamoDB for the S3 key.

Lý do chọn đáp án đúng 🏆:

• Cognito User Pools là dịch vụ fully managed của AWS để quản lý user directory, sign-up/sign-in (email/password/MFA/social), JWT tokens → Zero operational overhead cho auth (không cần tự host database users).
• Cognito Authorizer tích hợp native với API Gateway (Lambda@Edge không cần), validate JWT tự động → Secure, scalable cho hàng nghìn user.
• Lưu ảnh vào S3: Hoàn hảo cho object 300KB-5MB (S3 scale vô hạn, cheap, durable 99.999999999%). Lambda chỉ lưu S3 key (e.g., user-id/photo-uuid.jpg) vào DynamoDB metadata → Query DynamoDB lấy key → Generate presigned URL serve ảnh.
• Least overhead: Toàn bộ managed services (Cognito + S3 + DynamoDB), Lambda chỉ logic business. Không custom auth code.

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

• Phương án 1 [SAI]:
  Use Amazon Cognito user pools to manage user accounts. Create an Amazon Cognito user pool authorizer in API Gateway to control access to the API. Use the Lambda function to store the photos and details in the DynamoDB table. Retrieve previously uploaded photos directly from the DynamoDB table.
  ❌ Sai vì: DynamoDB không phù hợp lưu binary data lớn (max 400KB/item, ảnh lên 5MB → exceed limit, tốn RCU/WCU cao, không efficient). Overhead tăng do base64 encode/decode trong Lambda. Best practice: Metadata ở DynamoDB, object ở S3.

• Phương án 2 [ĐÚNG]:
  Use Amazon Cognito user pools to manage user accounts. Create an Amazon Cognito user pool authorizer in API Gateway to control access to the API. Use the Lambda function to store the photos in Amazon S3. Store the object's S3 key as part of the photo details in the DynamoDB table. Retrieve previously uploaded photos by querying DynamoDB for the S3 key.
  ✅ Đúng vì: Như giải thích trên – Fully managed auth (Cognito) + S3 cho storage + DynamoDB metadata → Scalable, low-cost, least overhead.

• Phương án 3 [SAI]:
  Create an IAM user for each user of the application during the sign-up process. Use IAM authentication to access the API Gateway API. Use the Lambda function to store the photos in Amazon S3. Store the object's S3 key as part of the photo details in the DynamoDB table. Retrieve previously uploaded photos by querying DynamoDB for the S3 key.
  ❌ Sai vì: Tạo IAM user per application user (hàng nghìn) là anti-pattern, vi phạm AWS best practice (IAM limit 5,000 users/account, khó manage credentials/password rotation). Overhead khổng lồ: Custom code sign-up tạo IAM, không scalable/secure cho end-user.

• Phương án 4 [SAI]:
  Create a users table in DynamoDB. Use the table to manage user accounts. Create a Lambda authorizer that validates user credentials against the users table. Integrate the Lambda authorizer with API Gateway to control access to the API. Use the Lambda function to store the photos in Amazon S3. Store the object's S3 key as par of the photo details in the DynamoDB table. Retrieve previously uploaded photos by querying DynamoDB for the S3 key.
  ❌ Sai vì: Tự build auth system (custom DynamoDB users table + Lambda authorizer) → High operational overhead (manage password hash/salt, sessions, MFA, compliance GDPR/SOC2, scaling). Cognito làm thay hết, rẻ hơn 10x.

📘 Tài liệu tham khảo (AWS Docs cập nhật 2026)

• Cognito User Pools + API Gateway: docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html ✅ Native integration.
• S3 cho media storage: aws.amazon.com/s3/features/ + DynamoDB patterns.
• Least overhead best practices: AWS Well-Architected Framework - Security Pillar (Operational Excellence).
• Exam tip DOP-C02: Cognito là standard cho user auth ở scale.

💡 Khuyến nghị triển khai: Sử dụng S3 presigned URLs từ Lambda cho direct upload (bypass Lambda payload limit). Thêm Cognito triggers cho custom logic nếu cần! 🚀

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

Câu hỏi xoay quanh một ứng dụng microservices trên AWS, nơi công ty nhận đơn hàng từ nhiều đối tác qua Amazon API Gateway tích hợp với một Lambda function chia sẻ (shared Lambda). Mỗi đối tác gọi API tùy chỉnh riêng để kích hoạt Lambda xử lý đơn hàng.
Yêu cầu chính:

• Sau khi Lambda xử lý, notify từng đối tác chỉ về đơn hàng của họ (không lẫn lộn).
• Dễ dàng thêm đối tác mới với ít thay đổi code nhất.
• Giải pháp phải scalable nhất (mở rộng dễ dàng, chi phí thấp, không phụ thuộc vào số lượng đối tác).
  Vấn đề cốt lõi là tách biệt thông báo (notification) cho từng đối tác mà không cần tạo nhiều tài nguyên riêng lẻ, tận dụng tính năng SNS message filtering để lọc tin nhắn dựa trên attributes. Đây là best practice cho pub/sub pattern trong microservices, phù hợp với kiến trúc serverless hiện đại trên AWS (cập nhật đến 2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create an Amazon Simple Notification Service (Amazon SNS) topic. Configure the Lambda function to publish messages with specific attributes to the SNS topic. Subscribe each partner to the SNS topic. Apply the appropriate filter policy to the topic subscriptions.

Lý do chọn:
🛠️ Giải pháp này sử dụng một SNS topic duy nhất làm trung tâm pub/sub, Lambda publish message kèm attributes cụ thể (ví dụ: partnerId: "PartnerA"). Mỗi subscription của đối tác áp dụng filter policy (SNS Subscription Filter Policies) để chỉ nhận message khớp attributes của họ.

• Scalable nhất: Thêm partner mới chỉ cần tạo subscription mới + filter policy (không code change ở Lambda hoặc API).
• Ít code change: Lambda chỉ publish một message với attributes, không cần logic riêng cho từng partner.
• Tiết kiệm tài nguyên: Một topic duy nhất, tránh tạo hàng trăm topic/subscription riêng lẻ.
  Đây là pattern chuẩn AWS Well-Architected Framework cho event-driven architecture (Reliability & Operational Excellence pillars).

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

Dưới đây là phân tích tất cả các phương án (giữ nguyên văn bản gốc). Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm lý do cụ thể dựa trên yêu cầu scalability và ít code change.

• Create a different Amazon Simple Notification Service (Amazon SNS) topic for each partner. Configure the Lambda function to publish messages for each partner to the partner's SNS topic.
  ❌ Sai: Tạo topic riêng cho từng partner yêu cầu code Lambda phải biết tất cả topic ARN và publish riêng lẻ (switch-case logic dựa trên partner). Khi thêm partner mới, phải update code Lambda (deploy lại), vi phạm "fewest code changes". Không scalable vì số topic tăng tuyến tính với partner, tăng chi phí quản lý (AWS SNS có limit 100,000 topics/account).

• Create a different Lambda function for each partner. Configure the Lambda function to notify each partner's service endpoint directly.
  ❌ Sai: Tạo Lambda riêng cho từng partner vi phạm nguyên tắc "shared Lambda" hiện tại, đòi hỏi tái kiến trúc toàn bộ API Gateway (tạo integration riêng). Thêm partner mới cần code/deploy Lambda mới + endpoint config. Không scalable (cold starts tăng, chi phí Lambda nhân lên), và phức tạp bảo trì.

• Create an Amazon Simple Notification Service (Amazon SNS) topic. Configure the Lambda function to publish messages with specific attributes to the SNS topic. Subscribe each partner to the SNS topic. Apply the appropriate filter policy to the topic subscriptions.
  ✅ Đúng: Như giải thích ở trên. Sử dụng SNS filtering (hỗ trợ JSON policy phức tạp, cập nhật 2023-2026 với improved attribute matching). Lambda chỉ publish một message với attributes (e.g., {"partner": ["PartnerA"]}), filter tự động route. Scalable vô hạn (SNS hỗ trợ 100M+ publishes/day), thêm partner chỉ CLI/API call tạo subscription.

• Create one Amazon Simple Notification Service (Amazon SNS) topic. Subscribe all partners to the SNS topic.
  ❌ Sai: Một topic + subscribe tất cả sẽ khiến mọi partner nhận tất cả message (không filter), vi phạm "each partner must receive updates for only the partner's own orders". Phải xử lý filter ở client-side (tăng latency, code phức tạp ở partner), không scalable và không an toàn dữ liệu.

📘 Tài liệu tham khảo

• AWS SNS Subscription Filter Policies (cập nhật 2026): https://docs.aws.amazon.com/sns/latest/dg/sns-subscription-filter-policies.html – Chi tiết attributes và JSON examples.
• AWS Well-Architected Framework - Serverless: https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html – Pub/sub patterns với SNS.
• API Gateway + Lambda + SNS Best Practices: AWS re:Post và Blogs (e.g., "Event Filtering with SNS" 2024).
• Limits SNS (2026): https://docs.aws.amazon.com/sns/latest/dg/sns_limits.html – Xác nhận scalability.

Giải pháp này đạt 5/5 nguyên tắc AWS Well-Architected! 🚀 Nếu cần demo CDK/Serverless Framework code, hãy hỏi thêm!

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

📘 Nội dung câu hỏi:
Câu hỏi mô tả một công ty tài chính cần lưu trữ hồ sơ khách hàng gốc (chứa thông tin cá nhân PII) trong 10 năm vì lý do pháp lý. Hồ sơ phải immutable (không thay đổi), chỉ một số nhân viên công ty được truy cập PII, và không được chia sẻ với bên thứ ba. Tuy nhiên, công ty cần cung cấp hồ sơ cho tổ chức thứ ba để phân tích thống kê mà không lộ PII.
Developer muốn lưu bản gốc immutable trên Amazon S3, và tùy theo người truy cập, tài liệu trả về nguyên bản hoặc loại bỏ PII. Có sẵn AWS Lambda function tên removePii để loại bỏ PII.
Mục tiêu chính: Đáp ứng yêu cầu PII, chỉ duy trì một bản copy duy nhất của tài liệu (không tạo bản sao mới).
🛠️ Vấn đề cốt lõi: Cần cơ chế transform on-the-fly (chuyển đổi động) khi GET object từ S3, sử dụng Lambda để loại PII mà không lưu bản mới, phù hợp với S3 Object Lambda Access Points (tính năng mới nhất AWS đến 2026).

✅ Đáp án đúng:
Create an S3 Object Lambda access point from the S3 console. Select the removePii function. Use S3 Access Points to access the object without PII.

📌 Lý do chọn đáp án đúng (bằng tiếng Việt):
S3 Object Lambda Access Points là giải pháp lý tưởng của AWS (ra mắt 2021, cập nhật liên tục đến 2026) để chuyển đổi object động khi truy cập qua GET request. Developer tạo Object Lambda Access Point từ console S3, gắn Lambda removePii làm transform function. Khi người dùng (như bên thứ ba) truy cập qua access point này, Lambda tự động chạy, loại bỏ PII và trả về object đã transform mà không lưu bản mới – giữ nguyên một bản gốc immutable. Người nội bộ dùng S3 bucket gốc để lấy bản đầy đủ PII. Điều này tuân thủ quy định (PII chỉ nội bộ), hiệu quả chi phí, và scalable. ✅ Hoàn hảo cho yêu cầu!

🔍 Phân tích tất cả các phương án (đúng/sai)

Dưới đây là phân tích chi tiết từng lựa chọn. Tôi giữ nguyên nội dung phương án gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt. Sử dụng ✅ cho đúng, ❌ cho sai.

• ❌ [SAI] Set up an S3 event notification that invokes the removePii function when an S3 GET request is made. Call Amazon S3 by using a GET request to access the object without PII.
  Giải thích sai: S3 Event Notifications không hỗ trợ trigger trên GET request (chỉ trigger trên PUT, POST, COPY, DELETE, v.v.). Nếu cố thiết lập, Lambda không chạy khi GET, dẫn đến luôn trả bản gốc có PII. Không giải quyết được transform động, vi phạm yêu cầu chỉ một bản copy. ❌ Không khả thi về mặt kỹ thuật.

• ❌ [SAI] Set up an S3 event notification that invokes the removePii function when an S3 PUT request is made. Call Amazon S3 by using a PUT request to access the object without PII.
  Giải thích sai: Event trên PUT chỉ chạy khi upload object mới, tạo bản sao không PII (vi phạm "chỉ một bản copy"). Hơn nữa, dùng PUT để access là sai logic (PUT dùng để lưu, không phải lấy dữ liệu). Không hỗ trợ transform khi truy cập, không phù hợp quy định PII. ❌ Tạo bản sao thừa và sai API.

• ✅ [ĐÚNG] Create an S3 Object Lambda access point from the S3 console. Select the removePii function. Use S3 Access Points to access the object without PII.
  Giải thích đúng: Như đã phân tích ở trên, Object Lambda Access Point gắn Lambda removePii để transform GET request động, trả object không PII cho bên thứ ba qua access point, giữ bản gốc immutable. Nội bộ dùng bucket gốc. Hỗ trợ versioning/immutability (S3 Object Lock), scalable đến 2026. 🛠️ Giải pháp chính thức AWS cho use case này!

• ❌ [SAI] Create an S3 access point from the S3 console. Use the access point name to call the GetObjectLegalHold S3 API function. Pass in the removePii function name to access the object without PII.
  Giải thích sai: S3 Access Point thông thường không transform object (chỉ kiểm soát truy cập/policy). GetObjectLegalHold API chỉ kiểm tra trạng thái legal hold (liên quan Object Lock), không loại PII và không nhận tham số Lambda function. Không thể pass removePii như vậy. ❌ Sai API và tính năng.

📚 Tài liệu tham khảo (AWS docs mới nhất 2026)

• S3 Object Lambda Access Points: docs.aws.amazon.com/AmazonS3/latest/userguide/object-lambda-access-points.html – Hướng dẫn tạo và dùng Lambda transform.
• S3 Event Notifications: docs.aws.amazon.com/AmazonS3/latest/userguide/NotificationHowTo.html – Xác nhận không trigger GET.
• S3 Access Points: docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html – Phân biệt với Object Lambda.
• Exam Topic (DOP-C02): AWS Certified DevOps Engineer Professional – Storage & Security (S3 advanced features).

🛠️ Lời khuyên DevOps: Test Object Lambda với IAM role phù hợp (Lambda cần quyền GetObject từ backing bucket). Scale với Provisioned Concurrency nếu traffic cao! 🚀

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

Câu hỏi tập trung vào việc triển khai AWS Lambda function 📦, nơi developer cần trở về phiên bản cũ nhanh chóng và mượt mà (quickly and seamlessly), đồng thời đạt được mục tiêu với ít overhead vận hành nhất (LEAST operational overhead) 🛡️.

• Bối cảnh chính: AWS Lambda cho phép tạo nhiều phiên bản (versions) của function (qua $LATEST và các version số). Developer muốn cơ chế rollback dễ dàng mà không cần can thiệp thủ công nhiều, tránh downtime hoặc phức tạp.
• Yêu cầu cốt lõi: Giải pháp phải tích hợp native với Lambda, tự động hóa cao, và ít tốn công quản lý so với các cách thủ công hoặc công cụ bên ngoài.
• Kiến thức cập nhật 2026: Theo AWS Lambda (phiên bản mới nhất 2024-2026), tính năng Versions & Aliases là cách chuẩn để quản lý rollback, hỗ trợ traffic shifting và integration với API Gateway, ALB mà không cần tool ngoài. ✅

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Use a function alias with different versions.

Lý do:

• AWS Lambda hỗ trợ tạo versions tự động khi publish (e.g., version 1, 2,...). Alias (biệt danh như "PROD" hoặc "DEV") là con trỏ linh hoạt trỏ đến một version cụ thể 🖱️.
• Để rollback: Chỉ cần update alias để trỏ về version cũ (qua Console, CLI, hoặc SDK) – thao tác tức thì, zero-downtime, không cần redeploy package.
• Least overhead: Native feature, không cần lưu trữ ngoài, pipeline phức tạp, hay tool khác. Hỗ trợ weighted traffic shifting (gradual rollout) từ 2023+. Hoàn hảo cho seamless rollback! 🚀

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tính seamless, operational overhead, và tính tương thích với Lambda.

• Use AWS OpsWorks to perform blue/green deployments.
  ❌ SAI. AWS OpsWorks chủ yếu dành cho EC2/On-prem layers, không native hỗ trợ Lambda (dù có custom recipes). Blue/green deployment yêu cầu setup stack phức tạp, script thủ công cho Lambda → overhead cao, không seamless, không least effort. Lambda có blue/green riêng qua aliases/versions rồi! 🛑

• Use a function alias with different versions.
  ✅ ĐÚNG (như đã giải thích ở trên). Native, nhanh (API call duy nhất), zero-config thêm, hỗ trợ canary/gradual traffic từ 2023. Ít overhead nhất cho Lambda! 🌟

• Maintain deployment packages for older versions in Amazon S3.
  ❌ SAI. Có thể lưu .zip cũ ở S3, rồi manual create/update function từ package đó → overhead lớn (tạo version mới, update ARN, test lại). Không seamless (cần script/CLI lặp lại), dễ lỗi, không tận dụng Lambda versioning native. Phù hợp archive hơn là rollback nhanh. 📦❌

• Use AWS CodePipeline for deployments and rollbacks.
  ❌ SAI. CodePipeline tốt cho CI/CD pipeline với Lambda source/deploy stage, hỗ trợ manual approval/rollback. Nhưng overhead cao: Phải build pipeline đầy đủ (Source → Build → Deploy), config rollback action phức tạp, không "seamless" như alias switch (cần trigger pipeline lại). Lambda aliases đơn giản hơn nhiều! 🔄❌

📘 Tài liệu tham khảo (AWS chính thức, cập nhật 2026)

• AWS Lambda Developer Guide: AWS Lambda Versions & Aliases – Chi tiết versioning, aliases, traffic shifting.
• AWS Well-Architected Framework (DevOps Pillar): Nhấn mạnh Lambda aliases cho low-overhead rollbacks.
• AWS re:Post & Best Practices: Blue/green cho Lambda ưu tiên aliases, không OpsWorks/CodePipeline thuần.
• Console/CLI Example: aws lambda update-alias --function-name myfunc --name PROD --function-version 1 → Instant rollback! ⚡

Giải pháp này giúp developer tối ưu DevOps trên Lambda một cách chuyên nghiệp! 💼 Nếu cần ví dụ code CLI, hỏi thêm nhé! 😊

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

Câu hỏi tập trung vào việc tối ưu hóa hiệu suất (performance) của một hàm AWS Lambda CPU-bound (hàm bị giới hạn bởi tài nguyên CPU, nghĩa là thời gian thực thi chủ yếu bị chậm do CPU phải xử lý nhiều công việc tính toán nặng). Developer muốn hàm trả về response nhanh chóng hơn.

🛠️ Bối cảnh AWS Lambda: Lambda là dịch vụ serverless, tự động scale theo nhu cầu. Tài nguyên CPU không được cấu hình trực tiếp mà tỷ lệ thuận với bộ nhớ (memory) được cấp phát (từ 128 MB đến 10.240 GB). Khi hàm CPU-bound, việc tăng memory sẽ tự động tăng sức mạnh CPU (bao gồm số vCPU ảo), giúp giảm thời gian thực thi invocation. Kiến thức này dựa trên mô hình định giá và scale của Lambda cập nhật đến năm 2026 (không thay đổi cơ bản từ các phiên bản trước, hỗ trợ Arm-based Graviton processors cho hiệu suất cao hơn).

📘 Tài liệu tham khảo:

• AWS Lambda Documentation: Memory and CPU allocation
• AWS re:Post: Best practices for CPU-bound workloads

✅ Đáp án đúng và lý do lựa chọn

Increase the function's memory.
🧩 Lý do: Trong AWS Lambda, CPU power được scale tuyến tính với memory. Hàm CPU-bound sẽ chạy nhanh hơn đáng kể khi tăng memory (ví dụ: từ 512 MB lên 1 GB có thể tăng CPU gấp đôi, giảm thời gian thực thi 50%). Đây là cách hiệu quả nhất để cải thiện latency/response time mà không cần thay đổi code. Theo benchmark AWS, tăng memory có thể cải thiện throughput lên đến 4-6 lần cho workload CPU-intensive.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích bằng tiếng Việt dựa trên cơ chế Lambda mới nhất.

• ❌ Increase the function's CPU core count.
  🛠️ Giải thích sai: AWS Lambda không cho phép cấu hình trực tiếp số core CPU. CPU được tự động phân bổ dựa trên memory (ví dụ: 1.769 GB memory ≈ 1 vCPU). Không có tùy chọn "tăng core count" trong console/CLI/API, nên phương án này không khả thi và không tồn tại.

• ✅ Increase the function's memory.
  🛠️ Giải thích đúng: Như đã nêu ở trên, memory là "đòn bẩy" chính để tăng CPU power. Đối với hàm CPU-bound, tăng memory (qua Console, CLI: aws lambda update-function-configuration --memory-size 1024) sẽ giảm cold start và execution time, cải thiện response nhanh chóng. AWS khuyến nghị benchmark với CloudWatch metrics (Duration, Billed Duration) để xác nhận.

• ❌ Increase the function's reserved concurrency.
  🛠️ Giải thích sai: Reserved concurrency giới hạn số lượng invocation đồng thời (ví dụ: đặt 100 để tránh throttle), giúp kiểm soát scale nhưng không ảnh hưởng đến performance của từng invocation riêng lẻ. Nó chỉ quản lý concurrency toàn hàm, không tăng tốc CPU/memory cho workload CPU-bound.

• ❌ Increase the function's timeout.
  🛠️ Giải thích sai: Timeout (mặc định 3 giây, max 15 phút) chỉ cho phép hàm chạy lâu hơn, tránh lỗi timeout nhưng không làm hàm chạy nhanh hơn. Với hàm CPU-bound chậm, tăng timeout chỉ che giấu vấn đề (có thể tăng chi phí), không cải thiện response time thực tế.

🚀 Lời khuyên bổ sung từ DevOps Engineer

• 🧪 Test thực tế: Sử dụng AWS X-Ray hoặc CloudWatch Insights để đo Duration trước/sau khi tăng memory.
• 💡 Best practices: Sử dụng Provisioned Concurrency cho latency thấp, hoặc migrate sang Arm (Graviton2/Graviton3) để CPU hiệu suất cao hơn 20-30%.
• 📈 Chi phí: Tăng memory tăng billable duration nhưng thường tiết kiệm tổng chi phí nhờ execution nhanh hơn.

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! Nếu cần ví dụ code/config, hãy hỏi thêm nhé! 🌟

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

Câu hỏi tập trung vào AWS CodeDeploy – một dịch vụ tự động hóa triển khai ứng dụng trên AWS. Cụ thể, nó hỏi về thứ tự chạy các lifecycle hooks (các điểm móc tùy chỉnh) trong in-place deployments (triển khai tại chỗ, không sử dụng blue/green).

• In-place deployment là phương thức triển khai trực tiếp lên các instance đang chạy (như EC2), mà không tạo môi trường mới.
• Lifecycle hooks là các sự kiện tùy chỉnh trong file AppSpec.yaml, cho phép chạy script trước/sau các giai đoạn triển khai (ví dụ: dừng app, cài đặt, khởi động lại).
• Các hooks chính bao gồm: ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, và ValidateService (ValidateService chỉ chạy cuối cùng nếu được định nghĩa).
• Thứ tự chạy chuẩn cho in-place (theo tài liệu AWS mới nhất đến 2026): ApplicationStop → BeforeInstall → AfterInstall → ApplicationStart → ValidateService (nếu có).
  • Lý do thứ tự này: Đầu tiên dừng ứng dụng cũ (ApplicationStop), chuẩn bị cài đặt (BeforeInstall), hoàn tất cài đặt (AfterInstall), khởi động ứng dụng mới (ApplicationStart), rồi xác thực (ValidateService).

Câu hỏi yêu cầu xác định đúng thứ tự các hooks này, giúp DevOps Engineer hiểu rõ flow để tránh lỗi triển khai! 🛠️

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: ApplicationStop -> BeforeInstall -> AfterInstall -> ApplicationStart

Lý do:

• Đây chính là thứ tự chuẩn xác của các lifecycle hooks chính trong in-place deployments theo AWS CodeDeploy.
• Flow logic: Dừng app cũ trước (ApplicationStop) để tránh xung đột, chuẩn bị môi trường (BeforeInstall), cài đặt xong (AfterInstall), rồi khởi động app mới (ApplicationStart). ValidateService (nếu có) chạy sau ApplicationStart, nên không nằm trong chuỗi này.
• Không có thay đổi nào đến năm 2026; đây là quy trình cố định từ phiên bản CodeDeploy hiện tại. ✅

📋 Phân tích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn một cách chi tiết. Tôi giữ nguyên nội dung văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji nổi bật:

• ❌ [SAI] BeforeInstall -> ApplicationStop -> ApplicationStart -> AfterInstall
  Phương án này sai hoàn toàn vì đảo ngược thứ tự logic: Không thể chạy BeforeInstall trước khi dừng app cũ (ApplicationStop) – sẽ gây xung đột file/process. AfterInstall phải chạy sau BeforeInstall, không phải cuối cùng. Sai về flow chuẩn AWS.

• ✅ [ĐÚNG] ApplicationStop -> BeforeInstall -> AfterInstall -> ApplicationStart
  Đúng 100% như đã giải thích ở trên. Đây là thứ tự chính xác, khớp docs AWS, đảm bảo triển khai an toàn mà không downtime lớn. Hoàn hảo cho in-place! 🎯

• ❌ [SAI] BeforeInstall -> ApplicationStop -> ValidateService -> ApplicationStart
  Sai cơ bản: Bắt đầu bằng BeforeInstall thay vì ApplicationStop là lỗi lớn (app cũ vẫn chạy sẽ override). ValidateService không chạy giữa chừng mà phải ở cuối (sau ApplicationStart), và thứ tự đảo lộn hoàn toàn so với flow chuẩn.

• ❌ [SAI] ApplicationStop -> BeforeInstall -> ValidateService -> ApplicationStart
  Gần đúng nhưng sai chi tiết: Bắt đầu tốt với ApplicationStop → BeforeInstall, nhưng nhảy sang ValidateService quá sớm (nó phải chạy sau ApplicationStart). Thiếu AfterInstall và đặt ValidateService sai vị trí, dẫn đến triển khai thất bại nếu app chưa start. 🛑

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• AWS CodeDeploy Documentation: Lifecycle event hooks for CodeDeploy – Chi tiết thứ tự hooks cho in-place.
• AWS CodeDeploy Developer Guide: In-place deployment workflow – Minh họa flow với hình ảnh.
• AWS re:Post & Exam Prep: Xác nhận DOP-C02 (DevOps Professional 2023+) vẫn dùng thứ tự này, không thay đổi.
• Kiểm tra thực tế: Tạo deployment test trên EC2 với AppSpec.yaml để verify logs CloudWatch. 🔍

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! Nếu cần ví dụ code AppSpec, hỏi thêm nhé! 🚀

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

Câu hỏi mô tả một ứng dụng serverless trên AWS sử dụng AWS Lambda để xử lý đơn hàng khách hàng 24/7. Lambda gọi HTTP API của nhà cung cấp bên ngoài để xử lý thanh toán. Trong quá trình load test, phát hiện API này thỉnh thoảng timeout và trả lỗi. Công ty chấp nhận một số lỗi xảy ra, nhưng yêu cầu:

• Nhóm support nhận thông báo gần real-time (near real-time) chỉ khi tỷ lệ lỗi (error rate) vượt 5% tổng số giao dịch trong 1 giờ.
• Sử dụng Amazon SNS topic hiện có đã cấu hình để notify support team.
• Giải pháp phải đáp ứng chính xác yêu cầu: theo dõi error rate theo giờ, threshold 5%, notify qua SNS existing, và gần real-time.

🛠️ Yêu cầu cốt lõi: Cần cơ chế giám sát metric-based (dựa trên số liệu), tính toán error rate (lỗi / tổng giao dịch), alarm khi vượt ngưỡng, integrate với SNS. Không phải log-based phức tạp hay notify mọi lỗi.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Publish custom metrics to CloudWatch that record the failures of the external payment processing API calls. Configure a CloudWatch alarm to notify the existing SNS topic when error rate exceeds the specified rate.

Lý do chọn 🏆:

• Lambda dễ dàng publish custom metrics vào Amazon CloudWatch (sử dụng put_metric_data API) để ghi nhận số lần thất bại (failures) và tổng số giao dịch (total transactions).
• CloudWatch Alarms hỗ trợ metric math (tính toán tỷ lệ: failures / total > 5%) trên khoảng thời gian 1 giờ (period 3600s), kích hoạt near real-time (thường trong 1-2 phút).
• Alarm trực tiếp notify SNS topic existing, không cần Lambda scheduler hay service khác.
• Hiệu quả, scalable cho serverless, chi phí thấp. Phù hợp best practice AWS DevOps cho monitoring serverless apps.

📘 Kiến thức cập nhật 2026: CloudWatch hỗ trợ anomaly detection và composite alarms nâng cao, nhưng metric math vẫn là chuẩn cho error rate custom (AWS Well-Architected Framework: Monitoring pillar).

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

• Phương án 1 [SAI]: Write the results of payment processing API calls to Amazon CloudWatch. Use Amazon CloudWatch Logs Insights to query the CloudWatch logs. Schedule the Lambda function to check the CloudWatch logs and notify the existing SNS topic.
  ❌ Sai vì: Logs Insights dùng để query logs (không phải metric real-time), cần Lambda scheduler chạy định kỳ (không near real-time, delay >5-10 phút). Phức tạp, tốn chi phí (logs storage + Lambda invocations), không tính error rate tự động. Không scalable cho 24/7 high-volume.

• Phương án 2 [ĐÚNG]: Publish custom metrics to CloudWatch that record the failures of the external payment processing API calls. Configure a CloudWatch alarm to notify the existing SNS topic when error rate exceeds the specified rate.
  ✅ Đúng vì: Như giải thích trên, custom metrics + alarm với metric math cho error rate chính xác theo giờ, near real-time, integrate trực tiếp SNS. Đơn giản, native AWS, zero thêm resource.

• Phương án 3 [SAI]: Publish the results of the external payment processing API calls to a new Amazon SNS topic. Subscribe the support team members to the new SNS topic.
  ❌ Sai vì: Notify mọi kết quả (success + error) qua SNS mới, không lọc error rate 5%/giờ. Support bị spam (flood notifications), không dùng SNS existing, không tính toán threshold. Vi phạm "only when exceed 5%" và near real-time cho aggregated data.

• Phương án 4 [SAI]: Write the results of the external payment processing API calls to Amazon S3. Schedule an Amazon Athena query to run at regular intervals. Configure Athena to send notifications to the existing SNS topic when the error rate exceeds the specified rate.
  ❌ Sai vì: Athena query S3 logs batch/scheduled (delay 15-60 phút), không near real-time. Cấu hình Athena notify SNS phức tạp (qua Lambda/EventBridge), tốn chi phí (S3 storage + Athena scans). Không phù hợp high-frequency monitoring.

🔗 Tài liệu tham khảo (AWS docs cập nhật 2026)

• 📘 CloudWatch Custom Metrics: docs.aws.amazon.com/lambda/latest/dg/monitoring-metrics.html & CloudWatch Metric Math.
• 📘 CloudWatch Alarms + SNS: docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html.
• 🛠️ AWS Well-Architected: Reliability Pillar (Monitoring serverless): aws.amazon.com/architecture/well-architected.
• ✅ Exam Tips DOP-C02: Serverless monitoring ưu tiên CloudWatch Metrics/Alarms over Logs/Queries (từ AWS re:Post & practice exams 2024-2026).

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

Câu hỏi mô tả một công ty cung cấp APIs như một dịch vụ (API as a service) qua internet, cho phép truy cập đọc không xác thực (unauthenticated read access) vào thông tin thống kê được cập nhật hàng ngày. Họ sử dụng Amazon API Gateway kết hợp AWS Lambda để xây dựng APIs. Dịch vụ đang phổ biến, nên công ty muốn tăng cường tính responsive (độ phản hồi nhanh) của APIs.
📌 Mục tiêu chính: Tối ưu hóa tốc độ phản hồi API mà không thay đổi kiến trúc cốt lõi, tận dụng tính năng sẵn có của AWS để giảm độ trễ (latency), đặc biệt với dữ liệu ít thay đổi (daily update). Đây là tình huống điển hình trong serverless architecture với API Gateway làm frontend.

✅ Đáp án đúng: Enable API caching in API Gateway

Lý do chọn đáp án này:
API Gateway hỗ trợ tính năng caching tích hợp, cho phép lưu trữ (cache) phản hồi từ backend Lambda ở edge locations của CloudFront. Với dữ liệu thống kê cập nhật hàng ngày, caching sẽ giảm đáng kể số lần gọi Lambda (tiết kiệm chi phí và latency), tăng tốc độ phản hồi lên đến giây thay vì hàng giây. TTL (Time-To-Live) có thể cấu hình linh hoạt (tối đa 24 giờ), phù hợp hoàn hảo. Đây là giải pháp đơn giản, hiệu quả nhất để nâng cao responsiveness cho public APIs read-only.
🛠️ Cách triển khai: Bật caching trong stage settings của API Gateway, đặt cache size (0.5GB-10GB), TTL phù hợp.
📘 Tài liệu tham khảo: AWS API Gateway Caching Docs (cập nhật 2024-2026, không thay đổi lớn ở phiên bản mới).

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

• ✅ Enable API caching in API Gateway
  Đúng vì: Tính năng này cache response từ Lambda tại edge, giảm latency từ ~200ms xuống dưới 50ms cho các request lặp lại. Lý tưởng cho dữ liệu ít thay đổi (daily stats), không ảnh hưởng authentication (unauthenticated). Hỗ trợ đầy đủ ở HTTP/REST APIs (2026 vẫn là best practice).

• ❌ Configure API Gateway to use an interface VPC endpoint
  Sai vì: Interface VPC endpoint dùng để truy cập private resources từ VPC (như Lambda private), nhưng APIs ở đây là public over internet (không cần VPC). Việc dùng endpoint sẽ tăng latency do routing nội bộ VPC, không cải thiện responsiveness mà còn phức tạp hóa kiến trúc public.

• ❌ Enable cross-origin resource sharing (CORS) for the APIs
  Sai vì: CORS chỉ giải quyết vấn đề browser security (cho phép cross-domain requests từ web apps), không ảnh hưởng đến tốc độ phản hồi API. Nó chỉ thêm headers, thậm chí có thể tăng nhẹ overhead nếu không cần thiết. Không liên quan đến responsiveness.

• ❌ Configure usage plans and API keys in API Gateway
  Sai vì: Usage plans + API keys dùng cho throttling, quota và billing (kiểm soát traffic), nhưng sẽ giới hạn request rate (ví dụ: 1000 req/s), dẫn đến throttle và tăng latency khi traffic cao. Không giúp tăng tốc, mà còn làm chậm dịch vụ phổ biến.

🧩 Kết luận: Caching là giải pháp serverless-native, zero-code change tối ưu nhất cho trường hợp này. Nếu traffic cao hơn, có thể kết hợp Lambda Provisioned Concurrency, nhưng caching là bước đầu tiên! 🚀

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

Câu hỏi xoay quanh việc thiết kế data store trên AWS để lưu trữ thông tin phim ảnh, với các thuộc tính chính: title (tên phim), release year (năm phát hành), genre (thể loại), và các thuộc tính linh hoạt khác như dàn diễn viên (cast) hoặc đoàn làm phim (crew) – những thông tin này không đồng nhất giữa các phim (ví dụ: phim này có assistant director, phim kia có animal trainer).

📋 Yêu cầu use cases cụ thể (phải hỗ trợ query hiệu quả):

• Cho title + release year: Lấy tất cả chi tiết của đúng phim đó (query chính xác).
• Cho title: Lấy tất cả chi tiết của tất cả phim có title đó (có thể nhiều phim cùng tên nhưng năm khác).
• Cho genre: Lấy tất cả chi tiết của tất cả phim thuộc genre đó.

🛠️ Yêu cầu thiết kế: Phải chọn data store configuration phù hợp, tận dụng schema linh hoạt cho dữ liệu không cấu trúc (nhờ DynamoDB NoSQL), và hỗ trợ query patterns trên mà không cần full table scan kém hiệu quả. Kiến thức dựa trên AWS DynamoDB phiên bản mới nhất 2026 (hỗ trợ single-table design, GSI/GSI v2 với on-demand capacity, và flexible attributes mà không cần schema rigid như RDS).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create an Amazon DynamoDB table. Configure the table with a primary key that consists of the title as the partition key and the release year as the sort key. Create a global secondary index that uses the genre as the partition key and the title as the sort key.

Lý do chi tiết:

• 🗝️ Primary Key (PK): title (partition key - PK) + release year (sort key - SK) →
  • Hỗ trợ title + release year: Query chính xác partition title + exact/range SK release year (O(1) efficient).
  • Hỗ trợ title alone: Query partition title + scan tất cả SK (tất cả năm của title đó).
• 📊 Global Secondary Index (GSI): genre (PK) + title (SK) →
  • Hỗ trợ genre: Query partition genre + scan tất cả SK title (tất cả phim trong genre).
• ✨ Lợi ích DynamoDB: Schema linh hoạt (Map/List attributes cho cast/crew không consistent), single-table design tối ưu cost/performance. Không cần join phức tạp như RDS. Hoàn hảo cho DOP-C02 exam (thiết kế scalable NoSQL).

📝 Giải thích tất cả các phương án

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

• ✅ Create an Amazon DynamoDB table. Configure the table with a primary key that consists of the title as the partition key and the release year as the sort key. Create a global secondary index that uses the genre as the partition key and the title as the sort key.
  (Đã giải thích ở trên – đáp án hoàn hảo, hỗ trợ tất cả 3 use cases hiệu quả với PK/GSI).

• ❌ Create an Amazon DynamoDB table. Configure the table with a primary key that consists of the genre as the partition key and the release year as the sort key. Create a global secondary index that uses the title as the partition key.
  Sai vì: PK genre (PK) + release year (SK) chỉ hỗ trợ query genre tốt (partition genre + SK year), nhưng:

  • Title + year: Không query trực tiếp (phải scan toàn table hoặc GSI title PK, nhưng GSI thiếu SK year → không exact match title+year).
  • Title alone: GSI title PK hỗ trợ, nhưng kém vì không phân biệt year và thiếu chi tiết full. Không đáp ứng title+year chính xác.

• ❌ On an Amazon RDS DB instance, create a table that contains columns for title, release year, and genre. Configure the title as the primary key.
  Sai vì: RDS (relational SQL) yêu cầu schema rigid, PK title → title phải unique (không lưu nhiều phim cùng title khác year).

  • Không hỗ trợ title alone (duplicate key error).
  • Query genre cần index phụ, kém scalable cho dữ liệu lớn/linh hoạt (cast/crew không consistent). RDS kém NoSQL patterns.

• ❌ On an Amazon RDS DB instance, create a table where the primary key is the title and all other data is encoded into JSON format as one additional column.
  Sai vì: PK title vẫn unique (không lưu multiple movies cùng title). JSON column giúp linh hoạt nhưng:

  • Không giải quyết duplicate title.
  • Query title+year/genre kém hiệu quả (parse JSON mỗi lần, full scan). RDS không tối ưu cho high-read NoSQL workloads.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• DynamoDB Developer Guide: Designing with partition keys and sort keys & GSI best practices.
• DOP-C02 Exam Guide: Domain 2.1 – Implement data storage solutions (DynamoDB single-table design).
• AWS Well-Architected Framework: Reliability Pillar – NoSQL for flexible schemas.

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần ví dụ code Terraform/CloudFormation deploy table, hỏi thêm nhé!