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

Đáp án

A — Dựng AWS Client VPN endpoint, gắn nó vào một subnet trong VPC, bật self-service portal, rồi hướng dẫn lập trình viên nối bằng Client VPN client.

Vì sao đúng

Đề có hai ràng buộc chồng lên nhau, và chỉ một dịch vụ thoả cả hai: người dùng phân tán ở nhiều nơi (làm việc từ xa + ba văn phòng) và dữ liệu phải nằm trong VPC.

⚠ Điểm mấu chốt: Client VPN là VPN "client-to-site", khác hẳn Site-to-Site VPN:

Laptop lập trình viên (bất kỳ đâu)
        ↓
    Client VPN endpoint (dịch vụ có quản lý, nhiều AZ)
        ↓
    Gắn vào subnet trong VPC → nhận IP trong dải VPC
        ↓
    → gọi thẳng endpoint riêng của OpenSearch, không đi qua Internet

Điểm quan trọng nhất: OpenSearch trong VPC chỉ có địa chỉ riêng. Máy ở ngoài không phân giải và không định tuyến tới được. Client VPN giải quyết đúng chuyện đó bằng cách đưa laptop vào trong mạng VPC — sau khi nối, laptop có một IP thuộc dải subnet đã gắn, nên nó phân giải và gọi được endpoint riêng như một EC2 nội bộ.

Client VPN còn khớp với hình thái người dùng của đề. Người làm từ xa không có địa chỉ IP cố định — họ ở nhà, ở quán, ở khách sạn. Mọi giải pháp gắn với địa điểm (Site-to-Site VPN, Direct Connect) đều giả định một đầu mạng cố định, và giả định đó sai với nhóm người này.

Dựng endpoint và gắn subnet:

aws ec2 create-client-vpn-endpoint \
  --client-cidr-block 10.100.0.0/22 \
  --server-certificate-arn arn:aws:acm:ap-southeast-1:111122223333:certificate/abc \
  --authentication-options Type=federated-authentication,FederatedAuthentication={SAMLProviderArn=arn:aws:iam::111122223333:saml-provider/IdP} \
  --connection-log-options Enabled=true,CloudwatchLogGroup=/aws/clientvpn \
  --self-service-portal enabled

aws ec2 associate-client-vpn-target-network \
  --client-vpn-endpoint-id cvpn-endpoint-abc \
  --subnet-id subnet-private-1a

⚠ Dải client CIDR không được trùng với CIDR của VPC:

Client CIDR trùng dải VPC
        ↓
    Bảng định tuyến của laptop có hai đường cho cùng một dải
        ↓
    → nối được VPN nhưng không tới được tài nguyên, và không có lỗi rõ ràng

Dải này cũng phải đủ lớn: mỗi subnet được gắn tiêu tốn một phần, và AWS đòi tối thiểu /22.

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

• B (bastion host trong public subnet, mở SSH từ dải CIDR của công ty) — đây là phương án gần nhất và nó thật sự giữ được dữ liệu trong VPC: OpenSearch không phơi ra ngoài, mọi truy cập đi qua một điểm kiểm soát. Nhưng nó vỡ ở đúng chỗ đề nhấn mạnh. Thứ nhất, "dải CIDR của công ty" không phủ được người làm từ xa — họ dùng mạng gia đình với IP động, không nằm trong dải nào cả. Thứ hai, phân tích log OpenSearch là việc dùng giao diện web Dashboards, mà qua SSH thì phải dựng port forwarding hoặc SOCKS proxy thủ công trên từng máy — đó không phải "truy cập trực tiếp từ máy phát triển" như đề đòi. Thứ ba, bastion là một EC2 phải vá, phải giám sát, phải quản lý khoá SSH: nhiều việc hơn hẳn một endpoint có quản lý.

• C (transit gateway + Site-to-Site VPN, nối bằng OpenVPN client) — trộn lẫn hai mô hình không ăn khớp. Site-to-Site VPN nối hai mạng với nhau, không nối từng laptop; nó cần thiết bị đầu cuối có IP công cộng cố định ở phía kia. Câu "lập trình viên nối bằng OpenVPN client" không khớp với thứ vừa dựng — Site-to-Site VPN của AWS không phát hồ sơ cho client cá nhân. Ngay cả khi dựng cho ba văn phòng thì người làm từ xa vẫn ở ngoài.

• D (transit gateway + Direct Connect với public VIF) — sai nặng nhất, và sai ở một chi tiết đáng nhớ: public VIF không cho vào tài nguyên riêng trong VPC. Public VIF chỉ tới các endpoint công cộng của AWS (S3, DynamoDB, API công khai). Muốn tới VPC phải là private VIF hoặc transit VIF. Ngoài ra Direct Connect mất hàng tuần tới hàng tháng để cung cấp, tốn kém, và nối tới địa điểm — vô dụng với người làm từ xa.

Ghi nhớ

⚠ Bốn cách nối vào tài nguyên riêng trong VPC — bảng phải thuộc: | Cách | Nối cái gì | Hợp với | |---|---|---| | Client VPN | một máy khách → VPC | người dùng phân tán, làm từ xa | | Site-to-Site VPN | mạng → VPC, qua Internet | văn phòng có thiết bị đầu cuối cố định | | Direct Connect | mạng → AWS, đường riêng | băng thông lớn, độ trễ ổn định, dài hạn | | Session Manager | shell vào EC2 | quản trị máy, không phải truy cập ứng dụng web |

Từ khoá nhận diện:

"remote workers" hoặc "users at multiple locations" → Client VPN "data must remain in the VPC" → không được đổi sang endpoint công khai "connect from their local development machines" → client-to-site, không phải bastion "public VIF" để vào tài nguyên riêng trong VPC → LUÔN SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Laptop đã vào được mạng VPC chưa | dig <domain-opensearch> phải ra IP riêng | | Đường về có thông không | kiểm bảng định tuyến của Client VPN endpoint | | Ai đang nối | bật connection log ghi vào CloudWatch Logs |

Và một lời khuyên: hãy gỡ association của subnet khi không dùng nữa, đừng chỉ ngắt kết nối người dùng. Client VPN tính tiền theo giờ mỗi subnet được gắn, không theo số người đang nối — một endpoint dựng để thử nghiệm rồi bỏ quên vẫn tính tiền đều đặn hằng tháng dù không ai kết nối lần nào. Không có cảnh báo nào cho chuyện này; nó chỉ hiện ra khi ai đó đọc kỹ hoá đơn.

Đáp án

B, D, E — ba thứ phải kiểm khi liên kết danh tính SAML hỏng:

• B — Trust policy của IAM role đặt SAML provider làm principal.
• D — IdP của công ty phát SAML assertion ánh xạ đúng người dùng/nhóm sang IAM role có quyền phù hợp.
• E — Web portal gọi AssumeRoleWithSAML với ARN của SAML provider, ARN của IAM role, và SAML assertion từ IdP.

Vì sao đúng

Manh mối quan trọng nhất nằm ở chỗ dễ lướt qua: kiến trúc sư thử thì được, người dùng thử thì không. Hạ tầng liên kết danh tính đã đứng vững — nếu SAML provider hay endpoint sai thì cả hai đều hỏng. Vậy lỗi nằm ở đường ánh xạ từ danh tính cụ thể sang role cụ thể, chứ không ở nền tảng.

⚠ Điểm mấu chốt: liên kết SAML là một chuỗi ba mắt xích, đứt bất kỳ mắt nào cũng ra cùng một triệu chứng "không vào được":

Người dùng đăng nhập vào IdP tại chỗ
        ↓
    IdP phát SAML assertion — trong đó có thuộc tính Role
        ↓
    Portal gọi sts:AssumeRoleWithSAML (provider ARN + role ARN + assertion)
        ↓
    IAM đọc trust policy của role: principal có phải SAML provider này không?
        ↓
    → trả về thông tin đăng nhập tạm thời

B — trust policy phải nhận đúng provider. Đây là chiều "role có tin IdP không". Không có nó thì dù assertion hoàn hảo, IAM vẫn từ chối:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::111122223333:saml-provider/CongTyIdP"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}}
  }]
}

D — IdP phải ánh xạ người dùng sang role. Đây là mắt xích khớp nhất với triệu chứng của đề: tài khoản kiểm thử của kiến trúc sư nằm trong nhóm đã được ánh xạ, tài khoản người dùng thử thì chưa. Assertion phải mang hai thuộc tính:

E — portal phải gọi đúng API với đủ ba tham số:

aws sts assume-role-with-saml \
  --role-arn arn:aws:iam::111122223333:role/NguoiDungLienKet \
  --principal-arn arn:aws:iam::111122223333:saml-provider/CongTyIdP \
  --saml-assertion file://assertion-base64.txt

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

• F (IAM user phải có sts:AssumeRoleWithSAML trong permissions policy) — đây là phương án gần nhất và nó đúng ở một điểm quan trọng: AssumeRoleWithSAML thật sự là hành động cần được cho phép. Nhưng nó đặt sai chỗ hoàn toàn. Hành động này được cho phép trong trust policy của role (chiều tài nguyên), không phải trong permissions policy của một IAM user. Sâu hơn nữa: liên kết danh tính tồn tại chính là để KHÔNG cần IAM user. Người dùng liên kết không có IAM user nào để gắn policy vào — nói "permissions policy của IAM user" là tự mâu thuẫn với mô hình đang bàn. Đây là bẫy hay gặp nhất của dạng câu này vì tên hành động đọc lên nghe rất hợp lý.

• A (STS có IdP tại chỗ làm "event source") — không có khái niệm này. STS không đăng ký "nguồn sự kiện"; nó nhận lời gọi API kèm assertion. Cụm "event source" mượn từ Lambda, đặt vào đây chỉ để nghe quen tai.

• C (người dùng phải nhập mã TOTP) — MFA thuộc về bước xác thực tại IdP, xảy ra trước khi có assertion. Nó không phải mắt xích trong đường liên kết sang AWS, và triệu chứng của MFA sai là "đăng nhập IdP thất bại", không phải "đăng nhập IdP xong mà không vào được AWS". Lại một lần nữa mâu thuẫn: đề nói người dùng liên kết, mà "IAM users" thì không tồn tại trong luồng này.

Ghi nhớ

⚠ Bốn thành phần của liên kết SAML — bảng phải thuộc: | Thành phần | Ở đâu | Việc | |---|---|---| | IdP metadata | tải lên IAM khi tạo SAML provider | cho AWS biết khoá ký của IdP | | Trust policy | trên IAM role | role tin provider nào | | Attribute mapping | cấu hình ở IdP | người/nhóm nào ra role nào | | Permissions policy | trên IAM role | sau khi vào rồi thì làm được gì |

Từ khoá nhận diện:

"the architect's test worked but users cannot access" → lỗi ở ánh xạ người dùng/nhóm, không ở nền tảng "SAML provider as the principal" → đúng, đó là trust policy "IAM users' permissions policy" trong bài về người dùng liên kết → LUÔN SAI, họ không có IAM user "AssumeRoleWithSAML" → cần provider ARN + role ARN + assertion, thiếu một là hỏng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem nội dung assertion thật | bắt SAMLResponse ở trình duyệt, giải base64, đọc thuộc tính Role | | Xem lời gọi có tới AWS không | tìm sự kiện AssumeRoleWithSAML trong CloudTrail | | Thử tách biệt khỏi portal | gọi thẳng aws sts assume-role-with-saml bằng assertion vừa bắt |

Và một lời khuyên: hãy giải mã SAMLResponse thật của chính người dùng đang lỗi, đừng tin cấu hình ánh xạ trên màn hình IdP. Rất nhiều IdP hiển thị quy tắc ánh xạ trông hoàn hảo nhưng không khớp người dùng cụ thể — vì họ thuộc nhóm khác, hoặc thuộc tính nguồn rỗng. Khi ánh xạ không khớp, IdP vẫn phát assertion hợp lệ, chỉ là thiếu thuộc tính Role; đăng nhập vẫn "thành công" ở phía IdP, không có lỗi nào ở đó cả, và sự cố chỉ lộ ra ở bước sau dưới dạng một trang trắng khó hiểu.

Đáp án

A — Cấu hình Service Control Policy (SCP) trong AWS Control Tower để cấm gán địa chỉ IP công cộng cho EC2 instance trên toàn bộ các OU.

Vì sao đúng

Đề dùng ba từ khoá cùng lúc: enforce, across all OUs, AWS Control Tower. Cả ba đều trỏ về một công cụ duy nhất — SCP. Đây là dạng câu phân biệt ngăn chặn với phát hiện rồi sửa.

⚠ Điểm mấu chốt: SCP chặn TRƯỚC khi tài nguyên tồn tại, mọi cách khác chỉ dọn sau khi nó đã tồn tại:

RunInstances kèm AssociatePublicIpAddress=true
        ↓
    SCP xét: hành động này có bị Deny không?
        ↓
    → API trả UnauthorizedOperation — instance KHÔNG BAO GIỜ được tạo
        ↓
    → không có cửa sổ thời gian nào máy có IP công cộng

Chính sách thực tế trông như sau. Chú ý nó chặn theo điều kiện trên tham số, không chặn nguyên hành động RunInstances:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "CamGanIpCongCong",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:network-interface/*",
    "Condition": {
      "Bool": {"ec2:AssociatePublicIpAddress": "true"}
    }
  }]
}

⚠ Resource phải là network-interface, không phải instance:

IP công cộng gắn vào ENI, không gắn vào instance
        ↓
    Điều kiện ec2:AssociatePublicIpAddress chỉ xét được ở ngữ cảnh ENI
        ↓
    → viết Resource là instance/* thì chính sách không khớp lần nào
        ↓
    → không lỗi, không cảnh báo, guardrail đơn giản là không bao giờ chặn ai

Trong Control Tower, SCP xuất hiện dưới tên preventive guardrail và được quản lý tập trung: bật ở cấp OU, mọi tài khoản trong đó và mọi tài khoản mới được Account Factory tạo ra sau này đều thừa hưởng. Đó chính là nghĩa "centrally governed" của đề.

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

• C (AWS Config giám sát rồi Lambda tự gỡ IP công cộng) — đây là phương án gần nhất và nó thật sự chạy được: đây là mẫu "detective guardrail + auto-remediation" hoàn toàn hợp lệ, Control Tower cũng có sẵn detective guardrail. Nhưng nó không phải cấm, nó là dọn dẹp. Giữa lúc instance khởi động và lúc Lambda gỡ IP có một khoảng thời gian thật — thường vài phút với Config — trong đó máy đang mở ra Internet. Với một chính sách bảo mật viết là "strictly prohibits", một cửa sổ vài phút là vi phạm. Thêm nữa: gỡ IP công cộng khỏi một ENI đang chạy không đơn giản như nghe — với IP tự động gán thì cách duy nhất là dừng hoặc huỷ instance, nghĩa là hành động khắc phục tự nó gây gián đoạn. Và giải pháp này còn phải triển khai Config rule + Lambda + quyền cross-account cho hàng chục tài khoản, nhiều việc hơn hẳn một SCP.

• B (network ACL chặn traffic Internet trong từng VPC) — chặn lưu lượng chứ không chặn việc gán IP. Instance vẫn nhận IP công cộng, vẫn hiện ra trong danh sách tài nguyên phơi ra ngoài, vẫn vi phạm chính sách. Tệ hơn, NACL nằm trong quyền của từng tài khoản thành viên — người vận hành ở đó sửa được, nên đây không phải kiểm soát tập trung. Và phải làm thủ công cho từng VPC mới.

• D (AWS WAF web ACL hạn chế truy cập Internet tới EC2) — sai về bản chất dịch vụ. WAF không gắn được trực tiếp vào EC2 instance; nó chỉ gắn vào CloudFront, ALB, API Gateway, AppSync và Cognito. WAF cũng chỉ xét lưu lượng HTTP/HTTPS ở tầng 7 — nó không liên quan gì tới việc một máy có địa chỉ công cộng hay không.

Ghi nhớ

⚠ Bốn loại guardrail trong Control Tower — bảng phải thuộc: | Loại | Cơ chế | Thời điểm | |---|---|---| | Preventive | SCP | chặn lời gọi API — vi phạm không xảy ra | | Detective | AWS Config rule | phát hiện sau khi tài nguyên đã tồn tại | | Proactive | CloudFormation Hooks | chặn lúc triển khai stack, trước khi tạo | | Mandatory / Strongly recommended / Elective | phân loại theo mức | mandatory thì không tắt được |

Từ khoá nhận diện:

"prohibits" / "prevent" / "must not be able to" → SCP (preventive) "detect" / "report" / "alert when" → AWS Config (detective) "across all OUs" + "centrally" → SCP gắn ở root hoặc OU "AWS Config + Lambda to remove" khi đề nói cấm tuyệt đối → SAI, đó là dọn sau "WAF" gắn vào EC2 → LUÔN SAI, WAF không gắn được vào EC2

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP có thật sự chặn không | chạy aws ec2 run-instances --associate-public-ip-address trong tài khoản thành viên | | Còn máy nào đang có IP công cộng | Config rule quản lý sẵn ec2-instance-no-public-ip | | Có ai bị chặn nhầm không | lọc CloudTrail theo errorCode = UnauthorizedOperation |

Và một lời khuyên: hãy chặn cả ec2:AssociateAddress chứ không chỉ IP tự động. Một SCP chỉ chặn AssociatePublicIpAddress vẫn cho phép người dùng khởi động máy trong subnet riêng rồi gắn Elastic IP vào sau — kết quả cuối cùng y hệt thứ chính sách muốn cấm, nhưng đi qua một API khác. Không có gì báo cho bạn biết lỗ này tồn tại: bảng điều khiển Control Tower vẫn hiện guardrail màu xanh "đang bật", vì đúng là nó đang bật — chỉ có điều nó canh sai cửa.

Đáp án

A — Đặt reserved concurrency cho hàm Lambda mới, và theo dõi các hàm quan trọng hiện có bằng CloudWatch alarm trên chỉ số Throttles.

Vì sao đúng

Lambda có một hạn mức concurrency dùng chung cho cả tài khoản trong mỗi Region (mặc định 1.000). Mọi hàm rút từ cùng một hũ đó. Một hàm mới nổi lên có thể ăn hết hũ và làm mọi hàm khác bị throttle — đúng nỗi lo của đề.

⚠ Điểm mấu chốt: reserved concurrency vừa là TRẦN vừa là SÀN, đó là lý do nó giải được bài này:

Đặt reserved concurrency = 100 cho hàm sao chép
        ↓
    Hàm đó KHÔNG BAO GIỜ vượt quá 100 lời gọi đồng thời  ← trần: bảo vệ hàm khác
        ↓
    100 suất ấy bị RÚT khỏi hũ chung, dành riêng cho nó   ← sàn: bảo vệ chính nó
        ↓
    → hàm quan trọng vẫn còn 900 suất, không ai giẫm chân ai

Tính hai mặt này là điều hay bị bỏ sót. Đặt reserved concurrency không chỉ kìm hàm mới lại — nó còn cắt hẳn phần đó ra khỏi hũ chung. Nghĩa là ngay cả khi hàm sao chép bùng lên vì hàng nghìn object đổ vào S3 cùng lúc, phần còn lại của tài khoản vẫn nguyên vẹn.

# đặt trần 100 cho hàm sao chép
aws lambda put-function-concurrency \
  --function-name sao-chep-s3 --reserved-concurrent-executions 100

# xem hũ chung còn bao nhiêu
aws lambda get-account-settings \
  --query 'AccountLimit.ConcurrentExecutions'

Phần alarm cũng không thừa. Throttles là chỉ số duy nhất cho biết đã có lời gọi bị từ chối vì hết suất:

aws cloudwatch put-metric-alarm \
  --alarm-name lambda-quan-trong-bi-nghen \
  --namespace AWS/Lambda --metric-name Throttles \
  --dimensions Name=FunctionName,Value=ham-quan-trong \
  --statistic Sum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1

⚠ Đặt reserved concurrency quá thấp thì chính hàm đó tự bóp cổ mình:

Sự kiện S3 gọi Lambda bất đồng bộ
        ↓
    Vượt reserved concurrency → bị throttle
        ↓
    Lambda tự thử lại, mặc định 2 lần trong tối đa 6 giờ
        ↓
    → hết lượt thử mà vẫn nghẽn thì SỰ KIỆN BỊ MẤT nếu không cấu hình DLQ

Vì thế đi kèm reserved concurrency luôn phải có dead-letter queue hoặc on-failure destination.

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

• D (thuật toán exponential backoff trong hàm + alarm Throttles) — đây là phương án gần nhất và backoff thật sự là kỹ thuật đúng cho việc gọi ra dịch vụ ngoài: hàm này ghi sang nhiều bucket ở nhiều tài khoản, backoff giúp nó chịu được lỗi tạm thời từ S3. Nhưng nó không giải bài này. Backoff xử lý cái xảy ra bên trong một lời gọi Lambda đang chạy; vấn đề của đề là có bao nhiêu lời gọi chạy cùng lúc. Tệ hơn nữa, backoff kéo dài thời gian chạy mỗi lời gọi, mà concurrency = tốc độ gọi × thời gian chạy — nên nó làm tăng số suất bị chiếm, đúng chiều ngược với mục tiêu. Đây là bẫy tinh vi: một kỹ thuật đúng đắn, đặt sai bài toán, và tác dụng phụ của nó lại đi ngược yêu cầu.

• B (tăng timeout lên mức tối đa) — sai theo cùng cơ chế, còn rõ ràng hơn. Timeout dài hơn nghĩa là mỗi lời gọi giữ suất concurrency lâu hơn, nên hàm chiếm nhiều suất hơn chứ không ít đi. Đây là phương án làm vấn đề tệ đi.

• C (tạo nhiều hàm Lambda, cho S3 "cân bằng tải" giữa chúng) — hai chỗ sai. Thứ nhất, S3 event notification không có cơ chế cân bằng tải — nó gửi sự kiện tới mọi đích khớp cấu hình, không chia lượt. Thứ hai, kể cả chia được thì tổng concurrency vẫn rút từ cùng một hũ của tài khoản; chia một khối lượng công việc ra năm hàm không làm nó tốn ít suất hơn.

Ghi nhớ

⚠ Bốn khái niệm concurrency của Lambda — bảng phải thuộc: | Khái niệm | Nghĩa | |---|---| | Account concurrency | hũ chung của Region, mặc định 1.000, xin nâng được | | Reserved concurrency | trần cứng cho một hàm, đồng thời rút phần đó khỏi hũ chung | | Provisioned concurrency | giữ sẵn môi trường đã khởi tạo — chống cold start, có tính tiền | | Burst concurrency | tốc độ tăng suất ban đầu, tuỳ Region |

Từ khoá nhận diện:

"not impact other functions" → reserved concurrency "cold start" / "consistent latency" → provisioned concurrency "TooManyRequestsException" → đang bị throttle vì concurrency "increase the timeout" để chữa nghẽn concurrency → LUÔN SAI, làm tệ hơn "exponential backoff" để chữa nghẽn concurrency → SAI, đó là chữa lỗi gọi ra ngoài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm đang dùng bao nhiêu suất | chỉ số ConcurrentExecutions theo từng hàm | | Đã có ai bị từ chối chưa | chỉ số Throttles — bất kỳ giá trị nào khác 0 đều đáng xem | | Hũ chung còn bao nhiêu | UnreservedConcurrentExecutions |

Và một lời khuyên: hãy cấu hình dead-letter queue hoặc on-failure destination cho mọi hàm được gọi bất đồng bộ mà bạn đặt reserved concurrency. Đây là nơi mất dữ liệu âm thầm điển hình: sự kiện S3 bị throttle sẽ được Lambda thử lại vài lần rồi bỏ đi hẳn nếu không có nơi hứng. Hàm không báo lỗi vì nó chưa từng chạy, Errors vẫn bằng 0, biểu đồ nhìn hoàn toàn bình thường — chỉ có object không bao giờ được sao chép sang bucket đích, và bạn chỉ biết khi có người đi tìm một tệp lẽ ra phải ở đó.

Đáp án

C, E — hai bước để duyệt AMI tự động và quét lại định kỳ:

• C — Dùng Amazon Inspector chạy gói đánh giá CVE trên các EC2 instance khởi động từ AMI đã duyệt.
• E — Dùng Lambda viết luật duyệt tự động, lưu danh sách AMI đã duyệt trong SSM Parameter Store, dùng EventBridge kích hoạt Systems Manager Automation document trên mọi instance mỗi 30 ngày.

Vì sao đúng

Đề đòi ba thứ: đánh giá CVE tự động, đánh dấu đã duyệt, và quét lại mỗi 30 ngày. Hai phương án đúng chia nhau đúng ba việc đó.

⚠ Điểm mấu chốt: Inspector quét INSTANCE, không quét AMI trực tiếp — nên quy trình phải chạy máy lên từ AMI đó:

AMI ứng viên
        ↓
    Khởi động một instance tạm từ AMI
        ↓
    Inspector quét lỗ hổng phần mềm trên instance đó
        ↓
    Lambda đọc kết quả, đối chiếu ngưỡng nghiêm trọng
        ↓
    → đạt thì ghi AMI id vào Parameter Store, huỷ instance tạm

C — vì sao Inspector là công cụ đúng. Trong bộ công cụ AWS, Inspector là dịch vụ duy nhất làm đánh giá lỗ hổng phần mềm dựa trên cơ sở dữ liệu CVE. Nó tự phát hiện tài nguyên qua SSM agent, tự cập nhật nguồn CVE, và chấm điểm rủi ro. Đề nói thẳng "CVE assessment" — chỉ có một câu trả lời.

E — vì sao Parameter Store là nơi giữ danh sách duyệt. Nó cần một nơi mà cả người và pipeline đọc được, có phiên bản, có quyền IAM riêng:

# ghi nhận một AMI đã qua kiểm duyệt
aws ssm put-parameter \
  --name /ami/da-duyet/amazon-linux-2023 \
  --type String --value ami-0abc123 --overwrite

# CloudFormation/Terraform lấy AMI hiện hành từ đây thay vì hard-code
aws ssm get-parameter --name /ami/da-duyet/amazon-linux-2023 \
  --query 'Parameter.Value' --output text

Và lịch 30 ngày do EventBridge giữ:

aws events put-rule --name quet-lai-ami-30-ngay \
  --schedule-expression "rate(30 days)"

⚠ Vì sao phải quét LẠI dù AMI không đổi:

AMI đóng băng tại thời điểm tạo — nội dung không bao giờ đổi
        ↓
    Nhưng CVE mới được công bố mỗi ngày
        ↓
    → một AMI "sạch" tháng trước có thể đang chứa lỗ hổng nghiêm trọng hôm nay
        ↓
    → "đã duyệt" phải có hạn dùng, không phải nhãn vĩnh viễn

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

• A (Lambda + Parameter Store + Config rule quản lý sẵn quét liên tục + SSM Automation khắc phục) — đây là phương án gần nhất và nửa đầu của nó giống hệt E: Lambda viết luật duyệt, Parameter Store giữ danh sách — phần đó đúng. Nó chỉ hỏng ở nửa sau. AWS Config không đánh giá CVE. Config kiểm tra cấu hình tài nguyên có khớp quy tắc mong muốn không (bucket có mã hoá chưa, security group có mở 0.0.0.0/0 không) — nó không nhìn vào danh sách gói phần mềm bên trong máy và không biết CVE là gì. Ngoài ra "continuous scanning" không đáp ứng yêu cầu chu kỳ 30 ngày rõ ràng của đề, và Config đắt hơn hẳn khi chạy liên tục trên toàn bộ đội máy.

• B (dùng SSM agent để chạy đánh giá CVE) — nhầm vai trò. SSM agent là phương tiện, không phải công cụ đánh giá: Inspector dùng SSM agent để thu thập kho gói phần mềm, nhưng bản thân agent không có cơ sở dữ liệu CVE và không chấm điểm gì. Nói "dùng SSM agent chạy CVE assessment" giống như nói "dùng dây mạng để quét virus".

• D (GuardDuty chạy gói đánh giá CVE) — sai dịch vụ. GuardDuty là phát hiện mối đe doạ, không phải quản lý lỗ hổng. Nó đọc VPC Flow Logs, DNS logs, CloudTrail để tìm hành vi bất thường — máy đang gọi tới địa chỉ C2, khoá bị dùng từ nơi lạ, dấu hiệu đào tiền số. Nó trả lời "có ai đang tấn công tôi không", còn Inspector trả lời "tôi có lỗ hổng nào không". Hai câu hỏi khác nhau hoàn toàn.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật hay bị lẫn — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | Nguồn dữ liệu | |---|---|---| | Inspector | "Tôi có lỗ hổng phần mềm nào?" | kho gói qua SSM agent + CSDL CVE | | GuardDuty | "Có ai đang tấn công tôi?" | Flow Logs, DNS, CloudTrail | | AWS Config | "Cấu hình có lệch chuẩn không?" | trạng thái cấu hình tài nguyên | | Security Hub | "Gom mọi phát hiện lại xem thế nào?" | tổng hợp từ ba cái trên |

Từ khoá nhận diện:

"CVE" / "vulnerability assessment" / "patch level" → Inspector "threat detection" / "malicious activity" / "compromised credentials" → GuardDuty "compliance" / "configuration drift" / "desired state" → AWS Config "every 30 days" / lịch cố định → EventBridge scheduled rule "Config rule để quét CVE" → LUÔN SAI, Config không biết CVE

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Inspector có thấy máy không | aws inspector2 list-coverage — máy thiếu SSM agent sẽ không xuất hiện | | Danh sách duyệt có mới không | aws ssm get-parameter-history xem lần cập nhật gần nhất | | Lịch có chạy không | chỉ số Invocations của EventBridge rule |

Và một lời khuyên: hãy kiểm list-coverage của Inspector chứ đừng nhìn số phát hiện. Đây là lỗi im lặng nguy hiểm nhất của quản lý lỗ hổng: một máy thiếu SSM agent, hoặc agent chết, sẽ không xuất hiện trong kết quả quét — và vì nó không xuất hiện, nó cũng không có phát hiện nào. Bảng điều khiển hiện "0 lỗ hổng nghiêm trọng" trông y hệt nhau dù bạn đang an toàn thật hay đang không quét gì cả. Con số cần theo dõi là số máy được quét, không phải số lỗ hổng tìm thấy.

Đáp án

B, D — hai bước để có một hoá đơn chung, tách chi phí theo đơn vị, và giới hạn dịch vụ tập trung:

• D — Dùng AWS Organizations tạo một tổ chức duy nhất trong tài khoản mẹ với all features bật, rồi mời từng tài khoản đơn vị kinh doanh gia nhập.
• B — Tạo SCP chỉ cho phép các dịch vụ và tính năng đã duyệt, gắn vào các tài khoản đơn vị kinh doanh.

Vì sao đúng

Đề có ba yêu cầu, và thứ tự phụ thuộc giữa chúng chính là nội dung câu hỏi: một hoá đơn, tách chi phí theo đơn vị, giới hạn dịch vụ được quản lý tập trung.

⚠ Điểm mấu chốt: SCP chỉ tồn tại khi tổ chức bật "all features" — nên D là điều kiện tiên quyết của B:

Tạo tổ chức với chế độ Consolidated billing only
        ↓
    Có hoá đơn gộp, có tách chi phí theo tài khoản
        ↓
    Nhưng KHÔNG dùng được SCP — mục quản trị bị xám
        ↓
    → phải bật all features mới có công cụ kiểm soát

Đây là lý do B và D đi với nhau chứ không phải hai lựa chọn độc lập. AWS Organizations có hai chế độ, và chọn nhầm thì mất hẳn nửa yêu cầu của đề:

Về tách chi phí: consolidated billing tự nhiên cho ra chi phí theo từng tài khoản thành viên. Vì mỗi đơn vị kinh doanh dùng một tài khoản riêng, ranh giới tài khoản chính là ranh giới chi phí — không cần gắn tag gì thêm. Đây là một trong những lý do chính người ta tách tài khoản theo đơn vị tổ chức.

# tạo tổ chức với đầy đủ tính năng
aws organizations create-organization --feature-set ALL

# mời tài khoản đơn vị kinh doanh
aws organizations invite-account-to-organization \
  --target Id=444455556666,Type=ACCOUNT

# nâng cấp nếu lỡ tạo ở chế độ chỉ gộp hoá đơn
aws organizations enable-all-features

⚠ Nâng từ "chỉ gộp hoá đơn" lên "all features" cần MỌI tài khoản thành viên đồng ý:

Gọi enable-all-features
        ↓
    Mỗi tài khoản thành viên nhận một handshake phải chấp nhận
        ↓
    Một tài khoản không phản hồi → cả quá trình treo
        ↓
    → tạo đúng chế độ ngay từ đầu rẻ hơn nhiều

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

• A (bật consolidated billing trong billing console rồi liên kết các tài khoản) — đây là phương án gần nhất và nó thật sự giải được hai trong ba yêu cầu: một hoá đơn, và chi phí tách theo tài khoản. Rất nhiều người chọn nó vì đề mở đầu bằng chuyện hoá đơn. Nhưng nó bỏ trắng yêu cầu thứ ba — không có SCP thì không có cách nào giới hạn dịch vụ tập trung. Còn một điểm nữa đáng nhớ: consolidated billing ngày nay không phải một tính năng bật riêng mà là một chế độ của AWS Organizations. Mô tả "bật trong billing console rồi liên kết tài khoản" là cách làm của thời trước Organizations, không còn đúng với giao diện hiện tại.

• C (permissions boundary áp cho từng tài khoản) — sai về đơn vị áp dụng. Permissions boundary gắn vào IAM user hoặc IAM role, không gắn vào tài khoản. Không tồn tại thứ gọi là "permissions boundary của một AWS account". Kể cả nếu gắn cho từng role thì đó vẫn là việc phải làm trong từng tài khoản, do người ở tài khoản đó thực hiện và sửa được — trái hẳn với "governed centrally".

• E (tạo tổ chức riêng cho mỗi tài khoản rồi thiết lập quan hệ tin cậy giữa các tổ chức) — không có cơ chế này. Các tổ chức AWS không "liên kết" hay "tin cậy" lẫn nhau, và một tài khoản chỉ thuộc đúng một tổ chức tại một thời điểm. Nhiều tổ chức cũng có nghĩa nhiều hoá đơn — đi ngược yêu cầu đầu tiên.

Ghi nhớ

⚠ Bốn thứ chỉ có ở chế độ all features — bảng phải thuộc: | Tính năng | Việc | |---|---| | SCP | đặt trần quyền cho tài khoản và OU | | Tag policy | ép chuẩn hoá khoá và giá trị tag | | Backup policy | áp chính sách AWS Backup tập trung | | AI services opt-out policy | chặn dùng dữ liệu để cải thiện dịch vụ |

Từ khoá nhận diện:

"single AWS bill" → Organizations (consolidated billing nằm sẵn trong đó) "restrict services ... governed centrally" → SCP → bắt buộc all features "costs broken out for each business unit" + mỗi đơn vị một tài khoản → có sẵn, không cần tag "permissions boundary applied to an account" → LUÔN SAI, boundary gắn cho IAM entity "trust relationships between organizations" → LUÔN SAI, không tồn tại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức đang ở chế độ nào | aws organizations describe-organization --query 'Organization.FeatureSet' | | SCP đã áp cho tài khoản nào | list-policies-for-target | | Chi phí theo tài khoản | Cost Explorer, nhóm theo Linked Account |

Và một lời khuyên: hãy kiểm FeatureSet trước khi hứa với ai rằng bạn sẽ áp SCP. Một tổ chức tạo ở chế độ chỉ gộp hoá đơn nhìn bề ngoài không khác gì tổ chức đầy đủ — vẫn thấy danh sách tài khoản, vẫn thấy OU trong giao diện, hoá đơn vẫn gộp đúng. Sự khác biệt chỉ lộ ra khi bạn đi tìm mục Policies và thấy nó bị vô hiệu hoá. Đến lúc đó, việc nâng cấp lại cần mọi tài khoản thành viên bấm đồng ý — và tài khoản của đơn vị vừa được mua lại, do một đội khác giữ, có thể mất vài tuần mới trả lời.

Đáp án

C — Tạo Glue crawler và custom classifier theo định dạng data feed để dựng định nghĩa bảng, dùng Lambda kích hoạt khi tệp về để chạy Glue ETL job làm toàn bộ việc che dữ liệu, gộp trường và chuyển sang JSON, rồi ghi kết quả sang bucket S3 khác.

Vì sao đúng

Đề mô tả một bài ETL kinh điển, và ba con số trong đề quyết định lựa chọn: 2.500 bản ghi, mỗi 10 phút, định dạng phải đổi.

⚠ Điểm mấu chốt: cả bốn phép biến đổi là MỘT công việc trên MỘT bản ghi — tách chúng ra là tự tạo việc:

Tệp về bucket nguồn
        ↓
    S3 event notification → Lambda
        ↓
    Lambda gọi StartJobRun của Glue
        ↓
    Glue job đọc bản ghi → che → bỏ trường → gộp trường → đổi sang JSON
        ↓
    → ghi thẳng sang bucket đích, một lượt đọc, một lượt ghi

Glue là dịch vụ serverless: không có cụm để dựng, không có cụm để tắt, tính tiền theo DPU-giờ thực dùng. Với khối lượng 2.500 bản ghi mỗi 10 phút, đây là mức tải rất nhỏ — mọi thứ nặng hơn đều là thừa.

Phần custom classifier cũng không phải chi tiết trang trí. Crawler mặc định nhận ra CSV, JSON, Parquet, Avro và vài dạng phổ biến. Data feed của nhà cung cấp thẻ tín dụng thường là định dạng riêng — cột cố định chiều rộng, hoặc dấu phân cách lạ. Classifier tự viết cho crawler biết cách đọc, và crawler dựng bảng trong Data Catalog để job tham chiếu.

# trong Glue ETL job — che số thẻ, giữ 4 số cuối
from pyspark.sql import functions as F

bang = bang.withColumn(
    "so_the_che",
    F.concat(F.lit("************"), F.substring(F.col("so_the"), -4, 4))
).drop("so_the", "cvv")

bang.write.mode("append").json("s3://xu-ly-noi-bo/giao-dich/")

⚠ Che dữ liệu phải BỎ HẲN cột gốc, không chỉ thêm cột đã che:

Thêm cột so_the_che nhưng giữ nguyên cột so_the
        ↓
    Tệp đầu ra vẫn chứa số thẻ đầy đủ
        ↓
    → dữ liệu vẫn thuộc phạm vi PCI DSS, việc che coi như chưa làm

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

• A (Glue crawler + classifier, nhưng Athena query kích hoạt EMR ETL job rồi tắt cụm) — đây là phương án gần nhất và nửa đầu giống hệt C: crawler với custom classifier để dựng bảng là bước đúng. Nó hỏng ở nửa sau, theo hai cách. Thứ nhất, cơ chế kích hoạt vô lý: Athena là công cụ truy vấn, không phải bộ kích hoạt — một truy vấn Athena không "khởi động EMR job khi tệp về", chuyện đó không xảy ra. Thứ hai, dựng và tắt một cụm EMR cho mỗi 10 phút là sai hoàn toàn về quy mô: cụm EMR mất 5–10 phút chỉ để khởi động, tức là chu kỳ tiếp theo đã tới trước khi chu kỳ trước kịp sẵn sàng. EMR dành cho khối lượng hàng terabyte, không phải 2.500 bản ghi.

• B (Lambda tách từng bản ghi → SQS → Lambda xử lý → Lambda cuối chuyển JSON khi hàng đợi rỗng) — kiến trúc vỡ ở một điểm chí mạng: không có sự kiện "hàng đợi SQS đã rỗng". ApproximateNumberOfMessages là con số xấp xỉ, có độ trễ, và có thể về 0 giữa chừng trong khi vẫn còn tin nhắn đang bay. Xây điều kiện kết thúc lên trên nó là xây trên cát — job cuối sẽ chạy sớm và bỏ sót bản ghi. Ngoài ra, bổ 2.500 bản ghi thành 2.500 tin nhắn rồi ba tầng Lambda là phức tạp gấp nhiều lần một job đọc cả tệp.

• D (Lambda → SQS → Fargate tự co giãn về một instance → xử lý → tắt) — cùng lỗi "khi hàng đợi rỗng" như B, cộng thêm một cụm container phải định nghĩa, phải đóng gói image, phải quản lý vòng đời. "Tự co giãn về một instance" cũng tự mâu thuẫn: một tác vụ duy nhất thì đâu còn là co giãn.

Ghi nhớ

⚠ Bốn công cụ xử lý dữ liệu — chọn theo quy mô và tần suất: | Công cụ | Hợp với | Không hợp với | |---|---|---| | AWS Glue | ETL theo lô, serverless, vài MB tới vài trăm GB | luồng dưới một giây | | Lambda | biến đổi nhỏ, dưới 15 phút | dữ liệu lớn hơn bộ nhớ, job dài | | EMR | hàng TB, cần Spark/Hive tuỳ biến sâu | lô nhỏ chạy thường xuyên | | Kinesis Data Firehose | biến đổi nhẹ khi đang truyền | phép biến đổi phức tạp nhiều bước |

Từ khoá nhận diện:

"crawler + custom classifier" → định dạng nguồn không chuẩn, cần Glue Data Catalog "mask / remove / merge / transform into JSON" → một Glue ETL job làm hết "when the SQS queue is empty" → LUÔN SAI, không có sự kiện đó "spin up an EMR cluster" cho lô nhỏ chạy mỗi vài phút → SAI về quy mô "Athena query ... to start a job" → SAI, Athena không kích hoạt gì cả

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng có đọc đúng không | chạy SELECT * FROM bang LIMIT 10 trong Athena sau khi crawler xong | | Job có che thật không | tải một tệp đầu ra về, grep tìm mẫu số thẻ | | Job có chạy mỗi lần tệp về không | so số lần StartJobRun với số object mới trong bucket |

Và một lời khuyên: hãy grep tệp ĐẦU RA để tìm dữ liệu nhạy cảm, đừng chỉ đọc mã biến đổi. Đây là kiểu lỗi im lặng đắt giá nhất trong nhóm này: nếu phép che của bạn thêm cột mới mà quên drop cột gốc, job vẫn chạy thành công, số bản ghi vẫn khớp, không log nào báo gì — chỉ có bucket "đã làm sạch" vẫn chứa nguyên số thẻ đầy đủ. Và vì nó được gắn nhãn là dữ liệu đã che, sẽ có người sao chép nó sang nơi có quyền truy cập rộng hơn.

Đáp án

B, C, D — ba bước để nội dung chỉ vào được qua CloudFront:

• D — Tạo Origin Access Identity (OAI), thêm vào distribution, sửa bucket policy của S3 chỉ cho OAI.
• B — Cấu hình CloudFront thêm một custom header vào request nó gửi tới origin.
• C — Tạo web ACL trong AWS WAF với luật kiểm tra header đó có mặt, gắn web ACL vào ALB.

Vì sao đúng

Đề có hai origin khác nhau — S3 cho nội dung tĩnh và ALB cho nội dung động — và mỗi loại có cách khoá riêng. Đây là điểm mấu chốt: một cơ chế không dùng cho cả hai được.

⚠ Điểm mấu chốt: S3 khoá bằng DANH TÍNH, ALB khoá bằng BÍ MẬT DÙNG CHUNG:

Người dùng → CloudFront
        ↓
    Đường tĩnh: CloudFront ký request bằng OAI
        ↓
        → S3 bucket policy chỉ cho principal OAI đó → người ngoài bị chặn
        ↓
    Đường động: CloudFront thêm header X-Origin-Verify: <chuỗi bí mật>
        ↓
        → WAF trên ALB kiểm header → không có header thì chặn

D — vì sao OAI là cách đúng cho S3. OAI là một danh tính đặc biệt do CloudFront giữ. Bucket policy tham chiếu tới nó, nên chỉ CloudFront ký được request hợp lệ:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E1ABCDEF"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::cong-ty-tinh/*"
}

B + C — vì sao ALB cần cách khác. ALB không xác thực principal AWS; nó chỉ thấy một request HTTP. Cách duy nhất để nó phân biệt "đến từ CloudFront" với "ai đó gọi thẳng" là một giá trị bí mật CloudFront biết mà người ngoài không biết:

# CloudFront thêm header khi gọi origin (cấu hình ở origin custom headers)
#   X-Origin-Verify: 8f3a...  ← chuỗi ngẫu nhiên dài

# WAF trên ALB: chặn request không mang đúng header đó
aws wafv2 create-web-acl --name chi-cho-cloudfront --scope REGIONAL \
  --default-action Block={} \
  --rules file://luat-kiem-header.json

⚠ Web ACL phải gắn vào ALB, KHÔNG phải vào CloudFront distribution:

Gắn web ACL kiểm header vào CloudFront
        ↓
    Nó kiểm request của NGƯỜI DÙNG gửi tới CloudFront
        ↓
    Người dùng không mang header đó → mọi khách bị chặn
        ↓
    → còn đường vào thẳng ALB thì vẫn mở toang

Header phải được kiểm ở đúng nơi cần bảo vệ, tức là ở ALB. Đây là chỗ phân biệt phương án C và E.

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

• E (web ACL kiểm header, gắn vào CloudFront distribution) — đây là phương án gần nhất và luật WAF trong đó hoàn toàn đúng: kiểm sự có mặt của custom header là đúng kỹ thuật. Nó chỉ gắn sai chỗ, và sai chỗ làm hỏng cả hai chiều. Gắn ở CloudFront thì WAF xét request đi vào CloudFront — do trình duyệt người dùng gửi, và trình duyệt tất nhiên không có header nội bộ đó, nên khách thật bị chặn. Trong khi đó ALB vẫn không được bảo vệ chút nào: ai biết tên miền của nó vẫn gọi thẳng được. Đây là bẫy hay nhất của câu này vì E và C chỉ khác đúng một từ ở cuối câu.

• A (ALB thêm custom header vào request gửi tới EC2) — sai chiều hoàn toàn. Header phải do CloudFront thêm vào ở đầu thượng nguồn, để chứng minh request đã đi qua CloudFront. Nếu ALB tự thêm header thì mọi request tới ALB đều có nó, kể cả request đi thẳng — nó không chứng minh được gì cả. Ngoài ra bảo vệ chặng ALB→EC2 không phải điều đề hỏi.

• F (bucket policy chỉ cho dải IP của CloudFront) — chạy được nhưng sai về vận hành và về bảo mật. Dải IP của CloudFront thay đổi liên tục; giữ danh sách này bằng tay là bảo trì vô tận, và bỏ sót một dải mới là mất dịch vụ. Về bảo mật thì nó còn tệ hơn: các dải đó dùng chung cho mọi distribution CloudFront của mọi khách hàng AWS, nên bất kỳ ai cũng có thể trỏ distribution của họ vào bucket của bạn và đi lọt.

Ghi nhớ

⚠ Bốn cách khoá origin sau CloudFront — bảng phải thuộc: | Origin | Cơ chế nên dùng | Ghi chú | |---|---|---| | S3 (REST endpoint) | OAC (mới) hoặc OAI (cũ) | OAC hỗ trợ SSE-KMS và mọi Region | | S3 (website endpoint) | custom header + bucket policy | website endpoint không nhận OAI | | ALB / EC2 | custom header + WAF | không có khái niệm principal | | API Gateway | custom header, hoặc IAM/Lambda authorizer | tuỳ kiểu API |

Từ khoá nhận diện:

"available through CloudFront only" + S3 → OAI/OAC + bucket policy "available through CloudFront only" + ALB → custom header + WAF trên ALB "associate the web ACL with the CloudFront distribution" khi mục tiêu là chặn đường vào ALB → SAI, gắn nhầm chỗ "allow the CloudFront IP ranges" → SAI, IP đổi liên tục và dùng chung mọi khách hàng "LEAST operational overhead" cho ALB → AWS managed prefix list cho CloudFront

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường vòng đã bị chặn chưa | curl thẳng vào tên miền của ALB — phải nhận 403 | | Đường chính còn chạy không | curl qua tên miền CloudFront — phải nhận 200 | | S3 đã khoá chưa | curl thẳng vào URL S3 — phải nhận AccessDenied |

Và một lời khuyên: hãy curl thẳng vào tên miền của ALB sau khi làm xong, đừng chỉ kiểm rằng trang web vẫn chạy. Cấu hình sai kiểu này không gây bất kỳ triệu chứng nào ở đường đi bình thường: khách vẫn vào được, trang vẫn hiện, biểu đồ vẫn đẹp — vì đường qua CloudFront chưa bao giờ bị đụng tới. Thứ duy nhất khác biệt là cánh cửa sau vẫn mở, và cách duy nhất để biết là tự đi thử cánh cửa đó. Nếu nó trả về 200, bạn chưa bảo vệ được gì cả.

Đáp án

C — Cài Application Discovery Service Discovery Connector trong VMware vCenter, ĐỒNG THỜI cài Discovery Agent trên các máy chủ vật lý tại chỗ, rồi để chúng thu thập dữ liệu một thời gian.

Vì sao đúng

Đề nêu hai đặc điểm môi trường và ba yêu cầu, và chỉ một phương án phủ hết cả năm.

⚠ Điểm mấu chốt: Connector và Agent nhìn thấy hai thứ khác nhau, và chỉ Agent thấy được phụ thuộc mạng:

Discovery Connector — một máy ảo cắm vào vCenter
        ↓
    Hỏi vCenter về danh sách VM, CPU, RAM, đĩa, mạng ở mức máy ảo
        ↓
    → thấy được "có gì" và "dùng bao nhiêu", KHÔNG thấy được "nói chuyện với ai"

Discovery Agent — cài trong hệ điều hành
        ↓
    Đọc tiến trình đang chạy, cổng đang mở, kết nối TCP đang mở
        ↓
    → thấy được máy A cổng 3306 đang nối tới máy B — chính là quan hệ phụ thuộc

Đây là lý do phương án B (chỉ Connector) không đủ, và cũng là lý do phải cài Agent trên máy vật lý — Connector chỉ biết những gì vCenter biết, mà vCenter không biết gì về máy chủ vật lý.

Sau khi thu thập, dữ liệu đổ về AWS Migration Hub, nơi bạn nhóm các máy chủ thành application và xem đồ thị phụ thuộc:

# xem những gì đã phát hiện
aws discovery describe-configurations --configuration-ids <id>

# gom thành một ứng dụng để lập kế hoạch di chuyển theo cụm
aws discovery create-application \
  --name "He thong dat hang" --description "Web + app + MySQL"

⚠ Phải để chạy đủ lâu, và "đủ lâu" phụ thuộc chu kỳ nghiệp vụ:

Thu thập một ngày
        ↓
    Bỏ sót job chạy cuối tuần, báo cáo cuối tháng, đỉnh tải theo mùa
        ↓
    → right-size theo dữ liệu thiếu → máy chọn quá nhỏ, hoặc bỏ sót một phụ thuộc quan trọng

Vì thế đề viết "for a period of time" chứ không nêu con số cứng — khoảng hai tới bốn tuần là mức thường dùng, đủ phủ ít nhất một chu kỳ tháng.

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

• B (chỉ cài Connector trong vCenter, thu thập một tuần) — đây là phương án gần nhất và nó đúng một nửa: Connector là công cụ chuẩn cho phần VMware, và một tuần cũng không phải khoảng thời gian vô lý. Nhưng nó hỏng ở hai chỗ. Thứ nhất, đề nói rõ môi trường có cả máy chủ vật lý — Connector không thấy chúng, nên một phần hạ tầng biến mất khỏi kế hoạch di chuyển. Thứ hai, và quan trọng hơn: Connector không thu thập được quan hệ phụ thuộc. Nó đọc số liệu ở mức máy ảo từ vCenter, không nhìn vào bên trong hệ điều hành để thấy tiến trình và kết nối TCP. Mà "identify dependencies between systems" là yêu cầu đầu tiên đề nêu.

• D (chỉ cài Agent trên mọi hệ thống) — về mặt kỹ thuật thì thu được đủ dữ liệu, kể cả phụ thuộc. Nhưng nó bỏ qua công cụ dựng riêng cho môi trường VMware: cài agent lên hàng trăm máy ảo thủ công tốn công gấp bội so với cắm một Connector vào vCenter và lấy ngay toàn bộ kho máy ảo. Với môi trường VMware, mẫu chuẩn của AWS là Connector cho VM, Agent cho phần Connector không với tới — hoặc cho những máy cần dữ liệu phụ thuộc chi tiết.

• A (xuất dữ liệu từ CMDB tại chỗ rồi nhập vào Application Discovery Service) — đề nói thẳng công ty không có CMDB trung tâm và tài liệu thì thiếu và lỗi thời. Phương án này giả định đúng cái mà đề vừa phủ nhận. Ngay cả khi có CMDB, dữ liệu tĩnh trong đó không chứa số liệu hiệu năng thật để right-size, cũng không chứa quan hệ phụ thuộc quan sát được.

Ghi nhớ

⚠ Hai chế độ của Application Discovery Service — bảng phải thuộc: | | Discovery Connector | Discovery Agent | |---|---|---| | Cài ở đâu | máy ảo cắm vào vCenter | trong hệ điều hành từng máy | | Hợp với | môi trường VMware, quy mô lớn | máy vật lý, máy ngoài VMware, cần chi tiết | | Thấy được | kho máy ảo, CPU/RAM/đĩa/mạng | thêm tiến trình, cổng, kết nối TCP | | Phụ thuộc mạng | KHÔNG | CÓ | | Công cài đặt | một lần cho cả vCenter | từng máy một |

Từ khoá nhận diện:

"identify dependencies between systems" → bắt buộc có Agent "VMware" + "physical servers" → cả Connector lẫn Agent "no CMDB / documentation is outdated" → loại mọi phương án nhập từ CMDB "group systems into applications" → Migration Hub "estimate costs after migration" → Migration Evaluator (trước là TSO Logic)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã thấy đủ máy chưa | so số máy trong Migration Hub với danh sách vCenter cộng máy vật lý | | Đã có dữ liệu phụ thuộc chưa | mở đồ thị Network Connections của một máy bất kỳ | | Dữ liệu đủ dài chưa | xem khoảng thời gian thu thập có phủ ít nhất một chu kỳ tháng |

Và một lời khuyên: hãy mở đồ thị phụ thuộc của một máy bạn đã biết rõ, xem nó có hiện đúng những kết nối bạn biết là có không. Đây là kiểu thiếu sót không báo lỗi: nếu bạn chỉ cắm Connector, Migration Hub vẫn hiện đầy đủ danh sách máy chủ, số liệu CPU và RAM vẫn đẹp, mọi thứ trông như đã xong — chỉ có phần phụ thuộc là trống, và bạn không nhận ra vì "trống" trông y hệt "máy này không phụ thuộc gì". Kết quả là một làn di chuyển được lên lịch thiếu mất cơ sở dữ liệu mà ứng dụng cần, và chuyện đó chỉ lộ ra sau khi cắt chuyển.

Đáp án

D — Chuyển nội dung sang S3, tạo CloudFront distribution phục vụ từ bucket đó, và dùng Lambda@Edge để nạp tài nguyên khác nhau dựa trên header User-Agent.

Vì sao đúng

Đề có hai vấn đề chồng lên nhau: độ trễ vì người dùng ở khắp thế giới và EC2 quá tải vì đang phục vụ tệp tĩnh. Cộng thêm một ràng buộc: nội dung phải khác nhau tuỳ hệ điều hành máy khách.

⚠ Điểm mấu chốt: CloudFront không tự phân nhánh theo User-Agent — mặc định nó chỉ có một phiên bản cho mỗi URL:

Request tới điểm biên kèm User-Agent: ... Android ...
        ↓
    Lambda@Edge chạy ngay tại điểm biên (viewer request hoặc origin request)
        ↓
    Đọc header, viết lại đường dẫn: /anh/logo.png → /anh/android/logo.png
        ↓
    → trả nội dung đúng nền tảng, vẫn được cache tại biên

Đây là phần thực chất của câu hỏi. Nếu chỉ đặt CloudFront lên trước S3, mọi máy khách nhận cùng một tệp — không đáp ứng được yêu cầu "tài nguyên khác nhau tuỳ hệ điều hành". Lambda@Edge là cơ chế cho phép chạy logic tại điểm biên, không phải quay về origin.

// Lambda@Edge — origin request
exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const ua = (request.headers['user-agent'] || [{value: ''}])[0].value;
  const nenTang = /Android/i.test(ua) ? 'android'
                : /iPhone|iPad/i.test(ua) ? 'ios'
                : 'web';
  request.uri = '/' + nenTang + request.uri;
  return request;
};

⚠ Phải đưa User-Agent vào cache key, nếu không mọi máy nhận chung một bản:

Lambda@Edge chọn đúng nội dung cho máy đầu tiên
        ↓
    CloudFront cache kết quả theo URL gốc, không tính User-Agent
        ↓
    → máy iPhone tiếp theo nhận bản Android còn trong cache
        ↓
    → không lỗi, không cảnh báo, chỉ là giao diện sai với một nửa người dùng

Cách làm đúng là chuẩn hoá User-Agent thành một header hẹp (ví dụ X-Nen-Tang: android|ios|web) ở viewer request, rồi đưa header đó vào cache policy. Đưa thẳng User-Agent vào cache key là thảm hoạ về tỷ lệ trúng cache, vì có hàng chục nghìn chuỗi khác nhau — mỗi chuỗi thành một mục cache riêng.

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

• A (S3 + CloudFront, dùng User-Agent để nạp nội dung khác nhau) — đây là phương án gần nhất và hai bước đầu giống hệt D: chuyển sang S3 và đặt CloudFront lên trước là đúng, và nó cũng nhận ra User-Agent là tín hiệu cần dùng. Nó chỉ thiếu đúng một thứ — cơ chế. "Dùng header User-Agent để nạp nội dung khác nhau" mô tả kết quả mong muốn chứ không nói ai làm việc đó. CloudFront tự nó không phân nhánh nội dung theo header; nó chỉ có thể chuyển tiếp header về origin và đưa vào cache key. Với origin là S3 tĩnh thì chẳng có gì ở đầu kia đọc header và chọn tệp cả — S3 trả object theo khoá, hết. Thiếu Lambda@Edge (hoặc CloudFront Function) thì yêu cầu thứ ba không được đáp ứng.

• B (Auto Scaling group riêng theo hệ điều hành, chuyển sang NLB, định tuyến theo User-Agent ở NLB) — sai về tầng mạng. NLB hoạt động ở tầng 4, nó nhìn IP và cổng, không đọc được header HTTP. Định tuyến theo User-Agent ở NLB là chuyện không thể. Ngoài ra phương án này không đụng gì tới hai vấn đề chính: nội dung vẫn phục vụ từ một Region nên người ở xa vẫn chậm, và EC2 vẫn phải phục vụ tệp tĩnh.

• C (ALB riêng cho mỗi hệ điều hành, Route 53 định tuyến theo User-Agent) — Route 53 là DNS, và DNS không thấy header HTTP. Truy vấn DNS xảy ra trước khi kết nối HTTP tồn tại; nó chỉ biết địa chỉ IP của bộ phân giải, không biết trình duyệt nào đang hỏi. Đây là một trong những nhầm lẫn phổ biến nhất về Route 53. Phương án này cũng nhân đôi hạ tầng mà không giải quyết độ trễ toàn cầu.

Ghi nhớ

⚠ Bốn nơi chạy mã ở điểm biên — bảng phải thuộc: | | CloudFront Functions | Lambda@Edge | |---|---|---| | Ngôn ngữ | JavaScript (ECMAScript 5.1) | Node.js, Python | | Thời gian chạy tối đa | dưới 1 ms | 5 giây (viewer), 30 giây (origin) | | Chạy ở | viewer request/response | cả bốn điểm móc | | Gọi mạng được không | không | có | | Hợp với | viết lại URL, thêm header, chuyển hướng | logic cần gọi dịch vụ khác, xử lý thân request |

Từ khoá nhận diện:

"users around the world" + "high EC2 utilization" → S3 + CloudFront "different content based on the User-Agent" → Lambda@Edge hoặc CloudFront Function "NLB routes based on HTTP header" → LUÔN SAI, NLB ở tầng 4 "Route 53 routes based on User-Agent" → LUÔN SAI, DNS không thấy HTTP "ALB routes based on header" → đúng, ALB làm được — nhưng không giải bài toán độ trễ toàn cầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tỷ lệ trúng cache | chỉ số CacheHitRate của CloudFront | | Có trả đúng bản cho từng nền tảng không | curl -H "User-Agent: ... Android ..." và so với bản iOS | | Lambda@Edge có chạy không | log nằm ở CloudWatch của Region gần điểm biên, không phải Region gốc |

Và một lời khuyên: hãy thử hai User-Agent khác nhau liên tiếp trên cùng một URL và so nội dung trả về. Lỗi cache key kiểu này không hiện ra ở lần thử đầu: máy đầu tiên gọi vào một điểm biên lạnh sẽ nhận đúng nội dung, và bạn kết luận là xong. Chỉ từ request thứ hai trở đi, khi bản đã cache được trả lại cho một nền tảng khác, sai lệch mới xuất hiện — và nó xuất hiện không đều, tuỳ điểm biên nào đang giữ bản nào, nên rất dễ bị bỏ qua như một sự cố ngẫu nhiên của người dùng.