Ngân hàng đề — AWS Certified Security Specialty

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

Câu hỏi tập trung vào việc bảo vệ Amazon S3 bucket chứa AWS CloudTrail logs tập trung (centrally stored), nhằm ngăn chặn truy cập trái phép (unauthorized access) và can thiệp/tampering (thay đổi nội dung logs). Security team kiểm soát AWS account của công ty, và cần chọn kết hợp 3 bước phù hợp nhất.

Bối cảnh chính (dựa trên best practices AWS mới nhất 2024-2026):

• CloudTrail logs ghi lại hoạt động API, rất quan trọng cho audit/security.
• S3 bucket cần mã hóa, kiểm soát truy cập nghiêm ngặt (least privilege), và tính toàn vẹn (integrity) để chống tampering.
• AWS khuyến nghị sử dụng các tính năng native như KMS encryption, bucket policy, và CloudTrail integrity validation cho logs immutable.

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

• AWS CloudTrail User Guide: Encrypting and Integrity (cập nhật 2025).
• AWS S3 Security Best Practices.
• AWS Well-Architected Framework: Security Pillar.

✅ Đáp án đúng (Chọn 3 phương án sau)

Các bước đúng giúp prevent unauthorized access (qua bucket policy) và tampering (qua encryption KMS + integrity validation):

1. Configure server-side encryption with AWS KMS managed encryption keys (SSE-KMS): Mã hóa server-side với KMS keys do AWS quản lý, đảm bảo logs luôn encrypted tại rest, chống truy cập trái phép nếu key bị kiểm soát.
2. Implement least privilege access to the S3 bucket by configuring a bucket policy: Bucket policy thực thi nguyên tắc least privilege, chỉ cho phép truy cập cần thiết (ví dụ: chỉ security team đọc logs).
3. Configure CloudTrail log file integrity validation: Bật tính năng validation để tạo digest files (.gz), cho phép verify logs chưa bị tamper bằng SHA-256 hash – đây là cách native chống tampering hiệu quả nhất.

Lý do chọn: Kết hợp này bao quát đầy đủ confidentiality (encryption), access control (policy), và integrity (validation) theo AWS best practices cho CloudTrail logs. Không phương án nào dư thừa hoặc không trực tiếp giải quyết vấn đề.

🛠️ Phân tích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, với ✅ Đúng hoặc ❌ Sai, giải thích rõ lý do dựa trên tính hiệu quả chống unauthorized access/tampering:

• ✅ Configure server-side encryption with AWS KMS managed encryption keys (SSE-KMS):
  Đúng! SSE-KMS sử dụng customer-managed hoặc AWS-managed KMS keys để mã hóa tự động logs tại S3. Security team kiểm soát key rotation/policy, ngăn chặn truy cập dữ liệu plain-text ngay cả nếu ai đó có quyền đọc object. Hỗ trợ audit key usage qua CloudTrail. (Best practice từ AWS 2025).

• ❌ Compress log files with secure gzip:
  Sai! Nén gzip chỉ giảm kích thước file (CloudTrail tự nén .gz), không cung cấp encryption hay chống tampering. "Secure gzip" không phải tính năng AWS chuẩn, dễ bị decompress và tamper nếu bucket không bảo vệ.

• ❌ Create an Amazon EventBridge rule to notify the security team of any modifications on CloudTrail log files:
  Sai! EventBridge có thể monitor S3 events (PUT/DELETE), nhưng không prevent tampering (chỉ notify sau khi xảy ra). Logs CloudTrail được thiết kế immutable nếu config đúng, notify không phải bước cốt lõi; dễ miss nếu attacker xóa event trước.

• ✅ Implement least privilege access to the S3 bucket by configuring a bucket policy:
  Đúng! Bucket policy deny tất cả access trừ explicit allow (ví dụ: principal security team + MFA/conditions). Kết hợp IAM roles cho least privilege, ngăn unauthorized access hoàn toàn – yêu cầu bắt buộc theo AWS security pillar.

• ✅ Configure CloudTrail log file integrity validation:
  Đúng! Khi bật, CloudTrail tạo file digest (.gz) chứa hash SHA-256 của từng log file. Security team dùng AWS CLI (validate-logs) để verify tính toàn vẹn, phát hiện tampering ngay lập tức. Immutable và tamper-proof native.

• ❌ Configure Access Analyzer for S3:
  Sai! Access Analyzer phân tích bucket policy để tìm unused access hoặc external risks (policy findings), hữu ích cho audit nhưng không prevent access/tampering realtime. Chỉ là tool diagnostic, không thay thế bucket policy trực tiếp.

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

Câu hỏi tập trung vào việc lưu trữ petabytes dữ liệu (dữ liệu lớn quy mô hàng nghìn terabytes) trong 7 năm để tuân thủ các quy định pháp lý (regulatory requirements). Yêu cầu chính là ngăn chặn hoàn toàn việc thay đổi hoặc xóa dữ liệu (immutable data), và giải pháp phải cost-effective nhất (tiết kiệm chi phí nhất).

📊 Bối cảnh AWS: Với lượng dữ liệu khổng lồ và thời gian lưu trữ dài hạn, cần sử dụng dịch vụ lưu trữ archival rẻ tiền như Amazon S3 Glacier (bao gồm các storage class như Glacier Flexible Retrieval hoặc Deep Archive). Tính năng khóa dữ liệu phải đảm bảo không ai (kể cả root user) có thể xóa hoặc sửa trong retention period (7 năm). Giải pháp phải cân bằng giữa tuân thủ nghiêm ngặt và chi phí thấp (Glacier rẻ hơn S3 Standard ~10-20 lần cho lưu trữ dài hạn theo giá AWS 2024-2026).

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

Đáp án đúng: Create a vault in Amazon S3 Glacier. Create a Vault Lock policy in S3 Glacier that meets all the regulatory requirements. Upload the data to the vault.

Lý do 🛠️:

• Amazon S3 Glacier Vault được thiết kế chuyên biệt cho lưu trữ archival dài hạn, cost-effective nhất với giá chỉ $0.004/GB/tháng (Glacier Flexible Retrieval) hoặc rẻ hơn nữa với Deep Archive ($0.00099/GB/tháng) – lý tưởng cho petabytes dữ liệu 7 năm.
• Vault Lock policy khóa vault ngay lập tức (immediate lock) hoặc sau thời gian chờ (delayed lock), đảm bảo dữ liệu immutable 100% (không xóa/sửa được) trong 7 năm, tuân thủ quy định như SEC 17a-4.
• Upload trực tiếp vào vault tiết kiệm nhất, tránh chi phí S3 tạm thời. Đây là giải pháp chuẩn AWS best practice cho compliance archival (cập nhật AWS 2026).

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

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

• Create an Amazon S3 bucket. Configure the bucket to use S3 Object Lock in compliance mode. Upload the data to the bucket. Create a resource-based bucket policy that meets all the regulatory requirements.
  ❌ Sai: S3 Object Lock (compliance mode) đúng là immutable (không ai bypass được), nhưng dùng S3 Standard bucket đắt đỏ (~$0.023/GB/tháng) cho petabytes 7 năm – chi phí cao gấp 5-10 lần Glacier. Bucket policy chỉ hỗ trợ, không tối ưu cost. Không phải giải pháp "MOST cost-effectively".

• Create an Amazon S3 bucket. Configure the bucket to use S3 Object Lock in governance mode. Upload the data to the bucket. Create a user-based IAM policy that meets all the regulatory requirements.
  ❌ Sai: Governance mode cho phép root/admin bypass khóa (không strict compliance), vi phạm yêu cầu "prevent anyone from changing or deleting". IAM policy user-based không đủ mạnh; lại dùng S3 Standard đắt tiền, không cost-effective.

• Create a vault in Amazon S3 Glacier. Create a Vault Lock policy in S3 Glacier that meets all the regulatory requirements. Upload the data to the vault.
  ✅ Đúng: Như giải thích trên – Glacier Vault + Vault Lock immutable nghiêm ngặt, upload trực tiếp rẻ nhất, phù hợp petabytes dài hạn. AWS khuyến nghị cho regulatory compliance.

• Create an Amazon S3 bucket. Upload the data to the bucket. Use a lifecycle rule to transition the data to a vault in S3 Glacier. Create a Vault Lock policy that meets all the regulatory requirements.
  ❌ Sai: Upload vào S3 trước rồi lifecycle sang Glacier tốn kém kép (S3 storage tạm thời + retrieval fees), chậm hơn (lifecycle delay). Vault Lock chỉ áp dụng sau transition, không cost-effective bằng upload trực tiếp. Không phải "MOST" tối ưu.

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

• AWS Documentation: Amazon S3 Glacier Vault Lock – Chi tiết Vault Lock policy cho compliance.
• S3 Glacier Pricing: AWS Pricing Page – So sánh cost S3 vs Glacier (Deep Archive rẻ nhất 2026).
• Best Practices: AWS Well-Architected Framework - Storage Lens & S3 Object Lock vs Glacier Vault Lock – Khuyến nghị Glacier cho petabyte-scale archival immutable.
• Exam Prep: AWS Certified DevOps Engineer Professional DOP-C02 guide (2024 edition).

🛡️ Lưu ý: Giải pháp này đảm bảo WORM (Write Once Read Many) tuân thủ quy định như FINRA, GDPR. Nếu cần thực hiện, dùng AWS CLI: aws glacier initiate-vault-lock.

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

Câu hỏi xoay quanh vấn đề SAML-based Single Sign-On (SSO) sử dụng third-party Identity Provider (IdP) để truy cập các AWS accounts. 🎓

• Bối cảnh: Công ty đã renew signing certificate (chứng chỉ ký SAML assertion) hết hạn của IdP bên thứ ba. Sau đó, người dùng gặp lỗi "Response Signature Invalid" (mã lỗi: InvalidIdentityToken, Status: 400 từ AWSSecurityTokenService) khi cố gắng đăng nhập vào AWS. Lỗi này xảy ra vì AWS không thể verify chữ ký SAML do certificate mới chưa được cập nhật đúng cách trên phía AWS IAM.

• Yêu cầu giải pháp: Sửa lỗi và minimize operational overhead (giảm thiểu công việc vận hành thủ công lặp lại). 🛠️ Điều này ngụ ý cần giải pháp đơn giản, tự động hóa một phần, ưu tiên sử dụng CLI để script hóa nếu có thể, thay vì can thiệp thủ công liên tục.

Vấn đề cốt lõi: AWS IAM cần SAML metadata XML mới từ IdP (chứa public key mới) để verify signature. Nếu không update, mọi SAML response từ IdP sẽ bị reject. 📘

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

Đáp án đúng:
Download the updated SAML metadata file from the identity service provider. Update the file in the AWS identity provider entity defined in AWS Identity and Access Management (IAM) by using the AWS CLI.

Lý do chi tiết (bằng kiến thức AWS mới nhất 2024-2026):
✅ Đây là phương pháp chuẩn và khuyến nghị của AWS để cập nhật certificate mới cho SAML IdP entity trong IAM. Metadata XML từ IdP chứa public key mới (trong phần <X509Certificate>), khi upload sẽ tự động update entity để AWS verify signature đúng. Sử dụng AWS CLI (aws iam update-saml-provider) giúp script hóa, giảm overhead (chạy tự động qua CI/CD hoặc Lambda). Không cần Console thủ công, phù hợp DevOps best practice. Hoàn thành ngay lập tức, không downtime dài. 🚀

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

Dưới đây là phân tích từng lựa chọn một, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên AWS IAM SAML Provider docs (không hỗ trợ upload private key, không auto-fetch, metadata phải manual update).

• ❌ Phương án SAI:
  Upload the third-party signing certificate’s new private key to the AWS identity provider entity defined in AWS Identity and Access Management (IAM) by using the AWS Management Console.
  Giải thích sai: Private key là bí mật tuyệt đối của IdP, KHÔNG BAO GIỜ upload lên AWS (vi phạm security principle). AWS chỉ cần public key từ metadata để verify, không lưu trữ private key. Sử dụng Console cũng không hỗ trợ upload private key. Nếu thử, sẽ fail validation và lộ key rủi ro cao. 🔒

• ❌ Phương án SAI:
  Sign the identity provider's metadata file with the new public key. Upload the signature to the AWS identity provider entity defined in AWS Identity and Access Management (IAM) by using the AWS CLI.
  Giải thích sai: Public key KHÔNG dùng để sign (signing dùng private key). Metadata XML đã được IdP sign bằng private key gốc; bạn chỉ cần download bản updated (đã chứa public key mới) và upload toàn bộ file. Việc "sign với public key" là sai logic crypto (public dùng verify). CLI không hỗ trợ upload riêng signature như vậy. 🤦‍♂️

• ✅ Phương án ĐÚNG (như đã giải thích ở trên):
  Download the updated SAML metadata file from the identity service provider. Update the file in the AWS identity provider entity defined in AWS Identity and Access Management (IAM) by using the AWS CLI.
  Giải thích đúng: Metadata chứa public key mới, CLI command aws iam update-saml-provider --saml-provider-arn <ARN> --saml-metadata-document file://metadata.xml sẽ update atomic, validate tự động. Giảm overhead nhờ scriptable. Hoàn hảo cho production. 🏆

• ❌ Phương án SAI:
  Configure the AWS identity provider entity defined in AWS Identity and Access Management (IAM) to synchronously fetch the new public key by using the AWS Management Console.
  Giải thích sai: IAM SAML Provider KHÔNG hỗ trợ auto-fetch metadata động (khác với OIDC hoặc external IdP như Okta trong một số config). Console chỉ cho phép manual upload metadata XML, không có tùy chọn "synchronously fetch" public key. Phải download thủ công từ IdP. Tính năng này không tồn tại đến 2026. ⏳

📚 Tài liệu tham khảo (AWS Official Docs - cập nhật mới nhất 2024+)

• AWS IAM SAML Provider Management: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html (phần "Updating the metadata document").
• CLI Command Reference: https://docs.aws.amazon.com/cli/latest/reference/iam/update-saml-provider.html.
• Troubleshooting SAML Errors: https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_saml.html (InvalidIdentityToken do certificate mismatch).
• Best Practices SSO: AWS Well-Architected Framework - Identity pillar (2024 edition).

Giải pháp này đảm bảo zero-downtime update nếu script đúng. Nếu cần demo CLI, comment thêm nhé! 💡

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

Câu hỏi tập trung vào bảo mật truy cập ứng dụng web legacy đã được migrate lên Amazon EC2, với yêu cầu chỉ nhân viên công ty mới truy cập được từ internet, mà không cần thay đổi code ứng dụng.

• Bối cảnh chính:
  • Công ty sử dụng on-premises ADFS (Active Directory Federation Services) và SSO để nhân viên authenticate vào AWS Management Console.
  • Ứng dụng hiện chạy trên EC2, không có hệ thống authentication tích hợp sẵn.
  • Mục tiêu: Triển khai employee-only access an toàn, tận dụng ADFS hiện có, hỗ trợ truy cập từ anywhere on the internet (qua public internet), nhưng không modify app.

🛠️ Yêu cầu cốt lõi: Giải pháp phải proxy traffic qua lớp authentication bên ngoài (như load balancer hoặc proxy), tích hợp SAML federation với ADFS, đảm bảo zero-trust access mà không chạm vào app code. Đây là best practice theo AWS Well-Architected Framework (Security Pillar) cho legacy apps.

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

• AWS Docs: Integrate a SAML IdP (ADFS) with Cognito User Pool (cập nhật 2024-2026).
• ALB Authentication with Cognito (hỗ trợ SAML từ 2020, stable đến 2026).
• AWS Security Best Practices: Legacy App Modernization.

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

Đáp án đúng: Place the application behind an Application Load Balancer (ALB). Use Amazon Cognito as authentication for the ALB. Define a SAML-based Amazon Cognito user pool and connect it to ADFS.

Lý do chi tiết:

• ✅ ALB làm reverse proxy: Đặt EC2 sau ALB (target group), ALB xử lý HTTP/HTTPS traffic từ internet, authenticate trước khi forward đến app → Không cần thay đổi app.
• ✅ Amazon Cognito User Pool + SAML: Tạo Cognito User Pool hỗ trợ SAML 2.0 IdP (kết nối trực tiếp ADFS qua metadata XML). Nhân viên login qua Cognito hosted UI (redirect từ ALB), nhận JWT token khớp ADFS creds → Seamless integration với existing SSO/ADFS.
• ✅ Zero app change: ALB rules (authenticate action) tự động challenge auth, chỉ allow authenticated users → Employee-only via ADFS groups/attributes.
• ✅ Scalable & secure: ALB hỗ trợ OIDC/SAML, WAF integration, HTTPS enforcement. Phù hợp kiến trúc serverless/microservices đến 2026.

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

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

• Place the application behind an Application Load Balancer (ALB). Use Amazon Cognito as authentication for the ALB. Define a SAML-based Amazon Cognito user pool and connect it to ADFS.
  ✅ ĐÚNG (như giải thích trên). Giải pháp chuẩn AWS, tận dụng ALB listener rules (authenticate với Cognito), SAML federation mượt mà với ADFS, không touch app code.

• Implement AWS IAM Identity Center (AWS Single Sign-On) in the management account and link it to ADFS as an identity provider. Define the EC2 instance as a managed resource, then apply an IAM policy on the resource.
  ❌ SAI. IAM Identity Center (trước là AWS SSO) chỉ quản lý access AWS services/Console (permission sets cho accounts/resources), không hỗ trợ custom web app trên EC2. Không thể "define EC2 as managed resource" cho web access; chỉ dùng cho AWS APIs/CLI, không proxy HTTP traffic từ internet.

• Define an Amazon Cognito identity pool, then install the connector on the Active Directory server. Use the Amazon Cognito SDK on the application instance to authenticate the employees using their Active Directory user names and passwords.
  ❌ SAI. Cognito Identity Pool dùng để cấp temporary AWS creds (IAM roles) cho mobile/web apps gọi AWS services, không phải authenticate web app access. "Connector on AD" là Cognito Directory Service (cho sync users), nhưng SDK trên EC2 app yêu cầu thay đổi code app (vi phạm yêu cầu). Không hỗ trợ SAML federation đúng cách.

• Create an AWS Lambda custom authorizer as the authenticator for a reverse proxy on Amazon EC2. Ensure the security group on Amazon EC2 only allows access from the Lambda function.
  ❌ SAI. Lambda custom authorizer chủ yếu cho API Gateway (token/JWT validation), không phải "reverse proxy on EC2" (yêu cầu setup Nginx/Apache custom + Lambda invoke). Security group chỉ Lambda phức tạp, single-point failure, không tận dụng ADFS/SAML, và thay đổi infra lớn (thêm proxy layer trên EC2). Không phải best practice so với ALB native support.

🛠️ Kết luận: Giải pháp đúng tuân thủ least privilege và federation best practices, dễ scale với AWS services native. Recommend test với Cognito SAML setup trong dev env! 🚀

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

Câu hỏi mô tả một tình huống bảo mật trên AWS:
Một công ty chạy quy trình phân tích dữ liệu dài hạn từ Amazon S3 buckets trên fleet EC2 instances thuộc Auto Scaling group, nằm trong private subnet của VPC không có internet access. EC2 và S3 cùng một AWS account.

• EC2 truy cập S3 qua S3 gateway endpoint với default access policy (cho phép tất cả traffic S3 hợp lệ).
• Mỗi EC2 gắn instance profile role với policy chỉ allow s3:GetObject và s3:PutObject cho chỉ các S3 buckets cần thiết.

🔒 Vấn đề: Một số EC2 bị compromise (xâm phạm), đang exfiltrate data (rò rỉ dữ liệu) ra S3 bucket ngoài AWS Organizations của công ty.
Yêu cầu giải pháp:

• Dừng exfiltration ngay lập tức.
• Giữ nguyên chức năng job xử lý (EC2 vẫn access được buckets nội bộ).

🛠️ Bối cảnh kỹ thuật quan trọng (cập nhật AWS 2026):

• S3 Gateway Endpoint (Gateway VPC Endpoint for S3) route traffic nội bộ VPC đến S3 mà không qua internet/NAT, chỉ áp dụng cho S3 prefixes (không phải HTTPS port 443). Policy endpoint kiểm soát actions/buckets cụ thể.
• Compromised EC2 chỉ có thể access S3 qua endpoint này (no internet), nên policy endpoint là "chốt chặn" lý tưởng.
• Sử dụng condition keys: aws:ResourceOrgID (ID tổ chức của S3 resource/bucket) và aws:PrincipalOrgID (ID tổ chức của principal thực hiện action) để filter theo Organizations.

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

• AWS Docs: Gateway VPC Endpoints for Amazon S3 (Policy examples với conditions).
• IAM Policy Elements: Global Condition Keys (aws:ResourceOrgID & aws:PrincipalOrgID).
• AWS Organizations Best Practices.

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

Đáp án đúng: Update the policy on the S3 gateway endpoint to allow the S3 actions only if the values of the aws:ResourceOrgID and aws:PrincipalOrgID condition keys match the company's values.

Lý do:

• 🛡️ Chặn exfiltration hiệu quả: Gateway endpoint policy là lớp kiểm soát tất cả traffic S3 từ VPC private. Default policy cho phép mọi thứ → attacker dùng instance profile creds để PutObject ra bucket ngoài org. Update policy với cả hai condition keys (aws:ResourceOrgID match org của bucket nội bộ + aws:PrincipalOrgID match org của EC2 principal) sẽ deny access đến bucket ngoài org, block rò rỉ ngay.
• 🔄 Giữ job functional: Buckets nội bộ (cùng org) vẫn pass conditions → EC2 tiếp tục Get/Put bình thường.
• 🚀 Không ảnh hưởng kiến trúc: Không cần thay đổi role, network, hay downtime ASG. Áp dụng ngay lập tức (AWS 2026 hỗ trợ conditions này full).

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

• Update the policy on the S3 gateway endpoint to allow the S3 actions only if the values of the aws:ResourceOrgID and aws:PrincipalOrgID condition keys match the company's values.
  ✅ Đúng (như giải thích trên). Đây là giải pháp tối ưu, chính xác vì endpoint policy kiểm soát endpoint-specific traffic đến S3, kết hợp hai keys đảm bảo bidirectional org matching.

• Update the policy on the instance profile role to allow the S3 actions only if the value of the aws:ResourceOrgID condition key matches the company's value.
  ❌ Sai: Chỉ dùng aws:ResourceOrgID (không có aws:PrincipalOrgID) → không full-proof, có thể bypass nếu attacker impersonate principal ngoài org. Hơn nữa, instance profile policy không chặn traffic qua endpoint (endpoint policy override/default allow), và compromised EC2 có thể dùng creds từ nơi khác nếu leak. Không giải quyết root cause (traffic routing).

• Add a network ACL rule to the subnet of the EC2 instances to block outgoing connections on port 443.
  ❌ Sai: Gateway endpoint KHÔNG dùng port 443 (nó là internal VPC routing qua route table đến S3 prefixes như bucket.s3.region.vpce-xxx). Block 443 chỉ ảnh hưởng NAT/IGW (nhưng VPC no internet), sẽ block toàn bộ HTTPS khác (như API calls nội bộ), làm job fail hoàn toàn. NACL quá coarse-grained!

• Apply an SCP on the AWS account to allow the S3 actions only if the values of the aws:ResourceOrgID and aws:PrincipalOrgID condition keys match the company's values.
  ❌ Sai: Service Control Policy (SCP) chỉ kiểm soát actions TRONG organization (prevent members thực hiện actions trên resources ngoài org), nhưng không block access TO resources ngoài org (S3 cross-account/org access vẫn ok nếu IAM allow). SCP không apply cho traffic qua endpoint và không ảnh hưởng instance profile. Bucket ngoài org → SCP vô hiệu!

🏆 Kết luận: Giải pháp endpoint policy là best practice cho zero-trust S3 access trong VPC private (AWS Well-Architected Security Pillar). Implement ngay để mitigate!

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

Câu hỏi mô tả một công ty hoạt động trong môi trường hybrid cloud (kết hợp on-premises và AWS), phải tuân thủ các yêu cầu compliance nghiêm ngặt. Họ cần tạo báo cáo bao gồm bằng chứng (evidence) từ cả workloads on-premises và tài nguyên AWS. Vai trò của security engineer là triển khai giải pháp để thu thập (collect), xem xét (review) và quản lý (manage) evidence, nhằm chứng minh tuân thủ chính sách công ty. 🔍
Yêu cầu chính: Giải pháp phải hỗ trợ hybrid (manual evidence từ on-prem + tự động từ AWS), tạo báo cáo compliance đầy đủ. Đây là chủ đề liên quan đến AWS Audit Manager (dịch vụ chuyên thu thập evidence cho audit/compliance, cập nhật đến 2026 hỗ trợ framework NIST, PCI DSS, v.v.).

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

Đáp án đúng: Create an assessment in AWS Audit Manager from a prebuilt framework or a custom framework. Upload manual evidence from the on-premises workloads. Add the evidence to the assessment. Generate an assessment report after Audit Manager collects the necessary evidence from the AWS resources.

Lý do: 🛠️ AWS Audit Manager là dịch vụ chính thức dành riêng cho compliance auditing trong hybrid cloud. Nó cho phép tạo assessment từ framework có sẵn (prebuilt) hoặc tùy chỉnh, upload manual evidence từ on-premises trực tiếp vào assessment, tự động thu thập evidence từ AWS resources (như EC2, S3, IAM qua data sources). Sau đó, generate assessment report chuyên nghiệp (PDF/CSV) với đầy đủ evidence, dễ review/manage. Đây là giải pháp tối ưu, native hybrid support theo best practices AWS (cập nhật 2026: hỗ trợ evidence collector cho 100+ controls).
📘 Nguồn tham khảo: AWS Audit Manager Documentation & Hybrid Evidence Collection.

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

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

1. Create an assessment in AWS Audit Manager from a prebuilt framework or a custom framework. Upload manual evidence from the on-premises workloads. Add the evidence to the assessment. Generate an assessment report after Audit Manager collects the necessary evidence from the AWS resources.
   ✅ Đúng hoàn toàn 🏆: Như giải thích trên, Audit Manager hỗ trợ full lifecycle collect/review/manage evidence hybrid. Manual upload từ on-prem + auto từ AWS → report chuyên dụng. Không có giải pháp nào thay thế tốt hơn cho yêu cầu này.

2. Install the Amazon CloudWatch agent on the on-premises workloads. Use AWS Config to deploy a conformance pack from a sample conformance pack template or a custom YAML template. Generate an assessment report after AWS Config identifies noncompliant workloads and resources.
   ❌ Sai: AWS Config + conformance packs chỉ tập trung compliance checking cho AWS resources (qua rules), hỗ trợ hybrid hạn chế qua agent nhưng không hỗ trợ upload manual evidence hay generate báo cáo audit đầy đủ với evidence review. CloudWatch agent chỉ monitor metrics/logs, không phải evidence management. Không đáp ứng "collect/review/manage evidence" toàn diện.
   📘 Nguồn: AWS Config Conformance Packs – chủ yếu AWS-centric.

3. Set up the appropriate security standard in AWS Security Hub. Upload manual evidence from the on-premises workloads. Wait for Security Hub to collect the evidence from the AWS resources. Download the list of controls as a .csv file.
   ❌ Sai: Security Hub hỗ trợ security standards (CIS, PCI, NIST) và hybrid qua agent/manual insights, nhưng không có tính năng upload manual evidence trực tiếp vào assessment hay generate báo cáo compliance đầy đủ. Chỉ download CSV list of controls/findings, thiếu review/manage evidence chi tiết. Không phải giải pháp audit chính.
   📘 Nguồn: AWS Security Hub Hybrid Support – tập trung findings, không phải evidence reports.

4. Install the Amazon CloudWatch agent on the on-premises workloads. Create a CloudWatch dashboard to monitor the on-premises workloads and the AWS resources. Run a query on the workloads and resources. Download the results.
   ❌ Sai: CloudWatch chỉ là monitoring tool (metrics/logs/dashboards/Logs Insights queries), hỗ trợ hybrid qua agent nhưng hoàn toàn không liên quan đến compliance evidence hay báo cáo audit. Download results chỉ là dữ liệu thô, không có framework/review/manage cho policy compliance.
   📘 Nguồn: CloudWatch Agent for Hybrid – pure observability, không phải governance.

Kết luận tổng quát 🎯: AWS Audit Manager là lựa chọn best fit cho hybrid compliance reporting. Các phương án khác thiếu tính năng cốt lõi hoặc không chuyên sâu. Nên implement theo AWS Well-Architected Framework (Security Pillar). Nếu cần lab thực hành, dùng AWS Free Tier! 🚀

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

Câu hỏi yêu cầu một security engineer triển khai IAM policy để tuân thủ quy định pháp lý (regulatory requirements), nhằm hạn chế việc sử dụng các dịch vụ AWS chỉ trong Region us-east-1.

📌 Mục tiêu chính: Policy phải chặn (restrict) mọi hoạt động sử dụng AWS services ở các Region khác ngoài us-east-1. Điều này thường áp dụng cho các tổ chức cần kiểm soát địa lý dữ liệu (data residency) theo quy định như GDPR, HIPAA hoặc các luật địa phương.

🛠️ Kiến thức cốt lõi từ AWS (cập nhật đến 2026):

• IAM policy sử dụng condition key "aws:RequestedRegion" để kiểm tra Region mà request nhắm đến (áp dụng cho hầu hết services như EC2, S3, Lambda, RDS...).
• Nguyên tắc IAM: Deny luôn override Allow, và mặc định là implicit Deny nếu không có Allow explicit. Để restrict chặt chẽ, cần explicit Deny cho các Region không mong muốn.
• Không nên dùng Allow với condition vì nó chỉ cho phép ở Region cụ thể, nhưng vẫn có thể bị bypass nếu có policy khác Allow ở Region khác.

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

• AWS IAM Condition Keys: aws:RequestedRegion (IAM User Guide, phiên bản mới nhất 2026).
• AWS Well-Architected Framework: Security Pillar - Region Restrictions (hướng dẫn best practices).

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

Đáp án đúng là lựa chọn thứ 3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Lý do chọn 🏆:

• Policy này Deny tất cả actions () trên mọi resources () khi RequestedRegion KHÔNG PHẢI us-east-1 (StringNotEquals).
• Điều này chặn hoàn toàn mọi hoạt động ở các Region khác, đồng thời cho phép tự do sử dụng ở us-east-1 (vì không match condition Deny).
• Hoàn hảo cho regulatory compliance, không có lỗ hổng bypass. Đây là best practice được AWS khuyến nghị cho multi-region lockdown.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên code gốc bằng tiếng Anh. Mỗi phương án được đánh giá với lý do cụ thể dựa trên IAM policy evaluation logic.

• Phương án 1 ❌ SAI:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "StringEquals": {
            "aws:RequestedRegion": "us-east-1"
          }
        }
      }
    ]
  }
  

  Giải thích sai: Policy chỉ Allow ở us-east-1, nhưng không Deny ở các Region khác. Nếu có policy khác (hoặc default Allow từ role/group), user vẫn có thể sử dụng services ở Region khác. Không đáp ứng "restrict" chặt chẽ theo regulatory needs.

• Phương án 2 ❌ SAI:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "StringEquals": {
            "ec2:Region": "us-east-1"
          }
        }
      }
    ]
  }
  

  Giải thích sai: Sử dụng "ec2:Region" chỉ áp dụng cho EC2 service (service-specific key), không phải global cho tất cả AWS services. Các service như S3, Lambda ở Region khác vẫn không bị chặn. Không phù hợp cho yêu cầu toàn cục.

• Phương án 3 ✅ ĐÚNG (như đã giải thích ở trên):

  {
    "Version": "2012-10-17",
    "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
  }
  

  Giải thích đúng: 🔒 Explicit Deny cho mọi thứ ngoài us-east-1, sử dụng global condition key "aws:RequestedRegion". Đảm bảo compliance 100%, override mọi Allow khác.

• Phương án 4 ❌ SAI:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Deny",
        "NotAction": "*",
        "Resource": "*",
        "Condition": {
          "StringEquals": {
            "aws:RequestedRegion": "us-east-1"
          }
        }
      }
    ]
  }
  

  Giải thích sai: "NotAction": "*" nghĩa là Deny mọi action KHÔNG PHẢI tất cả actions (tức Deny nothing - policy vô hiệu). Condition chỉ trigger ở us-east-1, nhưng logic sai hoàn toàn. Không chặn được gì cả!

🧪 Lưu ý thực tế triển khai: Attach policy này vào IAM user/role/group. Test bằng IAM Policy Simulator để verify. Kết hợp với SCP (Service Control Policy) ở Organizations cho account-level enforcement nếu cần scale.

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

Câu hỏi tập trung vào việc bảo mật và tối ưu hóa phân phối nội dung từ Amazon S3 qua Amazon CloudFront trong AWS Cloud. Cụ thể:

• Công ty có web server trên AWS, lưu trữ nội dung (files) trong S3 bucket.
• Sử dụng CloudFront distribution để tăng tốc độ delivery (CDN - Content Delivery Network).
• Yêu cầu quan trọng: Không file nào được public accessible trực tiếp từ S3 bucket (bucket phải private hoàn toàn, tránh truy cập trực tiếp qua S3 URL).
• Mục tiêu: CloudFront có thể đọc files từ S3 private, nhưng người dùng cuối chỉ truy cập qua CloudFront (an toàn, nhanh hơn).

Vấn đề cốt lõi là cách thiết lập quyền truy cập giữa CloudFront và S3 private bucket. AWS khuyến nghị sử dụng Origin Access Control (OAC) – tính năng mới nhất (ra mắt 2021, cập nhật đến 2026) để thay thế Origin Access Identity (OAI) cũ, đảm bảo CloudFront là unique referrer truy cập S3 mà không cần làm bucket public.

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

Đáp án đúng: Create an origin access control (OAC). Associate the OAC with the CloudFront distribution. Configure the S3 bucket permissions so that only the OAC can access the files in the S3 bucket.

Lý do:

• OAC là giải pháp chuẩn và mới nhất của AWS (từ CloudFront năm 2021, được ưu tiên đến 2026). Nó tạo chứng chỉ signing đặc biệt cho CloudFront, cho phép chỉ CloudFront distribution cụ thể truy cập S3 bucket private.
• Quy trình: Tạo OAC → Gắn vào distribution → Cập nhật S3 bucket policy để chỉ OAC (qua aws:SourceArn hoặc aws:SourceAccount) được s3:GetObject.
• Đảm bảo S3 hoàn toàn private (block public access), files không accessible trực tiếp, nhưng CloudFront cache và deliver nhanh chóng. ✅ Hoàn hảo khớp yêu cầu.

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

• ❌ Phương án SAI: Configure the permissions on the individual files in the S3 bucket so that only the CloudFront distribution has access to them.
  Giải thích: Không khả thi và không scale được. S3 không hỗ trợ set ACL/policy riêng lẻ cho từng file một cách tự động với CloudFront. Nếu có hàng triệu files, việc config thủ công từng file là impractical (không thực tế), dễ lỗi, và không dùng được cơ chế signing của CloudFront. AWS không khuyến nghị.

• ✅ Phương án ĐÚNG: Create an origin access control (OAC). Associate the OAC with the CloudFront distribution. Configure the S3 bucket permissions so that only the OAC can access the files in the S3 bucket.
  Giải thích: Như đã nêu ở phần đáp án đúng. Đây là best practice hiện tại (OAC thay thế OAI), bucket policy ví dụ:

  {
    "Statement": [
      {
        "Effect": "Allow",
        "Principal": {"Service": "cloudfront.amazonaws.com"},
        "Action": "s3:GetObject",
        "Resource": "arn:aws:s3:::bucket/*",
        "Condition": {
          "StringEquals": {"aws:SourceArn": "arn:aws:cloudfront::account:distribution/DIST-ID"}
        }
      }
    ]
  }
  

  Hoàn toàn an toàn và hiệu quả.

• ❌ Phương án SAI: Create an S3 role in AWS Identity and Access Management (IAM). Allow only the CloudFront distribution to assume the role to access the files in the S3 bucket.
  Giải thích: CloudFront không hỗ trợ assume IAM role như EC2 hay Lambda. CloudFront dùng service principal (cloudfront.amazonaws.com) qua OAC/OAI, không cần role. Tạo role vô ích và không work.

• ❌ Phương án SAI: Create an S3 bucket policy that uses only the CloudFront distribution ID as the principal and the Amazon Resource Name (ARN) as the target.
  Giải thích: Principal không thể là distribution ID (như "E123ABC"). Bucket policy yêu cầu Principal là service (cloudfront.amazonaws.com) + Condition với aws:SourceArn chứa distri ID hoặc OAC. Chỉ dùng ID làm principal sẽ fail validation, không secure và không khớp docs AWS.

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

• AWS Docs chính thức: Restrict access to an Amazon S3 origin (Using OAC) – Best practice dùng OAC.
• AWS re:Post & Blogs: Migrate from OAI to OAC (2021, vẫn valid 2026).
• Exam Prep: AWS Certified DevOps Engineer Professional DOP-C02 – Topic: CloudFront + S3 Security (phiên bản mới nhất 2024-2026).

Tóm tắt: OAC là golden standard cho private S3 + CloudFront! 🚀 Nếu cần demo code Terraform/CloudFormation, hỏi thêm nhé! 😊

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

📘 Nội dung câu hỏi:
Một kỹ sư bảo mật đăng nhập vào AWS Lambda console với quyền administrator (quyền cao nhất). Kỹ sư này đang cố gắng xem logs của Lambda function có tên myFunction trong Amazon CloudWatch. Khi chọn tùy chọn "View logs in CloudWatch" từ giao diện Lambda console, xuất hiện lỗi "error loading Log Streams" (lỗi tải Log Streams).

IAM policy của execution role (vai trò thực thi) cho Lambda function này chỉ có hai statements:

• Statement 1: Cho phép logs:CreateLogGroup trên tất cả log groups (arn:aws:logs:us-east-1:111111111111:*).
• Statement 2: Cho phép logs:PutLogEvents trên log streams thuộc log group /aws/lambda/myFunction (arn:aws:logs:us-east-1:111111111111:log-group:/aws/lambda/myFunction:*).

🛠️ Vấn đề cốt lõi:
Lỗi xảy ra vì Lambda function chưa thể tạo Log Streams (các luồng log riêng cho từng invocation) trong CloudWatch Logs. Execution role của Lambda cần quyền logs:CreateLogStream để tự động tạo Log Stream mỗi khi function được invoke. Policy hiện tại thiếu quyền này, dẫn đến không có Log Streams nào tồn tại → console không tải được danh sách.

Kỹ sư bảo mật có quyền admin nên có thể truy cập CloudWatch nếu Log Streams tồn tại, nhưng vì Lambda chưa tạo chúng được (do thiếu quyền trên execution role), nên báo lỗi. Giải pháp là bổ sung quyền thiếu vào execution role để Lambda có thể tạo Log Streams khi chạy.

✅ Đáp án đúng:
Add the logs:CreateLogStream action to the second Allow statement.

Lý do chọn đáp án đúng (🧩 Phân tích sâu):

• Execution role của Lambda cần ba quyền cơ bản để ghi logs đầy đủ vào CloudWatch: logs:CreateLogGroup (tạo Log Group), logs:CreateLogStream (tạo Log Stream cho mỗi invocation), và logs:PutLogEvents (ghi events vào Stream).
• Policy hiện tại đã có CreateLogGroup và PutLogEvents, nhưng thiếu CreateLogStream trên resource cụ thể của function (log-group:/aws/lambda/myFunction:*).
• Thêm logs:CreateLogStream vào statement thứ 2 (cùng resource với PutLogEvents) sẽ cho phép Lambda tạo Stream → sau khi invoke function một lần, Log Streams sẽ xuất hiện → console tải được.
• Đây là best practice theo AWS (cập nhật đến 2026, không thay đổi lớn trong Lambda runtime permissions).

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

• AWS Lambda Execution Role Permissions (Basic execution role policy bao gồm CreateLogStream).
• Amazon CloudWatch Logs IAM Permissions (Chi tiết actions cho logs).
• AWS Well-Architected Framework: Reliability Pillar (2023-2026 editions) khuyến nghị full log permissions cho Lambda monitoring.

❌ Phân tích tất cả các phương án trả lời

• Move the logs:CreateLogGroup action to the second Allow statement.
  ❌ Sai: Việc di chuyển logs:CreateLogGroup từ statement 1 sang statement 2 không giải quyết vấn đề. CreateLogGroup chỉ tạo Log Group (đã tồn tại hoặc có thể tạo trên *), nhưng lỗi là thiếu CreateLogStream để tạo Stream bên trong Group. Di chuyển chỉ làm policy kém linh hoạt (resource cụ thể hơn), không tạo Stream → lỗi vẫn còn.

• Add the logs:PutDestination action to the second Allow statement.
  ❌ Sai: logs:PutDestination dùng để tạo hoặc cập nhật destination cho log subscription filters (gửi logs đến Kinesis, Lambda, etc.), không liên quan đến việc tạo hoặc xem Log Streams cơ bản của Lambda. Thêm quyền này thừa và không fix lỗi loading Streams.

• Add the logs:GetLogEvents action to the second Allow statement.
  ❌ Sai: logs:GetLogEvents dùng để đọc logs từ Stream (dành cho user/console permissions), không phải execution role của Lambda (role này chỉ ghi logs khi runtime). Execution role không cần quyền đọc; kỹ sư đã có admin perms để đọc. Thiếu CreateLogStream mới là nguyên nhân gốc → thêm GetLogEvents vô ích.

• Add the logs:CreateLogStream action to the second Allow statement.
  ✅ Đúng: Như phân tích trên, bổ sung logs:CreateLogStream vào statement 2 (resource khớp với function) cho phép Lambda tạo Log Stream tự động. Sau invoke, Streams xuất hiện → console Lambda load được logs mà không lỗi. Đây là fix chính xác, tối ưu (least privilege).

🔧 Khuyến nghị thực hiện: Attach policy mới vào execution role qua IAM console hoặc CLI: aws iam put-role-policy --role-name <role> --policy-name LogsPolicy --policy-document <updated-json>. Test bằng invoke function → kiểm tra CloudWatch Logs! 🚀

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

Câu hỏi tập trung vào bảo mật dữ liệu nhạy cảm trên Amazon S3 trong bối cảnh một công ty hợp tác với nhà cung cấp (vendor). Công ty sẽ upload các file dữ liệu (objects) chứa thông tin nhạy cảm của khách hàng vào một S3 bucket. Vendor sẽ download các objects này để xử lý dữ liệu. Yêu cầu chính: Implement giải pháp đảm bảo objects không tồn tại trong bucket quá 72 giờ (tức là tự động xóa hoặc expire sau 72 giờ), nhằm giảm thiểu rủi ro bảo mật nếu dữ liệu bị lưu trữ lâu dài.

Đây là tình huống thực tế trong DevOps và Security trên AWS, nơi S3 Lifecycle là công cụ chuẩn để quản lý vòng đời objects dựa trên thời gian lưu trữ. Giải pháp phải tự động, đáng tin cậy, chi phí thấp và không phụ thuộc vào hành động thủ công hoặc phát hiện dữ liệu nhạy cảm (vì yêu cầu chỉ dựa trên thời gian, không phải nội dung).

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

• AWS S3 Lifecycle: docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html (cập nhật 2024-2026, hỗ trợ expire sau thời gian chính xác).
• AWS Well-Architected Framework - Security Pillar (2024).

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

Đáp án đúng: Configure an S3 Lifecycle rule on the S3 bucket to expire objects that have been in the S3 bucket for 72 hours.

🛠️ Lý do chọn đáp án này:

• S3 Lifecycle rule là tính năng native của S3, cho phép tự động expire (xóa vĩnh viễn) objects sau một khoảng thời gian cụ thể (ở đây là 72 giờ = 3 ngày). Quy tắc này áp dụng cho toàn bộ bucket hoặc prefix cụ thể, không cần code custom, chạy serverless và chi phí gần như bằng 0.
• Hoàn toàn phù hợp yêu cầu: Objects được upload, vendor download trong 72 giờ, sau đó tự động xóa → Đơn giản, scalable, tuân thủ bảo mật.
• Cập nhật mới nhất (2026): S3 Lifecycle hỗ trợ "Expire" action chính xác sau NoncurrentDays hoặc Days, tích hợp S3 Object Lock nếu cần.

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

• Use Amazon Macie to scan the S3 bucket for sensitive data every 72 hours. Configure Macie to delete the objects that contain sensitive data when they are discovered.
  ❌ Sai vì: Amazon Macie là dịch vụ phát hiện dữ liệu nhạy cảm (sensitive data discovery) dựa trên ML, không phải quản lý thời gian lưu trữ. Macie scan định kỳ (không chính xác 72 giờ) và chỉ xóa nếu phát hiện sensitive data, nhưng câu hỏi không yêu cầu kiểm tra nội dung mà chỉ dựa trên thời gian tồn tại. Việc config Macie để delete là không chuẩn (Macie chỉ alert/quarantine, không tự delete), tốn kém và phức tạp không cần thiết. 📘 docs.aws.amazon.com/macie.

• Configure an S3 Lifecycle rule on the S3 bucket to expire objects that have been in the S3 bucket for 72 hours.
  ✅ Đúng vì: Như đã giải thích ở trên, đây là giải pháp tối ưu nhất, native, tự động và chính xác theo thời gian.

• Create an Amazon EventBridge scheduled rule that invokes an AWS Lambda function every day. Program the Lambda function to remove any objects that have been in the S3 bucket for 72 hours.
  ❌ Sai vì: Đây là giải pháp custom, phức tạp và kém hiệu quả. EventBridge + Lambda chạy hàng ngày (không chính xác 72 giờ), phải list objects (tốn API calls), check last-modified date và delete thủ công → Chi phí cao hơn (Lambda invocations, S3 ListObjects), dễ lỗi code, không scalable cho bucket lớn. S3 Lifecycle làm việc này tốt hơn mà không cần code. 📘 docs.aws.amazon.com/eventbridge.

• Use the S3 Intelligent-Tiering storage class for all objects that are uploaded to the S3 bucket. Use S3 Intelligent-Tiering to expire objects that have been in the $3 bucket for 72 hours.
  ❌ Sai vì: S3 Intelligent-Tiering là storage class tự động di chuyển objects giữa các tier (Frequent, Infrequent, Archive) dựa trên access pattern, KHÔNG hỗ trợ expire/delete sau thời gian cố định. Không có action "expire" trong Intelligent-Tiering; chỉ chuyển tier để tối ưu chi phí. Lỗi typo "$3" là S3. Phải dùng Lifecycle rule kết hợp với class này nếu cần. 📘 docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering.html (cập nhật 2025: thêm Deep Archive tier, nhưng vẫn không expire).

🛠️ Khuyến nghị thực tế: Kết hợp S3 Lifecycle với S3 Bucket Policies (deny public access), Server-Side Encryption (SSE-KMS) và VPC Endpoints để vendor truy cập an toàn. Test rule trên bucket dev trước khi apply production! 🚀