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

Đáp án

D — Dùng target tracking scaling.

Vì sao đúng

Đề nêu hai yêu cầu đối nghịch nhau, và target tracking là chính sách được thiết kế để cân bằng chúng: | Yêu cầu | Cơ chế | |---|---| | Tránh cấp phát thừa tài nguyên | tự động giảm khi tải thấp | | Không ảnh hưởng hiệu năng ứng dụng | tự động tăng khi tải cao |

Cách target tracking hoạt động — giống bộ điều nhiệt:

Bạn đặt MỘT mục tiêu:  CPU trung bình = 50%
    ↓
Auto Scaling tự tính toán cần bao nhiêu instance
    ├─ CPU vượt 50%  → tự thêm máy
    └─ CPU dưới 50%  → tự bớt máy
    ↓
Duy trì quanh mức mục tiêu, liên tục

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-ung-dung-web   --policy-name giu-cpu-50   --policy-type TargetTrackingScaling   --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 50.0
  }'

Vì sao nó tiết kiệm hơn simple scaling: | | Target tracking | Simple scaling | |---|---|---| | Cấu hình | một giá trị mục tiêu | nhiều alarm và bước điều chỉnh | | Phản ứng | liên tục, tỷ lệ với độ lệch | cố định: +2 máy mỗi lần | | Thời gian chờ | tự quản lý | cooldown chặn mọi hành động | | Cấp phát thừa | thấp — bám sát nhu cầu | cao — bước nhảy cố định |

Và Auto Scaling tự tạo các CloudWatch alarm cần thiết — bạn không phải quản lý chúng.

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

• A. Dùng simple scaling — đây là phương án gần nhất và là chính sách động thật sự, nhưng nó kém hiệu quả hơn hẳn: mỗi lần kích hoạt nó thêm hoặc bớt một số lượng cố định, rồi chờ hết cooldown mới làm gì tiếp. Với tải biến động, điều đó dẫn tới lúc thiếu lúc thừa. AWS khuyến nghị dùng target tracking thay cho simple scaling.
• B. Dùng scheduled scaling — không phải chính sách ĐỘNG: nó thay đổi số lượng instance theo lịch cố định, không phản ứng với tải thật. Đề hỏi rõ "dynamic scaling policy". (Scheduled scaling đúng cho mẫu tải dự đoán được — xem câu #8115.)
• C. Dùng suspend and resume scaling — không phải chính sách mở rộng: đó là tính năng tạm dừng các tiến trình của Auto Scaling (thường dùng khi bảo trì hoặc gỡ lỗi để ASG không can thiệp).

Ghi nhớ

Ba loại chính sách mở rộng động: | Loại | Cách hoạt động | Phù hợp | |---|---|---| | Target tracking | giữ một metric ở giá trị mục tiêu | hầu hết trường hợp — AWS khuyến nghị | | Step scaling | các bước khác nhau theo mức độ vi phạm | cần kiểm soát chi tiết | | Simple scaling | một hành động cố định + cooldown | cơ chế cũ, ít dùng |

Cộng thêm hai loại không phải "động": | Loại | Đặc điểm | |---|---| | Scheduled scaling | theo lịch — cho mẫu tải biết trước | | Predictive scaling | học lịch sử, dự báo và mở rộng TRƯỚC |

Các metric dựng sẵn cho target tracking: | Metric | Dùng khi | |---|---| | ASGAverageCPUUtilization | tải phụ thuộc CPU | | ALBRequestCountPerTarget | tải phụ thuộc số request — thường chính xác hơn CPU | | ASGAverageNetworkIn / NetworkOut | tải phụ thuộc mạng | | Custom metric | metric riêng của ứng dụng |

ALBRequestCountPerTarget đáng cân nhắc cho ứng dụng web: số request là chỉ báo trực tiếp về nhu cầu, trong khi CPU là hệ quả gián tiếp và có độ trễ.

Ba cấu hình quan trọng khác của ASG: | Cấu hình | Việc | |---|---| | MinSize / MaxSize | trần và sàn — target tracking không vượt qua được | | HealthCheckGracePeriod | chờ bao lâu trước khi kiểm tra sức khoẻ instance mới | | Warm pool | giữ sẵn instance đã khởi tạo để mở rộng nhanh hơn |

MaxSize là rào chắn chi phí quan trọng: nó ngăn ASG mở rộng vô hạn khi có tải bất thường — kể cả tải do tấn công (xem câu #7774).

Kết hợp nhiều chính sách:

Target tracking     → xử lý biến động thường ngày
Scheduled scaling   → tăng MinSize trước giờ cao điểm đã biết
Predictive scaling  → mở rộng trước dựa trên mẫu lịch sử

Ba cái này dùng chung được — Auto Scaling lấy giá trị lớn nhất trong các đề xuất, nên chúng bổ sung chứ không xung đột.

Và một cách tiết kiệm chi phí đáng kể mà đề gợi mở: kết hợp ASG với mixed instance policy dùng cả On-Demand lẫn Spot Instance. Với ứng dụng web không trạng thái, Spot có thể giảm chi phí 60–90% cho phần dung lượng vượt trên mức nền — một mức tiết kiệm lớn hơn nhiều so với việc tinh chỉnh chính sách mở rộng.

Đáp án

B — Dùng mã hoá phía client với khoá chính do client quản lý (client-side master key).

Vì sao đúng

Đề nêu một ràng buộc tuyệt đối: cả khoá chính LẪN dữ liệu chưa mã hoá đều KHÔNG BAO GIỜ được gửi tới AWS.

Chỉ một lựa chọn thoả cả hai vế:

Mã hoá phía CLIENT với khoá chính của client:
    Ứng dụng của bạn giữ master key (không bao giờ rời khỏi hệ thống của bạn)
        ↓ sinh data key, mã hoá dữ liệu NGAY TẠI CHỖ
    Chỉ BẢN MÃ được tải lên S3
        ↓
    AWS không bao giờ thấy: master key ✗   dữ liệu rõ ✗

Bảng đối chiếu bốn lựa chọn với hai ràng buộc: | Kiểu mã hoá | AWS thấy master key? | AWS thấy dữ liệu rõ? | |---|---|---| | Client-side + client master key | ❌ KHÔNG | ❌ KHÔNG | | Client-side + KMS key | ✅ CÓ (khoá ở KMS) | ❌ không | | SSE-KMS | ✅ CÓ | ✅ CÓ | | SSE-C | ❌ không lưu, nhưng khoá ĐƯỢC GỬI theo mỗi request | ✅ CÓ |

Chỉ dòng đầu có hai dấu ❌ — và đó chính là yêu cầu của đề.

Vì sao đề đặt ra ràng buộc này: với dữ liệu y tế nhạy cảm và quy định nghiêm ngặt, tổ chức muốn loại AWS ra khỏi phạm vi tin cậy hoàn toàn. Ngay cả khi AWS bị buộc phải giao nộp dữ liệu, họ chỉ có bản mã và không có khoá để mở.

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

• A. Mã hoá phía client với AWS KMS key — đây là phương án gần nhất và dữ liệu rõ đúng là không rời khỏi hệ thống của bạn, nhưng nó vi phạm vế thứ nhất: master key nằm trong KMS, tức là ở AWS. Đề nói rõ "master keys ... should never be sent to AWS".
• D. Mã hoá phía máy chủ với khoá do khách hàng cung cấp (SSE-C) — vi phạm CẢ HAI vế: dữ liệu rõ được gửi lên S3 để S3 mã hoá, và khoá cũng được gửi kèm mỗi request (S3 dùng xong thì xoá khỏi bộ nhớ, nhưng nó vẫn đã đi qua AWS).
• C. Mã hoá phía máy chủ với AWS KMS key (SSE-KMS) — vi phạm cả hai vế rõ ràng nhất: khoá ở KMS và dữ liệu rõ được gửi lên S3.

Ghi nhớ

Bốn kiểu mã hoá S3 — bảng cần thuộc: | Kiểu | Ai mã hoá | Ai giữ khoá | Dữ liệu rõ tới AWS? | |---|---|---|---| | SSE-S3 | S3 | AWS hoàn toàn | ✅ | | SSE-KMS | S3 | bạn qua KMS | ✅ | | SSE-C | S3 | bạn — gửi kèm mỗi request | ✅ | | Client-side | ứng dụng của bạn | bạn hoàn toàn | ❌ |

Câu hỏi phân biệt nhanh:

"Dữ liệu rõ không được tới AWS" → bắt buộc client-side "Khoá không được ở AWS" → bắt buộc khoá do client quản lý Cả hai → client-side + client master key ← câu này

Hai biến thể của mã hoá phía client: | Biến thể | Master key ở đâu | |---|---| | Client-side với KMS key | KMS (ở AWS) | | Client-side với client master key | hệ thống của bạn (HSM, kho khoá riêng) ← câu này |

Cả hai đều mã hoá dữ liệu trước khi gửi — khác biệt duy nhất là nơi giữ master key.

Cái giá của mã hoá phía client — cần cân nhắc thật: | Cái giá | Chi tiết | |---|---| | Bạn chịu trách nhiệm hoàn toàn về khoá | mất khoá = mất dữ liệu vĩnh viễn, không ai cứu được | | Ứng dụng phức tạp hơn | phải dùng SDK mã hoá ở mọi nơi đọc ghi | | Không dùng được nhiều tính năng của S3 | S3 Select, Athena, Glue không đọc được bản mã | | Xoay vòng khoá thủ công | phải mã hoá lại dữ liệu |

Dòng thứ ba là hạn chế bị đánh giá thấp nhất: dữ liệu mã hoá phía client là khối byte vô nghĩa với AWS, nên mọi dịch vụ phân tích đều mất tác dụng. Nếu có nhu cầu truy vấn dữ liệu, đây là đánh đổi rất lớn.

Công cụ để thực hiện: | Công cụ | Đặc điểm | |---|---| | AWS Encryption SDK | thư viện chuẩn, hỗ trợ nhiều nguồn khoá | | Amazon S3 Encryption Client | tích hợp sẵn với luồng S3 | | Tự viết | không khuyến khích — mã hoá tự viết rất dễ sai |

Dòng cuối đáng nhấn mạnh: tự cài đặt mã hoá là một trong những việc dễ sai nhất trong lập trình. Dùng thư viện đã được kiểm chứng, kể cả khi bạn tự quản lý khoá.

Và một lưu ý về mô hình trách nhiệm chung: mã hoá phía client chuyển toàn bộ rủi ro quản lý khoá sang bạn. Với dữ liệu y tế trong đề, đó là quyết định đúng nếu quy định yêu cầu — nhưng nó đi kèm nghĩa vụ phải có quy trình sao lưu và khôi phục khoá nghiêm ngặt, vì AWS không còn là lưới an toàn nữa.

Đáp án

C — Bật cấu hình Cross-Origin Resource Sharing (CORS) trên bucket.

Vì sao đúng

Đề mô tả chính xác một tình huống CORS: trang web tải từ một tên miền, nhưng JavaScript gọi request tới một tên miền khác:

Trang web:  http://tutorialsdojo.s3-website-us-east-1.amazonaws.com
JavaScript gọi tới:  tutorialsdojo.s3.amazonaws.com
                     ^^^^^^^^^^^^^^^^^^^^^^^^^ ORIGIN KHÁC

Trình duyệt áp dụng "same-origin policy" — một cơ chế bảo mật nền tảng:

Origin = giao thức + tên miền + cổng
    → khác BẤT KỲ thành phần nào = origin khác
    → JavaScript bị CHẶN không cho đọc phản hồi

Ở đây tên miền khác nhau (s3-website-us-east-1 với s3), nên trình duyệt chặn — dù cả hai đều trỏ tới cùng một bucket.

CORS là cách máy chủ nói với trình duyệt "tôi cho phép origin đó":

[{
  "AllowedHeaders": ["*"],
  "AllowedMethods": ["GET"],
  "AllowedOrigins": ["http://tutorialsdojo.s3-website-us-east-1.amazonaws.com"],
  "ExposeHeaders": ["ETag"],
  "MaxAgeSeconds": 3000
}]

Cơ chế đầy đủ:

JavaScript gửi request tới origin khác
    ↓ trình duyệt thêm header Origin:
S3 kiểm tra cấu hình CORS
    ├─ origin nằm trong AllowedOrigins
    │     → trả về Access-Control-Allow-Origin
    │     → trình duyệt CHO PHÉP JavaScript đọc phản hồi ✓
    └─ không khớp
          → không có header đó
          → trình duyệt CHẶN ✗

Điểm dễ gây hiểu nhầm: S3 vẫn trả về dữ liệu bình thường — chính trình duyệt mới là bên chặn. Nên khi gỡ lỗi, curl sẽ thành công trong khi trình duyệt báo lỗi.

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

• **A. Bật cross-account access — đây là phương án gần nhất về mặt tên gọi có chữ "cross", nhưng nó nói về việc cấp quyền cho tài khoản AWS khác. Ở đây chỉ có một tài khoản và một bucket; vấn đề nằm ở trình duyệt, không phải ở quyền.
• **D. Bật Cross-Region Replication (CRR) — sao chép object sang bucket ở Region khác cho mục đích khôi phục thảm hoạ và giảm độ trễ. Không liên quan tới việc trình duyệt chặn JavaScript.
• **B. Bật Cross-Zone Load Balancing — tính năng của Elastic Load Balancing phân phối lưu lượng đều giữa các target ở các AZ khác nhau. Không liên quan gì tới S3 hay CORS.

Ghi nhớ

Same-origin policy — nền tảng của vấn đề này:

Origin = GIAO THỨC + TÊN MIỀN + CỔNG

https://vidu.com        và  http://vidu.com        → KHÁC (giao thức)
https://vidu.com        và  https://api.vidu.com   → KHÁC (tên miền)
https://vidu.com        và  https://vidu.com:8443  → KHÁC (cổng)

Chỉ cần một thành phần khác là khác origin — và đây là nguồn gốc của rất nhiều lỗi khó hiểu khi phát triển web.

Năm phần tử của cấu hình CORS trên S3: | Phần tử | Việc | |---|---| | AllowedOrigins | origin nào được phép — * cho mọi origin | | AllowedMethods | GET, PUT, POST, DELETE, HEAD | | AllowedHeaders | header nào client được gửi | | ExposeHeaders | header nào JavaScript ĐỌC được từ phản hồi | | MaxAgeSeconds | trình duyệt cache kết quả preflight bao lâu |

ExposeHeaders hay bị bỏ sót: mặc định JavaScript chỉ đọc được vài header cơ bản. Muốn đọc ETag, x-amz-version-id hay header tuỳ chỉnh thì phải khai ở đây.

Preflight request — cơ chế cần biết khi gỡ lỗi:

Với request "không đơn giản" (PUT, DELETE, có header tuỳ chỉnh):
    ① Trình duyệt gửi OPTIONS trước  ← preflight
    ② Máy chủ trả về các header Access-Control-Allow-*
    ③ Nếu được phép, trình duyệt mới gửi request thật

Nên AllowedMethods phải bao gồm phương thức thật, và nhiều lỗi CORS thực ra là preflight thất bại chứ không phải request chính.

Ba lỗi CORS thường gặp trên S3: | Lỗi | Nguyên nhân | |---|---| | Khai origin có dấu / ở cuối | https://vidu.com/ không khớp https://vidu.com | | Quên phương thức trong AllowedMethods | preflight thất bại | | Nhầm HTTP với HTTPS | khác giao thức = khác origin |

Cách chẩn đoán nhanh:

curl -I -H "Origin: http://vidu.com" https://bucket.s3.amazonaws.com/tep.json
# Có header Access-Control-Allow-Origin trong phản hồi không?

Nếu curl có header mà trình duyệt vẫn báo lỗi, kiểm tra tab Network của DevTools — thường là preflight OPTIONS mới là request thất bại.

Và một lời khuyên về bảo mật: đừng dùng "AllowedOrigins": ["*"] cho bucket chứa dữ liệu riêng tư. Nó cho phép JavaScript từ bất kỳ trang web nào đọc nội dung bucket của bạn qua trình duyệt của người dùng. Liệt kê đúng origin cần thiết — với trang web tĩnh công khai thì * chấp nhận được, với API có xác thực thì không.

Đáp án

B — Amazon DynamoDB.

Vì sao đúng

Đề nêu bốn yêu cầu, và DynamoDB là lựa chọn duy nhất thoả cả bốn: | Yêu cầu | DynamoDB | |---|---| | Mở rộng toàn cầu | Global Tables — sao chép đa Region, đa chủ | | Xử lý thay đổi lược đồ thường xuyên | không có lược đồ cố định (schemaless) | | Không ngừng dịch vụ khi đổi lược đồ | thêm thuộc tính mới không cần thao tác gì | | Độ trễ thấp với truy vấn lưu lượng cao | mili giây một chữ số, ở mọi quy mô |

Vế "thay đổi lược đồ thường xuyên" là điểm quyết định — và đây là khác biệt căn bản giữa NoSQL và cơ sở dữ liệu quan hệ:

Cơ sở dữ liệu quan hệ (RDS, Aurora):
    Thêm cột → ALTER TABLE
        → khoá bảng hoặc chạy nền tốn nhiều giờ với bảng lớn
        → ảnh hưởng hiệu năng, có thể phải ngừng dịch vụ

DynamoDB:
    Thêm thuộc tính → chỉ cần GHI item mới có thuộc tính đó
        → KHÔNG có thao tác lược đồ nào
        → item cũ và mới cùng tồn tại trong một bảng
        → KHÔNG ngừng dịch vụ, KHÔNG ảnh hưởng hiệu năng

DynamoDB chỉ bắt buộc khai PRIMARY KEY — mọi thuộc tính khác là tuỳ ý theo từng item:

// Hai item trong cùng một bảng, "lược đồ" khác nhau — hoàn toàn hợp lệ
{"userId": "u1", "ten": "An", "email": "an@vidu.com"}
{"userId": "u2", "ten": "Binh", "sdt": "0900000000", "diaChi": {...}}

Và Global Tables cho vế "toàn cầu": sao chép tự động sang nhiều Region với mô hình đa chủ — người dùng ở mỗi Region đọc và ghi vào bản sao gần nhất, độ trễ thấp ở mọi nơi.

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

• **C. Amazon Aurora với Read Replica — đây là phương án gần nhất và mở rộng đọc rất tốt (Aurora Global Database còn sao chép đa Region), nhưng nó là cơ sở dữ liệu QUAN HỆ có lược đồ cố định: mỗi lần đổi lược đồ vẫn cần ALTER TABLE, và với bảng lớn thì đó là thao tác nặng — trái yêu cầu "no downtime or performance issues whenever there is a schema change".
• **A. Amazon RDS ở cấu hình Multi-AZ — Multi-AZ là để SẴN SÀNG CAO, không phải mở rộng: bản dự phòng ở AZ khác không phục vụ đọc. Và RDS cũng có lược đồ cố định, cũng không mở rộng toàn cầu được.
• **D. Redshift — kho dữ liệu phân tích (OLAP), tối ưu cho truy vấn tổng hợp trên khối lượng lớn. Nó không phù hợp cho truy vấn giao dịch độ trễ thấp, lưu lượng cao như đề mô tả.

Ghi nhớ

Bốn nhóm cơ sở dữ liệu của AWS — chọn đúng theo bài toán: | Nhóm | Dịch vụ | Phù hợp | |---|---|---| | Quan hệ (OLTP) | RDS, Aurora | giao dịch, JOIN phức tạp, lược đồ ổn định | | Khoá–giá trị / tài liệu | DynamoDB | quy mô lớn, độ trễ thấp, lược đồ linh hoạt ← câu này | | Kho dữ liệu (OLAP) | Redshift | phân tích, tổng hợp trên khối lượng lớn | | Chuyên biệt | ElastiCache, Neptune, Timestream, DocumentDB | cache, đồ thị, chuỗi thời gian, MongoDB |

Từ khoá nhận diện trong đề thi:

"schema changes", "flexible schema", "scale globally", "single-digit millisecond" → DynamoDB "complex joins", "transactions", "SQL" → RDS/Aurora "data warehouse", "analytics", "petabyte" → Redshift "microsecond", "cache" → ElastiCache hoặc DAX

Ba đặc điểm của Global Tables: | Đặc điểm | Chi tiết | |---|---| | Đa chủ (multi-active) | đọc và ghi được ở MỌI Region | | Sao chép nhất quán cuối cùng | thường dưới một giây | | Giải quyết xung đột "last writer wins" | ghi cùng lúc ở hai Region thì bản mới nhất thắng |

Dòng cuối là điều cần thiết kế quanh nó: nếu ứng dụng cần nhất quán mạnh khi ghi đồng thời, Global Tables không phải công cụ đúng.

Hai chế độ dung lượng của DynamoDB: | Chế độ | Phù hợp | |---|---| | On-demand | tải không dự đoán được, hoặc mới bắt đầu | | Provisioned + Auto Scaling | tải ổn định — rẻ hơn đáng kể |

Ba tính năng đáng biết: | Tính năng | Việc | |---|---| | DAX | cache trong bộ nhớ — giảm độ trễ xuống MICROgiây | | DynamoDB Streams | bắt thay đổi để kích hoạt Lambda | | Point-in-time recovery | khôi phục về bất kỳ giây nào trong 35 ngày |

Một hạn chế quan trọng cần biết: DynamoDB không hỗ trợ truy vấn linh hoạt như SQL. Bạn phải thiết kế bảng theo mẫu truy cập ngay từ đầu, và thêm Global Secondary Index cho các cách truy vấn khác. "Lược đồ linh hoạt" nói về thuộc tính của item, không có nghĩa là truy vấn linh hoạt — đây là điểm hay bị hiểu nhầm khi chuyển từ cơ sở dữ liệu quan hệ sang.

Và với đề này: ứng dụng cần "low latency response to high-traffic queries" — nếu các truy vấn đó tập trung vào một số ít item nóng, hãy cân nhắc thêm DAX để giảm độ trễ xuống micro giây và giảm chi phí đọc.

Đáp án

A — Thiết lập và cấu hình Amazon Macie để giám sát dữ liệu trên Amazon S3.

Vì sao đúng

Đề nêu hai yêu cầu, và Macie là dịch vụ được thiết kế đúng cho cả hai: | Yêu cầu | Cơ chế | |---|---| | Xác minh dữ liệu chứa thông tin định danh cá nhân (PII) | Macie quét nội dung object và phân loại | | Cảnh báo khi có vi phạm chính sách về quyền riêng tư của bucket | Macie sinh finding về bucket công khai, chưa mã hoá, chia sẻ ra ngoài |

Macie làm hai việc song song:

① Phát hiện DỮ LIỆU NHẠY CẢM
   Quét nội dung object → nhận diện số CMND, thẻ tín dụng,
                          hộ chiếu, hồ sơ y tế, khoá AWS

② Đánh giá TƯ THẾ BẢO MẬT của bucket
   → bucket có công khai không?
   → có mã hoá không?
   → có chia sẻ ra ngoài tài khoản/tổ chức không?

Vế thứ hai chính là "alerted if there are potential policy violations with the privacy of their S3 buckets" trong đề — và nó chạy tự động, không cần bật gì thêm.

Và finding của Macie tự chuyển sang Security Hub và EventBridge:

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": {"severity": {"description": ["High"]}}
}

→ SNS cảnh báo, hoặc Lambda tự động khắc phục.

Đề mô tả dữ liệu điều tra dân số — chính xác loại dữ liệu mà Macie được xây dựng để bảo vệ: hàng loạt hồ sơ hộ gia đình chứa thông tin định danh cá nhân.

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

• B. Thiết lập Amazon Kendra để giám sát hoạt động độc hại trên dữ liệu S3 — đây là phương án gần nhất về mặt "cũng đọc nội dung tài liệu", nhưng Kendra là dịch vụ TÌM KIẾM DOANH NGHIỆP: nó lập chỉ mục tài liệu để nhân viên tìm kiếm bằng ngôn ngữ tự nhiên. Nó không phải công cụ bảo mật và không giám sát hoạt động độc hại.
• C. Thiết lập Amazon Polly để quét mẫu sử dụng trên dữ liệu S3 — Polly chuyển văn bản thành giọng nói. Hoàn toàn không liên quan.
• D. Thiết lập Amazon Fraud Detector để gửi cảnh báo khi phát hiện vi phạm bảo mật trên dữ liệu S3 — Fraud Detector phát hiện GIAN LẬN trong giao dịch (đăng ký tài khoản giả, thanh toán gian lận) bằng học máy. Nó không quét S3 và không giám sát cấu hình bảo mật.

Ghi nhớ

Bốn dịch vụ bảo mật của AWS — bảng phân biệt cốt lõi: | Dịch vụ | Phát hiện | Nguồn dữ liệu | |---|---|---| | Macie | DỮ LIỆU NHẠY CẢM | nội dung object S3 ← câu này | | GuardDuty | MỐI ĐE DOẠ đang diễn ra | Flow Logs, DNS, CloudTrail | | Inspector | LỖ HỔNG phần mềm | EC2, ECR, Lambda | | Security Hub | tổng hợp và chấm điểm chuẩn | finding từ ba cái trên |

Câu hỏi phân biệt:

"Dữ liệu nhạy cảm nằm ở đâu?" → Macie "Có ai đang tấn công không?" → GuardDuty "Phần mềm có lỗ hổng không?" → Inspector

Các loại dữ liệu Macie nhận diện sẵn: | Nhóm | Ví dụ | |---|---| | Tài chính | số thẻ tín dụng, số tài khoản ngân hàng | | Định danh cá nhân | số an sinh xã hội, hộ chiếu, bằng lái | | Thông tin đăng nhập | AWS access key, private key, chuỗi kết nối CSDL | | Y tế | mã số bảo hiểm y tế | | Tuỳ chỉnh | custom data identifier bằng regex |

Dòng cuối cần thiết cho tổ chức Việt Nam: số CCCD, mã số thuế, số tài khoản ngân hàng nội địa không nằm trong bộ nhận dạng sẵn. Phải tự viết custom data identifier:

{
  "name": "so-cccd-viet-nam",
  "regex": "\\b0[0-9]{11}\\b",
  "maximumMatchDistance": 50,
  "keywords": ["CCCD", "căn cước", "số định danh"]
}

keywords giảm mạnh cảnh báo giả — nó yêu cầu một từ khoá xuất hiện gần chuỗi khớp.

Hai loại finding của Macie: | Loại | Nội dung | |---|---| | Sensitive data finding | tìm thấy PII trong object cụ thể | | Policy finding | bucket công khai, chưa mã hoá, chia sẻ ra ngoài ← vế thứ hai của đề |

Ba lưu ý về chi phí Macie: | Lưu ý | Chi tiết | |---|---| | Tính phí theo số object đánh giá + dung lượng quét | | | Dùng sampling cho hồ dữ liệu lớn | không cần quét 100% | | Giới hạn phạm vi theo bucket hoặc prefix | quét toàn bộ mỗi ngày là khoản chi bất ngờ phổ biến nhất |

Policy finding thì miễn phí và tự động — chỉ việc quét nội dung mới tính phí. Nên bật Macie ở mức cơ bản là hợp lý cho mọi tài khoản có dữ liệu trên S3.

Và một điểm về kiến trúc cho tình huống của đề: dữ liệu điều tra dân số đã được mã hoá theo mô tả. Macie vẫn quét được object mã hoá bằng SSE-S3 và SSE-KMS (nó có quyền giải mã qua service-linked role), nhưng KHÔNG quét được object mã hoá phía client — vì với Macie đó chỉ là khối byte vô nghĩa. Đây là đánh đổi cần biết khi chọn kiểu mã hoá (xem câu #8110).

Đáp án

A và D.

• D — Hợp nhất mọi tài khoản của công ty bằng AWS Organizations
• A — Dùng AWS Resource Access Manager (RAM) để chia sẻ tài nguyên với các tài khoản AWS một cách dễ dàng và an toàn

Vì sao đúng

Đề liệt kê đúng ba tài nguyên: Transit Gateway, cấu hình License Manager, và Route 53 Resolver rule — cả ba đều nằm trong danh sách tài nguyên mà AWS RAM chia sẻ được. Đó không phải trùng hợp; đề đang mô tả chính xác trường hợp sử dụng của RAM.

Hai đáp án là hai lớp bổ sung nhau:

D: AWS Organizations
   → gom mọi tài khoản vào một tổ chức
   → thanh toán hợp nhất, quản trị tập trung
   → LÀ NỀN TẢNG cho việc chia sẻ

A: AWS Resource Access Manager
   → chia sẻ tài nguyên CỤ THỂ giữa các tài khoản
   → chạy trên nền Organizations

Vì sao Organizations là điều kiện cần: RAM chia sẻ được với tài khoản đơn lẻ, nhưng khi có Organizations thì: | Lợi ích | Chi tiết | |---|---| | Chia sẻ với cả OU hoặc cả tổ chức | không phải liệt kê từng tài khoản | | Không cần chấp nhận lời mời | tài khoản trong tổ chức nhận tài nguyên tự động | | Tài khoản mới tự động được chia sẻ | nếu chia sẻ ở mức OU |

Dòng giữa là khác biệt vận hành lớn: chia sẻ ra ngoài tổ chức đòi bên nhận chấp nhận lời mời; trong tổ chức thì không.

Và giá trị kinh tế mà đề nhấn mạnh ("drive costs down") là thật:

KHÔNG chia sẻ:  mỗi tài khoản một Transit Gateway, một NAT Gateway,
                một bộ Route 53 Resolver rule
                → nhân chi phí lên theo số tài khoản

CÓ chia sẻ:     một Transit Gateway trung tâm dùng chung
                → chi phí cố định chia cho cả tổ chức

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

• B. Dùng IAM để thiết lập truy cập chéo tài khoản nhằm chia sẻ tài nguyên — đây là phương án gần nhất và IAM cross-account role là cơ chế thật, nhưng nó cấp quyền gọi API trên tài nguyên của tài khoản khác. Nó KHÔNG chia sẻ được hạ tầng như Transit Gateway hay subnet — bạn không thể "assume role" để gắn một ENI vào Transit Gateway của tài khoản khác.
• C. Dùng AWS Control Tower để chia sẻ tài nguyên với các tài khoản — nhầm chức năng: Control Tower dựng và quản trị môi trường nhiều tài khoản (tạo tài khoản theo mẫu, áp guardrail, thiết lập log tập trung). Nó không phải công cụ chia sẻ tài nguyên. (Control Tower chạy trên nền Organizations và bổ trợ cho RAM, nhưng không thay thế.)
• E. Hợp nhất tài khoản bằng AWS ParallelCluster — sai hoàn toàn: ParallelCluster là công cụ triển khai cụm tính toán hiệu năng cao (HPC). Nó không liên quan gì tới quản lý tài khoản.

Ghi nhớ

Những gì AWS RAM chia sẻ được — danh sách đáng thuộc: | Tài nguyên | Ghi chú | |---|---| | VPC subnet | VPC sharing — nhiều tài khoản khởi chạy vào cùng một VPC | | Transit Gateway | ← đề nhắc tới | | License Manager configuration | ← đề nhắc tới | | Route 53 Resolver rule | ← đề nhắc tới | | Aurora DB cluster | | | Capacity Reservation, Dedicated Host | | | Prefix list | | | Image Builder component, Resource Group | |

Ba dòng đầu tiên trong đề khớp chính xác ba mục trong danh sách này — dấu hiệu rõ ràng rằng RAM là đáp án.

Ba dịch vụ quản lý nhiều tài khoản — phân biệt vai trò: | Dịch vụ | Việc | |---|---| | AWS Organizations | NỀN TẢNG: gom tài khoản, thanh toán hợp nhất, SCP | | AWS RAM | CHIA SẺ tài nguyên giữa các tài khoản | | AWS Control Tower | DỰNG và quản trị môi trường nhiều tài khoản theo chuẩn |

Ba cái này chồng lên nhau chứ không thay thế nhau:

Organizations  → khung tổ chức
Control Tower  → tự động dựng tài khoản + guardrail (chạy trên Organizations)
RAM            → chia sẻ tài nguyên (chạy trên Organizations)

Ba khả năng chính của AWS Organizations: | Khả năng | Chi tiết | |---|---| | Consolidated billing | một hoá đơn, hưởng giá theo bậc chung — tiết kiệm thật | | Service Control Policy (SCP) | trần quyền cho tài khoản, áp cả root của member | | Tự động tạo tài khoản | qua API hoặc Control Tower |

Thanh toán hợp nhất đáng nói riêng cho vế "drive costs down": dung lượng Reserved Instance và Savings Plan được chia sẻ giữa các tài khoản trong tổ chức, và mức sử dụng cộng dồn để hưởng bậc giá tốt hơn.

Hai mô hình chia sẻ mạng — chọn theo nhu cầu: | Mô hình | Đặc điểm | |---|---| | VPC Sharing (RAM chia sẻ subnet) | một VPC, nhiều tài khoản khởi chạy vào | | Transit Gateway (RAM chia sẻ TGW) | mỗi tài khoản VPC riêng, nối qua hub trung tâm |

Mô hình thứ hai phù hợp hơn với đề này — công ty toàn cầu có văn phòng ở nhiều nơi, nên mỗi đơn vị có VPC riêng và nối qua Transit Gateway dùng chung là kiến trúc chuẩn.

Và một lưu ý về chia sẻ Transit Gateway: sau khi chia sẻ, các tài khoản tự tạo attachment từ VPC của họ, nhưng route table của TGW vẫn do tài khoản chủ quản lý. Đó là ranh giới trách nhiệm rõ ràng — đội mạng trung tâm kiểm soát định tuyến, các đơn vị tự lo VPC của mình.

Đáp án

C — Cấu hình scheduled scaling policy cho Auto Scaling group để khởi chạy instance mới trước khi ngày làm việc bắt đầu.

Vì sao đúng

Đề mô tả một mẫu tải hoàn toàn dự đoán được:

Ứng dụng CRM dùng nhiều từ 9h sáng tới 17h chiều
Triệu chứng: CHẬM lúc đầu ngày, bình thường sau vài tiếng

Chẩn đoán: mở rộng phản ứng luôn CHẬM MỘT NHỊP.

9h00  người dùng đổ vào    → tải tăng vọt
9h03  CPU vượt ngưỡng      → alarm kích hoạt
9h05  ASG bắt đầu khởi chạy instance
9h08  instance khởi động xong, qua health check
9h10  bắt đầu nhận lưu lượng
      ↑
      MƯỜI PHÚT người dùng chịu ứng dụng chậm

Đó chính xác là "slow during the start of the day but then works normally after a couple of hours" trong đề.

Scheduled scaling loại bỏ độ trễ bằng cách mở rộng TRƯỚC:

# Tăng dung lượng trước giờ làm việc
aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-crm   --scheduled-action-name mo-rong-truoc-gio-lam   --recurrence "30 8 * * MON-FRI"   --min-size 10 --desired-capacity 10

# Thu nhỏ sau giờ làm việc
aws autoscaling put-scheduled-update-group-action   --auto-scaling-group-name asg-crm   --scheduled-action-name thu-nho-sau-gio-lam   --recurrence "0 18 * * MON-FRI"   --min-size 2 --desired-capacity 2

Đặt lịch lúc 8h30 cho giờ cao điểm 9h00 — cho instance đủ thời gian khởi động và sẵn sàng trước khi người dùng đến.

Và "MOST operationally efficient" nghiêng về scheduled scaling vì mẫu tải đã biết rõ: hai hành động theo lịch, không cần cấu hình metric, ngưỡng hay dự báo gì.

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

• D. Cấu hình predictive scaling policy để tự động điều chỉnh số lượng instance — đây là phương án gần nhất và về mặt kỹ thuật cũng giải quyết được: predictive scaling học lịch sử và mở rộng trước. Nhưng với mẫu tải cố định và đã biết chính xác như đề mô tả, nó phức tạp hơn mức cần thiết — nó cần ít nhất 24 giờ dữ liệu để bắt đầu, và tốt nhất là 14 ngày để dự báo chính xác.
• A. Dynamic scaling policy dựa trên CPU utilization — đây chính là thứ đang không hoạt động đủ tốt: mở rộng phản ứng luôn có độ trễ, và đó là nguyên nhân gốc của triệu chứng.
• B. Dynamic scaling policy dựa trên Memory utilization — cùng vấn đề độ trễ như A, cộng thêm một trở ngại: CloudWatch không có metric bộ nhớ sẵn cho EC2. Phải cài CloudWatch agent mới thu thập được (xem câu #8117) — nên nó còn tốn công hơn.

Ghi nhớ

Ba loại chính sách mở rộng và khi nào dùng: | Loại | Cơ chế | Phù hợp | |---|---|---| | Dynamic (target tracking, step) | PHẢN ỨNG với metric | tải biến động không đoán trước | | Scheduled | theo LỊCH cố định | mẫu tải biết trước ← câu này | | Predictive | học lịch sử, DỰ BÁO | mẫu lặp lại nhưng phức tạp |

Ba loại này KẾT HỢP được và nên kết hợp:

Scheduled scaling  → tăng MinSize lúc 8h30 (nền cho giờ làm việc)
Target tracking    → xử lý biến động trong ngày

Auto Scaling lấy giá trị LỚN NHẤT trong các đề xuất, nên chúng bổ sung chứ không xung đột.

Đây là cấu hình đáng áp dụng cho đề này: scheduled scaling đảm bảo có sẵn dung lượng nền lúc 9h, còn target tracking xử lý những đợt tải bất thường trong ngày.

Bốn nguyên nhân gây độ trễ khi mở rộng: | Nguyên nhân | Thời gian điển hình | |---|---| | Alarm cần vài chu kỳ để kích hoạt | 1–3 phút | | Khởi chạy và boot instance | 1–3 phút | | Ứng dụng khởi động (JVM, cache warm-up) | 1–10 phút | | Health check qua | 1–2 phút |

Dòng thứ ba thường lớn nhất và hay bị bỏ qua — ứng dụng Java hay .NET có thể mất nhiều phút để sẵn sàng phục vụ, dù instance đã "chạy".

Ba cách giảm thời gian mở rộng: | Cách | Lợi ích | |---|---| | Warm pool | giữ sẵn instance đã khởi tạo ở trạng thái Stopped — khởi động rất nhanh | | AMI đã nướng sẵn ứng dụng | không phải cài đặt lúc khởi chạy | | Lifecycle hook + InstanceWarmup | không nhận lưu lượng cho tới khi thật sự sẵn sàng |

Warm pool đáng cân nhắc cho ứng dụng khởi động chậm: instance nằm ở trạng thái Stopped (chỉ tính phí lưu trữ EBS, không tính phí compute) và chuyển sang InService trong vài chục giây thay vì vài phút.

Hai điều cần biết về scheduled action: | Điều | Chi tiết | |---|---| | Dùng cú pháp cron của UNIX | mặc định là UTC — nhớ đổi múi giờ | | Đặt được MinSize, MaxSize, DesiredCapacity | |

Múi giờ là lỗi hay gặp nhất: "30 8 * * MON-FRI" theo UTC là 15h30 giờ Việt Nam — muộn hẳn nửa ngày so với ý định. Khai --time-zone "Asia/Ho_Chi_Minh" để tránh:

--recurrence "30 8 * * MON-FRI" --time-zone "Asia/Ho_Chi_Minh"

Và một lợi ích chi phí của cặp lịch tăng–giảm: thu nhỏ sau 17h và cuối tuần cắt được khoảng hai phần ba chi phí compute cho một ứng dụng nội bộ chỉ dùng trong giờ hành chính — thường lớn hơn nhiều so với mọi tối ưu khác.

Đáp án

A — Bật IAM Database Authentication.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: cơ sở dữ liệu chỉ truy cập được bằng một token xác thực gắn với thông tin đăng nhập trong profile của EC2 instance.

IAM database authentication làm đúng điều đó:

EC2 instance có IAM role qua instance profile
    ↓ gọi rds:generate-db-auth-token
Nhận về một TOKEN xác thực (hết hạn sau 15 phút)
    ↓ dùng token thay cho mật khẩu khi kết nối
RDS xác minh token với IAM
    ↓
Kết nối được thiết lập

TOKEN=$(aws rds generate-db-auth-token   --hostname csdl.abc123.ap-northeast-1.rds.amazonaws.com   --port 3306 --region ap-northeast-1 --username ung_dung)

mysql --host=csdl.abc123.ap-northeast-1.rds.amazonaws.com       --user=ung_dung --password="$TOKEN"       --enable-cleartext-plugin --ssl-ca=global-bundle.pem

Ba lợi ích so với mật khẩu tĩnh: | Lợi ích | Chi tiết | |---|---| | Không có mật khẩu nào được lưu ở đâu cả | không có gì để rò rỉ | | Token hết hạn sau 15 phút | token bị lộ cũng nhanh vô dụng | | Quyền quản lý tập trung trong IAM | thu hồi bằng cách gỡ policy |

Và bắt buộc dùng SSL/TLS — đây là điều kiện của chính tính năng: token đi qua đường truyền nên phải được mã hoá.

Cấu hình cần hai bước:

-- ① Trong cơ sở dữ liệu, tạo user dùng plugin IAM
CREATE USER ung_dung IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';
GRANT SELECT, INSERT, UPDATE ON ung_dung_db.* TO ung_dung;

// ② IAM policy cho role của EC2
{
  "Effect": "Allow",
  "Action": "rds-db:connect",
  "Resource": "arn:aws:rds-db:ap-northeast-1:111122223333:dbuser:db-ABCDEFGHIJKL/ung_dung"
}

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

• D. Dùng kết hợp IAM và STS để buộc truy cập hạn chế vào RDS bằng một token xác thực tạm thời — đây là phương án gần nhất và mô tả gần đúng kết quả, nhưng nó không phải cơ chế có sẵn: STS cấp token cho lời gọi API AWS, không phải cho kết nối cơ sở dữ liệu. Tính năng có tên riêng là IAM database authentication, và đó là thứ cần bật.
• C. Tạo IAM role gắn cho EC2 instance để cấp quyền truy cập độc quyền vào RDS — IAM role một mình không xác thực được vào cơ sở dữ liệu: RDS vẫn cần một cơ chế đăng nhập ở tầng CSDL. Role chỉ có ý nghĩa khi IAM DB authentication đã được bật — nó là điều kiện cần chứ không đủ.
• B. Cấu hình SSL trong ứng dụng để mã hoá kết nối tới RDS — giải quyết vấn đề khác: SSL bảo vệ tính bí mật khi truyền, nó không xác thực ai được kết nối. (SSL là bắt buộc khi dùng IAM DB auth — nhưng nó là điều kiện đi kèm, không phải câu trả lời.)

Ghi nhớ

Ba cách xác thực vào RDS — theo mức bảo mật: | Cách | Bí mật lưu ở đâu | Xoay vòng | |---|---|---| | Mật khẩu tĩnh | trong cấu hình ứng dụng | thủ công | | Secrets Manager + xoay vòng tự động | Secrets Manager | tự động 30–90 ngày | | IAM database authentication | KHÔNG Ở ĐÂU CẢ | token hết hạn sau 15 phút |

Dòng cuối an toàn nhất — không có bí mật dài hạn nào tồn tại.

Giới hạn của IAM database authentication — cần biết trước khi chọn: | Giới hạn | Chi tiết | |---|---| | Chỉ MySQL, PostgreSQL, MariaDB | KHÔNG hỗ trợ Oracle, SQL Server | | Giới hạn số kết nối mới mỗi giây | ~200/giây với MySQL — không hợp ứng dụng mở kết nối liên tục | | Token hết hạn sau 15 phút | ứng dụng phải sinh lại token | | Bắt buộc SSL | thêm chút chi phí xử lý |

Dòng thứ hai là hạn chế thực tế quan trọng nhất: nếu ứng dụng không dùng connection pool và mở kết nối mới cho mỗi request, IAM DB auth sẽ thành nút thắt. Với connection pool thì không vấn đề gì.

Khi nào chọn Secrets Manager thay vì IAM DB auth: | Tình huống | Chọn | |---|---| | Oracle hoặc SQL Server | Secrets Manager | | Rất nhiều kết nối mới mỗi giây | Secrets Manager | | Ứng dụng chạy trên AWS, dùng MySQL/PostgreSQL | IAM DB auth ← câu này | | Cần chia sẻ thông tin đăng nhập với hệ thống ngoài | Secrets Manager |

Ba lớp bảo vệ nên có cho RDS trong kiến trúc của đề: | Lớp | Cơ chế | |---|---| | Mạng | private subnet, security group chỉ cho phép từ SG của EC2 trên cổng CSDL | | Xác thực | IAM database authentication ← câu này | | Mã hoá | at-rest bằng KMS, in-transit bằng SSL |

Bắt buộc SSL ở tầng CSDL:

MySQL:      parameter group đặt require_secure_transport = ON
PostgreSQL: parameter group đặt rds.force_ssl = 1

Không có cấu hình này, client vẫn kết nối được không mã hoá nếu họ muốn.

Và một chi tiết về ARN trong policy: arn:aws:rds-db:...:dbuser:<DbiResourceId>/<ten-user> dùng DbiResourceId (dạng db-ABCDEFGHIJKL), không phải tên instance. Đây là chỗ hay sai khi viết policy lần đầu — lấy giá trị đúng bằng:

aws rds describe-db-instances --db-instance-identifier csdl   --query 'DBInstances[0].DbiResourceId'

Đáp án

A — Memory Utilization (mức sử dụng bộ nhớ) của EC2 instance.

Vì sao đúng

Đề hỏi metric nào KHÔNG có sẵn trong CloudWatch và phải tự thiết lập — và câu trả lời nằm ở ranh giới giữa hypervisor và hệ điều hành.

Nguyên tắc quyết định:

CloudWatch thu thập metric từ HYPERVISOR (tầng ảo hoá)
    → nhìn thấy: CPU, mạng, hoạt động đọc/ghi đĩa
    → KHÔNG nhìn thấy được vào BÊN TRONG hệ điều hành khách

Bộ nhớ và dung lượng đĩa còn trống là thông tin BÊN TRONG hệ điều hành
    → hypervisor không biết
    → phải cài AGENT trong máy để báo cáo ra

Vì sao hypervisor không biết mức dùng RAM: nó cấp cho instance một khối bộ nhớ cố định. Việc hệ điều hành dùng bao nhiêu trong khối đó — và bao nhiêu là cache, bao nhiêu là buffer — chỉ hệ điều hành khách mới biết.

Bảng phân loại metric EC2: | Metric | Có sẵn? | Nguồn | |---|---|---| | CPUUtilization | ✅ | hypervisor | | NetworkIn / NetworkOut | ✅ | hypervisor | | DiskReadOps / DiskWriteOps | ✅ | hypervisor (instance store) | | EBSReadOps / EBSWriteOps | ✅ | EBS | | StatusCheckFailed | ✅ | hypervisor | | Mức dùng BỘ NHỚ | ❌ CẦN AGENT ← câu này | | Dung lượng ĐĨA CÒN TRỐNG | ❌ CẦN AGENT | | Số tiến trình, swap | ❌ cần agent |

Cách thu thập: cài unified CloudWatch agent:

{
  "metrics": {
    "metrics_collected": {
      "mem": {"measurement": ["mem_used_percent"]},
      "disk": {"measurement": ["disk_used_percent"], "resources": ["/"]}
    },
    "append_dimensions": {"InstanceId": "${aws:InstanceId}"}
  }
}

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

(Ba phương án còn lại đều là metric CÓ SẴN — câu hỏi tìm cái không có.)

• **B. CPU Utilization — có sẵn, và là metric cơ bản nhất. Hypervisor đo được trực tiếp phần thời gian CPU vật lý mà instance sử dụng.
• **C. Disk Reads activity — có sẵn: DiskReadOps và DiskReadBytes cho instance store, EBSReadOps cho volume EBS. (Lưu ý: đây là hoạt động ĐỌC GHI, khác với dung lượng đĩa còn trống — cái sau mới cần agent.)
• **D. Network packets out — có sẵn: NetworkPacketsOut cùng với NetworkOut, NetworkIn, NetworkPacketsIn.

Ghi nhớ

Quy tắc phân biệt — thuộc lòng cái này là trả lời được cả nhóm câu hỏi:

Hypervisor nhìn thấy được → CloudWatch có sẵn Chỉ hệ điều hành bên trong biết → cần agent

Hai chế độ giám sát của EC2: | Chế độ | Tần suất | Chi phí | |---|---|---| | Basic monitoring | 5 phút | miễn phí | | Detailed monitoring | 1 phút | tính phí |

Tần suất ảnh hưởng tới alarm: đặt Period = 60 với basic monitoring tạo ra bốn chu kỳ thiếu dữ liệu trong mỗi năm phút — kết hợp với TreatMissingData sai sẽ gây báo động giả (xem câu #7788).

Ba khả năng của unified CloudWatch agent: | Khả năng | Chi tiết | |---|---| | Metric hệ thống | RAM, đĩa, swap, tiến trình | | Log | tệp log ứng dụng, Windows Event Log | | Trace | qua OpenTelemetry |

Quyền cần cho agent — managed policy CloudWatchAgentServerPolicy:

cloudwatch:PutMetricData
logs:CreateLogGroup, CreateLogStream, PutLogEvents, DescribeLogStreams
ssm:GetParameter   (nếu lưu cấu hình trong Parameter Store)

Ba lưu ý về custom metric: | Lưu ý | Chi tiết | |---|---| | Tính phí theo số metric | mỗi tổ hợp dimension là một metric riêng | | Đừng dùng dimension có độ phân giải cao | request ID, timestamp → sinh hàng nghìn metric | | Gộp nhiều điểm dữ liệu vào một lời gọi | giảm chi phí API |

Dòng giữa là bẫy chi phí thật: thêm dimension InstanceId cho 1.000 instance nghĩa là 1.000 metric riêng — hợp lý. Nhưng thêm dimension RequestId sẽ sinh ra hàng triệu metric và hoá đơn tăng vọt.

Vì sao mức dùng bộ nhớ quan trọng mà lại không có sẵn: | Tình huống | Triệu chứng | |---|---| | Rò rỉ bộ nhớ | CPU bình thường, ứng dụng chết dần — CloudWatch mặc định KHÔNG thấy gì | | Chọn sai loại instance | RAM cạn trong khi CPU nhàn rỗi | | Đĩa đầy | ứng dụng lỗi ghi mà không có cảnh báo nào trước đó |

Đây là lý do nên cài agent trên mọi instance sản xuất — hai metric thiếu này lại chính là hai nguyên nhân sự cố phổ biến nhất.

Và một lựa chọn thay thế đáng biết: với ứng dụng container trên ECS hoặc EKS, CloudWatch Container Insights thu thập sẵn metric bộ nhớ ở mức task và pod — không cần cấu hình agent thủ công cho từng máy.

Đáp án

D — Tạo một AWS KMS key mới và dùng nó để bật encryption helper — cơ chế dựa trên AWS Key Management Service để lưu và mã hoá thông tin nhạy cảm.

Vì sao đúng

Đề nêu yêu cầu chính xác: ngăn các lập trình viên khác, hoặc bất kỳ ai, nhìn thấy thông tin đăng nhập ở dạng rõ — và đòi mức bảo mật cao nhất.

Điểm mấu chốt: Lambda mã hoá biến môi trường theo hai mức, và chúng khác nhau về ai đọc được.

MẶC ĐỊNH (khoá aws/lambda):
    Biến được mã hoá KHI LƯU
    → NHƯNG Console HIỂN THỊ giá trị dạng rõ
    → ai có quyền lambda:GetFunctionConfiguration đều ĐỌC ĐƯỢC

ENCRYPTION HELPER với CMK riêng:
    Giá trị được mã hoá bằng CMK của bạn
    → Console chỉ hiện BẢN MÃ
    → phải có quyền kms:Decrypt trên CMK đó mới đọc được
    → mã hàm tự giải mã lúc chạy

Đây chính là khác biệt mà đề nhắm tới: mặc định bảo vệ dữ liệu khi lưu trên đĩa của AWS, nhưng không bảo vệ khỏi đồng nghiệp có quyền xem cấu hình hàm.

Mã hàm giải mã lúc chạy:

import boto3, os
from base64 import b64decode

def giai_ma(ten_bien):
    ban_ma = os.environ[ten_bien]
    kq = boto3.client('kms').decrypt(
        CiphertextBlob=b64decode(ban_ma),
        EncryptionContext={'LambdaFunctionName': os.environ['AWS_LAMBDA_FUNCTION_NAME']})
    return kq['Plaintext'].decode('utf-8')

MAT_KHAU_DB = giai_ma('MAT_KHAU_DB')

EncryptionContext với tên hàm là chi tiết bảo mật quan trọng: nó ràng buộc bản mã với đúng hàm đó — sao chép biến môi trường sang một hàm khác thì không giải mã được.

Và tách quyền là kết quả cuối cùng: | Ai | Thấy gì | |---|---| | Lập trình viên khác (có quyền xem Lambda) | chỉ chuỗi mã hoá | | Execution role của hàm (có kms:Decrypt) | giá trị thật |

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

• A. Không cần làm gì, vì mặc định Lambda đã mã hoá biến môi trường bằng KMS — đây là phương án gần nhất và phần đầu là sự thật, nhưng nó bỏ sót đúng vấn đề của đề: với khoá mặc định, Console vẫn hiển thị giá trị dạng rõ cho bất kỳ ai xem được cấu hình hàm. Đề hỏi cách ngăn "other developers on the team, or anyone" nhìn thấy.
• C. Lambda không cung cấp mã hoá cho biến môi trường; hãy triển khai mã lên EC2 instance thay thế — sai sự thật: Lambda luôn mã hoá biến môi trường khi lưu. Và chuyển sang EC2 không giải quyết vấn đề quản lý bí mật.
• B. Bật mã hoá SSL dựa trên AWS CloudHSM để lưu và mã hoá thông tin nhạy cảm — nhầm cả hai khái niệm: SSL bảo vệ dữ liệu khi truyền, không phải khi lưu. Và CloudHSM là nơi lưu khoá, không phải cơ chế lưu biến môi trường của Lambda.

Ghi nhớ

Ba mức bảo vệ biến môi trường của Lambda: | Mức | Console hiện gì | Ai đọc được | |---|---|---| | Mặc định (aws/lambda) | giá trị RÕ | ai xem được cấu hình hàm | | CMK riêng, không dùng helper | giá trị rõ | ai xem được cấu hình hàm | | CMK riêng + encryption helper | BẢN MÃ | chỉ ai có kms:Decrypt trên CMK |

Chỉ mức thứ ba đáp ứng yêu cầu "maximum security" của đề.

Ba cách quản lý bí mật cho Lambda — so sánh đầy đủ: | Cách | Xoay vòng | Chia sẻ nhiều hàm | Chi phí | |---|---|---|---| | Biến môi trường + encryption helper | thủ công | không — mỗi hàm một bản | thấp | | SSM Parameter Store (SecureString) | thủ công | ✅ dùng chung | miễn phí (standard) | | AWS Secrets Manager | ✅ TỰ ĐỘNG | ✅ dùng chung | ~0,4 USD/bí mật/tháng |

Với tình huống của đề — bốn môi trường (DEV, SIT, UAT, PROD) và thông tin đăng nhập MongoDB Atlas cùng API bên thứ ba — Secrets Manager thường là lựa chọn tốt hơn: | Lý do | Chi tiết | |---|---| | Một bí mật dùng cho nhiều hàm | không phải cập nhật từng hàm khi đổi mật khẩu | | Xoay vòng tự động | kể cả cho CSDL ngoài AWS, qua Lambda xoay vòng tuỳ chỉnh | | Kiểm toán chi tiết | CloudTrail ghi ai đọc bí mật nào, khi nào | | Phiên bản và staging label | chuyển đổi mượt khi xoay vòng |

Nhưng đề hỏi trong phạm vi các phương án đã cho, và D là lựa chọn đúng trong bốn cái đó.

Ba lưu ý khi dùng bí mật trong Lambda: | Lưu ý | Chi tiết | |---|---| | Cache giá trị đã giải mã ngoài handler | giải mã ở phạm vi module, không phải mỗi lần gọi | | Đừng ghi giá trị ra log | print(mat_khau) là cách nhanh nhất làm hỏng mọi thứ | | Dùng Parameters and Secrets Lambda Extension | cache sẵn, giảm lời gọi API và độ trễ |

Dòng đầu quan trọng cho cả hiệu năng lẫn chi phí: mã ở phạm vi module chỉ chạy khi khởi tạo execution environment, nên một lần giải mã phục vụ hàng nghìn lời gọi.

Ba giới hạn của biến môi trường Lambda: | Giới hạn | Giá trị | |---|---| | Tổng kích thước mọi biến | 4 KB | | Không cập nhật được lúc chạy | phải deploy lại hàm | | Không chia sẻ giữa các hàm | mỗi hàm một bản riêng |

Dòng đầu là ràng buộc thật: bản mã dài hơn bản rõ đáng kể, nên với nhiều bí mật bạn sẽ chạm giới hạn 4 KB nhanh hơn tưởng — thêm một lý do để chuyển sang Secrets Manager khi số lượng bí mật tăng lên.