Ngân hàng đề — AWS Certified SysOps Administrator Associate

Đáp án

B — Số mã lỗi HTTP 4XX phía client mà CHÍNH LOAD BALANCER sinh ra.

Vì sao đúng

Tên chỉ số đã nói tất cả — chỉ cần đọc đúng phần giữa: HTTPCode_ELB_4XX_Count.

⚠ Điểm mấu chốt — chữ ELB hay TARGET trong tên quyết định ai sinh ra lỗi:

HTTPCode_ELB_4XX_Count
        ↓
    → LOAD BALANCER tự trả lỗi
    → request CHƯA từng tới ứng dụng của bạn

HTTPCode_TARGET_4XX_Count
        ↓
    → ỨNG DỤNG trả lỗi
    → request đã tới nơi, backend từ chối

Phân biệt hai chỉ số này quyết định bạn đi tìm nguyên nhân ở đâu.

⚠ Khi nào ALB tự sinh lỗi 4XX:

400 Bad Request      → request hỏng, header sai định dạng
401 Unauthorized     → xác thực (Cognito/OIDC) ở listener thất bại
403 Forbidden        → WAF chặn, hoặc listener rule từ chối
460                  → CLIENT ngắt kết nối trước khi ELB trả lời
463                  → X-Forwarded-For có quá nhiều địa chỉ

⚠ Và cách đọc hai chỉ số cùng nhau để chẩn đoán:

ELB_4XX cao, TARGET_4XX thấp
        ↓
    → vấn đề ở TẦNG LOAD BALANCER
    → xem WAF, listener rule, hoặc client gửi request hỏng

TARGET_4XX cao, ELB_4XX thấp
        ↓
    → vấn đề ở ỨNG DỤNG
    → đường dẫn sai, thiếu xác thực, dữ liệu không hợp lệ

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

• D (số mã 4XX do TARGET của ELB sinh ra) — đây là phương án gần nhất và là mô tả chính xác của một chỉ số KHÁC: HTTPCode_Target_4XX_Count. Đây chính là bẫy trung tâm — hai chỉ số chỉ khác nhau một từ trong tên.

• A (số request mà load balancer chọn target mới vì không dùng được sticky session) — đây là mô tả của chỉ số NonStickyRequestCount.

• C (số kết nối TLS do client khởi tạo mà không thiết lập được phiên với load balancer) — đây là mô tả của ClientTLSNegotiationErrorCount.

Ghi nhớ

⚠ Các cặp chỉ số ELB/TARGET của ALB — bảng phải thuộc: | Chỉ số | Ai sinh ra | |---|---| | HTTPCode_ELB_4XX_Count | load balancer | | HTTPCode_Target_4XX_Count | ứng dụng | | HTTPCode_ELB_5XX_Count | load balancer (502, 503, 504) | | HTTPCode_Target_5XX_Count | ứng dụng | | HTTPCode_Target_2XX/3XX_Count | ứng dụng, phản hồi thành công |

Từ khoá nhận diện:

"lỗi do load balancer sinh ra" → chỉ số có chữ ELB "lỗi do ứng dụng sinh ra" → chỉ số có chữ Target "client ngắt kết nối sớm" → 460 "không có target khoẻ" → 503, trong HTTPCode_ELB_5XX_Count "target không trả lời kịp" → 504

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lỗi đến từ đâu | so HTTPCode_ELB_* với HTTPCode_Target_* | | Request nào lỗi | ALB access log + Athena, lọc theo elb_status_code | | Chi tiết vì sao | cột x-edge-detailed-result-type (CloudFront) hoặc access log của ALB |

Và một mẹo chẩn đoán rất nhanh với hai chỉ số này: vẽ chồng HTTPCode_ELB_4XX_Count và HTTPCode_Target_4XX_Count lên cùng một biểu đồ. Chỉ cần nhìn xem đường nào tăng là bạn biết ngay nên gọi cho đội hạ tầng hay đội ứng dụng — và đó thường là mười phút tiết kiệm được nhiều nhất trong một sự cố.

Đáp án

A — CloudTrail có thể gửi tệp log từ NHIỀU REGION về MỘT bucket S3 duy nhất của tài khoản.

Vì sao đúng

Đây là hành vi mặc định của một multi-region trail, và cũng là lý do người ta luôn nên dùng loại trail này.

⚠ Điểm mấu chốt — một trail, mọi Region, một bucket:

Tạo trail với --is-multi-region-trail
        ↓
    CloudTrail ghi lại hoạt động ở MỌI Region
        ↓
    Tất cả đổ về CÙNG MỘT bucket S3
        ↓
    Phân chia theo tiền tố:
        AWSLogs/<account-id>/CloudTrail/<region>/<năm>/<tháng>/<ngày>/
        ↓
    → một nơi để phân tích
    → một bucket để bảo vệ
    → Region MỚI của AWS ra mắt cũng TỰ ĐỘNG được bao phủ

⚠ Và khi tạo trail từ Console thì mặc định đã là multi-region:

Console: ô "Enable for all accounts in my organization"
         và trail mặc định áp cho MỌI Region
        ↓
    → không phải làm gì thêm
        ↓
CLI: phải khai tường minh
    aws cloudtrail create-trail --name kiem-toan \
      --s3-bucket-name bucket-log --is-multi-region-trail

⚠ Vì sao gom về một bucket lại quan trọng đến vậy:

Nhiều bucket, mỗi Region một cái
        ↓
    → phải bảo vệ nhiều bucket
    → phải tạo nhiều bảng Athena
    → dễ bỏ sót một Region khi rà soát
        ↓
Một bucket duy nhất
        ↓
    → một Object Lock, một bucket policy, một chính sách mã hoá
    → một bảng Athena truy vấn được tất cả
    → dễ chứng minh với kiểm toán viên

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

• B (CloudTrail chỉ gửi log về bucket ở Region gốc của trail; phải cấu hình một bucket cho mỗi Region) — đây là phương án gần nhất và mô tả cách làm SAI mà nhiều người tưởng là bắt buộc. Thực tế trail đa Region gom tất cả về một bucket, và bucket đó không cần cùng Region với nơi phát sinh sự kiện.

• C (không bật CloudTrail cho mọi Region từ Console được, chỉ làm qua CLI) — sai; Console là nơi dễ nhất để làm việc này, và đó còn là mặc định.

• D (CloudTrail không ghi log từ nhiều Region) — sai hoàn toàn; đây là tính năng cốt lõi.

Ghi nhớ

⚠ Ba loại trail — bảng phải thuộc: | Loại | Phạm vi | |---|---| | Single-region trail | một Region — hiếm khi nên dùng | | Multi-region trail | MỌI Region, gồm cả Region mới ra mắt sau này | | Organization trail | mọi Region của MỌI TÀI KHOẢN trong tổ chức |

Từ khoá nhận diện:

"log từ nhiều Region về một chỗ" → multi-region trail "log của mọi tài khoản trong tổ chức" → organization trail "tài khoản thành viên không tắt được" → organization trail "chứng minh log chưa bị sửa" → log file validation "ai đã tải một tệp trong S3" → data event (có phí)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trail có đa Region không | describe-trails, xem IsMultiRegionTrail | | Trail có đang ghi không | get-trail-status, xem IsLogging | | Có Region nào bị bỏ sót không | mở Event history ở vài Region ít dùng và đối chiếu |

Và một lời khuyên nên áp dụng cho mọi tài khoản AWS, kể cả tài khoản thử nghiệm: luôn tạo trail ở chế độ đa Region. Region mà bạn không dùng chính là Region mà kẻ tấn công sẽ dùng — vì đó là nơi không ai nhìn tới, không có cảnh báo nào, và nếu trail chỉ bật ở Region chính thì mọi hoạt động ở đó sẽ không để lại bất kỳ dấu vết nào trong hệ thống kiểm toán của bạn.

Đáp án

D — CẢ HAI chính sách đều CHẶN mọi thao tác cập nhật lên tài nguyên có logical ID là MyDatabase, và CHO PHÉP mọi thao tác cập nhật lên tất cả tài nguyên khác của stack.

Vì sao đúng

Hai chính sách được viết theo hai cách khác nhau nhưng cho kết quả hoàn toàn giống nhau.

⚠ Policy-1 — cách viết tường minh: Deny cụ thể + Allow rộng:

Deny  Update:*  trên  LogicalResourceId/MyDatabase
Allow Update:*  trên  *
        ↓
    MyDatabase khớp CẢ HAI câu lệnh
        ↓
    → nhưng DENY TƯỜNG MINH THẮNG ALLOW
        ↓
    → MyDatabase: bị chặn
    → tài nguyên khác: chỉ khớp Allow → được phép

⚠ Policy-2 — cách viết bằng NotResource:

Allow Update:*  trên  NotResource: LogicalResourceId/MyDatabase
        ↓
    "Cho phép trên MỌI tài nguyên NGOẠI TRỪ MyDatabase"
        ↓
    → MyDatabase: KHÔNG khớp câu Allow nào
        ↓
    → rơi vào TỪ CHỐI NGẦM (implicit deny)
        ↓
    → tài nguyên khác: khớp Allow → được phép

⚠ Điểm mấu chốt — hai kiểu từ chối khác nhau nhưng kết quả như nhau:

Policy-1 → EXPLICIT DENY (từ chối tường minh)
Policy-2 → IMPLICIT DENY (từ chối ngầm, vì không có Allow nào khớp)
        ↓
    Trong tình huống này: KẾT QUẢ GIỐNG HỆT NHAU
        ↓
    Nhưng KHÁC NHAU khi có thêm chính sách khác chồng lên:
        - Explicit Deny: KHÔNG THỂ bị ghi đè bởi Allow nào
        - Implicit Deny: một Allow từ chính sách khác có thể lật ngược
        ↓
    → với stack policy chỉ có MỘT chính sách cho mỗi stack,
      nên khác biệt này không phát sinh ở đây

Xem thêm câu #11710: cùng chủ đề stack policy nhưng ở góc khác — nhấn mạnh rằng stack policy không phải cơ chế kiểm soát truy cập, và không thay thế được chính sách IAM.

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

• B (Policy-1 chặn MyDatabase, còn Policy-2 CHO PHÉP MyDatabase) — đây là phương án gần nhất và là bẫy về cách đọc NotResource. Rất nhiều người đọc NotResource: MyDatabase thành "áp dụng cho MyDatabase", trong khi nó nghĩa là "áp dụng cho mọi thứ TRỪ MyDatabase".

• C (Policy-2 chặn, Policy-1 cho phép) — hiểu sai cả hai chính sách, và bỏ qua quy tắc Deny thắng Allow.

• A (cả hai đều cho phép cập nhật mọi tài nguyên) — bỏ qua hoàn toàn cả Deny lẫn NotResource.

Ghi nhớ

⚠ Resource và NotResource — bảng phải thuộc: | Cú pháp | Nghĩa | |---|---| | "Resource": "A" | áp dụng CHO A | | "NotResource": "A" | áp dụng cho MỌI THỨ TRỪ A | | "Action": "X" | áp dụng cho hành động X | | "NotAction": "X" | áp dụng cho mọi hành động TRỪ X |

Từ khoá nhận diện:

"NotResource" → mọi thứ NGOẠI TRỪ cái được nêu "Deny và Allow cùng khớp" → DENY thắng "không có Allow nào khớp" → implicit deny "chặn cập nhật một tài nguyên khi update stack" → stack policy "chặn xoá cả stack" → termination protection

⚠ Ba quy tắc vàng — áp dụng cho cả IAM lẫn stack policy: | Quy tắc | |---| | 1. Mặc định là TỪ CHỐI (implicit deny) | | 2. Allow tường minh cho phép | | 3. DENY TƯỜNG MINH THẮNG TẤT CẢ |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stack đang có policy gì | get-stack-policy --stack-name <ten> | | Update sẽ động vào gì | tạo change set và đọc cột Replacement | | Chính sách có chặn đúng không | thử một update cố tình chạm vào tài nguyên được bảo vệ |

Và một mẫu stack policy đáng áp dụng cho mọi stack sản xuất: chặn Update:Replace trên mọi tài nguyên có lưu trạng thái, nhưng vẫn cho Update:Modify. Cách này không cản trở việc cập nhật hằng ngày, nhưng biến một thay đổi vô tình gây thay thế cơ sở dữ liệu — thứ trông hoàn toàn vô hại khi đọc pull request — thành một lỗi rõ ràng ngay lúc triển khai.

Đáp án

B, E, F — ba bước cần để kết nối tới Aurora DB cluster từ ngoài VPC:

• F — Cấu hình DB subnet group gồm các PUBLIC subnet, và tạo Aurora DB instance từ subnet group đó.
• E — Aurora DB instance phải có ĐỊA CHỈ IP CÔNG CỘNG.
• B — BẬT hai thuộc tính của VPC: DNS hostnames và DNS resolution.

Vì sao đúng

⚠ Điều F — RDS không cho bạn chọn subnet trực tiếp:

Với EC2: bạn chọn subnet khi khởi chạy
        ↓
Với RDS/Aurora: bạn chọn DB SUBNET GROUP
        ↓
    DB subnet group = tập hợp subnet ở ÍT NHẤT HAI AZ
        ↓
    → RDS tự chọn subnet trong nhóm đó
        ↓
    → muốn instance ở public subnet thì DB subnet group
      phải chứa PUBLIC subnet

⚠ Điều E — PubliclyAccessible quyết định có IP công cộng hay không:

PubliclyAccessible = true
        ↓
    RDS gán một IP CÔNG CỘNG cho instance
    Endpoint DNS phân giải thành IP CÔNG CỘNG khi hỏi từ ngoài
        ↓
    → client ngoài VPC kết nối được

PubliclyAccessible = false
        ↓
    Chỉ có IP riêng
    Endpoint DNS luôn phân giải thành IP RIÊNG
        ↓
    → chỉ truy cập được từ trong VPC (hoặc qua VPN/DX/peering)

⚠ Điều B — vì sao cần bật hai thuộc tính DNS của VPC:

enableDnsHostnames + enableDnsSupport
        ↓
    Không bật → endpoint của RDS không phân giải đúng
        ↓
    → client ngoài VPC không tìm được địa chỉ để kết nối
        ↓
    → đây là điều kiện thường bị bỏ sót nhất trong ba điều

⚠ Và ba lớp phải mở đủ, không chỉ ba bước trên:

1. Route table của subnet phải có 0.0.0.0/0 → IGW
2. Security Group của DB cho phép cổng 3306/5432 từ IP client
3. NACL cho phép cả hai chiều

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

• C (chọn public subnet khi tạo Aurora DB instance) — đây là phương án gần nhất và ý tưởng thì đúng, nhưng cách diễn đạt sai về cơ chế: bạn không chọn subnet trực tiếp cho RDS — bạn chọn DB subnet group, đúng như đáp án F mô tả.

• D (không tạo được Aurora public trong default VPC, phải dùng VPC khác) — sai; default VPC hoàn toàn dùng được, và thực ra nó còn thuận tiện hơn vì mọi subnet đã là public sẵn.

• A (TẮT hai thuộc tính DNS) — ngược hẳn với điều B; tắt chúng là chắc chắn không kết nối được.

Ghi nhớ

⚠ Ba điều kiện để RDS/Aurora truy cập được từ internet — bảng phải thuộc: | Điều kiện | Nội dung | |---|---| | PubliclyAccessible = true | instance có IP công cộng | | DB subnet group chứa public subnet | subnet có tuyến 0.0.0.0/0 → IGW | | VPC bật enableDnsHostnames và enableDnsSupport | endpoint phân giải đúng | | (kèm) Security Group | cho phép cổng DB từ IP của client |

Từ khoá nhận diện:

"RDS truy cập từ ngoài VPC" → PubliclyAccessible + public subnet group + DNS attributes "chọn subnet cho RDS" → qua DB SUBNET GROUP, không chọn trực tiếp "RDS không được lộ ra internet" → PubliclyAccessible: false + private subnet "kết nối từ tại chỗ" → VPN/Direct Connect + private subnet — an toàn hơn nhiều "ép mọi kết nối phải mã hoá" → parameter group (rds.force_ssl)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance có công khai không | describe-db-instances, xem PubliclyAccessible | | DNS phân giải ra IP gì | dig <endpoint> từ ngoài VPC — phải ra IP công cộng | | VPC đã bật DNS chưa | describe-vpc-attribute --attribute enableDnsHostnames |

Và một lời khuyên thẳng thắn về yêu cầu "cơ sở dữ liệu phải truy cập được công khai": hãy hỏi lại xem nhu cầu thật sự là gì trước khi triển khai. Trong phần lớn trường hợp, thứ người ta cần là truy cập được từ máy của lập trình viên hay từ một công cụ BI — và cả hai đều giải quyết tốt hơn bằng VPN hoặc bastion, thay vì mở một cổng cơ sở dữ liệu ra cho toàn bộ internet quét thấy.

Đáp án

C — Cấp thêm quyền PutObjectAcl cho toàn bộ đối tượng đã xuất, sau khi việc xuất hoàn tất.

Vì sao đúng

Đây là biểu hiện kinh điển của bài toán object ownership liên tài khoản trên S3.

⚠ Điểm mấu chốt — ai GHI đối tượng thì người đó SỞ HỮU nó:

Tài khoản A xuất dữ liệu DynamoDB
        ↓
    Ghi vào bucket của TÀI KHOẢN B
        ↓
    → chủ sở hữu ĐỐI TƯỢNG là TÀI KHOẢN A
    → chủ sở hữu BUCKET là tài khoản B
        ↓
    → tài khoản B SỞ HỮU CÁI THÙNG nhưng KHÔNG SỞ HỮU
      những gì bên trong
        ↓
    → user của B không đọc được, dù bucket là của họ

⚠ Hai cách xử lý — một cách phòng, một cách chữa:

PHÒNG (lúc ghi):
    Ghi kèm ACL "bucket-owner-full-control"
        ↓
    → chủ bucket có toàn quyền ngay từ đầu

CHỮA (sau khi đã ghi):
    Tài khoản A gọi PutObjectAcl trên các đối tượng đã ghi
        ↓
    aws s3api put-object-acl --bucket bucket-b \
      --key du-lieu.json --acl bucket-owner-full-control
        ↓
    → đây là đáp án của đề, vì việc xuất ĐÃ hoàn tất

⚠ Và cách làm hiện đại khiến vấn đề này biến mất hoàn toàn:

S3 Object Ownership = BucketOwnerEnforced
        ↓
    → ACL bị VÔ HIỆU HOÁ hoàn toàn
    → CHỦ BUCKET LUÔN SỞ HỮU mọi đối tượng, bất kể ai ghi
        ↓
    → mặc định cho bucket tạo mới từ tháng 4/2023
    → AWS khuyến nghị dùng
        ↓
    Nếu bucket của B đã bật cái này thì bài toán không xảy ra

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

• A (cấu hình hàm xuất để ghi dữ liệu kèm ACL bucket-owner-full-control) — đây là phương án gần nhất và là cách PHÒNG đúng đắn. Nhưng đề nói việc xuất đã hoàn tất và người dùng đang không truy cập được — nên cần một cách CHỮA cho dữ liệu đã có, tức là PutObjectAcl. (Cách A sẽ đúng nếu áp dụng trước khi xuất.)

• B (dùng AWS Data Pipeline để xuất bảng DynamoDB sang S3 của tài khoản B) — không giải quyết vấn đề: dùng công cụ nào để ghi thì quyền sở hữu đối tượng vẫn thuộc về tài khoản ghi. (Ngoài ra AWS Data Pipeline đã ngừng nhận khách hàng mới — thay thế bằng Glue, Step Functions hoặc MWAA.)

• D (dùng Glue crawler để nhập thẳng dữ liệu vào DynamoDB của tài khoản B) — hiểu sai công dụng: Glue crawler chỉ QUÉT dữ liệu và dựng catalog, nó không nhập dữ liệu vào đâu cả.

Ghi nhớ

⚠ Object ownership liên tài khoản — bảng phải thuộc: | Tình huống | Ai sở hữu đối tượng | |---|---| | Tài khoản A ghi vào bucket của A | A | | Tài khoản A ghi vào bucket của B (ACL cũ) | A — B không đọc được | | A ghi kèm bucket-owner-full-control | B có toàn quyền | | Bucket bật BucketOwnerEnforced | B LUÔN sở hữu, ACL bị vô hiệu |

Từ khoá nhận diện:

"chủ bucket không đọc được đối tượng" → object ownership liên tài khoản "phòng từ đầu" → bucket-owner-full-control hoặc BucketOwnerEnforced "chữa sau khi đã ghi" → PutObjectAcl "AWS khuyến nghị" → tắt ACL bằng BucketOwnerEnforced "Data Pipeline" → đã ngừng nhận khách mới

⚠ Ba chế độ Object Ownership — bảng phải thuộc: | Chế độ | Nội dung | |---|---| | BucketOwnerEnforced | ACL VÔ HIỆU, chủ bucket luôn sở hữu — mặc định cho bucket mới, AWS khuyến nghị | | BucketOwnerPreferred | chủ bucket sở hữu nếu người ghi dùng bucket-owner-full-control | | ObjectWriter | người ghi sở hữu — cách cũ, nguồn gốc của vấn đề trong đề |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai sở hữu một đối tượng | get-object-acl --bucket ... --key ... | | Bucket đang ở chế độ nào | get-bucket-ownership-controls | | Vì sao AccessDenied | CloudTrail — xem lỗi từ s3 hay từ kms |

Và một lời khuyên nên áp dụng cho mọi bucket nhận dữ liệu từ tài khoản khác: bật BucketOwnerEnforced ngay từ khi tạo bucket. Nó xoá sổ vĩnh viễn cả một lớp sự cố mà câu hỏi này mô tả — và với những bucket đã tồn tại từ lâu, đây là một trong những thay đổi cấu hình đơn giản nhất mang lại lợi ích lớn nhất, miễn là bạn xác nhận trước rằng không có quy trình nào đang phụ thuộc vào ACL.

Đáp án

A, B — hai điểm cần nhớ về chứng chỉ ACM:

• A — ACM chỉ cấp chứng chỉ cho giao thức SSL/TLS.
• B — Bạn KHÔNG dùng được chứng chỉ ACM để mã hoá email.

Vì sao đúng

Cả hai điều đều xuất phát từ cùng một sự thật: ACM có phạm vi rất hẹp và rất chuyên biệt.

⚠ Điểm mấu chốt — ACM chỉ làm một việc:

ACM cấp chứng chỉ X.509 cho SSL/TLS
        ↓
    Dùng để MÃ HOÁ KẾT NỐI giữa client và dịch vụ
        ↓
    KHÔNG dùng cho:
        - mã hoá email (S/MIME)     ← điều B
        - ký mã nguồn (code signing)
        - xác thực client bằng chứng chỉ
        - mã hoá tài liệu
        ↓
    → mỗi loại chứng chỉ có một mục đích được ghi trong
      trường "Key Usage" và "Extended Key Usage"

⚠ Và ACM chỉ tích hợp được với các dịch vụ mà AWS tự kết thúc TLS:

Dùng được:
    Application / Network Load Balancer
    CloudFront (chứng chỉ BẮT BUỘC ở us-east-1)
    API Gateway, App Runner, AppSync
    Elastic Beanstalk (qua ELB)
        ↓
KHÔNG dùng được:
    EC2 instance          ← đây là lý do phương án C sai
    Máy chủ tại chỗ
    Container tự chạy TLS

Xem thêm câu #11725: cùng sự thật này ở góc khác — khi cần mã hoá toàn tuyến tới EC2, chứng chỉ ACM công khai không dùng được, phải dùng AWS Private CA hoặc chứng chỉ bên thứ ba.

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

• C (cài chứng chỉ ACM lên ứng dụng chạy trên EC2) — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất về ACM. Lý do không làm được: ACM giữ private key và không cho xuất ra — mà cài chứng chỉ lên EC2 thì bắt buộc phải có private key. (Chứng chỉ từ AWS Private CA thì xuất được và cài lên EC2 được.)

• D (private key của chứng chỉ ACM chỉ tải về được bằng tài khoản root) — sai; KHÔNG AI tải được, kể cả root. Đó là thiết kế cốt lõi của ACM.

• E (ACM giúp xin chứng chỉ cho tên miền do Amazon sở hữu) — ngược lại: ACM cấp chứng chỉ cho tên miền CỦA BẠN, và bạn phải chứng minh quyền sở hữu bằng DNS hoặc email validation.

Ghi nhớ

⚠ Hai loại chứng chỉ của ACM — bảng phải thuộc: | | ACM public certificate | AWS Private CA | |---|---|---| | Chi phí | MIỄN PHÍ | có phí (theo CA và theo chứng chỉ) | | Xuất private key | KHÔNG | CÓ | | Cài lên EC2 | KHÔNG | CÓ | | Trình duyệt tin cậy | có | không — chỉ nội bộ | | Tự gia hạn | có, nếu gắn với dịch vụ tích hợp | có |

Từ khoá nhận diện:

"cài chứng chỉ ACM lên EC2" → KHÔNG ĐƯỢC "tải private key từ ACM" → KHÔNG AI tải được "mã hoá email" → KHÔNG phải việc của ACM (dùng S/MIME từ CA khác) "chứng chỉ cho CloudFront" → ACM ở us-east-1, BẮT BUỘC "mã hoá toàn tuyến tới EC2" → AWS Private CA "ký mã nguồn" → AWS Signer, không phải ACM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chứng chỉ đang dùng ở đâu | describe-certificate, xem InUseBy | | Trạng thái xác thực | DomainValidationOptions[].ValidationStatus | | Sắp hết hạn chưa | NotAfter, và bật cảnh báo qua EventBridge |

Và một chi tiết khiến rất nhiều người mất thời gian mà không hiểu vì sao: chứng chỉ ACM cho CloudFront BẮT BUỘC nằm ở Region us-east-1, kể cả khi toàn bộ hạ tầng của bạn ở nơi khác. Triệu chứng là chứng chỉ hiện trạng thái Issued bình thường, nhưng ô chọn chứng chỉ trong cấu hình CloudFront lại trống trơn — và không có thông báo nào giải thích lý do.

Đáp án

C — Cho phép bạn gán IAM Role cho EC2, với điều kiện tên role bắt đầu bằng RDS-.

Vì sao đúng

Chính sách này gồm hai câu lệnh, và ý nghĩa nằm ở cách chúng kết hợp với nhau.

⚠ Câu lệnh thứ nhất — toàn quyền trên EC2:

"Action": "ec2:*", "Resource": "*"
        ↓
    → làm được mọi thao tác EC2: khởi chạy, dừng, xoá, sửa

⚠ Câu lệnh thứ hai — iam:PassRole, và đây mới là phần quan trọng:

"Action": "iam:PassRole"
"Resource": "arn:aws:iam:::role/RDS-*"
        ↓
    → được phép TRAO một role cho một dịch vụ AWS
    → nhưng CHỈ những role có tên bắt đầu bằng "RDS-"

⚠ Điểm mấu chốt — PassRole là gì và vì sao nó tồn tại:

Khởi chạy EC2 với một instance profile
        ↓
    Nghĩa là bạn TRAO quyền của role đó cho instance
        ↓
    → instance sẽ hành động với quyền của role
        ↓
    Nếu không có kiểm soát:
        một người chỉ có quyền ec2:*
        có thể khởi chạy máy với role AdministratorAccess
        rồi dùng máy đó làm mọi thứ
        ↓
    → đó chính là LEO THANG ĐẶC QUYỀN
        ↓
    iam:PassRole tồn tại để chặn điều đó

⚠ Vì sao chính sách này ghép hai câu lệnh lại:

ec2:* một mình
        ↓
    → khởi chạy được máy, nhưng KHÔNG gắn role nào được

ec2:* + iam:PassRole trên role/RDS-*
        ↓
    → khởi chạy máy VÀ gắn được role có tên RDS-*
    → nhưng không gắn được role nào khác
        ↓
    → đúng như đáp án C mô tả

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

• B (cho phép gán BẤT KỲ role nào cho EC2) — đây là phương án gần nhất và sẽ đúng nếu Resource là "*". Nhưng chính sách giới hạn ở role/RDS-*, nên chỉ những role khớp mẫu đó mới gán được.

• D (cho phép gán bất kỳ role nào cho RDS instance) — hiểu sai: RDS- chỉ là TIỀN TỐ TÊN ROLE, không có nghĩa là role dành cho dịch vụ RDS. Chính sách này không cấp quyền RDS nào cả.

• A (cho phép trao cho RDS toàn quyền trên EC2) — hiểu sai hoàn toàn cả hai câu lệnh.

Ghi nhớ

⚠ iam:PassRole — quyền quan trọng nhất mà ít người để ý: | Nội dung | |---| | Cần khi trao một role cho một DỊCH VỤ AWS | | EC2 (instance profile), Lambda (execution role), ECS (task role), CloudFormation (service role), Glue, SageMaker… | | Không giới hạn Resource là mở đường leo thang đặc quyền | | Luôn giới hạn bằng mẫu tên role hoặc iam:PassedToService |

Từ khoá nhận diện:

"gán role cho EC2/Lambda/ECS" → cần iam:PassRole "PassRole với Resource: *" → RỦI RO LEO THANG ĐẶC QUYỀN "đóng vai" → sts:AssumeRole — khác hẳn PassRole "giới hạn role được trao cho dịch vụ nào" → điều kiện iam:PassedToService

⚠ PassRole và AssumeRole — hai thứ rất dễ lẫn: | | iam:PassRole | sts:AssumeRole | |---|---|---| | Ai dùng role | DỊCH VỤ AWS (EC2, Lambda…) | CHÍNH BẠN | | Bạn nhận chứng chỉ không | KHÔNG | CÓ | | Ví dụ | gắn instance profile cho EC2 | aws sts assume-role để đổi vai | | Kiểm soát ở | chính sách IAM của người gọi | trust policy của role |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai có PassRole rộng | rà chính sách tìm iam:PassRole với Resource: "*" | | Instance đang dùng role nào | describe-instances, xem IamInstanceProfile | | Quyền hiệu lực thật | IAM Policy Simulator |

Và một việc đáng làm ngay trong bất kỳ tài khoản AWS nào đã dùng lâu năm: rà soát mọi chính sách có iam:PassRole và kiểm tra trường Resource của chúng. Đây là một trong những đường leo thang đặc quyền phổ biến nhất và cũng khó nhận ra nhất — vì bản thân PassRole nghe rất vô hại, và người viết chính sách thường thêm "Resource": "*" chỉ để "cho nó chạy" mà không nhận ra mình vừa mở cánh cửa nào.

Đáp án

C — Dùng AWS KMS với tính năng xoay khoá tự động (automatic key rotation).

Vì sao đúng

Đề nêu ba yêu cầu, và SSE-KMS đáp ứng cả ba bằng một công tắc:

⚠ Điểm mấu chốt — xoay khoá tự động của KMS hoàn toàn trong suốt:

aws kms enable-key-rotation --key-id <key-id>
        ↓
    KMS tự tạo key material MỚI mỗi năm
    và GIỮ LẠI toàn bộ material CŨ
        ↓
    Dữ liệu mới → mã hoá bằng material mới
    Dữ liệu cũ  → vẫn giải mã được bằng material cũ
        ↓
    → KHÔNG phải mã hoá lại gì cả
    → ARN và alias của khoá KHÔNG ĐỔI
    → ứng dụng không biết là đã có chuyện gì xảy ra

⚠ Vì sao "không phải mã hoá lại" là điều quan trọng nhất:

Xoay khoá theo cách thủ công (tạo khoá mới)
        ↓
    → phải mã hoá lại TOÀN BỘ dữ liệu cũ
    → với hàng terabyte thì đó là một dự án
        ↓
KMS automatic rotation
        ↓
    → chỉ đổi material bên trong cùng một CMK
    → dữ liệu cũ nằm yên, vẫn đọc được

Xem thêm câu #11655, #11720 và #11662: cùng họ chọn kiểu mã hoá S3 — mỗi câu một yêu cầu khác nhau nên đáp án khác nhau. Ở đây yêu cầu là xoay khoá định kỳ, và đó là thứ chỉ KMS làm tự động được.

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

• D (nhập khoá tuỳ chỉnh vào KMS rồi tự động xoay hằng năm bằng Lambda) — đây là phương án gần nhất và về kỹ thuật thì làm được. Nhưng nó vi phạm ràng buộc "cách dễ nhất": khoá nhập từ ngoài (imported key material) KHÔNG hỗ trợ xoay tự động — bạn phải tự sinh, tự nhập, tự viết Lambda, và tự giữ bản gốc để phòng khi cần nhập lại.

• A (SSE-C với xoay khoá tự động hằng năm) — SSE-C không có cơ chế xoay khoá nào: bạn tự giữ khoá và tự gửi kèm mỗi request. Muốn "xoay" thì phải tự mã hoá lại toàn bộ dữ liệu bằng khoá mới.

• B (mã hoá dữ liệu trước khi gửi lên S3) — client-side encryption cho kiểm soát cao nhất nhưng công sức lớn nhất: tự mã hoá, tự lưu khoá, tự xoay khoá. Trái thẳng yêu cầu "dễ nhất".

Ghi nhớ

⚠ Xoay khoá theo từng loại khoá KMS — bảng phải thuộc: | Loại khoá | Xoay tự động | |---|---| | AWS managed key (aws/s3) | CÓ, mỗi năm — bắt buộc, không tắt được | | Customer managed key (CMK) | CÓ, phải BẬT thủ công — mỗi năm (chỉnh được chu kỳ) | | Imported key material | KHÔNG — phải tự nhập khoá mới | | CloudHSM key store / XKS | tuỳ cấu hình bên ngoài | | AWS owned key | AWS lo, bạn không thấy |

Từ khoá nhận diện:

"xoay khoá tự động, dễ nhất" → KMS CMK + enable-key-rotation "khoá nhập từ ngoài" → KHÔNG xoay tự động được "SSE-C xoay khoá" → KHÔNG CÓ cơ chế nào "xoay MẬT KHẨU cơ sở dữ liệu" → Secrets Manager (khác hoàn toàn) "cần nhật ký ai dùng khoá" → SSE-KMS + CloudTrail

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoay khoá đã bật chưa | get-key-rotation-status | | Bucket dùng khoá nào | get-bucket-encryption | | Có bao nhiêu material đã xoay | list-key-rotations |

Và một điểm rất đáng hiểu rõ để không hiểu nhầm ý nghĩa của tính năng này: xoay khoá KMS đổi key material BÊN TRONG cùng một CMK, chứ không tạo ra một khoá mới. Nghĩa là nó không bảo vệ bạn khỏi việc CMK bị vô hiệu hoá hay bị xoá, và cũng không thay đổi ai có quyền dùng khoá — nó chỉ giới hạn lượng dữ liệu được mã hoá bằng cùng một material, đúng như các chuẩn tuân thủ yêu cầu.

Đáp án

A — Digest file được mã hoá bằng khoá do S3 quản lý (SSE-S3), không phải SSE-KMS.

Vì sao đúng

Đây là hành vi cố ý của CloudTrail, và lý do đằng sau nó rất đáng hiểu.

⚠ Điểm mấu chốt — hai loại tệp, hai cơ chế mã hoá khác nhau:

Tệp LOG
        ↓
    Chứa NỘI DUNG nhạy cảm: ai làm gì, tham số request
        ↓
    → mã hoá bằng SSE-KMS nếu bạn cấu hình
    → bạn kiểm soát ai giải mã được, có nhật ký dùng khoá

Tệp DIGEST
        ↓
    Chỉ chứa MÃ BĂM của các tệp log + chữ ký số
    KHÔNG chứa nội dung nhạy cảm nào
        ↓
    → luôn mã hoá bằng SSE-S3

⚠ Vì sao AWS thiết kế như vậy — lý do rất thực tế:

Digest file dùng để CHỨNG MINH tính toàn vẹn của log
        ↓
    Việc kiểm chứng phải luôn thực hiện được
        ↓
    Nếu digest cũng mã hoá bằng CMK của bạn:
        - CMK bị vô hiệu hoá → không kiểm chứng được
        - CMK bị xoá        → mất khả năng chứng minh VĨNH VIỄN
        - kiểm toán viên không có quyền dùng CMK → bó tay
        ↓
    → digest dùng SSE-S3 để việc kiểm chứng luôn khả thi

⚠ Và điều này KHÔNG làm giảm mức bảo mật:

Digest file chỉ chứa:
        - mã băm SHA-256 của từng tệp log
        - mã băm của digest file TRƯỚC ĐÓ
        - chữ ký số bằng khoá riêng của AWS
        ↓
    → không suy ngược ra nội dung log được từ mã băm
    → chữ ký số vẫn bảo đảm digest không bị làm giả

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

• D (CMK dùng cho log khác với CMK dùng cho digest) — đây là phương án gần nhất và nghe rất hợp lý, nhưng sai: digest không dùng CMK nào cả, nó dùng SSE-S3 — khoá do AWS quản lý hoàn toàn, không nằm trong tài khoản bạn.

• C (theo cấu hình mặc định, log và digest nằm ở hai bucket khác nhau) — sai; cả hai nằm CÙNG một bucket, chỉ khác tiền tố: AWSLogs/.../CloudTrail/ và AWSLogs/.../CloudTrail-Digest/.

• B (log và digest được tạo ở hai Region khác nhau) — sai; chúng được tạo cho cùng một Region và đổ về cùng một nơi.

Ghi nhớ

⚠ Log file và digest file của CloudTrail — bảng phải thuộc: | | Log file | Digest file | |---|---|---| | Nội dung | sự kiện API chi tiết | mã băm + chữ ký | | Tần suất | khoảng 5 phút một lần | mỗi giờ một lần | | Mã hoá | SSE-S3 hoặc SSE-KMS (bạn chọn) | LUÔN là SSE-S3 | | Vị trí | AWSLogs/.../CloudTrail/ | AWSLogs/.../CloudTrail-Digest/ | | Mục đích | ghi lại hoạt động | chứng minh log chưa bị sửa |

Từ khoá nhận diện:

"digest file mã hoá kiểu gì" → luôn SSE-S3 "chứng minh log chưa bị sửa" → log file validation + digest file "ai đọc được log" → SSE-KMS + key policy "không ai xoá được log" → S3 Object Lock chế độ Compliance "xoá digest file" → ĐỨT CHUỖI, mất khả năng chứng minh

⚠ Cơ chế chuỗi digest — vì sao nó chống được việc làm giả:

Digest giờ N chứa:
        - mã băm của mọi tệp log trong giờ N
        - MÃ BĂM CỦA DIGEST GIỜ N-1        ← mắt xích
        - chữ ký số bằng khoá riêng của AWS
        ↓
    → tạo thành một CHUỖI liên tục
        ↓
    Sửa một tệp log   → mã băm không khớp
    Xoá một tệp log   → digest thiếu mục
    Xoá một digest    → chuỗi ĐỨT
    Làm giả digest    → chữ ký không hợp lệ
        ↓
    → mọi kiểu can thiệp đều để lại dấu vết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Validation đã bật chưa | describe-trails, xem LogFileValidationEnabled | | Log có toàn vẹn không | validate-logs với khoảng thời gian cần kiểm | | Digest còn đủ không | liệt kê tiền tố CloudTrail-Digest/, kiểm tra không thiếu giờ nào |

Và một lời nhắc về việc bảo vệ chuỗi digest: hãy đặt lifecycle policy cho bucket log sao cho digest file KHÔNG bị xoá trước tệp log tương ứng. Một quy tắc lifecycle vô tình xoá digest sớm hơn log sẽ khiến bạn còn nguyên dữ liệu nhưng mất khả năng chứng minh nó chưa bị sửa — và với một cuộc kiểm toán thì hai điều đó không giống nhau chút nào.

Đáp án

C — AMI Linux dạng paravirtual (PV) không được hỗ trợ ở mọi Region của AWS, và sao chép chúng sang Region không hỗ trợ sẽ gây ra lỗi này.

Vì sao đúng

Thông báo lỗi nói rõ về kernel không có ở Region đích — và chỉ AMI kiểu PV mới phụ thuộc vào kernel do AWS cung cấp.

⚠ Điểm mấu chốt — hai kiểu ảo hoá và cách chúng khởi động:

PV (Paravirtual) — kiểu CŨ
        ↓
    Dùng AKI (Amazon Kernel Image) — một kernel RIÊNG
    do AWS cung cấp, gắn theo Region
        ↓
    → AMI PV tham chiếu tới một AKI ID cụ thể
    → AKI đó CHỈ TỒN TẠI ở một số Region
        ↓
    → copy sang Region không có AKI đó → LỖI ĐÚNG NHƯ ĐỀ

HVM (Hardware Virtual Machine) — kiểu HIỆN ĐẠI
        ↓
    Máy ảo tự khởi động như một máy vật lý
    KHÔNG phụ thuộc AKI nào
        ↓
    → copy sang MỌI Region đều được

⚠ Cách xử lý:

Ngắn hạn:
    - copy sang Region CÓ hỗ trợ PV, hoặc
    - dựng lại instance từ một AMI HVM tương đương

Dài hạn (nên làm):
    - CHUYỂN HẲN sang HVM
        ↓
    → mọi loại instance thế hệ mới CHỈ hỗ trợ HVM
    → PV đã lỗi thời từ lâu

⚠ Và vì sao HVM đã thay thế hoàn toàn PV:

HVM hỗ trợ:
        - enhanced networking (ENA, SR-IOV)
        - GPU và thiết bị phần cứng khác
        - mọi loại instance thế hệ hiện tại
        ↓
    PV không hỗ trợ những thứ đó
        ↓
    → AWS đã ngừng phát triển PV từ lâu
    → chỉ một số loại instance rất cũ còn dùng được

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

• B (AMI HVM không được hỗ trợ ở mọi Region) — đây là phương án gần nhất và đảo ngược sự thật: HVM được hỗ trợ ở MỌI Region; chính PV mới là loại bị giới hạn.

• D (AMI Linux không copy được giữa các Region) — sai; copy-image hoạt động bình thường với AMI Linux, chỉ trừ trường hợp PV gặp vấn đề AKI như câu này.

• A (lỗi chung chung, do AMI chưa được cấp phát đúng) — thông báo lỗi rất cụ thể, nêu đích danh vấn đề về kernel; đây không phải lỗi mơ hồ.

Ghi nhớ

⚠ PV và HVM — bảng phải thuộc: | | PV (Paravirtual) | HVM | |---|---|---| | Kernel | AKI do AWS cung cấp, gắn theo Region | tự chứa trong AMI | | Copy chéo Region | có thể LỖI | luôn được | | Enhanced networking | KHÔNG | CÓ | | GPU và thiết bị đặc biệt | KHÔNG | CÓ | | Loại instance thế hệ mới | KHÔNG hỗ trợ | hỗ trợ | | Trạng thái | lỗi thời | tiêu chuẩn hiện nay |

Từ khoá nhận diện:

"kernel không có ở Region đích" → AMI kiểu PV "AMI dùng ở Region khác" → copy-image (tạo AMI mới, id mới) "AMI dùng ở tài khoản khác" → modify-image-attribute launch permission "AMI mã hoá chia sẻ" → phải là CMK, không dùng aws/ebs "instance thế hệ mới không khởi chạy được từ AMI cũ" → AMI đang là PV

Ba việc kiểm chứng: | Việc | Cách | |---|---| | AMI thuộc kiểu nào | describe-images --image-ids ami-xxx, xem VirtualizationType | | Region đích có hỗ trợ không | thử copy-image và đọc thông báo lỗi | | AMI có AKI không | describe-images, xem trường KernelId — có giá trị nghĩa là PV |

Và một lời khuyên rút ra từ chính lỗi này: nếu bạn còn AMI kiểu PV trong sản xuất, hãy coi đây là tín hiệu để lên kế hoạch chuyển sang HVM. PV không chỉ gây rắc rối khi copy chéo Region — nó còn khoá bạn vào các loại instance thế hệ cũ, vốn đắt hơn và chậm hơn so với thế hệ hiện tại, đồng thời không dùng được enhanced networking hay bất kỳ tính năng phần cứng nào ra đời trong nhiều năm qua.