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

Đáp án

C — Dùng Amazon Athena để phân tích tệp export trong S3 bằng SQL.

Vì sao đúng

Đề nêu ba điều kiện, và Athena khớp cả ba: | Điều kiện | Cơ chế | |---|---| | Tệp CSV ĐÃ NẰM SẴN trong S3 | Athena truy vấn TRỰC TIẾP, không cần nạp đi đâu | | Dùng SQL tiêu chuẩn | Athena dùng Trino/Presto, cú pháp SQL chuẩn | | Rẻ nhất và DỄ NHẤT | không máy chủ, trả tiền theo dữ liệu quét |

Điểm mạnh quyết định: không phải di chuyển dữ liệu.

Ba phương án kia:
    S3 → viết công cụ nạp → cơ sở dữ liệu → truy vấn
        → tốn thời gian, tốn tiền, có hai bản sao dữ liệu

Athena:
    S3 → truy vấn NGAY
        → khai báo bảng rồi chạy SQL

Khai báo bảng và truy vấn:

CREATE EXTERNAL TABLE du_lieu_phan_tich (
  ngay        string,
  nguoi_dung  string,
  su_kien     string,
  gia_tri     double
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES ('separatorChar' = ',', 'quoteChar' = '"')
LOCATION 's3://kho-export/du-lieu-phan-tich/'
TBLPROPERTIES ('skip.header.line.count'='1');

SELECT su_kien, count(*) AS so_luong
FROM du_lieu_phan_tich
GROUP BY su_kien ORDER BY so_luong DESC;

Và mô hình chi phí phù hợp hoàn hảo với việc kiểm chứng một lần:

Athena: ~5 USD mỗi TB dữ liệu QUÉT
    → không có hạ tầng chạy 24/7
    → không truy vấn thì KHÔNG TỐN GÌ

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

• **D. Dùng công cụ nạp CSV vào Amazon Redshift rồi truy vấn — đây là phương án gần nhất và Redshift thực sự là kho dữ liệu OLAP mạnh, nhưng nó quá nặng cho một lần kiểm chứng: phải dựng cụm, thiết kế lược đồ, chạy COPY, và cụm tính phí theo giờ dù không dùng. Đề hỏi "most cost-effective and EASIEST".
• **B. Dùng mysqldump nạp CSV vào MySQL RDS — hai vấn đề: mysqldump là công cụ XUẤT dữ liệu ra, không phải nhập CSV vào (cái đó là LOAD DATA INFILE). Và phải dựng một RDS instance tính phí liên tục cho việc kiểm chứng một lần.
• **A. Nạp CSV vào DynamoDB rồi truy vấn — sai loại cơ sở dữ liệu: DynamoDB là kho khoá–giá trị, không hỗ trợ SQL và không tối ưu cho việc quét toàn bộ và tổng hợp — đúng thứ mà việc kiểm chứng dữ liệu cần làm.

Ghi nhớ

Ba công cụ truy vấn dữ liệu trên S3: | Công cụ | Đặc điểm | Phù hợp | |---|---|---| | Amazon Athena | SQL, KHÔNG máy chủ, trả theo dữ liệu quét | truy vấn thỉnh thoảng, khám phá dữ liệu ← câu này | | Redshift Spectrum | truy vấn S3 từ cụm Redshift | đã có Redshift, cần kết hợp với dữ liệu trong kho | | EMR | cụm Spark/Presto | ETL nặng, xử lý phức tạp |

Quy tắc chọn:

Dữ liệu ĐÃ ở S3, cần SQL, dùng thỉnh thoảng → Athena Truy vấn liên tục, nhiều người dùng, hiệu năng cao nhất → Redshift Xử lý phức tạp vượt quá SQL → EMR

Ba đặc điểm của Athena: | Đặc điểm | Chi tiết | |---|---| | Không có hạ tầng | không dựng, không vá, không mở rộng | | Trả tiền theo DỮ LIỆU QUÉT | ~5 USD/TB — không truy vấn thì 0 đồng | | Dùng Glue Data Catalog | khai báo bảng một lần, Redshift Spectrum và EMR cũng dùng được |

Bốn tối ưu giảm chi phí Athena — ảnh hưởng trực tiếp tới hoá đơn: | Tối ưu | Mức giảm | |---|---| | Chuyển sang Parquet hoặc ORC | 80–90% dữ liệu quét | | Phân vùng theo cột hay lọc | rất lớn | | Nén dữ liệu | đáng kể | | Chọn cột cụ thể thay vì SELECT * | với định dạng cột, chỉ đọc cột cần |

Ví dụ cụ thể:

100 GB CSV, SELECT *              → quét 100 GB → ~0,50 USD
Cùng dữ liệu ở Parquet, chọn 3 cột → quét 2 GB   → ~0,01 USD

Và Athena tự chuyển đổi được sang Parquet bằng CTAS:

CREATE TABLE du_lieu_parquet
WITH (format = 'PARQUET',
      external_location = 's3://kho-export/parquet/')
AS SELECT * FROM du_lieu_phan_tich;

Ba lưu ý khi dùng Athena với CSV: | Lưu ý | Chi tiết | |---|---| | Bỏ qua dòng tiêu đề | TBLPROPERTIES ('skip.header.line.count'='1') | | Chọn đúng SerDe | OpenCSVSerde xử lý được dấu ngoặc kép và dấu phẩy trong giá trị | | OpenCSVSerde đọc mọi cột thành chuỗi | phải CAST khi cần kiểu số hoặc ngày |

Dòng cuối hay gây bất ngờ:

SELECT sum(CAST(gia_tri AS double)) FROM du_lieu_phan_tich;

Ba lưu ý khác: | Lưu ý | Chi tiết | |---|---| | Kết quả truy vấn lưu vào S3 | đặt lifecycle rule dọn thư mục kết quả | | Nhiều tệp NHỎ làm chậm truy vấn | gộp thành tệp 128 MB – 1 GB | | Có hạn mức truy vấn đồng thời | tăng được nếu cần |

Và AWS Glue Crawler tự khai báo bảng giúp bạn, không cần viết CREATE EXTERNAL TABLE bằng tay:

aws glue create-crawler --name crawler-du-lieu-export   --role AWSGlueServiceRole   --database-name kho_phan_tich   --targets '{"S3Targets": [{"Path": "s3://kho-export/du-lieu-phan-tich/"}]}'

Nó tự phát hiện cột, kiểu dữ liệu và phân vùng — tiện khi tệp CSV có hàng chục cột.

Và một lưu ý về công cụ trực quan: nếu cần xem kết quả dưới dạng biểu đồ thay vì bảng số, Amazon QuickSight kết nối trực tiếp với Athena. Với việc kiểm chứng dữ liệu export như đề mô tả, một biểu đồ phân bố thường phát hiện ra bất thường nhanh hơn nhiều so với đọc kết quả SELECT.

Đáp án

D — Phân phối lưu lượng bằng Network Load Balancer và lưu dữ liệu trong Amazon DynamoDB.

Vì sao đúng

Đề cho hai dữ kiện kỹ thuật rất cụ thể, và mỗi cái quyết định một nửa câu trả lời: | Dữ kiện | Kết luận | |---|---| | Giao thức là UDP | chỉ Network Load Balancer hỗ trợ UDP | | Dữ liệu lưu dạng KHOÁ–GIÁ TRỊ (key-value store) | DynamoDB là kho khoá–giá trị |

Vì sao phải là NLB:

Application Load Balancer (tầng 7):
    → chỉ HTTP và HTTPS
    → KHÔNG hiểu UDP

Network Load Balancer (tầng 4):
    → TCP, UDP, TLS
    → giữ nguyên IP nguồn của client
    → độ trễ cực thấp

Và NLB có ba đặc điểm khác rất phù hợp với game nhiều người chơi: | Đặc điểm | Lợi ích cho game | |---|---| | Độ trễ rất thấp | phản hồi nhanh là yếu tố sống còn của game | | Chịu hàng triệu request mỗi giây | game phổ biến có lượng kết nối lớn | | IP tĩnh mỗi AZ | client game giữ được địa chỉ cố định |

Và DynamoDB khớp với "key-value store" mà đề nêu đích danh:

Hồ sơ người chơi:
    partition key = ID người chơi
    → truy cập bằng khoá, độ trễ MILI GIÂY một chữ số
    → tự mở rộng theo số người chơi

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

• **B. Network Load Balancer + Amazon Aurora — đây là phương án gần nhất và phần load balancer hoàn toàn đúng, nhưng nó sai loại cơ sở dữ liệu: Aurora là cơ sở dữ liệu QUAN HỆ. Đề nói rõ dữ liệu lưu trong key-value store.
• **A. Application Load Balancer + DynamoDB — sai load balancer: ALB không hỗ trợ UDP. Phần DynamoDB đúng nhưng vế đầu làm cả phương án không dùng được.
• **C. Application Load Balancer + Amazon RDS — sai cả hai: ALB không hỗ trợ UDP, và RDS là cơ sở dữ liệu quan hệ.

Ghi nhớ

Bốn loại Elastic Load Balancer — bảng cần thuộc: | | ALB | NLB | GWLB | CLB | |---|---|---|---|---| | Tầng | 7 (HTTP/HTTPS) | 4 (TCP/UDP/TLS) | 3 (IP) | 4 và 7 | | UDP | ❌ | ✅ | ✅ | ❌ | | Độ trễ | thấp | cực thấp | thấp | thấp | | IP tĩnh | ❌ (dùng Global Accelerator) | ✅ mỗi AZ một IP | — | ❌ | | Định tuyến theo đường dẫn/host | ✅ | ❌ | ❌ | hạn chế | | Giữ IP nguồn của client | ❌ (dùng X-Forwarded-For) | ✅ | ✅ | ❌ | | Trạng thái | hiện hành | hiện hành | hiện hành | cũ |

Quy tắc chọn:

HTTP/HTTPS, cần định tuyến theo URL → ALB UDP, TCP, cần IP tĩnh, độ trễ cực thấp → NLB Chèn thiết bị bảo mật của bên thứ ba → Gateway Load Balancer

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

"UDP" / "TCP"
"static IP address"
"extreme performance" / "millions of requests per second"
"gaming" / "IoT" / "VoIP"
"preserve source IP"

Đề này có ba trong năm dấu hiệu.

Các dịch vụ cơ sở dữ liệu của AWS theo mô hình dữ liệu: | Mô hình | Dịch vụ | |---|---| | Khoá–giá trị | DynamoDB | | Quan hệ | RDS, Aurora | | Tài liệu | DocumentDB | | Bộ nhớ đệm | ElastiCache, MemoryDB | | Đồ thị | Neptune | | Chuỗi thời gian | Timestream | | Cột rộng | Keyspaces (Cassandra) | | Sổ cái | QLDB |

Ba lý do DynamoDB phù hợp với game nhiều người chơi: | Lý do | Chi tiết | |---|---| | Độ trễ mili giây một chữ số | ổn định bất kể quy mô | | Tự mở rộng không giới hạn | game lan truyền không làm sập database | | DAX cho độ trễ microgiây | cache cho bảng xếp hạng, hồ sơ hay đọc |

Và với game toàn cầu, DynamoDB Global Tables cho phép đọc ghi ở mọi Region — người chơi ở châu Á truy cập bản sao ở châu Á.

Ba lưu ý khi dùng NLB cho game UDP: | Lưu ý | Chi tiết | |---|---| | Health check của NLB dùng TCP hoặc HTTP | KHÔNG có health check UDP — phải mở một cổng TCP để kiểm tra | | NLB không có security group riêng (trước đây) | lưu lượng đi thẳng tới security group của target | | Bật cross-zone load balancing | mặc định TẮT với NLB, và có phí truyền dữ liệu giữa AZ |

Dòng đầu là chi tiết triển khai quan trọng: máy chủ game phải phơi thêm một endpoint TCP hoặc HTTP đơn giản để NLB biết nó còn sống — nếu không, NLB không phát hiện được máy chủ game đã treo.

Và một lựa chọn đáng cân nhắc cho game toàn cầu: AWS Global Accelerator.

Cho hai IP TĨNH ANYCAST toàn cầu
    → người chơi kết nối tới IP gần nhất về mặt mạng
    → lưu lượng đi trên mạng xương sống AWS thay vì Internet công cộng
    → giảm độ trễ và ổn định hơn đáng kể
    → tự chuyển sang Region khác khi có sự cố

Kết hợp Global Accelerator + NLB là kiến trúc chuẩn cho game nhiều người chơi trên toàn cầu.

Và một lưu ý về thiết kế bảng DynamoDB cho game: hãy chọn partition key có độ phân biệt cao (ID người chơi thay vì ID khu vực) để tránh hot partition. Với bảng xếp hạng cần sắp xếp theo điểm, dùng GSI với điểm làm sort key — nhưng nhớ rằng GSI có dung lượng riêng và cũng bị throttle độc lập.

Đáp án

A và C.

• A — Cấp quyền đọc công khai cho object khi tải lên qua S3 Console
• C — Cấu hình bucket policy đặt mọi object thành public read

Vì sao đúng

Đề hỏi cách làm cho mọi object trong bucket đọc được công khai — và S3 có hai cơ chế cấp quyền cho việc đó.

A — cấp quyền ở mức TỪNG OBJECT (qua ACL):

Khi tải lên, chọn "Grant public-read access"
    → object đó nhận ACL public-read
    → ai cũng đọc được object đó

aws s3 cp trang-chu.css s3://kho-tai-nguyen/ --acl public-read

C — cấp quyền ở mức TOÀN BUCKET (qua bucket policy):

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChoPhepDocCongKhai",
   "Effect": "Allow",
   "Principal": "*",
   "Action": "s3:GetObject",
   "Resource": "arn:aws:s3:::kho-tai-nguyen/*"}]}

Bucket policy là cách được khuyến nghị hơn hẳn: | | ACL từng object | Bucket policy | |---|---|---| | Áp cho object MỚI | ❌ phải nhớ đặt mỗi lần | ✅ TỰ ĐỘNG | | Quản lý | phân tán, khó rà soát | tập trung, một chỗ | | Trạng thái | AWS khuyến nghị TRÁNH dùng | hiện hành |

Vế "ALL of the objects uploaded" trong đề nghiêng hẳn về bucket policy — ACL đòi nhớ đặt cho từng tệp, và quên một lần là tệp đó hỏng.

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

• **B. Cấu hình CORS để cho phép object truy cập được công khai từ mọi tên miền — đây là phương án gần nhất và hay bị nhầm với kiểm soát truy cập, nhưng CORS KHÔNG cấp quyền gì: nó chỉ quy định trình duyệt có cho JavaScript từ tên miền A gọi tài nguyên ở tên miền B hay không. Object vẫn phải được cấp quyền công khai bằng ACL hoặc bucket policy thì CORS mới có ý nghĩa.
• **D. Tạo IAM role để đặt object thành public read — sai cơ chế: IAM role cấp quyền cho thực thể AWS ĐÃ XÁC THỰC. Người dùng Internet ẩn danh không đảm nhận role nào — nên IAM không phải công cụ cho truy cập công khai.
• **E. Không làm gì, object S3 vốn đã công khai — hoàn toàn sai: S3 mặc định RIÊNG TƯ. Đây là mặc định an toàn quan trọng nhất của S3.

Ghi nhớ

Một điều kiện bắt buộc mà câu hỏi không nhắc tới: Block Public Access phải TẮT.

Từ tháng 4/2023, mọi bucket MỚI mặc định:
    ✓ Block Public Access = BẬT
    ✓ ACL bị vô hiệu hoá (Object Ownership = Bucket owner enforced)
        ↓
    → cả hai đáp án A và C đều KHÔNG có tác dụng
    → phải TẮT Block Public Access trước

aws s3api put-public-access-block --bucket kho-tai-nguyen   --public-access-block-configuration   "BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false"

Và để dùng được ACL, phải bật lại chúng:

aws s3api put-bucket-ownership-controls --bucket kho-tai-nguyen   --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerPreferred}]'

Bốn công tắc của Block Public Access: | Công tắc | Chặn | |---|---| | BlockPublicAcls | tạo MỚI ACL công khai | | IgnorePublicAcls | BỎ QUA mọi ACL công khai đã có | | BlockPublicPolicy | đặt bucket policy công khai | | RestrictPublicBuckets | hạn chế truy cập qua policy công khai |

Bốn cách kiểm soát truy cập S3: | Cách | Phạm vi | Trạng thái | |---|---|---| | Bucket policy | cả bucket hoặc theo prefix | được khuyến nghị | | IAM policy | theo người dùng, role | cho truy cập đã xác thực | | ACL | từng object hoặc bucket | cũ — AWS khuyên tránh | | S3 Access Point | nhóm người dùng khác nhau | cho bucket dùng chung phức tạp |

Và với "static assets cho ứng dụng web công khai" như đề mô tả, có một cách TỐT HƠN hẳn việc mở bucket công khai:

CloudFront + Origin Access Control: | Lợi ích | Chi tiết | |---|---| | Bucket vẫn RIÊNG TƯ hoàn toàn | giảm rủi ro cấu hình sai | | Cache tại hơn 600 điểm biên | nhanh hơn nhiều cho người dùng toàn cầu | | Rẻ hơn | S3 → CloudFront MIỄN PHÍ; S3 → Internet ~0,09 USD/GB | | Có HTTPS, WAF, chống DDoS | Shield Standard sẵn có |

Đây là kiến trúc chuẩn cho website tĩnh hiện nay — mở bucket công khai là cách làm cũ và có rủi ro.

Vì sao bucket công khai nguy hiểm:

Rất nhiều vụ rò rỉ dữ liệu lớn bắt nguồn từ bucket S3 cấu hình công khai nhầm
    → AWS phản ứng bằng cách bật Block Public Access mặc định
    → và vô hiệu hoá ACL cho bucket mới

Ba công cụ phát hiện bucket công khai: | Công cụ | Việc | |---|---| | IAM Access Analyzer for S3 | liệt kê bucket truy cập được từ ngoài | | AWS Config rule s3-bucket-public-read-prohibited | phát hiện liên tục | | Trusted Advisor | kiểm tra quyền bucket |

Và khi nào mở bucket công khai là hợp lý: | Trường hợp | Ghi chú | |---|---| | Website tĩnh dùng S3 static website hosting | endpoint website không hỗ trợ HTTPS | | Bộ dữ liệu công cộng cố ý chia sẻ | kèm Requester Pays nếu muốn chuyển chi phí |

Lưu ý về S3 static website hosting: endpoint dạng bucket.s3-website-region.amazonaws.com chỉ hỗ trợ HTTP, không có HTTPS. Muốn HTTPS bắt buộc phải đặt CloudFront phía trước — thêm một lý do nữa để dùng CloudFront.

Và một lời khuyên khi phải mở công khai: chỉ mở đúng prefix cần thiết, đừng mở cả bucket:

"Resource": "arn:aws:s3:::kho-tai-nguyen/cong-khai/*"

Như vậy các tệp cấu hình hay dữ liệu nội bộ vô tình đặt trong cùng bucket vẫn được bảo vệ.

Đáp án

C — Xây dựng một custom identity broker tại chỗ và dùng AWS STS để cấp thông tin đăng nhập AWS ngắn hạn.

Vì sao đúng

Đề cho một ràng buộc quyết định: kho danh tính hiện tại KHÔNG tương thích SAML.

Và đó là điều kiện loại bỏ mọi cơ chế liên kết danh tính dựng sẵn:

Mọi tích hợp danh tính doanh nghiệp chuẩn của AWS đều dựa trên SAML 2.0
    → không hỗ trợ SAML → không dùng được cách chuẩn
    ↓
Còn lại: TỰ VIẾT một identity broker gọi STS

Cách custom identity broker hoạt động:

① Người dùng đăng nhập vào ứng dụng broker (tại chỗ)
② Broker xác thực với LDAP theo cách riêng của nó
③ Broker gọi STS:
      AssumeRole  hoặc  GetFederationToken
④ STS trả về thông tin đăng nhập TẠM THỜI
      (access key + secret key + session token, có hạn)
⑤ Broker chuyển cho người dùng, hoặc tạo URL đăng nhập Console

sts = boto3.client('sts')
r = sts.assume_role(
    RoleArn='arn:aws:iam::123456789012:role/vai-tro-nhan-vien',
    RoleSessionName=ten_dang_nhap_ldap,
    DurationSeconds=3600)
tin_dang_nhap = r['Credentials']   # hết hạn sau 1 giờ

Và điểm mạnh cốt lõi: KHÔNG tạo IAM user cho từng nhân viên.

Thông tin đăng nhập TẠM THỜI, tự hết hạn
    → không có access key dài hạn để rò rỉ
    → nhân viên nghỉ việc: xoá ở LDAP là mất quyền ngay
    → không phải đồng bộ hai hệ thống người dùng

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

• **B. Dùng AWS IAM Identity Center để quản lý truy cập giữa AWS và LDAP — đây là phương án gần nhất và là công cụ đúng cho hầu hết trường hợp, nhưng nó không dùng được với ràng buộc của đề: IAM Identity Center kết nối với SAML 2.0, AWS Managed Microsoft AD, AD Connector, hoặc thư mục nội bộ của chính nó. Đề nói rõ kho danh tính không tương thích SAML.
• **A. Dùng IAM policy tham chiếu định danh LDAP và thông tin đăng nhập AWS — không có cơ chế như vậy: IAM policy chỉ hiểu principal của AWS (IAM user, role, service). Nó không đọc được danh tính LDAP.
• **D. Dùng IAM role để xoay vòng thông tin đăng nhập mỗi khi LDAP đổi — hiểu sai cách role hoạt động: IAM role không "xoay vòng theo LDAP". Và không có cơ chế liên kết tự động giữa việc đổi mật khẩu LDAP với thông tin đăng nhập AWS.

Ghi nhớ

Các cách liên kết danh tính với AWS — theo thứ tự ưu tiên: | Cách | Yêu cầu | Trạng thái | |---|---|---| | IAM Identity Center | SAML 2.0, AD, hoặc thư mục nội bộ | được khuyến nghị | | SAML 2.0 federation trực tiếp | IdP hỗ trợ SAML | phổ biến | | OIDC / web identity federation | Google, Facebook, Cognito | cho ứng dụng người dùng cuối | | Custom identity broker + STS | BẤT KỲ kho danh tính nào | khi các cách trên không dùng được ← câu này |

Quy tắc nhận diện trong đề thi:

"not SAML-compatible", "custom identity store", "legacy directory" → custom identity broker + STS "SAML 2.0", "Active Directory", "corporate directory" → IAM Identity Center "mobile app", "social login", "Google/Facebook" → Cognito

Hai API của STS cho liên kết danh tính: | API | Đặc điểm | |---|---| | AssumeRole | người gọi cần thông tin đăng nhập IAM; thời hạn 15 phút – 12 giờ | | GetFederationToken | thời hạn 15 phút – 36 GIỜ; quyền là GIAO của policy người gọi và policy truyền vào |

GetFederationToken được thiết kế riêng cho mô hình identity broker — nó cho thời hạn dài hơn và cho phép truyền policy giới hạn phạm vi ngay tại thời điểm gọi.

Ba API khác của STS đáng biết: | API | Dùng cho | |---|---| | AssumeRoleWithSAML | liên kết SAML | | AssumeRoleWithWebIdentity | Cognito, Google, Facebook | | GetSessionToken | thêm MFA cho phiên làm việc |

Tạo URL đăng nhập Console từ thông tin đăng nhập tạm thời:

phien = json.dumps({
    'sessionId':    tin_dang_nhap['AccessKeyId'],
    'sessionKey':   tin_dang_nhap['SecretAccessKey'],
    'sessionToken': tin_dang_nhap['SessionToken']})

r = requests.get('https://signin.aws.amazon.com/federation',
                 params={'Action': 'getSigninToken', 'Session': phien})
ma_thong = json.loads(r.text)['SigninToken']

url = ('https://signin.aws.amazon.com/federation'
       f'?Action=login&Issuer=cong-ty.com'
       f'&Destination={quote("https://console.aws.amazon.com/")}'
       f'&SigninToken={ma_thong}')

Đây là cách cho nhân viên vào AWS Console mà không cần IAM user nào.

Ba trách nhiệm của một identity broker: | Trách nhiệm | Chi tiết | |---|---| | Xác thực với kho danh tính | LDAP, hệ thống nội bộ | | Ánh xạ người dùng sang IAM role | theo nhóm LDAP — kiểm soát quyền tối thiểu | | Gọi STS và trả thông tin đăng nhập | không lưu trữ chúng lâu dài |

Ánh xạ nhóm sang role là chỗ thực thi quyền tối thiểu:

Nhóm LDAP "ky-su-ha-tang"  → role "quan-tri-ha-tang"
Nhóm LDAP "ke-toan"        → role "chi-doc-bao-cao-chi-phi"

Ba lưu ý bảo mật khi tự viết broker: | Lưu ý | Chi tiết | |---|---| | Broker cần thông tin đăng nhập IAM để gọi STS | bảo vệ nó rất kỹ — nó là chìa khoá vào toàn bộ hệ thống | | Đặt thời hạn phiên ngắn | 1 giờ cho thao tác thông thường | | Ghi log mọi lần cấp thông tin đăng nhập | phục vụ kiểm toán |

Và một khuyến nghị dài hạn cho tình huống của đề: cân nhắc thêm một lớp trung gian hỗ trợ SAML. Nhiều nhà cung cấp danh tính (Keycloak, Okta, Entra ID) đọc được LDAP và phơi ra SAML 2.0 — dựng một lớp như vậy cho phép dùng IAM Identity Center thay vì tự bảo trì broker. Tự viết broker là giải pháp đúng khi không còn cách nào khác, nhưng nó là mã bảo mật quan trọng mà bạn phải tự chịu trách nhiệm mãi về sau.

Đáp án

A — Dùng AWS Config managed rule kiểm tra access key chưa được xoay vòng trong 90 ngày; tạo EventBridge rule cho các khoá không tuân thủ, đích là Lambda function để vô hiệu hoá và xoá khoá.

Vì sao đúng

Đề cần tự động vô hiệu hoá và xoá access key quá 90 ngày, với ÍT CÔNG NHẤT — và phương án này tận dụng tối đa thứ AWS đã có sẵn.

Vì sao dùng managed rule là ít công nhất:

AWS Config có sẵn rule access-keys-rotated
    → không phải viết mã phát hiện
    → không phải phân trang qua danh sách IAM user
    → không phải tự tính tuổi khoá
    → chỉ khai một tham số: maxAccessKeyAge = 90

{"ConfigRuleName": "kiem-tra-tuoi-access-key",
 "Source": {"Owner": "AWS", "SourceIdentifier": "ACCESS_KEYS_ROTATED"},
 "InputParameters": "{\"maxAccessKeyAge\":\"90\"}"}

Và EventBridge bắt sự kiện thay đổi trạng thái tuân thủ:

{"source": ["aws.config"],
 "detail-type": ["Config Rules Compliance Change"],
 "detail": {
   "configRuleName": ["kiem-tra-tuoi-access-key"],
   "newEvaluationResult": {"complianceType": ["NON_COMPLIANT"]}}}

Luồng hoàn chỉnh — hướng sự kiện, không phải quét định kỳ:

AWS Config đánh giá liên tục
    → phát hiện khoá quá 90 ngày → NON_COMPLIANT
    → phát sự kiện
EventBridge bắt sự kiện
    → gọi Lambda
Lambda vô hiệu hoá rồi xoá khoá

Lambda chỉ cần làm phần hành động, không cần phần phát hiện:

def lambda_handler(event, context):
    iam = boto3.client('iam')
    res_id = event['detail']['resourceId']
    for k in iam.list_access_keys(UserName=res_id)['AccessKeyMetadata']:
        if (datetime.now(timezone.utc) - k['CreateDate']).days > 90:
            iam.update_access_key(UserName=res_id,
                                  AccessKeyId=k['AccessKeyId'], Status='Inactive')
            iam.delete_access_key(UserName=res_id, AccessKeyId=k['AccessKeyId'])

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

• **C. Tạo custom AWS Config rule kiểm tra tuổi khoá; chạy AWS Batch job mỗi 24 giờ để xoá — thừa công ở hai chỗ: đã có managed rule sẵn, viết custom rule là làm lại từ đầu. Và AWS Batch là dịch vụ cho tính toán theo lô quy mô lớn — dùng nó để gọi vài API IAM là quá nặng; Lambda phù hợp hơn hẳn.
• **D. Tạo EventBridge rule LỌC access key quá 90 ngày rồi gọi Lambda — đây là phương án gần nhất và có kiến trúc gọn, nhưng nó sai về khả năng của EventBridge: EventBridge định tuyến SỰ KIỆN, nó không quét trạng thái tài nguyên. Không có sự kiện nào tự phát ra khi một khoá "đủ 90 ngày tuổi" — phải có thứ gì đó đánh giá điều kiện đó, và đó chính là vai trò của AWS Config.
• **B. EventBridge rule lọc khoá quá 90 ngày + AWS Batch job mỗi 24 giờ — cùng lỗi về EventBridge, cộng thêm việc dùng AWS Batch không phù hợp.

Ghi nhớ

Vai trò của từng dịch vụ trong giải pháp — đừng nhầm: | Dịch vụ | Việc | |---|---| | AWS Config | ĐÁNH GIÁ trạng thái tài nguyên so với quy tắc | | EventBridge | ĐỊNH TUYẾN sự kiện tới đích | | Lambda | THỰC HIỆN hành động |

EventBridge không tự phát hiện điều kiện — nó chỉ phản ứng với sự kiện do dịch vụ khác phát ra hoặc theo lịch cố định.

Các managed rule của Config liên quan tới IAM: | Rule | Kiểm tra | |---|---| | access-keys-rotated | access key quá N ngày chưa xoay ← câu này | | iam-user-mfa-enabled | người dùng đã bật MFA chưa | | iam-password-policy | chính sách mật khẩu của tài khoản | | iam-user-unused-credentials-check | thông tin đăng nhập không dùng quá N ngày | | iam-root-access-key-check | root có access key không | | iam-policy-no-statements-with-admin-access | policy có quyền quản trị đầy đủ |

AWS Config có hơn 300 managed rule — trước khi viết custom rule, hãy tìm xem đã có sẵn chưa.

Và Config có cơ chế tự khắc phục dựng sẵn (remediation), không cần Lambda:

{"ConfigRuleName": "kiem-tra-tuoi-access-key",
 "TargetType": "SSM_DOCUMENT",
 "TargetId": "AWSConfigRemediation-RevokeUnusedIAMUserCredentials",
 "Automatic": true}

Đây là cách còn ít công hơn nữa — dùng SSM Automation document có sẵn thay vì tự viết Lambda. (Phương án A vẫn đúng theo bộ đề và linh hoạt hơn khi cần logic riêng.)

Ba loại rule trong AWS Config: | Loại | Đặc điểm | |---|---| | Managed rule | hơn 300 rule dựng sẵn, chỉ khai tham số | | Custom rule (Lambda) | logic riêng bằng mã | | Custom Policy rule (Guard) | viết bằng ngôn ngữ Guard, không cần Lambda |

Hai cơ chế kích hoạt đánh giá: | Cơ chế | Khi nào chạy | |---|---| | Configuration change | ngay khi tài nguyên thay đổi | | Periodic | theo chu kỳ — phù hợp với kiểm tra theo TUỔI |

access-keys-rotated là rule kiểu periodic — vì tuổi khoá thay đổi theo thời gian chứ không theo sự kiện cấu hình.

Và một hướng giải quyết căn bản hơn: bỏ hẳn access key. | Thay cho | Dùng | |---|---| | Access key trên EC2 | IAM role gắn vào instance | | Access key trong CI/CD | OIDC federation (GitHub Actions, GitLab) | | Access key cho nhân viên | IAM Identity Center với thông tin đăng nhập tạm thời | | Access key trên máy lập trình viên | aws sso login |

Access key dài hạn là loại thông tin đăng nhập rủi ro nhất trên AWS — chúng không tự hết hạn, dễ lọt vào Git, và là nguyên nhân của phần lớn các vụ tài khoản AWS bị chiếm dụng. Với lập trình viên như trong đề, IAM Identity Center kèm SSO loại bỏ hoàn toàn nhu cầu dùng access key.

Ba biện pháp bổ sung nên có: | Biện pháp | Chi tiết | |---|---| | SCP chặn tạo access key mới | iam:CreateAccessKey bị Deny cho tài khoản lập trình viên | | Cảnh báo trước khi xoá | báo trước 7 ngày để chủ khoá kịp xoay vòng | | IAM Credential Report | báo cáo CSV liệt kê tuổi mọi khoá của mọi người dùng |

Dòng giữa là lưu ý vận hành quan trọng: xoá khoá đột ngột sẽ làm hỏng quy trình tự động đang chạy của lập trình viên. Hãy vô hiệu hoá trước, chờ vài ngày rồi mới xoá — và gửi thông báo trước đó.

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

Đáp án

C — DNS resolution và DNS hostname của VPC phải được BẬT.

Vì sao đúng

Đề mô tả triệu chứng chính xác: instance trong VPC mới tạo không có DNS hostname.

Và nguyên nhân nằm ở hai thuộc tính của VPC: | Thuộc tính | Việc | |---|---| | enableDnsSupport | cho phép dùng máy chủ DNS của Amazon trong VPC | | enableDnsHostnames | CẤP tên DNS công khai cho instance có IP công khai |

Và mặc định khác nhau giữa VPC mặc định và VPC bạn tự tạo:

VPC MẶC ĐỊNH (do AWS tạo sẵn):
    enableDnsSupport   = true
    enableDnsHostnames = true    ← có DNS hostname

VPC bạn TỰ TẠO:
    enableDnsSupport   = true
    enableDnsHostnames = FALSE   ← KHÔNG có DNS hostname

Đề nói rõ "newly created VPC" — nên enableDnsHostnames đang tắt, đúng như mặc định.

Cách sửa:

aws ec2 modify-vpc-attribute --vpc-id vpc-0abc123 --enable-dns-hostnames
aws ec2 modify-vpc-attribute --vpc-id vpc-0abc123 --enable-dns-support

Sau khi bật, instance nhận tên dạng:

ec2-203-0-113-25.ap-southeast-1.compute.amazonaws.com   (công khai)
ip-10-0-1-25.ap-southeast-1.compute.internal            (riêng tư)

Lưu ý: chỉ instance có IP công khai mới nhận DNS hostname công khai — instance trong private subnet chỉ có tên nội bộ.

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

• **B. Amazon Route 53 chưa được bật — đây là phương án gần nhất vì cũng nói về DNS, nhưng nó nhầm dịch vụ: DNS hostname của EC2 do máy chủ DNS NỘI BỘ của VPC cấp (địa chỉ .2 trong dải CIDR), không phải Route 53. Route 53 là dịch vụ DNS công khai cho tên miền của bạn, và nó không có công tắc "bật/tắt" nào cả.
• **A. VPC có CIDR block không hợp lệ — không phải nguyên nhân: CIDR không hợp lệ thì VPC không tạo được ngay từ đầu. Đề nói VPC đã tạo xong và instance đã khởi chạy.
• **D. Security group của instance cần được sửa — giải quyết vấn đề khác: security group kiểm soát lưu lượng mạng vào ra. Nó không liên quan gì tới việc instance có được cấp tên DNS hay không.

Ghi nhớ

Hai thuộc tính DNS của VPC — bảng cần thuộc: | Thuộc tính | Tác dụng | VPC mặc định | VPC tự tạo | |---|---|---|---| | enableDnsSupport | DNS resolver của Amazon hoạt động trong VPC | true | true | | enableDnsHostnames | cấp tên DNS công khai cho instance | true | false |

Đây là một trong những khác biệt quan trọng nhất giữa VPC mặc định và VPC tự tạo.

Bốn hệ quả khi hai thuộc tính này tắt: | Hệ quả | Chi tiết | |---|---| | Instance không có DNS hostname | ← câu này | | RDS endpoint không phân giải được | RDS luôn trả về tên DNS, không trả IP | | VPC endpoint với private DNS không hoạt động | cần cả hai thuộc tính bật | | Route 53 private hosted zone không hoạt động | cần enableDnsSupport |

Dòng thứ hai là sự cố rất hay gặp: dựng RDS trong VPC tự tạo rồi ứng dụng báo "unknown host" — nguyên nhân là enableDnsSupport tắt.

Địa chỉ máy chủ DNS trong VPC:

VPC CIDR 10.0.0.0/16
    → DNS resolver ở 10.0.0.2   (địa chỉ cơ sở + 2)
    → hoặc địa chỉ cố định 169.254.169.253

Năm địa chỉ AWS giữ trong mỗi subnet: | Địa chỉ | Dùng cho | |---|---| | .0 | địa chỉ mạng | | .1 | router của VPC | | .2 | máy chủ DNS | | .3 | dành riêng cho tương lai | | địa chỉ cuối | broadcast |

Ba tính năng DNS nâng cao của VPC: | Tính năng | Việc | |---|---| | Route 53 Resolver inbound endpoint | cho phép mạng TẠI CHỖ phân giải tên trong VPC | | Route 53 Resolver outbound endpoint | cho phép VPC phân giải tên của mạng TẠI CHỖ | | Private hosted zone | tên miền riêng chỉ phân giải được trong VPC |

Hai endpoint đầu là thành phần bắt buộc của kiến trúc lai — kết nối mạng thông suốt qua Direct Connect hay VPN vẫn chưa đủ để hai bên gọi nhau bằng tên miền.

Tuỳ chọn Hostname type khi khởi chạy instance: | Loại | Ví dụ | |---|---| | IP-based (mặc định) | ip-10-0-1-25.ap-southeast-1.compute.internal | | Resource-based | i-0abc123def456.ap-southeast-1.compute.internal |

Resource-based hostname ổn định hơn: nó không đổi khi instance đổi IP riêng — hữu ích cho hệ thống tham chiếu máy chủ bằng tên.

Ba lưu ý về DHCP options set: | Lưu ý | Chi tiết | |---|---| | Mặc định dùng AmazonProvidedDNS | máy chủ DNS của VPC | | Đổi sang DNS riêng được | ví dụ trỏ về Active Directory tại chỗ | | Đổi DHCP options cần khởi động lại instance | hoặc gia hạn DHCP lease để có hiệu lực |

Nếu đổi DHCP options set sang máy chủ DNS riêng, hãy nhớ máy chủ đó phải chuyển tiếp được các truy vấn về dịch vụ AWS — nếu không, instance sẽ không phân giải được endpoint của S3, DynamoDB và các dịch vụ khác.

Và một lời khuyên khi dựng VPC mới: hãy dùng CloudFormation hoặc Terraform với một template chuẩn đã bật sẵn hai thuộc tính này, thay vì tạo tay qua Console mỗi lần. Đây đúng là loại chi tiết dễ quên và chỉ lộ ra khi ứng dụng đã triển khai xong.

Đáp án

B — Dùng Amazon Textract để trích xuất văn bản từ báo cáo PDF; tích hợp Amazon Comprehend Medical vào Lambda function hiện có để nhận diện thông tin sức khoẻ được bảo vệ (PHI).

Vì sao đúng

Đề cần nhận diện PHI trong báo cáo PDF, với ÍT THAY ĐỔI NHẤT cho Lambda hiện có — và cặp Textract + Comprehend Medical là hai dịch vụ chuyên dụng cho đúng việc đó.

Textract đọc được PDF là ảnh quét:

PDF báo cáo y tế thường là bản QUÉT
    → không phải văn bản chọn được
    → thư viện đọc PDF thông thường trả về rỗng
    ↓
Textract dùng OCR và học máy:
    → trích xuất văn bản, BẢNG, và BIỂU MẪU
    → giữ được cấu trúc, không chỉ chuỗi ký tự thô

Và Comprehend Medical được huấn luyện riêng cho văn bản y tế:

r = comprehend_medical.detect_phi(Text=van_ban)
for e in r['Entities']:
    print(e['Type'], e['Text'], e['Score'])
# NAME        Nguyen Van A    0.99
# AGE         45              0.98
# ID          BN-2026-0831    0.97

API detect_phi nhận diện đúng các loại PHI theo định nghĩa của HIPAA — tên, tuổi, địa chỉ, số hồ sơ, ngày tháng, số điện thoại, email.

Và "least operational overhead" được đáp ứng vì cả hai đều là API được quản lý sẵn:

Không huấn luyện mô hình
Không triển khai endpoint
Không bảo trì thuật toán
    → gọi API là xong

Vế "with minimal changes in the existing Lambda function": chỉ cần thêm hai lời gọi API vào hàm đang có, không phải viết lại kiến trúc.

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

• **A. Dùng Amazon Textract Medical với PII redaction để lọc văn bản; tạo Lambda MỚI gọi Comprehend thường — hai lỗi: "Amazon Textract Medical" KHÔNG TỒN TẠI (dịch vụ y tế là Comprehend Medical). Và Comprehend thường chỉ nhận diện PII chung chung, kém chính xác hơn nhiều so với Comprehend Medical trên văn bản y tế. Ngoài ra tạo hàm mới là thêm thay đổi, ngược yêu cầu.
• **D. Dùng Textract với StartDocumentTextDetection rồi phân tích bằng thuật toán phát hiện PHI TỰ VIẾT trong Lambda — phần Textract đúng nhưng phần sau nhiều công nhất: tự viết thuật toán nhận diện PHI nghĩa là tự xây và bảo trì mô hình NLP y tế — đúng thứ mà "least operational overhead" loại bỏ.
• **C. Dùng Amazon Transcribe đọc PDF bằng StartTranscriptionJob; dùng CloudWatch Logs phát hiện PHI — sai hoàn toàn: Transcribe chuyển GIỌNG NÓI thành văn bản, nó không đọc PDF. Và CloudWatch Logs lưu log, nó không phân tích nội dung y tế.

Ghi nhớ về chất lượng câu hỏi

Đề nêu hai yêu cầu, nhưng các phương án chỉ giải quyết một.

Yêu cầu ①: "liên tục giám sát thao tác S3 API ở mức OBJECT"
Yêu cầu ②: "nhận diện PHI trong báo cáo"
    ↓
Bốn phương án đều chỉ bàn về ②

Không phương án nào đề cập tới việc giám sát thao tác object-level của S3 — việc đó cần CloudTrail data event hoặc GuardDuty S3 Protection. Đáp án B là lựa chọn tốt nhất cho yêu cầu ②, và đó là cách câu hỏi được chấm.

Trong thực tế, Amazon Macie giải quyết được CẢ HAI:

Macie:
    ✓ giám sát liên tục bucket S3 và phát hiện cấu hình rủi ro
    ✓ tự phát hiện dữ liệu nhạy cảm bao gồm PHI
    ✓ tích hợp với Security Hub và EventBridge

Macie không nằm trong các phương án, nhưng nó là công cụ đúng cho yêu cầu "continuously monitors object-level S3 API operations and identifies PHI".

Ghi nhớ

Các dịch vụ AI đọc tài liệu và văn bản của AWS: | Dịch vụ | Đầu vào → đầu ra | |---|---| | Textract | tài liệu quét → văn bản, BẢNG, BIỂU MẪU | | Comprehend | văn bản → cảm xúc, thực thể, chủ đề, PII | | Comprehend Medical | văn bản Y TẾ → PHI, thuốc, chẩn đoán, mã ICD-10 | | Transcribe | giọng nói → văn bản | | Transcribe Medical | giọng nói y tế → văn bản | | Polly | văn bản → giọng nói | | Rekognition | ảnh và video → nhãn, khuôn mặt |

Chú ý: có Comprehend Medical và Transcribe Medical, nhưng KHÔNG có "Textract Medical".

Bốn API của Comprehend Medical: | API | Việc | |---|---| | DetectPHI | nhận diện thông tin sức khoẻ được bảo vệ ← câu này | | DetectEntitiesV2 | thuốc, triệu chứng, chẩn đoán, giải phẫu | | InferICD10CM | ánh xạ sang mã chẩn đoán ICD-10 | | InferRxNorm | ánh xạ sang mã thuốc RxNorm |

Ba API của Textract: | API | Việc | |---|---| | DetectDocumentText | chỉ văn bản thuần | | AnalyzeDocument | văn bản + BẢNG + BIỂU MẪU (cặp khoá–giá trị) | | AnalyzeExpense | hoá đơn, biên lai |

Với báo cáo y tế có bảng kết quả xét nghiệm, AnalyzeDocument với FeatureTypes: ["TABLES", "FORMS"] cho kết quả hữu ích hơn nhiều so với văn bản thuần — nó giữ được quan hệ giữa tên chỉ số và giá trị.

API đồng bộ và bất đồng bộ: | Loại | API | Giới hạn | |---|---|---| | Đồng bộ | DetectDocumentText, AnalyzeDocument | tối đa 1 trang, dưới 10 MB | | Bất đồng bộ | StartDocumentTextDetection, StartDocumentAnalysis | PDF nhiều trang, tới 3.000 trang |

Báo cáo y tế thường nhiều trang, nên phải dùng API bất đồng bộ — nó trả về job ID, và kết quả lấy về khi job xong (qua SNS notification hoặc polling).

Ba yêu cầu tuân thủ HIPAA trên AWS: | Yêu cầu | Chi tiết | |---|---| | Ký BAA với AWS | Business Associate Addendum — bắt buộc về pháp lý | | Chỉ dùng dịch vụ đủ điều kiện HIPAA | Textract, Comprehend Medical, S3, Lambda đều nằm trong danh sách | | Mã hoá at rest và in transit | KMS + bắt buộc HTTPS |

Ba biện pháp bổ sung cho vế "visibility" mà đề nêu: | Biện pháp | Việc | |---|---| | CloudTrail data event cho bucket S3 | ghi MỌI thao tác object-level: ai đọc tệp nào, lúc nào | | GuardDuty S3 Protection | phát hiện truy cập bất thường | | Amazon Macie | quét và phân loại dữ liệu nhạy cảm trong bucket |

CloudTrail data event là thứ trực tiếp đáp ứng "continuously monitors object-level S3 API operations":

aws cloudtrail put-event-selectors --trail-name theo-doi-bao-cao-y-te   --advanced-event-selectors '[{
    "Name": "Ghi moi thao tac object",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
      {"Field": "resources.ARN", "StartsWith": ["arn:aws:s3:::kho-bao-cao-y-te/"]}]}]'

Lưu ý: data event tính phí riêng theo số sự kiện — với bucket có lưu lượng lớn, khoản này đáng kể, nên hãy giới hạn phạm vi theo prefix.

Và một lời khuyên về xử lý PHI: sau khi Comprehend Medical nhận diện được PHI, hãy cân nhắc lưu bản đã che thông tin cho các mục đích phân tích, và giữ bản gốc trong bucket riêng với quyền truy cập chặt hơn. Nguyên tắc quyền tối thiểu áp cho dữ liệu cũng như cho con người — phần lớn công việc phân tích không cần biết tên bệnh nhân.

Đáp án

D — Yêu cầu chứng chỉ công khai ở Region us-east-2 bằng ACM; tạo regional API Gateway domain name gắn với api.tutorialsdojo.com và chứng chỉ đó; trong Route 53 tạo alias record trỏ tới domain name của API Gateway.

Vì sao đúng

Đề cho một chi tiết quyết định: API Gateway là loại REGIONAL và nằm ở us-east-2.

Và quy tắc Region của chứng chỉ ACM phụ thuộc vào loại endpoint: | Loại endpoint API Gateway | Chứng chỉ phải ở Region | |---|---| | Regional | CÙNG Region với API ← đề này: us-east-2 | | Edge-optimized | BẮT BUỘC us-east-1 | | Private | cùng Region với API |

Vì sao edge-optimized cần us-east-1: nó dùng CloudFront phía sau, và CloudFront chỉ đọc chứng chỉ từ us-east-1. Regional endpoint không qua CloudFront nên dùng chứng chỉ cùng Region.

Ba bước hoàn chỉnh:

# ① Yêu cầu chứng chỉ ở ĐÚNG Region
aws acm request-certificate --region us-east-2   --domain-name api.tutorialsdojo.com --validation-method DNS

# ② Tạo custom domain name cho API Gateway
aws apigateway create-domain-name --region us-east-2   --domain-name api.tutorialsdojo.com   --regional-certificate-arn <arn-chung-chi>   --endpoint-configuration types=REGIONAL

# ③ Ánh xạ API và stage vào domain name
aws apigateway create-base-path-mapping --region us-east-2   --domain-name api.tutorialsdojo.com --rest-api-id <api-id> --stage prod

Và bước cuối trong Route 53 phải là ALIAS record, không phải CNAME:

Alias record:
    ✓ dùng được ở ĐỈNH tên miền (apex)
    ✓ MIỄN PHÍ (Route 53 không tính phí truy vấn alias tới tài nguyên AWS)
    ✓ tự cập nhật khi địa chỉ đích thay đổi

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

• **A. Yêu cầu chứng chỉ ở us-east-1 rồi tạo regional domain name ở us-east-2 — đây là phương án gần nhất và chỉ khác đúng MỘT chữ, nhưng đó là chữ quyết định: regional endpoint không dùng được chứng chỉ ở Region khác. us-east-1 chỉ đúng cho edge-optimized endpoint.
• **B. Nhập chứng chỉ vào ACM ở us-east-2 rồi tạo CNAME trỏ tới invoke URL — sai cách ánh xạ tên miền: trỏ CNAME thẳng vào invoke URL không làm API Gateway nhận diện tên miền tuỳ chỉnh. API Gateway sẽ không biết request thuộc về API nào, và bắt tay TLS thất bại vì chứng chỉ không khớp. Phải tạo custom domain name trong API Gateway.
• **C. Dùng ACM Private CA sinh chứng chỉ riêng và ghi đè invoke URL bằng stage variable — sai hai chỗ: chứng chỉ từ Private CA không được trình duyệt tin cậy, nên client bên ngoài sẽ báo lỗi bảo mật. Và stage variable dùng để tham số hoá backend (ví dụ trỏ tới Lambda alias khác nhau), không để đổi tên miền.

Ghi nhớ

Ba loại endpoint của API Gateway: | Loại | Đặc điểm | Chứng chỉ ở | |---|---|---| | Regional | client ở cùng Region — độ trễ thấp nhất cho họ | cùng Region | | Edge-optimized | qua CloudFront — tốt cho client toàn cầu | us-east-1 | | Private | chỉ truy cập từ VPC qua interface endpoint | cùng Region |

Quy tắc chọn:

Client tập trung ở một khu vực → Regional Client phân tán toàn cầu → Edge-optimized Chỉ dùng nội bộ trong VPC → Private

Bảng Region của chứng chỉ ACM — nội dung hay bị hỏi: | Dịch vụ | Chứng chỉ phải ở | |---|---| | CloudFront | us-east-1 | | API Gateway edge-optimized | us-east-1 | | API Gateway regional | cùng Region với API | | ALB, NLB | cùng Region | | App Runner, Amplify | cùng Region |

Alias record và CNAME — bảng phân biệt: | | Alias | CNAME | |---|---|---| | Dùng ở ĐỈNH tên miền (example.com) | ✅ | ❌ KHÔNG ĐƯỢC | | Chi phí truy vấn | MIỄN PHÍ (tới tài nguyên AWS) | tính phí | | Trỏ tới | tài nguyên AWS, hoặc record khác cùng zone | bất kỳ tên miền nào | | Tự cập nhật khi đích đổi IP | ✅ | ✅ (qua tên) |

Alias là lựa chọn đúng cho mọi tài nguyên AWS — nó rẻ hơn và dùng được ở đỉnh tên miền.

Các đích mà alias record trỏ được:

CloudFront distribution
API Gateway custom domain name    ← câu này
Elastic Load Balancer
S3 static website endpoint
Elastic Beanstalk environment
Global Accelerator
VPC interface endpoint
Record khác trong cùng hosted zone

Ba bước sau khi tạo custom domain name: | Bước | Chi tiết | |---|---| | Base path mapping | ánh xạ API và STAGE vào tên miền | | Alias record trong Route 53 | trỏ tới regionalDomainName do API Gateway trả về | | Kiểm chứng | curl -sI https://api.tutorialsdojo.com/duong-dan |

Base path mapping cho phép nhiều API dùng chung một tên miền:

api.tutorialsdojo.com/nguoi-dung  → API A, stage prod
api.tutorialsdojo.com/don-hang    → API B, stage prod

Đây là cách gọn để trình bày nhiều microservice sau một tên miền duy nhất.

Ba lưu ý về chứng chỉ ACM: | Lưu ý | Chi tiết | |---|---| | Chứng chỉ do ACM CẤP thì tự gia hạn | chứng chỉ NHẬP VÀO thì không | | Xác thực bằng DNS tốt hơn email | bản ghi CNAME nằm mãi → gia hạn vĩnh viễn | | Miễn phí cho tài nguyên AWS | không tốn đồng nào |

Nếu tên miền nằm trong Route 53, ACM tạo bản ghi xác thực giúp bạn:

aws acm request-certificate --region us-east-2   --domain-name api.tutorialsdojo.com --validation-method DNS
# rồi bấm "Create records in Route 53" trong Console

Ba cấu hình bảo mật nên có cho API Gateway công khai: | Cấu hình | Lý do | |---|---| | Chính sách TLS tối thiểu 1.2 | securityPolicy: TLS_1_2 | | Usage plan và API key hoặc IAM auth | tránh bị lạm dụng | | AWS WAF gắn vào stage | chặn tấn công tầng 7 | | Throttling và quota | bảo vệ backend |

Và một lưu ý sau khi gắn tên miền tuỳ chỉnh: invoke URL gốc vẫn hoạt động. Nếu muốn buộc client dùng tên miền mới, hãy thêm resource policy từ chối request không đến qua custom domain — nếu không, endpoint cũ vẫn là một đường vào không được kiểm soát bởi WAF hay cấu hình TLS bạn đã đặt.

Đáp án

C — Lưu trong S3, sau một tháng dùng lifecycle policy chuyển prefix tdojo-finance sang One Zone-IA, phần còn lại sang Glacier.

Vì sao đúng

Đề cho ba điều kiện, và mỗi điều kiện loại bớt một lựa chọn: | Điều kiện | Kết luận | |---|---| | Tệp DỄ TÁI TẠO (easily reproducible) | One Zone-IA chấp nhận được — mất cũng dựng lại được | | Prefix tdojo-finance cần truy xuất MILI GIÂY | không được để ở Glacier Flexible | | Phần còn lại không có yêu cầu thời gian truy xuất | Glacier là rẻ nhất |

Vì sao One Zone-IA hợp lý ở đây:

One Zone-IA lưu ở MỘT AZ duy nhất
    → rẻ hơn Standard-IA khoảng 20%
    → RỦI RO: AZ đó bị phá huỷ thì dữ liệu MẤT
    ↓
Nhưng đề nói tệp "easily reproducible"
    → mất thì tạo lại được
    → rủi ro chấp nhận được, đổi lấy chi phí thấp hơn

Và nó vẫn cho truy xuất tức thì — đúng yêu cầu "millisecond retrieval time" của prefix tdojo-finance.

Vì sao phần còn lại để Glacier được:

"Chỉ lập trình viên truy cập, KHÔNG có yêu cầu về thời gian truy xuất"
    → chờ vài phút tới vài giờ chấp nhận được
    → Glacier rẻ hơn Standard khoảng 6 lần

Lifecycle policy với hai rule:

{"Rules": [
  {"ID": "tai-chinh-sang-onezone",
   "Status": "Enabled",
   "Filter": {"Prefix": "tdojo-finance/"},
   "Transitions": [{"Days": 30, "StorageClass": "ONEZONE_IA"}]},
  {"ID": "con-lai-sang-glacier",
   "Status": "Enabled",
   "Filter": {},
   "Transitions": [{"Days": 30, "StorageClass": "GLACIER"}]}
]}

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

• **D. Chuyển prefix tdojo-finance sang Standard-IA, phần còn lại sang Glacier — đây là phương án gần nhất và hoạt động hoàn toàn đúng về mặt kỹ thuật, nhưng nó đắt hơn: Standard-IA lưu ở ba AZ, giá cao hơn One Zone-IA khoảng 20%. Vì tệp "dễ tái tạo", độ bền nhiều AZ không cần thiết — đề hỏi "most cost-effective".
• **A. Chuyển CẢ BUCKET sang S3-IA — không tận dụng được cơ hội tiết kiệm: phần lớn tệp không cần truy xuất nhanh, để chúng ở IA thay vì Glacier là trả nhiều hơn mức cần.
• **B. Chuyển cả bucket sang Intelligent-Tiering — không tối ưu cho mẫu truy cập ĐÃ BIẾT RÕ: Intelligent-Tiering có giá trị khi mẫu truy cập khó đoán. Ở đây đề đã nói rõ tệp nào cần nhanh, tệp nào không — nên đặt lifecycle tường minh rẻ hơn, và tránh được phí giám sát của Intelligent-Tiering.

Ghi nhớ

Các lớp lưu trữ S3 — bảng cần thuộc: | Lớp | Số AZ | Truy xuất | Chi phí lưu trữ | |---|---|---|---| | Standard | ≥ 3 | tức thì | cao nhất | | Standard-IA | ≥ 3 | tức thì | ~45% rẻ hơn Standard | | One Zone-IA | 1 | tức thì | ~20% rẻ hơn Standard-IA | | Intelligent-Tiering | ≥ 3 | tức thì | tự tối ưu + phí giám sát | | Glacier Instant Retrieval | ≥ 3 | mili giây | rẻ hơn nhiều | | Glacier Flexible Retrieval | ≥ 3 | 1 phút – 12 giờ | rất rẻ | | Glacier Deep Archive | ≥ 3 | 12–48 giờ | rẻ nhất |

Quy tắc chọn One Zone-IA:

Dùng khi dữ liệu TÁI TẠO ĐƯỢC — bản sao thứ hai, ảnh thumbnail, dữ liệu trung gian KHÔNG dùng cho dữ liệu duy nhất, không thể phục hồi

Và một lựa chọn hiện đại hơn cho prefix tdojo-finance: Glacier Instant Retrieval.

Truy xuất MILI GIÂY như One Zone-IA
    → nhưng lưu ở BA AZ (bền hơn)
    → và rẻ hơn One Zone-IA về chi phí lưu trữ
    → đổi lại: phí truy xuất cao hơn, lưu tối thiểu 90 ngày

(Glacier Instant Retrieval ra mắt sau khi câu hỏi này được soạn. Với mẫu "hiếm khi truy cập nhưng cần ngay", nó thường là lựa chọn tốt hơn One Zone-IA nếu số lần đọc thấp.)

Ràng buộc thời gian lưu tối thiểu: | Lớp | Tối thiểu | |---|---| | Standard-IA, One Zone-IA | 30 ngày | | Glacier Instant / Flexible | 90 ngày | | Glacier Deep Archive | 180 ngày |

Xoá trước hạn vẫn bị tính đủ phí.

Và một ràng buộc về thời điểm chuyển đổi:

Object phải ở Standard ít nhất 30 NGÀY
    trước khi chuyển sang Standard-IA hoặc One Zone-IA

Đề nói "after a month" — vừa đúng 30 ngày, hợp lệ. (Chuyển thẳng sang Glacier thì không có ràng buộc này.)

Ba cách lọc trong lifecycle rule: | Cách | Ví dụ | |---|---| | Prefix | "Prefix": "tdojo-finance/" ← câu này | | Tag | "Tag": {"Key": "LoaiDuLieu", "Value": "tai-chinh"} | | Kích thước | ObjectSizeGreaterThan |

Lọc theo kích thước đáng nhớ: chuyển object rất nhỏ sang Glacier có thể đắt hơn vì Glacier tính thêm ~32 KB metadata cho mỗi object. Đặt ObjectSizeGreaterThan: 131072 (128 KB) tránh được điều đó.

Lưu ý về thứ tự rule khi có nhiều rule chồng nhau:

Rule không có Filter áp cho MỌI object, kể cả tdojo-finance/
    → S3 áp dụng rule "rẻ hơn" hoặc gây xung đột
→ nên đặt Filter loại trừ tường minh cho rule thứ hai

Cách an toàn: dùng prefix riêng cho từng nhóm thay vì để một rule bao trùm tất cả.

Intelligent-Tiering — khi nào nên dùng: | | Lifecycle rule | Intelligent-Tiering | |---|---|---| | Quyết định chuyển tầng | theo TUỔI | theo MẪU TRUY CẬP thực tế | | Phù hợp | biết rõ quy luật ← câu này | mẫu truy cập khó đoán | | Phí truy xuất | có (ở IA và Glacier) | KHÔNG | | Phí giám sát | không | nhỏ, theo object |

Với dữ liệu bí mật như đề nêu, đừng quên phần mã hoá:

{"Rules": [{"ApplyServerSideEncryptionByDefault":
  {"SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "<arn>"},
  "BucketKeyEnabled": true}]}

Mọi lớp lưu trữ đều hỗ trợ mã hoá — chuyển sang Glacier không làm mất cấu hình mã hoá.

Và một lời khuyên: dùng S3 Storage Class Analysis để đo mẫu truy cập thật trước khi chốt con số "một tháng". Nó cho biết tệp thực sự ngừng được truy cập sau bao lâu — chuyển quá sớm thì phí truy xuất ăn hết phần tiết kiệm được.

Đáp án

D — Triển khai NAT Gateway trong PUBLIC subnet và thêm route trỏ tới nó từ private subnet nơi đặt tầng web và tầng ứng dụng.

Vì sao đúng

Đề nêu hai yêu cầu đối lập nhau, và NAT gateway là cơ chế duy nhất thoả cả hai: | Yêu cầu | Cơ chế | |---|---| | Máy chủ cần RA Internet gọi API công khai | NAT gateway cho lưu lượng ĐI RA | | Máy chủ KHÔNG được truy cập TỪ Internet | đặt trong private subnet — không có đường vào |

NAT (Network Address Translation) hoạt động MỘT CHIỀU:

Instance trong private subnet gọi ra Internet:
    instance → NAT gateway → Internet Gateway → API công khai
        → NAT đổi IP nguồn thành IP của chính nó
        → phản hồi quay về đúng instance
    ✅ ĐI RA ĐƯỢC

Ai đó từ Internet gọi vào instance:
    → không có route nào dẫn vào private subnet
    → NAT KHÔNG chuyển tiếp kết nối khởi tạo từ ngoài
    ❌ KHÔNG VÀO ĐƯỢC

Và vị trí đặt NAT gateway là chi tiết quyết định:

NAT gateway phải nằm ở PUBLIC subnet
    → vì chính nó cần đường ra Internet Gateway
    → đặt nó ở private subnet thì nó cũng không ra được

Cấu hình route table:

Route table của PUBLIC subnet:
    10.0.0.0/16  → local
    0.0.0.0/0    → igw-xxxxx        (Internet Gateway)

Route table của PRIVATE subnet:
    10.0.0.0/16  → local
    0.0.0.0/0    → nat-xxxxx        (NAT Gateway)

aws ec2 create-nat-gateway --subnet-id subnet-public-1a   --allocation-id eipalloc-0abc123
aws ec2 create-route --route-table-id rtb-private   --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0abc123

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

• **B. Triển khai NAT gateway TRONG private subnet và thêm route từ public subnet — đây là phương án gần nhất và đảo ngược đúng hai yếu tố quan trọng nhất: NAT gateway phải ở public subnet (nó cần Internet Gateway để ra ngoài), và route trỏ tới nó phải nằm ở private subnet (nơi cần đường ra). Cấu hình như mô tả sẽ không hoạt động.
• **C. Đặt tầng web và tầng ứng dụng trong PUBLIC subnet và cấp Elastic IP cho mỗi máy — vi phạm yêu cầu bảo mật: máy có IP công khai trong public subnet là truy cập được từ Internet. Đề nói rõ chúng "should be INACCESSIBLE from the Internet".
• **A. Đặt trong private subnet rồi cấp Elastic IP cho mỗi máy — không có tác dụng: gắn Elastic IP vào instance ở private subnet không tạo ra đường đi nào — thiếu route tới Internet Gateway thì gói tin không đi đâu được. Elastic IP chỉ có ý nghĩa khi subnet có đường ra Internet Gateway.

Ghi nhớ

Public subnet và private subnet — khác biệt DUY NHẤT: | | Public subnet | Private subnet | |---|---|---| | Route 0.0.0.0/0 | → Internet Gateway | → NAT Gateway (hoặc không có) | | Ra Internet | trực tiếp | qua NAT | | Vào từ Internet | được | không | | Cần IP công khai | có | không |

Không có công tắc "public/private" nào cả — nó hoàn toàn do route table quyết định.

Internet Gateway và NAT Gateway: | | Internet Gateway | NAT Gateway | |---|---|---| | Chiều lưu lượng | HAI chiều | CHỈ ĐI RA | | Vị trí | gắn vào VPC | đặt trong PUBLIC subnet | | Chi phí | MIỄN PHÍ | ~32 USD/tháng + ~0,045 USD/GB | | Số lượng | một mỗi VPC | nên một mỗi AZ | | Sẵn sàng cao | tự động | trong MỘT AZ — cần nhiều cái |

Dòng cuối là điểm thiết kế quan trọng:

Một NAT gateway dùng chung cho mọi private subnet:
    → AZ chứa nó sập → MỌI private subnet mất đường ra Internet
    ↓
Kiến trúc chịu lỗi: MỘT NAT gateway MỖI AZ
    → mỗi private subnet trỏ tới NAT trong chính AZ của nó
    → và tránh được phí truyền dữ liệu giữa AZ

NAT Gateway và NAT Instance: | | NAT Gateway | NAT Instance | |---|---|---| | Quản lý | AWS lo hoàn toàn | bạn tự vá, tự giám sát | | Băng thông | tới 100 Gbps, tự mở rộng | theo loại instance | | Sẵn sàng cao | trong AZ | phải tự dựng | | Chi phí | cao hơn | có thể rẻ hơn với lưu lượng nhỏ | | Security group | không gắn được | gắn được |

NAT Gateway là lựa chọn mặc định — NAT instance chỉ đáng cân nhắc cho môi trường dev với lưu lượng rất thấp.

Và một tối ưu chi phí quan trọng: NAT gateway là khoản tốn kém âm thầm phổ biến nhất trên AWS.

Lưu lượng tới S3, DynamoDB đi qua NAT
    → trả ~0,045 USD/GB một cách vô ích
    ↓
Dùng VPC GATEWAY ENDPOINT cho S3 và DynamoDB:
    → HOÀN TOÀN MIỄN PHÍ
    → lưu lượng không qua NAT nữa

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc123   --service-name com.amazonaws.us-east-1.s3   --route-table-ids rtb-private-1a rtb-private-1b

Các dịch vụ khác cũng nên có interface endpoint nếu lưu lượng lớn: | Dịch vụ | Lý do | |---|---| | ECR | kéo image container tốn rất nhiều băng thông | | CloudWatch Logs | log đẩy lên liên tục | | Systems Manager | và cần thiết nếu không có NAT | | Secrets Manager, KMS | lưu lượng nhỏ nhưng thường xuyên |

Kiến trúc VPC ba tầng chuẩn:

PUBLIC subnet   : ALB, NAT Gateway, bastion (nếu có)
PRIVATE subnet  : tầng web, tầng ứng dụng      ← đề này
PRIVATE subnet  : tầng cơ sở dữ liệu (RDS, ElastiCache)
    → mỗi tầng ở ít nhất HAI AZ

Ba lưu ý khi triển khai NAT gateway: | Lưu ý | Chi tiết | |---|---| | Cần Elastic IP | gắn khi tạo | | Không gắn security group được | kiểm soát bằng security group của instance và NACL | | Chỉ hỗ trợ IPv4 | với IPv6 dùng egress-only Internet Gateway (miễn phí) |

Và một lưu ý về giám sát: đặt alarm cho metric BytesOutToDestination của NAT gateway. Lưu lượng tăng đột biến thường là dấu hiệu của một tiến trình chạy sai (tải lại dữ liệu lặp đi lặp lại) — và với giá theo GB, phát hiện muộn nghĩa là hoá đơn đã tăng đáng kể.