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

Đáp án

A, C — hai bước đảm bảo hiệu năng Athena khi dữ liệu lớn dần:

• A — Lưu dữ liệu trong S3 theo phân vùng kiểu Apache Hive với khoá chứa ngày.
• C — Lưu dữ liệu ở định dạng Apache Parquet hoặc Apache ORC.

Vì sao đúng

Athena tính tiền và tính thời gian theo số byte quét. Hai bước đúng là hai cách giảm con số đó mạnh nhất.

⚠ Điểm mấu chốt: đề nói "dữ liệu được phân tích theo khoảng ngày" — nên phân vùng theo ngày là đòn bẩy lớn nhất:

Truy vấn có WHERE ngay BETWEEN ... AND ...
        ↓
    Athena đọc metadata phân vùng trong Glue Data Catalog
        ↓
    Loại ngay mọi thư mục ngoài khoảng ngày — không mở tệp nào trong đó
        ↓
    → chỉ quét đúng phần dữ liệu liên quan
    → chi phí gần như không tăng dù dữ liệu tích luỹ nhiều năm

Cấu trúc tiền tố kiểu Hive để Athena tự nhận phân vùng:

s3://du-lieu/nam=2026/thang=09/ngay=02/du-lieu.parquet

CREATE EXTERNAL TABLE thong_ke (...)
PARTITIONED BY (nam string, thang string, ngay string)
STORED AS PARQUET
LOCATION 's3://du-lieu/';

MSCK REPAIR TABLE thong_ke;

⚠ Cột phân vùng phải xuất hiện trong WHERE thì mới có tác dụng:

Bảng đã phân vùng nhưng truy vấn không lọc theo cột phân vùng
        ↓
    Athena không loại được thư mục nào
        ↓
    → quét toàn bộ, chậm như cũ, và KHÔNG có cảnh báo nào

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

• E (lưu dữ liệu trong các bucket riêng cho từng khoảng ngày) — đây là phương án gần nhất và nó cũng tách dữ liệu theo thời gian, nên về nguyên tắc cũng giảm được lượng quét. Nhưng nó tệ hơn phân vùng theo mọi mặt: mỗi bucket thành một bảng riêng, nên truy vấn xuyên nhiều khoảng ngày phải UNION thủ công; số bucket trong một tài khoản có giới hạn; và việc quản lý quyền, lifecycle, replication phải lặp lại cho từng bucket. Phân vùng đạt cùng mục tiêu trong một bảng duy nhất.

• B (lưu mỗi object với khoá dùng chuỗi ngẫu nhiên) — đây từng là lời khuyên cũ để phân tán tải trên S3, nhưng S3 đã tự động mở rộng theo tiền tố từ năm 2018 nên nó không còn cần thiết. Tệ hơn, khoá ngẫu nhiên phá huỷ khả năng phân vùng — không còn cấu trúc nào để Athena loại bỏ thư mục.

• D (lưu các tệp nén nhỏ hơn 10 MB) — sai hướng. Quá nhiều tệp nhỏ làm Athena chậm vì chi phí liệt kê và mở từng tệp lấn át. Khuyến nghị là gộp thành các tệp cỡ 128 MB trở lên.

Ghi nhớ

⚠ Bốn cách giảm byte quét trong Athena — bảng phải thuộc, theo thứ tự hiệu quả: | Cách | Mức giảm | |---|---| | Phân vùng | lớn nhất — phải khớp cách truy vấn hay lọc | | Định dạng cột (Parquet/ORC) | 5–10 lần | | Nén (Snappy, GZIP) | 3–5 lần | | Gộp tệp nhỏ | tránh chi phí liệt kê |

Từ khoá nhận diện:

"analyzed using date ranges" → phân vùng theo ngày "optimal performance as data grows" → phân vùng + định dạng cột "khoá ngẫu nhiên" → lời khuyên đã lỗi thời, và phá phân vùng "tệp nhỏ hơn 10 MB" → SAI, tệp nhỏ làm chậm Athena "bucket riêng cho mỗi khoảng ngày" → phân mảnh, khó truy vấn xuyên khoảng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn quét bao nhiêu | cột Data scanned trong lịch sử Athena | | Pruning có chạy không | so byte quét khi có và không có lọc phân vùng | | Phân vùng đã nạp chưa | SHOW PARTITIONS ten_bang; |

Và một lời khuyên: hãy so con số "Data scanned" trước và sau khi tối ưu, đừng chỉ nhìn thời gian chạy. Thời gian chạy dao động theo tải chung của dịch vụ nên rất dễ đánh lừa; byte quét thì tất định. Quan trọng hơn: nếu bạn phân vùng xong mà truy vấn quên đặt cột phân vùng vào WHERE, nó vẫn chạy đúng và trả kết quả đúng — chỉ là quét toàn bộ như cũ. Không có lỗi, không có cảnh báo, hoá đơn không đổi, và bạn tin rằng mình đã tối ưu xong.

Đáp án

C — Dùng AWS Organizations tạo management account và tạo tài khoản cho từng đội từ đó; tạo một tài khoản bảo mật cho truy cập liên tài khoản; áp SCP cho từng tài khoản và cho đội bảo mật quyền truy cập liên tài khoản tới mọi tài khoản; đội bảo mật tạo IAM policy theo quyền tối thiểu.

Vì sao đúng

Đề có ba yêu cầu từ ba nhóm khác nhau, và chiến lược tài khoản phải thoả cả ba.

⚠ Điểm mấu chốt: ranh giới tài khoản cho ba thứ cùng lúc — cách ly, hoá đơn, và giới hạn sự cố:

Mỗi đội một tài khoản
        ↓
    Cách ly: đội A không thấy tài nguyên của đội B
    Hoá đơn: consolidated billing tách chi phí theo từng tài khoản, không cần tag
    Hạn mức: mỗi tài khoản có service quota riêng, không giành nhau
    Sự cố: một tài khoản bị xâm nhập không lan sang tài khoản khác

Đây là lý do tách tài khoản mạnh hơn tách bằng tag hay bằng IAM policy trong một tài khoản.

Vì sao cần tài khoản bảo mật riêng. Đội bảo mật cần nhìn được vào mọi tài khoản, nhưng không nên có danh tính nằm rải rác ở từng nơi. Một tài khoản security với cross-account role là mẫu chuẩn:

// Trong tài khoản của mỗi đội
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::<tai-khoan-security>:root"},
  "Action": "sts:AssumeRole"
}

⚠ SCP đặt trần, IAM policy cấp quyền — hai tầng bổ sung cho nhau:

SCP (do management account áp)
        ↓
    Giới hạn tối đa đội đó được dùng dịch vụ nào
        ↓
IAM policy (do đội bảo mật viết)
        ↓
    Cấp quyền cụ thể trong phạm vi trần đó
        ↓
    → quyền hiệu dụng = giao của cả hai

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

• B (Organizations với management account; nhóm trong Active Directory gán vào IAM role để truy cập liên kết; gắn tag cho tài nguyên của từng đội và tách hoá đơn theo tag; IAM cấp quyền tối thiểu) — đây là phương án gần nhất và liên kết danh tính từ AD là thực hành tốt. Nhưng nó không tách tài khoản cho từng đội, nên yêu cầu đầu tiên — "mỗi đội muốn cách ly tài nguyên khỏi đội khác" — không đạt: mọi đội vẫn ở chung một tài khoản, chỉ được ngăn bằng IAM policy. Và tách chi phí bằng tag mong manh hơn nhiều so với ranh giới tài khoản: tài nguyên thiếu tag sẽ rơi vào mục không phân loại được.

• D (tài khoản riêng cho mỗi đội; chỉ định tài khoản security làm management account; bật consolidated billing; tạo cross-account role cho bảo mật) — gần đúng nhưng đặt sai vai trò: tài khoản security không nên là management account. Management account có quyền đặc biệt (không bị SCP ràng buộc, quản lý toàn tổ chức) và nên được giữ trống, tách khỏi mọi khối lượng công việc kể cả công việc bảo mật.

• A (một tài khoản duy nhất, dùng CloudFormation cấp tài nguyên; cost allocation tag và công cụ bên thứ ba để tách chi phí; IAM policy kiểm soát, cấp cho bảo mật quyền đầy đủ) — không cách ly được các đội, phụ thuộc công cụ ngoài để tách hoá đơn, và cấp quyền đầy đủ cho đội bảo mật đi ngược nguyên tắc quyền tối thiểu mà chính đề nêu.

Ghi nhớ

⚠ Mô hình tài khoản khuyến nghị của AWS — bảng phải thuộc: | Tài khoản | Vai trò | |---|---| | Management | chỉ quản lý tổ chức — giữ trống nhất có thể | | Log Archive | nhận log từ mọi tài khoản, không ai xoá được | | Audit / Security | quyền đọc để điều tra, chạy Security Hub và GuardDuty | | Workload | mỗi đội, mỗi môi trường một tài khoản |

Từ khoá nhận diện:

"mỗi đội cách ly tài nguyên" → tài khoản riêng cho từng đội "tách chi phí theo đội" → ranh giới tài khoản, không cần tag "tách chi phí bằng tag" khi có thể tách bằng tài khoản → mong manh hơn "security account làm management account" → không nên, giữ management trống "cấp quyền đầy đủ cho đội bảo mật" → trái nguyên tắc quyền tối thiểu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí có tách đúng không | Cost Explorer nhóm theo Linked Account | | Đội bảo mật vào được mọi tài khoản chưa | thử assume role vào từng tài khoản | | SCP có áp đúng không | thử hành động bị chặn trong tài khoản thành viên |

Và một lời khuyên: hãy giữ management account gần như trống và bật MFA phần cứng cho root của nó. Đây là tài khoản duy nhất trong tổ chức không bị SCP ràng buộc, và nó có quyền tạo, đóng, và di chuyển mọi tài khoản khác. Đặt bất kỳ khối lượng công việc nào vào đó — kể cả một công cụ bảo mật, kể cả một hàm Lambda nhỏ — là mở rộng bề mặt tấn công của thứ có quyền lực nhất mà bạn sở hữu. Nguyên tắc là: nếu một thứ có thể chạy ở tài khoản khác, nó nên chạy ở tài khoản khác.

Đáp án

B — Lắp một kết nối Direct Connect thứ hai từ nhà mạng KHÁC và gắn nó vào cùng virtual private gateway với kết nối đầu tiên.

Vì sao đúng

Đề đòi kết nối bền bỉ nhất cho một ứng dụng quan trọng. Nguyên tắc là loại bỏ từng điểm hỏng đơn lẻ, và nhà mạng là một trong số đó.

⚠ Điểm mấu chốt: dùng cùng một nhà mạng nghĩa là hai kết nối chia sẻ chung một điểm hỏng vô hình:

Hai kết nối, cùng một nhà mạng
        ↓
    Có thể đi chung một tuyến cáp, chung một thiết bị tổng hợp,
    chung một sự cố định tuyến của nhà mạng đó
        ↓
    → mất cả hai cùng lúc
        ↓
Hai kết nối, hai nhà mạng khác nhau
        ↓
    Đường đi vật lý và hạ tầng định tuyến độc lập
        ↓
    → đây là mức bền bỉ cao nhất trong bốn phương án

Vì sao gắn vào cùng virtual private gateway. Cả hai kết nối tới cùng VGW nghĩa là chúng cùng phục vụ một VPC, và BGP tự chọn đường còn sống — không cần thao tác gì khi một đường đứt.

⚠ AWS khuyến nghị hai kết nối tại HAI ĐỊA ĐIỂM Direct Connect riêng biệt cho mức SLA cao nhất:

Hai kết nối cùng một địa điểm DX
        ↓
    Sự cố cả toà nhà (mất điện, cháy) → mất cả hai
        ↓
Hai kết nối, hai địa điểm, hai nhà mạng
        ↓
    → mức bền bỉ tối đa mà Direct Connect cung cấp

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

• A (thêm một kết nối vật lý nữa với CÙNG nhà mạng và gộp chúng vào một link aggregation group trên cùng private VIF) — đây là phương án gần nhất và LAG là công cụ có thật, hữu ích: nó gộp nhiều kết nối thành một đường logic để tăng băng thông. Nhưng nó không phải giải pháp cho tính bền bỉ: LAG đòi các kết nối phải kết thúc ở cùng một thiết bị AWS và cùng một địa điểm, nên nó không loại bỏ được sự cố thiết bị hay sự cố địa điểm. Và cùng nhà mạng nghĩa là vẫn chung điểm hỏng. LAG tăng thông lượng, không tăng khả năng chịu lỗi.

• C (tạo VPN có quản lý qua Internet và gắn vào cùng virtual private gateway) — đây là mẫu dự phòng hợp lệ và phổ biến, nhưng nó cho mức bền bỉ thấp hơn một kết nối DX thứ hai: đường lùi chạy trên Internet công cộng, băng thông thấp hơn và độ trễ dao động. Nó là lựa chọn tiết kiệm, không phải lựa chọn "MOST resilient".

• D (nhiều kết nối IPSec VPN tới các virtual private gateway riêng biệt, dùng BGP ưu tiên DX) — phức tạp và vẫn dựa trên Internet cho phần dự phòng. Việc dùng nhiều VGW riêng biệt còn làm rối định tuyến: mỗi VGW gắn với một VPC, nên nhiều VGW nghĩa là nhiều VPC — không khớp với mô tả của đề.

Ghi nhớ

⚠ Bốn mức bền bỉ của Direct Connect — bảng phải thuộc: | Mức | Cấu hình | |---|---| | Thấp nhất | một kết nối | | Cơ bản | một DX + một VPN dự phòng | | Cao | hai DX, cùng địa điểm | | Tối đa | hai DX, HAI địa điểm, hai nhà mạng, hai thiết bị router |

Từ khoá nhận diện:

"MOST resilient" → hai kết nối, hai nhà mạng, hai địa điểm "link aggregation group" → tăng BĂNG THÔNG, không tăng khả năng chịu lỗi "VPN qua Internet làm dự phòng" → hợp lệ nhưng bền bỉ thấp hơn DX thứ hai cùng nhà mạng → chung điểm hỏng vô hình cần băng thông lớn hơn → lúc đó LAG mới là công cụ đúng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | BGP có lên trên cả hai không | describe-virtual-interfaces, xem bgpPeers | | Đường dự phòng có nhận tải không | rút đường chính và quan sát | | Có dùng chung hạ tầng không | hỏi nhà mạng về đường đi vật lý |

Và một lời khuyên: hãy hỏi nhà mạng về đường đi vật lý thật của hai kết nối, đừng chỉ tin rằng hai hợp đồng khác nhau nghĩa là hai đường khác nhau. Đây là chỗ dự phòng trông hoàn hảo trên giấy mà không tồn tại trong thực tế: hai nhà mạng có thể thuê lại dung lượng trên cùng một tuyến cáp, hoặc cùng đi qua một điểm tập trung duy nhất trong thành phố. Cả hai kết nối đều xanh, BGP đều thiết lập, mọi chỉ số đều đẹp — cho tới ngày một chiếc máy xúc cắt đứt cả hai cùng lúc. Câu hỏi cần đặt ra với nhà cung cấp là "hai kết nối này có đi chung đoạn cáp nào không", và câu trả lời đôi khi gây bất ngờ.

Đáp án

D — Tạo SAML-based identity provider trong một tài khoản trung tâm và ánh xạ các IAM role cấp quyền cần thiết; ánh xạ người dùng trong nhóm của IdP tại chỗ sang các IAM role; dùng cross-account access tới các tài khoản AWS khác.

Vì sao đúng

Đề đòi hai thứ: quản lý tập trung danh tính và quyền, và đồng bộ với IdP tại chỗ đang có.

⚠ Điểm mấu chốt: liên kết SAML nghĩa là KHÔNG tạo IAM user — danh tính vẫn nằm ở IdP tại chỗ:

Người dùng đăng nhập vào IdP của công ty
        ↓
    IdP phát SAML assertion, trong đó có thuộc tính Role
        ↓
    Gọi sts:AssumeRoleWithSAML
        ↓
    Nhận thông tin đăng nhập TẠM THỜI của IAM role
        ↓
    → không có IAM user nào để tạo, để xoá, để xoay vòng mật khẩu
    → nhân viên nghỉ việc: vô hiệu hoá ở IdP là mất quyền ở mọi tài khoản AWS

Đây là điều làm cho phương án D "đồng bộ" thật sự — không phải bằng cách sao chép danh tính, mà bằng cách không nhân bản chúng.

Vì sao dựng ở một tài khoản trung tâm rồi cross-account. Nó giữ điểm vào duy nhất: một chỗ để cấu hình IdP, một chỗ để kiểm toán, và các tài khoản khác chỉ cần tin tài khoản đó.

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

• C (tạo SAML IdP ở tài khoản trung tâm và ánh xạ role — đúng; nhưng dùng một Lambda tập trung để NHÂN BẢN các danh tính từ IdP tại chỗ sang các tài khoản AWS) — đây là phương án gần nhất và nửa đầu của nó chính xác bằng đáp án đúng. Nhưng nửa sau đi ngược lại chính mục đích của liên kết danh tính: nhân bản danh tính nghĩa là tạo IAM user ở từng tài khoản, và từ đó bạn phải đồng bộ chúng mãi mãi. Mỗi lần nhân viên đổi nhóm hay nghỉ việc, Lambda phải chạy đúng ở mọi tài khoản — và mỗi lần nó chạy sai, bạn có một danh tính mồ côi còn quyền truy cập. Liên kết SAML tồn tại chính là để không phải làm việc đó.

• B (Organization với SCP; tạo SAML IdP trong TỪNG tài khoản và ánh xạ nhóm IdP sang role ở mỗi nơi) — chạy được nhưng không tập trung: cấu hình IdP phải lặp lại ở mọi tài khoản, và mỗi lần đổi chứng chỉ ký của IdP thì phải cập nhật tất cả. Nó cũng gán cho SCP vai trò không đúng: SCP đặt trần, không quản lý danh tính.

• A (triển khai IAM user, group, role, policy ở MỌI tài khoản; tạo Organization và liên kết IdP với các tài khoản) — mâu thuẫn nội tại: nếu đã liên kết IdP thì không cần IAM user; và tạo user ở mọi tài khoản là điều ngược hẳn với "quản lý tập trung".

Ghi nhớ

⚠ Bốn cách quản lý danh tính đa tài khoản — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | IAM Identity Center | khuyến nghị hiện nay — permission set, tích hợp IdP sẵn | | SAML federation + cross-account role | mẫu cổ điển, vẫn đúng | | Tài khoản identity với IAM user | không dùng IdP ngoài | | IAM user ở từng tài khoản | không tập trung được |

Từ khoá nhận diện:

"đồng bộ với IdP tại chỗ" → SAML federation, KHÔNG nhân bản danh tính "centralize identities and permissions" → một chỗ cấu hình, cross-account role "Lambda nhân bản danh tính" → đi ngược mục đích của liên kết "tạo IdP trong từng tài khoản" → không tập trung, khó bảo trì "SCP để quản lý quyền" → SCP đặt trần, không cấp quyền

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Assertion có đúng không | giải mã SAMLResponse, đọc thuộc tính Role | | Ai đã đăng nhập | CloudTrail, sự kiện AssumeRoleWithSAML | | Nhân viên nghỉ việc có mất quyền không | vô hiệu hoá ở IdP rồi thử đăng nhập |

Và một lời khuyên: hãy kiểm chứng rằng vô hiệu hoá một tài khoản ở IdP thật sự cắt được quyền truy cập AWS ngay lập tức. Đây là lợi ích lớn nhất của liên kết danh tính và cũng là thứ dễ bị phá vỡ nhất mà không ai để ý: nếu ở đâu đó còn tồn tại một IAM user, một bộ access key dài hạn, hay một role có trust policy quá rộng, thì người đã nghỉ việc vẫn vào được — và quy trình offboarding của bộ phận nhân sự, vốn chỉ chạm tới IdP, sẽ không phát hiện điều đó. Phép thử tốn năm phút và trả lời một câu hỏi mà mọi cuộc kiểm toán đều hỏi.

Đáp án

A — Tạo interface VPC endpoint cho API Gateway trong VPC; bật private DNS cho endpoint và cấu hình API resource policy cho phép truy cập từ endpoint đó; dùng tên DNS của API endpoint để gọi từ EC2.

Vì sao đúng

Đề đòi API chỉ truy cập được từ ứng dụng nội bộ trong VPC, và không phơi ra Internet. API Gateway có một kiểu endpoint dành riêng cho việc đó.

⚠ Điểm mấu chốt: private API endpoint KHÔNG có địa chỉ công cộng — nó chỉ tồn tại bên trong VPC:

Regional hoặc edge-optimized endpoint
        ↓
    Có tên DNS công cộng, ai cũng gọi tới được (rồi bị resource policy chặn)
        ↓
Private endpoint
        ↓
    Chỉ phân giải và định tuyến được từ VPC có interface endpoint
        ↓
    → không có bề mặt công khai nào để mà tấn công
    → đây là điều kiện tuân thủ mà đề yêu cầu

// Resource policy của API
{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "execute-api:Invoke",
  "Resource": "execute-api:/*",
  "Condition": {"StringNotEquals": {"aws:SourceVpce": "vpce-0abc123"}}
}

⚠ Bật private DNS là thứ cho phép gọi bằng tên chuẩn của API:

Không bật private DNS
        ↓
    Phải gọi bằng tên dài của endpoint kèm header Host
        ↓
Bật private DNS
        ↓
    Tên execute-api chuẩn phân giải về IP riêng của endpoint
        ↓
    → ứng dụng gọi như bình thường, không cần sửa mã
        ↓
    → điều kiện: VPC bật enableDnsSupport và enableDnsHostnames

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

• D (resource policy giới hạn theo dải IP của VPC; EC2 gọi API bằng tên DNS CÔNG CỘNG) — đây là phương án gần nhất và resource policy thật sự lọc được truy cập. Nhưng nó không đạt yêu cầu cốt lõi: API vẫn có endpoint công khai, ai cũng gửi request tới được (dù bị từ chối), nên nó vẫn "exposed to the public internet" theo nghĩa mà quy định y tế quan tâm. Ngoài ra, lọc theo dải IP riêng của VPC không hoạt động khi request đi qua Internet — địa chỉ nguồn lúc đó là IP công cộng của NAT gateway, không phải dải riêng.

• B (đặt ELB trước API Gateway và giới hạn truy cập ELB theo security group của EC2) — sai kiến trúc. Không đặt được ELB trước API Gateway theo cách này; API Gateway là dịch vụ có endpoint riêng, không phải target của load balancer. Và nó không giải quyết việc API vẫn phơi ra công khai.

• C (dựng một reverse proxy trong VPC chuyển tiếp request tới API Gateway) — chạy được nhưng thêm một máy chủ phải vận hành, vá lỗi và làm cho sẵn sàng cao — trong khi interface endpoint là dịch vụ có quản lý làm đúng việc đó. Và API Gateway vẫn phơi ra công khai phía sau proxy.

Ghi nhớ

⚠ Ba kiểu endpoint của API Gateway — bảng phải thuộc: | Kiểu | Truy cập từ | |---|---| | Edge-optimized | Internet, qua mạng CloudFront của AWS | | Regional | Internet, từ một Region | | Private | CHỈ từ VPC qua interface endpoint |

Từ khoá nhận diện:

"không phơi ra Internet" + API Gateway → private endpoint + interface VPC endpoint "chỉ VPC này gọi được" → resource policy với aws:SourceVpce "resource policy theo dải IP riêng của VPC" → không hoạt động qua Internet "ELB trước API Gateway" → SAI kiến trúc "reverse proxy" khi có interface endpoint → thêm việc vận hành không cần thiết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tên có phân giải về IP riêng không | dig <api-id>.execute-api.<region>.amazonaws.com từ EC2 | | Từ ngoài có gọi được không | thử từ máy ngoài VPC — phải không phân giải được | | Resource policy có chặn đúng không | thử từ một VPC endpoint khác |

Và một lời khuyên: hãy luôn gắn resource policy cho private API, đừng dựa vào việc nó "riêng tư" là đủ. Private endpoint giới hạn ai tới được API, nhưng nếu nhiều VPC hoặc nhiều tài khoản cùng có interface endpoint trỏ tới nó, tất cả đều gọi được — và với dữ liệu y tế, "trong mạng nội bộ" không đồng nghĩa với "được phép". Resource policy với aws:SourceVpce là thứ biến một ranh giới mạng thành một ranh giới cho phép tường minh, và nó là bằng chứng bạn đưa ra được khi có người hỏi ai truy cập được API đó.

Đáp án

C — Tải dữ liệu lên bucket S3 bằng S3 Transfer Acceleration.

Vì sao đúng

Câu này giải bằng một phép tính. 25 TB với các đường truyền mà đề cho:

⚠ Điểm mấu chốt: 1 Gbps là đường nhanh nhất đang có, và Transfer Acceleration làm cho nó nhanh hơn nữa:

Direct Connect chỉ 500 Mbps — chậm hơn Internet 1 Gbps
        ↓
    Nên dùng đường Internet
        ↓
Transfer Acceleration
        ↓
    Đưa dữ liệu vào mạng AWS tại điểm biên gần nhất
    Phần còn lại đi trên xương sống AWS thay vì Internet công cộng
        ↓
    → giảm mất gói và độ trễ, tăng thông lượng thực tế

Vì sao Snowball chậm hơn ở đây. Snowball là lựa chọn đúng khi băng thông không đủ — nhưng nó có độ trễ cố định không rút ngắn được: đặt thiết bị, chờ gửi tới, chép dữ liệu, gửi trả, AWS nhập vào S3. Tổng cộng thường khoảng một tuần, dài hơn ba ngày truyền qua mạng.

aws s3api put-bucket-accelerate-configuration \
  --bucket du-lieu --accelerate-configuration Status=Enabled

aws s3 cp ./du-lieu s3://du-lieu/ --recursive \
  --endpoint-url https://s3-accelerate.amazonaws.com

⚠ Transfer Acceleration không phải lúc nào cũng nhanh hơn — hãy đo trước:

Lợi ích lớn khi nguồn ở XA Region của bucket
        ↓
    Nếu trung tâm dữ liệu nằm ngay cạnh Region đó, mức cải thiện có thể không đáng kể
        ↓
    → AWS có công cụ so tốc độ chính thức; chạy nó trước khi trả thêm phí

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

• A (dùng đường Direct Connect 500 Mbps để tải lên S3) — đây là phương án gần nhất và Direct Connect thường là lựa chọn tốt hơn về độ ổn định. Nhưng ở đây nó chậm hơn một nửa: 500 Mbps so với 1 Gbps của đường Internet. Đề hỏi cách NHANH NHẤT, và con số quyết định.

• B (chép dữ liệu vào một thiết bị Snowball 80 TB) — đúng dung lượng nhưng chậm hơn vì thời gian vận chuyển. Snowball thắng khi băng thông quá thấp — ví dụ 25 TB qua 50 Mbps mất hai tháng — nhưng ở đây mạng đủ nhanh.

• D (dùng AWS DataSync để chuyển dữ liệu sang S3) — DataSync là công cụ tốt cho việc chuyển dữ liệu có lịch, tự xác minh và chuyển phần thay đổi. Nhưng nó vẫn dùng chính đường truyền đang có — nó không tạo thêm băng thông. Với một lần chuyển duy nhất và tiêu chí là tốc độ, Transfer Acceleration tối ưu đường đi còn DataSync thì không.

Ghi nhớ

⚠ Phép tính băng thông — bảng phải thuộc: | Băng thông | Thời gian chuyển 25 TB (hiệu suất ~70%) | |---|---| | 50 Mbps | khoảng 60 ngày | | 500 Mbps | khoảng 6 ngày | | 1 Gbps | khoảng 3 ngày | | 10 Gbps | khoảng 8 giờ |

Công thức: thời gian ≈ dung lượng ÷ (băng thông × hiệu suất).

Từ khoá nhận diện:

"FASTEST method" → tính thời gian cho từng đường, chọn con số nhỏ nhất băng thông đủ → truyền qua mạng, Transfer Acceleration nếu ở xa băng thông không đủ → Snow Family "DataSync" → dùng chính đường truyền hiện có, không tăng băng thông Direct Connect chậm hơn Internet → so con số, đừng mặc định DX luôn tốt hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Băng thông thực tế | đo bằng iperf ngoài giờ cao điểm | | Transfer Acceleration có nhanh hơn không | công cụ so tốc độ của AWS | | Đã chuyển đủ chưa | so số tệp và dung lượng hai đầu |

Và một lời khuyên: hãy đo băng thông thực tế trước khi cam kết một mốc thời gian, và dùng multipart upload cho mọi tệp lớn. Con số trên hợp đồng đường truyền hiếm khi là con số bạn nhận được: có giới hạn của nhà mạng, có lưu lượng nền, và với các luồng TCP đường dài thì cửa sổ truyền cũng ảnh hưởng đáng kể. Multipart upload giải quyết vế thứ hai — nó tải nhiều phần song song nên tận dụng được băng thông tốt hơn nhiều so với một luồng đơn, và khi một phần lỗi thì chỉ phải tải lại phần đó thay vì cả tệp.

Đáp án

D — Chuyển các ứng dụng sang container Docker trên Amazon ECS; tạo ECS task và service riêng cho mỗi ứng dụng; bật service Auto Scaling theo mức sử dụng bộ nhớ với ngưỡng 75%; giám sát bằng CloudWatch.

Vì sao đúng

Đề có ba dữ kiện quyết định: 30 ứng dụng nhỏ, chuẩn hoá một phương pháp triển khai duy nhất, và 1 GB bộ nhớ thường xuyên, lên tới 3 GB trong nhiều giờ khi cao điểm.

⚠ Điểm mấu chốt: "peak processing periods which can last several hours" là thứ loại Lambda:

Lambda tối đa 15 phút mỗi lời gọi
        ↓
    Đề nói giai đoạn xử lý cao điểm kéo dài NHIỀU GIỜ
        ↓
    → nếu đó là các tác vụ chạy dài, Lambda không chạy nổi
        ↓
Container trên ECS
        ↓
    Chạy bao lâu cũng được, co giãn theo bộ nhớ

Vì sao container tiết kiệm nhất với 30 ứng dụng nhỏ. Mỗi ứng dụng chỉ dùng 1 GB bộ nhớ và có ít người dùng — nghĩa là một EC2 instance đủ lớn có thể chứa nhiều ứng dụng cùng lúc. Với EC2 riêng cho từng ứng dụng (phương án A) hay Elastic Beanstalk riêng cho từng cái (phương án B), bạn trả tiền cho 30 hạ tầng gần như nhàn rỗi.

⚠ Co giãn theo bộ nhớ đòi chỉ số tuỳ chỉnh với EC2, nhưng ECS có sẵn:

ECS service Auto Scaling
        ↓
    Có sẵn chỉ số MemoryUtilization ở mức service
        ↓
    → khai ngưỡng 75% là xong
        ↓
Auto Scaling group của EC2
        ↓
    KHÔNG có chỉ số bộ nhớ mặc định — phải cài CloudWatch agent

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

• B (mỗi ứng dụng một môi trường Elastic Beanstalk riêng, bật Auto Scaling, giám sát bằng CloudWatch alarm) — đây là phương án gần nhất và Elastic Beanstalk thật sự là cách triển khai đơn giản, chuẩn hoá, hỗ trợ cả Node.js lẫn Python. Nhưng với 30 môi trường riêng, mỗi cái có ít nhất một EC2 chạy liên tục, chi phí cao hơn hẳn so với việc gói 30 container lên một cụm chung. Đề nhấn mạnh MOST cost effective, và đó là điểm quyết định.

• A (mỗi ứng dụng một Auto Scaling group, target group riêng sau một ALB với host-based routing, co giãn theo bộ nhớ ngưỡng 75%) — cùng vấn đề chi phí như B, và nặng hơn về vận hành: 30 Auto Scaling group, 30 target group. Ngoài ra Auto Scaling group của EC2 không có chỉ số bộ nhớ sẵn — phải cài và cấu hình CloudWatch agent cho mọi máy.

• C (chuyển sang Lambda, mỗi ứng dụng một hàm, dùng CloudTrail và CloudWatch alarm để xác nhận tiến trình hoàn thành) — vướng trần 15 phút với các giai đoạn xử lý kéo dài nhiều giờ. Nó cũng đòi viết lại ứng dụng theo mô hình hàm, trong khi đề chỉ nói chuyển lên AWS. Và CloudTrail không ghi việc ứng dụng hoàn thành tiến trình — nó ghi lời gọi API.

Ghi nhớ

⚠ Bốn lựa chọn tính toán theo hình thái tải — bảng phải thuộc: | Hình thái | Lựa chọn | |---|---| | Theo sự kiện, dưới 15 phút | Lambda | | Nhiều ứng dụng nhỏ, chạy liên tục | container trên ECS/EKS — gói chung hạ tầng | | Một ứng dụng, cần đơn giản | Elastic Beanstalk | | Cần kiểm soát máy | EC2 + Auto Scaling |

Từ khoá nhận diện:

"30 ứng dụng nhỏ" + "MOST cost effective" → container, gói chung cụm "standardize on a single deployment methodology" → container hoặc Beanstalk "peak periods last several hours" → loại Lambda "mỗi ứng dụng một môi trường Beanstalk" → 30 hạ tầng riêng, đắt co giãn theo bộ nhớ trên EC2 → cần CloudWatch agent, không có sẵn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mật độ container | số task đang chạy chia số instance | | Có bị thiếu bộ nhớ không | task bị dừng với mã thoát 137 | | Co giãn có kích hoạt không | lịch sử scaling của service |

Và một lời khuyên: hãy đặt memoryReservation (soft limit) thấp hơn memory (hard limit) trong task definition. Đây là thứ quyết định mật độ container mà bạn đạt được: soft limit là mức ECS dùng để quyết định xếp bao nhiêu task lên một máy, còn hard limit là trần mà container không được vượt. Nếu đặt cả hai bằng 3 GB — mức đỉnh — thì mỗi ứng dụng chiếm chỗ như thể nó luôn ở đỉnh, và bạn mất phần lớn lợi ích chi phí của việc dùng container. Đặt soft limit ở 1 GB (mức thường dùng) và hard limit ở 3 GB cho phép gói nhiều ứng dụng hơn, mà vẫn cho từng cái bung lên khi cần.

Đáp án

A, D — hai bước để đạt quyền tối thiểu ở tầng mạng và tầng danh tính cho ECS:

• A — Cấu hình task dùng network mode awsvpc để có cách ly mạng ở mức task.
• D — Gắn security group cho từng task và dùng IAM role dành riêng cho task để truy cập tài nguyên AWS.

Vì sao đúng

Đề đòi quyền tối thiểu cho cả quyền mạng lẫn quyền truy cập tài nguyên. Hai bước đúng lo đúng hai tầng đó.

⚠ Điểm mấu chốt: awsvpc cho mỗi task một ENI riêng — đó là điều kiện để gắn security group ở mức task:

Network mode bridge (phương án B)
        ↓
    Mọi container chia sẻ ENI của host
        ↓
    Security group áp cho CẢ MÁY, không phân biệt được task nào
        ↓
    → không đạt được quyền mạng tối thiểu

Network mode awsvpc
        ↓
    Mỗi task có ENI riêng với IP riêng trong subnet
        ↓
    → security group riêng cho từng task
    → task A không nói chuyện được với task B nếu bạn không cho phép

Vì sao task role chứ không phải instance role (điểm phân biệt với E). Instance role áp cho cả máy, nghĩa là mọi container trên máy đó đều có cùng quyền — vi phạm quyền tối thiểu. Task role cho mỗi task một bộ quyền riêng.

{
  "networkMode": "awsvpc",
  "taskRoleArn": "arn:aws:iam::111122223333:role/TaskDonHang",
  "executionRoleArn": "arn:aws:iam::111122223333:role/ecsTaskExecutionRole"
}

⚠ Đừng bao giờ nhúng thông tin đăng nhập vào container (phương án C):

Inject IAM credentials vào container lúc khởi động
        ↓
    Thông tin đăng nhập dài hạn nằm trong biến môi trường hoặc tệp
        ↓
    Hiện trong `docker inspect`, trong log, trong ảnh chụp container
        ↓
    → task role cấp thông tin đăng nhập TẠM THỜI, tự xoay vòng, không lộ ra

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

• E (áp security group ở mức EC2 instance và gán IAM role cho instance để truy cập tài nguyên) — đây là phương án gần nhất và nó là cách làm mặc định nếu không dùng awsvpc. Nhưng nó vi phạm quyền tối thiểu ở cả hai tầng: security group của instance áp cho mọi container trên máy, và instance role cấp quyền cho mọi container — nên một container bị xâm nhập có toàn bộ quyền mà máy đó có, kể cả quyền của các dịch vụ khác đang chạy cùng.

• C (gắn security group cho task — đúng; nhưng inject IAM credentials vào container lúc khởi động) — nửa đầu đúng, nửa sau là một lỗi bảo mật nghiêm trọng. Nhúng thông tin đăng nhập nghĩa là chúng dài hạn, lộ ra trong nhiều nơi, và phải tự xoay vòng. Task role giải quyết trọn vẹn vấn đề đó bằng thông tin đăng nhập tạm thời.

• B (dùng network mode bridge) — không cho phép gắn security group ở mức task, nên không đạt được cách ly mạng mà đề yêu cầu.

Ghi nhớ

⚠ Bốn network mode của ECS — bảng phải thuộc: | Mode | Đặc điểm | |---|---| | awsvpc | mỗi task một ENI, IP riêng, security group riêng — bắt buộc với Fargate | | bridge | dùng cầu Docker trên host, chia sẻ ENI của máy | | host | container dùng thẳng mạng của host | | none | không có mạng ngoài |

Từ khoá nhận diện:

"least privilege" cho mạng trong ECS → awsvpc + security group theo task "least privilege" cho quyền truy cập AWS → task role "security group ở mức instance" → áp cho mọi container, quá rộng "instance role" cho quyền của ứng dụng → quá rộng "inject credentials vào container" → LUÔN SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Task đang mang danh tính gì | aws sts get-caller-identity từ trong container | | Task có ENI riêng không | describe-tasks, xem attachments | | Subnet còn IP không | AvailableIpAddressCount |

Và một lời khuyên: hãy kiểm tra AvailableIpAddressCount của subnet trước khi chuyển sang awsvpc ở quy mô lớn. Đây là hệ quả dễ bị bỏ qua nhất của network mode này: mỗi task tiêu một địa chỉ IP trong subnet, nên một service co giãn lên vài trăm task có thể làm cạn subnet — và khi đó task mới không khởi động được, với một thông báo lỗi nói về ENI chứ không nói về địa chỉ IP. Sự cố xuất hiện đúng vào lúc bạn đang cần co giãn nhất, và nó ảnh hưởng cả những service khác dùng chung subnet đó.

Đáp án

B — Tạo IAM account cho nhân viên mới và thêm vào IAM group của đội bảo mật; đặt permissions boundary cấp quyền quản lý DynamoDB, RDS và CloudWatch; khi nhân viên nhận thêm trách nhiệm thì thêm dịch vụ vào policy làm permissions boundary.

Vì sao đúng

Đề đòi giới hạn quyền của một người trong khi họ vẫn thuộc group chung, và mở rộng dần một cách đơn giản. Permissions boundary sinh ra đúng cho việc đó.

⚠ Điểm mấu chốt: permissions boundary đặt TRẦN cho một IAM entity — quyền hiệu dụng là giao của boundary và policy:

Group cấp quyền quản lý mọi dịch vụ
        ↓
    Permissions boundary chỉ cho DynamoDB, RDS, CloudWatch
        ↓
    Quyền hiệu dụng = GIAO của hai cái
        ↓
    → người này chỉ quản được ba dịch vụ đó
    → mọi người khác trong group không bị ảnh hưởng gì

Đây là điều làm cho B đơn giản nhất: không phải tạo group mới, không phải viết policy riêng, không phải đổi cấu trúc gì. Và khi người đó sẵn sàng nhận thêm trách nhiệm, bạn chỉ sửa một policy; cuối cùng gỡ boundary đi là họ có đúng quyền như mọi thành viên khác.

aws iam put-user-permissions-boundary --user-name nhan-vien-moi \
  --permissions-boundary arn:aws:iam::111122223333:policy/GioiHanNhanVienMoi

⚠ Permissions boundary KHÔNG cấp quyền — nó chỉ giới hạn:

Chỉ có boundary, không có policy nào cấp quyền
        ↓
    Quyền hiệu dụng = rỗng
        ↓
    → boundary luôn phải đi cùng một nguồn cấp quyền (group hoặc policy)

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

• D (tạo IAM account cho nhân viên; tạo một IAM group MỚI cho riêng họ với policy cấp quyền ba dịch vụ; sau này thêm dịch vụ vào policy đó) — đây là phương án gần nhất và nó thật sự đạt được kết quả mong muốn. Nhưng nó tạo ra một nhánh riêng phải bảo trì: khi người đó cuối cùng cần quyền như mọi thành viên khác, bạn phải nhớ chuyển họ sang group của đội và xoá group tạm — một bước dễ quên, và nếu quên thì họ vĩnh viễn có bộ quyền lệch với đồng nghiệp. Với boundary, người đó đã ở đúng group ngay từ đầu; việc "cấp đủ quyền" chỉ là gỡ một hạn chế.

• C (thêm vào group của đội; dùng SCP giới hạn quyền tối đa; sau này gỡ SCP) — sai đơn vị áp dụng. SCP áp cho cả TÀI KHOẢN hoặc OU, không áp cho một IAM user. Dùng SCP để giới hạn một người nghĩa là giới hạn luôn mọi người trong tài khoản đó — hậu quả rộng hơn rất nhiều so với ý định.

• A (tạo IAM account trong một tài khoản riêng, dùng cross-account access, giới hạn quyền trên role liên tài khoản) — quá phức tạp cho một yêu cầu đơn giản: tạo hẳn một tài khoản AWS và một mô hình truy cập liên tài khoản chỉ để giới hạn quyền của một nhân viên mới. Đề nói rõ "minimizing complexity".

Ghi nhớ

⚠ Bốn tầng quyết định quyền hiệu dụng — bảng phải thuộc: | Tầng | Phạm vi | |---|---| | SCP | tài khoản hoặc OU | | Permissions boundary | một IAM user hoặc role | | Identity policy | user, group, role | | Resource policy | trên chính tài nguyên |

Quyền hiệu dụng = giao của tất cả.

Từ khoá nhận diện:

"giới hạn quyền của MỘT người, vẫn ở trong group" → permissions boundary "minimizing complexity" → không tạo group hay tài khoản mới "SCP để giới hạn một user" → SAI đơn vị, SCP áp cho cả tài khoản "tạo tài khoản riêng" cho một nhân viên → quá phức tạp "tạo group riêng" → chạy được nhưng để lại nhánh phải dọn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Boundary đã gắn chưa | aws iam get-user --query 'User.PermissionsBoundary' | | Quyền hiệu dụng là gì | aws iam simulate-principal-policy | | Có bị chặn nhầm không | CloudTrail, lọc AccessDenied cho user đó |

Và một lời khuyên: hãy nhớ rằng permissions boundary không hiện ra khi bạn chỉ đọc các policy đính kèm. Đây là nguyên nhân của những cuộc gỡ lỗi rất dài: người quản trị mở trang IAM của user, thấy họ thuộc group có quyền quản trị đầy đủ, và kết luận rằng lỗi AccessDenied là không thể xảy ra. Boundary nằm ở một trường riêng mà giao diện không làm nổi bật, và nó lặng lẽ cắt đi phần lớn những gì group cấp. Lệnh get-user hiển thị nó trong một dòng, và thường kết thúc cuộc điều tra ngay lập tức.

Đáp án

A, E, F — ba bước để chuyển hướng 10 tên miền tới các URL đích với ít công vận hành nhất:

• F — Tạo Application Load Balancer có listener cho cả HTTP và HTTPS.
• E — Tạo chứng chỉ SSL bằng ACM, đưa các tên miền vào làm Subject Alternative Name.
• A — Tạo CloudFront distribution và triển khai một Lambda@Edge function.

Vì sao đúng

Đề đòi chuyển hướng theo bảng ánh xạ trong một tài liệu JSON, cho 10 tên miền, chấp nhận cả HTTP và HTTPS, với ít công vận hành nhất.

⚠ Điểm mấu chốt: một chứng chỉ ACM với nhiều SAN phục vụ được cả 10 tên miền — không cần 10 chứng chỉ:

Tạo một chứng chỉ, khai 10 tên miền vào Subject Alternative Names
        ↓
    ACM cấp miễn phí và tự gia hạn
        ↓
    → một chứng chỉ gắn vào ALB và CloudFront
    → không có việc theo dõi ngày hết hạn của 10 chứng chỉ

Vì sao Lambda@Edge chứ không phải Lambda thường (điểm phân biệt với B). Chuyển hướng nên xảy ra tại điểm biên, trước khi request đi xa hơn:

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const host = request.headers.host[0].value;
  const dich = BANG_ANH_XA[host] || 'https://congty.vn';
  return {
    status: '301',
    headers: { location: [{ key: 'Location', value: dich + request.uri }] }
  };
};

⚠ Chuyển hướng trả về ngay tại biên — không cần chạm tới origin:

Lambda@Edge ở viewer request trả về phản hồi 301 luôn
        ↓
    Request KHÔNG đi tiếp tới ALB hay bất kỳ origin nào
        ↓
    → nhanh nhất, rẻ nhất, và không có hạ tầng nào phải chịu tải

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

• B (tạo một Lambda function dùng event message và tài liệu JSON để tra và trả về URL chuyển hướng) — đây là phương án gần nhất và logic của nó chính xác bằng đáp án đúng: tra bảng rồi trả URL. Nhưng nó thiếu chỗ để chạy: một Lambda thường cần một thứ gọi nó — API Gateway, ALB target, hoặc một sự kiện. Bản thân nó không nhận được request HTTP từ người dùng. Trong bộ ba đã chọn, Lambda@Edge (phương án A) vừa là nơi chạy vừa là logic, nên B trở nên thừa và không hoàn chỉnh.

• C (API Gateway API với custom domain để publish một Lambda function) — chạy được nhưng nhiều việc hơn: phải cấu hình custom domain cho từng tên miền, quản base path mapping, và chịu chi phí API Gateway cho mỗi request chuyển hướng. Với việc chỉ trả về một header Location, đó là hạ tầng thừa.

• D (dựng một trang web động trên EC2 để tra JSON và trả về URL chuyển hướng) — nhiều việc vận hành nhất: một máy chủ phải vá, giám sát, làm cho sẵn sàng cao và co giãn — cho một tác vụ chỉ là trả về một header.

Ghi nhớ

⚠ Bốn cách chuyển hướng URL trên AWS — bảng phải thuộc, theo thứ tự ít việc nhất: | Cách | Việc vận hành | |---|---| | S3 static website redirect | gần như bằng 0 — nhưng chỉ chuyển hướng đơn giản | | ALB listener rule với redirect action | thấp — không cần mã, nhưng luật tĩnh | | CloudFront Function / Lambda@Edge | thấp — logic tuỳ ý, chạy tại biên | | EC2 hoặc container | cao nhất |

Từ khoá nhận diện:

"redirect theo bảng ánh xạ trong JSON" → cần logic → Lambda@Edge hoặc CloudFront Function "nhiều tên miền, một chứng chỉ" → ACM với Subject Alternative Names "HTTP và HTTPS" → hai listener, hoặc CloudFront với redirect-to-https "Lambda thường" để nhận request HTTP → cần một thứ gọi nó "EC2 cho việc chuyển hướng" → quá nặng

Với bài này, nếu bảng ánh xạ đủ nhỏ để nhúng vào mã, CloudFront Function còn rẻ hơn — nhưng nó không có trong danh sách phương án.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chuyển hướng có đúng không | curl -I https://ten-mien — xem header Location | | Chứng chỉ có phủ đủ tên miền không | kiểm danh sách SAN trong ACM | | Lambda@Edge có chạy không | log nằm ở Region gần điểm biên, không phải Region gốc |

Và một lời khuyên: hãy tạo chứng chỉ ACM cho CloudFront ở us-east-1, bất kể ứng dụng của bạn nằm ở Region nào. Đây là ràng buộc cứng và là nguyên nhân của rất nhiều phút bối rối: bạn tạo chứng chỉ ở Region của ALB, mọi thứ hợp lệ, chứng chỉ ở trạng thái Issued — nhưng khi cấu hình CloudFront thì nó không xuất hiện trong danh sách chọn, và giao diện không giải thích vì sao. CloudFront là dịch vụ toàn cầu và chỉ đọc chứng chỉ từ us-east-1. Nếu bạn cần dùng cùng bộ tên miền cho cả ALB lẫn CloudFront, hãy tạo hai chứng chỉ giống nhau ở hai Region.