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

Đáp án

A và D.

• A — Security group A (web): inbound cho phép cổng 443 từ mọi nguồn; outbound tới security group B trên cổng 1433
• D — Security group B (database): inbound chỉ cho phép từ security group A trên cổng 1433

Vì sao đúng

Hai đáp án mô tả đúng luồng lưu lượng của kiến trúc hai tầng:

Internet ──443──▶ Web (SG A) ──1433──▶ MSSQL (SG B)

A — cấu hình cho tầng web: | Chiều | Quy tắc | Lý do | |---|---|---| | Inbound 443 từ mọi nguồn | 0.0.0.0/0 | web server phải nhận được HTTPS từ Internet | | Outbound 1433 tới SG B | tham chiếu security group | web gọi database qua cổng MSSQL |

D — cấu hình cho tầng database:

Inbound 1433 CHỈ TỪ security group A
    → không phải từ CIDR
    → không phải từ mọi nguồn
        ↓
    Chỉ máy thuộc tầng web mới kết nối được

Và cổng 1433 là cổng của Microsoft SQL Server — đề nêu rõ điều này.

Vì sao tham chiếu SECURITY GROUP thay vì CIDR là cấu hình an toàn nhất:

Dùng CIDR (10.0.1.0/24):
    → MỌI máy trong subnet đó kết nối được
    → kể cả máy không thuộc tầng web
    → và IP thay đổi khi ASG tạo máy mới

Dùng security group:
    → chỉ máy được gán SG A mới vào được
    → instance mới do ASG tạo TỰ ĐỘNG được phép
    → không phụ thuộc IP hay subnet

aws ec2 authorize-security-group-ingress --group-id sg-database   --protocol tcp --port 1433 --source-group sg-web

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

• **E. Security group A: inbound 443 từ mọi nguồn, outbound tới SG B trên cổng 443 — đây là phương án gần nhất và vế inbound hoàn toàn đúng, nhưng vế outbound sai cổng: kết nối tới MSSQL dùng cổng 1433, không phải 443. Cấu hình này khiến web server không kết nối được database.
• **B. Security group B: inbound chỉ từ SG A trên cổng 443 — cùng lỗi cổng, đặt ở phía database.
• **C. Security group B: inbound cổng 1433 từ MỌI NGUỒN — đúng cổng nhưng sai nguồn: mở database cho toàn bộ Internet là lỗ hổng nghiêm trọng. Đây chính là điều mà kiến trúc private subnet muốn ngăn.

Ghi nhớ

Cổng của các database phổ biến — bảng nên thuộc: | Database | Cổng | |---|---| | Microsoft SQL Server | 1433 | | MySQL, MariaDB, Aurora MySQL | 3306 | | PostgreSQL, Aurora PostgreSQL | 5432 | | Oracle | 1521 | | Redis | 6379 | | Memcached | 11211 | | MongoDB / DocumentDB | 27017 | | NFS (EFS) | 2049 | | SMB | 445 | | RDP | 3389 | | SSH | 22 |

Bảng này xuất hiện rất thường xuyên trong đề thi.

Ba đặc điểm của security group: | Đặc điểm | Chi tiết | |---|---| | CHỈ có quy tắc Allow | không có Deny | | STATEFUL | trả lời tự động được phép, không cần quy tắc ngược | | Tham chiếu security group khác được | ← điểm mấu chốt của câu này |

Tính stateful có hệ quả quan trọng:

Web gửi request tới database qua cổng 1433
    → SG B cho phép inbound 1433 ✓
    → phản hồi từ database TỰ ĐỘNG được phép ra
    → KHÔNG cần quy tắc outbound trên SG B

Khác với NACL (stateless), phải mở cả hai chiều.

Security group và NACL — bảng phân biệt: | | Security group | Network ACL | |---|---|---| | Phạm vi | ENI | SUBNET | | Quy tắc | chỉ Allow | Allow và Deny | | Trạng thái | stateful | stateless | | Đánh giá | mọi quy tắc | theo số thứ tự, dừng ở quy tắc đầu khớp | | Tham chiếu SG khác | ✅ | ❌ chỉ CIDR | | Mặc định | chặn hết inbound, cho hết outbound | cho hết cả hai chiều |

Ba nguyên tắc thiết kế security group: | Nguyên tắc | Chi tiết | |---|---| | Một SG cho mỗi TẦNG, không phải mỗi máy | dễ quản lý | | Tham chiếu SG thay vì CIDR | an toàn hơn và tự thích ứng | | Chỉ mở cổng thật sự cần | không mở dải cổng rộng |

Mẫu kiến trúc ba tầng:

SG-ALB:      inbound 443 từ 0.0.0.0/0
SG-Web:      inbound 443 từ SG-ALB
SG-Database: inbound 1433 từ SG-Web
    ↓
    Chuỗi tham chiếu — mỗi tầng chỉ nhận từ tầng trên nó

Ba lưu ý về outbound rule: | Lưu ý | Chi tiết | |---|---| | Mặc định cho phép MỌI outbound | nhiều tổ chức thắt chặt lại | | Thắt outbound tăng bảo mật | chặn rò rỉ dữ liệu và gọi ra máy chủ điều khiển | | Nhớ mở cho dịch vụ AWS cần dùng | S3, KMS qua VPC endpoint |

Thắt chặt outbound là thực hành tốt nhưng dễ gây sự cố:

Chặn hết outbound của SG-Web:
    → không gọi được S3, không tải được bản vá
    → không gửi được log lên CloudWatch
        ↓
    → Dùng VPC endpoint và mở đúng những gì cần

Ba hạn mức của security group: | Hạn mức | Giá trị | |---|---| | Quy tắc mỗi SG | 60 inbound + 60 outbound (nâng được) | | SG mỗi ENI | 5 (nâng tối đa 16) | | SG mỗi VPC | 2.500 |

Ba biện pháp bảo vệ tầng database ngoài security group: | Biện pháp | Chi tiết | |---|---| | Đặt trong PRIVATE subnet | ← đã có trong đề | | Không gán public IP | | | Mã hoá kết nối (TLS) và dữ liệu at rest | | | Xác thực bằng IAM database authentication | không dùng mật khẩu tĩnh |

Ba công cụ kiểm tra cấu hình mạng: | Công cụ | Việc | |---|---| | VPC Reachability Analyzer | kiểm tra đường đi giữa hai tài nguyên có thông không | | VPC Flow Logs | thấy lưu lượng thật, kể cả bị từ chối | | AWS Config rule | phát hiện SG mở quá rộng |

Reachability Analyzer rất hữu ích khi chẩn đoán:

aws ec2 create-network-insights-path   --source i-web --destination i-database   --destination-port 1433 --protocol tcp

Nó chỉ ra chính xác thành phần nào chặn — security group, NACL, hay route table.

Và một lời khuyên: hãy đặt tên security group theo TẦNG chứ không theo ứng dụng (sg-web-tier, sg-db-tier). Khi ứng dụng phát triển và có thêm dịch vụ, chuỗi tham chiếu giữa các tầng vẫn giữ nguyên ý nghĩa — còn tên theo ứng dụng sẽ nhanh chóng không còn phản ánh đúng thực tế.

Đáp án

B và D.

• B — Tạo Aurora read replica ở Region eu-west-1
• D — Dựng thêm fleet EC2 cho tầng web ở eu-west-1, bật latency routing policy trong Route 53

Vì sao đúng

Đề nêu vấn đề rõ: khách hàng ở châu Âu bị chậm vì mọi thứ đều ở us-east-1.

Người dùng ở châu Âu → us-east-1 (Mỹ)
    → mỗi vòng lượt mạng khoảng 80–100ms
    → một trang cần hàng chục vòng lượt
        ↓
    Thời gian tải cao

Và giải pháp phải xử lý CẢ HAI tầng: | Tầng | Giải pháp | |---|---| | Web | fleet EC2 ở eu-west-1 + định tuyến theo độ trễ | | Database | Aurora read replica xuyên Region ở eu-west-1 |

D — vì sao latency routing chứ không phải chính sách khác:

Latency-based routing:
    → Route 53 đo độ trễ THẬT từ mạng của người dùng tới từng Region
    → trả về endpoint cho độ trễ THẤP NHẤT
        ↓
    Tự động, thích ứng theo điều kiện mạng thực tế

B — read replica xuyên Region giải quyết tầng dữ liệu:

Không có replica ở châu Âu:
    Web server ở eu-west-1 → database ở us-east-1
    → MỖI truy vấn phải vượt Đại Tây Dương
    → chuyển tầng web sang châu Âu gần như VÔ ÍCH

Có Aurora read replica ở eu-west-1:
    → truy vấn ĐỌC xử lý ngay tại châu Âu
    → chỉ truy vấn GHI mới đi về us-east-1

Và với ứng dụng quản lý nội dung, phần lớn lưu lượng là ĐỌC — nên lợi ích rất lớn.

aws rds create-db-cluster --db-cluster-identifier cum-eu   --engine aurora-mysql --region eu-west-1   --replication-source-identifier arn:aws:rds:us-east-1:123456789012:cluster:cum-chinh

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

• **E. Fleet EC2 ở eu-west-1 với geolocation routing policy — đây là phương án gần nhất và cũng đưa người dùng châu Âu tới Region châu Âu, nhưng nó kém tối ưu hơn latency routing: geolocation định tuyến theo biên giới hành chính, không theo độ trễ thật. Người dùng ở Iceland có thể được gửi tới eu-west-1 dù us-east-1 gần hơn về mặt mạng. Geolocation dùng cho tuân thủ và bản quyền, không phải tối ưu hiệu năng.
• **A. Fleet EC2 ở eu-west-1 với failover routing policy — sai mục đích: failover chuyển lưu lượng sang endpoint dự phòng khi endpoint chính hỏng. Ở trạng thái bình thường, toàn bộ người dùng vẫn tới us-east-1.
• **C. Tạo Aurora Multi-AZ standby ở eu-west-1 — sai về mặt kỹ thuật: Multi-AZ hoạt động trong một Region, không trải Region. Và standby của Multi-AZ không phục vụ đọc.

Ghi nhớ

Bảy loại routing policy của Route 53 — bảng phải thuộc: | Policy | Định tuyến theo | Dùng cho | |---|---|---| | Simple | không điều kiện | một endpoint | | Weighted | tỷ lệ phần trăm | thử nghiệm A/B, triển khai dần | | Latency-based | độ trễ mạng THẬT | tối ưu hiệu năng ← câu này | | Failover | sức khoẻ endpoint | khôi phục thảm hoạ | | Geolocation | vị trí người dùng | tuân thủ, bản quyền, ngôn ngữ | | Geoproximity | khoảng cách tới tài nguyên + bias | cân bằng tải theo vùng | | Multivalue answer | tới 8 bản ghi khoẻ mạnh | cân bằng đơn giản |

Latency và Geolocation — phân biệt rõ: | | Latency-based | Geolocation | |---|---|---| | Dựa trên | độ trễ mạng đo được | biên giới hành chính | | Mục đích | hiệu năng | tuân thủ, nội dung theo vùng | | Cần bản ghi mặc định | không bắt buộc | BẮT BUỘC |

Từ khoá nhận diện:

"reduce latency", "improve performance", "closest Region" → latency-based "comply with regulations", "block a country", "language" → geolocation

Ba lựa chọn Aurora cho nhiều Region: | Lựa chọn | Đặc điểm | |---|---| | Cross-Region read replica | replica đọc ở Region khác, promote được ← câu này | | Aurora Global Database | độ trễ sao chép DƯỚI 1 GIÂY, RTO dưới 1 phút | | Snapshot copy | thủ công, cho sao lưu |

Aurora Global Database là lựa chọn mạnh hơn: | | Cross-Region replica | Global Database | |---|---|---| | Độ trễ sao chép | giây | thường dưới 1 giây | | Số Region phụ | 1 (với Aurora MySQL) | tới 5 | | Chuyển vùng | promote thủ công | quản lý, RTO dưới 1 phút | | Ảnh hưởng tới primary | có | KHÔNG — sao chép ở tầng lưu trữ | | Write forwarding | ❌ | ✅ ghi từ Region phụ được chuyển tiếp |

Với ứng dụng toàn cầu nghiêm túc, Global Database là lựa chọn đúng. (Đề chỉ nêu read replica, và đó vẫn là đáp án phù hợp với các phương án cho sẵn.)

Ba lưu ý về read replica xuyên Region: | Lưu ý | Chi tiết | |---|---| | CHỈ ĐỌC — không ghi được | ứng dụng phải tách đường ghi | | Có độ trễ sao chép | không dùng cho đọc-sau-ghi | | Tốn phí truyền dữ liệu xuyên Region | ~0,02 USD/GB |

Và ứng dụng phải biết dùng endpoint nào:

# Đọc → replica ở Region gần nhất
ket_noi_doc = connect(host=os.environ['DB_READER_ENDPOINT'])
# Ghi → luôn về primary ở us-east-1
ket_noi_ghi = connect(host=os.environ['DB_WRITER_ENDPOINT'])

Ba cách giảm độ trễ cho người dùng ở xa: | Cách | Giải quyết | |---|---| | CloudFront | nội dung tĩnh — cách rẻ và nhanh nhất | | Fleet ở Region gần + latency routing | nội dung động ← câu này | | Read replica xuyên Region | truy vấn database ← câu này |

CloudFront đáng làm TRƯỚC TIÊN:

Ứng dụng quản lý nội dung:
    → phần lớn tải trang là ảnh, CSS, JS
    → đưa lên CloudFront: cải thiện ngay, chi phí thấp
    → thường giải quyết được phần lớn vấn đề
        ↓
    Dựng Region thứ hai là bước sau, tốn kém hơn nhiều

Ba chi phí của kiến trúc nhiều Region: | Khoản | Chi tiết | |---|---| | Nhân đôi tầng web | EC2, ALB ở Region thứ hai | | Read replica | instance database thêm | | Truyền dữ liệu xuyên Region | ~0,02 USD/GB |

Ba lưu ý khi vận hành nhiều Region: | Lưu ý | Chi tiết | |---|---| | Triển khai mã đồng bộ ở cả hai Region | tránh lệch phiên bản | | Trạng thái phiên phải dùng chung hoặc theo Region | DynamoDB Global Tables | | Giám sát riêng từng Region | dashboard theo Region |

Và health check của Route 53 nên bật cho latency routing:

aws route53 create-health-check --caller-reference $(uuidgen)   --health-check-config '{"FullyQualifiedDomainName":"eu.congty.com",
    "Port":443,"Type":"HTTPS","ResourcePath":"/health"}'

Không có health check thì Route 53 vẫn gửi người dùng tới Region đã hỏng — vì nó chỉ biết độ trễ, không biết tình trạng.

Và một lời khuyên về thứ tự thực hiện: hãy bật CloudFront trước, đo lại, rồi mới quyết định có cần Region thứ hai không. Với ứng dụng quản lý nội dung, tỷ lệ tài nguyên tĩnh thường rất cao, và một distribution CloudFront có thể cải thiện thời gian tải nhiều hơn cả một fleet EC2 ở châu Âu — với chi phí và độ phức tạp thấp hơn hẳn.

Đáp án

C — Cấu hình S3 Access Point riêng cho mỗi dịch vụ phân tích, gắn access point policy giới hạn truy cập vào đúng prefix của dịch vụ đó.

Vì sao đúng

Đề nêu ba yêu cầu, và S3 Access Points được thiết kế đúng cho bài toán này: | Yêu cầu | Cơ chế | |---|---| | Mỗi dịch vụ chỉ truy cập prefix của mình | access point policy giới hạn theo prefix | | Mở rộng và dễ bảo trì | mỗi dịch vụ một access point độc lập | | Ít công vận hành | không phải sửa một bucket policy khổng lồ |

Vấn đề mà Access Points giải quyết:

Không có access point:
    MỘT bucket policy chứa quy tắc cho MỌI dịch vụ
    → thêm dịch vụ = sửa chính sách chung
    → chính sách phình to, khó đọc, dễ sai
    → và có GIỚI HẠN 20 KB cho bucket policy
        ↓
    Với hàng chục dịch vụ, đây là nút thắt thật sự

Có access point:

Mỗi dịch vụ có ENDPOINT RIÊNG với chính sách RIÊNG
    → thêm dịch vụ = tạo access point mới
    → không đụng tới chính sách của dịch vụ khác
    → mỗi chính sách nhỏ, dễ đọc, dễ kiểm toán

Tạo access point và gắn chính sách:

aws s3control create-access-point --account-id 123456789012   --name ap-phan-tich-ban-hang --bucket kho-log-trung-tam

aws s3control put-access-point-policy --account-id 123456789012   --name ap-phan-tich-ban-hang --policy '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/vai-tro-ban-hang"},
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:ap-northeast-1:123456789012:accesspoint/ap-phan-tich-ban-hang/object/ban-hang/*"}]}'

Và ứng dụng dùng ARN của access point thay vì tên bucket:

aws s3api get-object   --bucket arn:aws:s3:ap-northeast-1:123456789012:accesspoint/ap-phan-tich-ban-hang   --key ban-hang/2026-08-30.json ket-qua.json

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

• **D. Một bucket policy DUY NHẤT liệt kê ARN của mọi object theo từng prefix — đây là phương án gần nhất và về nguyên tắc là làm được, nhưng nó không mở rộng được: bucket policy có giới hạn 20 KB, và mọi thay đổi đều phải sửa chính sách chung — rủi ro làm hỏng quyền của dịch vụ khác. Đề yêu cầu "scalable and maintainable".
• **A. Tạo IAM user riêng cho từng dịch vụ với inline policy tham chiếu TÊN OBJECT cụ thể — hai lỗi: IAM user với access key dài hạn là thực hành kém (nên dùng role), và liệt kê tên từng object là bất khả thi với dữ liệu sinh ra liên tục.
• **B. Dùng Amazon Macie phân loại object và áp chính sách theo thẻ — sai chức năng dịch vụ: Macie phát hiện dữ liệu nhạy cảm (PII, PHI), nó không phải công cụ kiểm soát truy cập và không áp chính sách nào.

Ghi nhớ

Ba đặc điểm của S3 Access Points: | Đặc điểm | Chi tiết | |---|---| | Mỗi access point có TÊN DNS và chính sách RIÊNG | | | Không giới hạn 20 KB như bucket policy | mỗi chính sách tính riêng | | Tạo được tới 10.000 access point mỗi bucket | mở rộng thoải mái |

Ba cấu hình của access point: | Cấu hình | Việc | |---|---| | NetworkOrigin | Internet hoặc VPC — giới hạn chỉ gọi từ VPC | | PublicAccessBlockConfiguration | chặn truy cập công khai | | Access point policy | quyền cụ thể |

NetworkOrigin: VPC là tính năng bảo mật mạnh:

aws s3control create-access-point --account-id 123456789012   --name ap-noi-bo --bucket kho-log-trung-tam   --vpc-configuration VpcId=vpc-0abc123

Access point kiểu VPC:
    → CHỈ gọi được từ VPC đó qua VPC endpoint
    → không có endpoint công khai

Ba loại access point của S3: | Loại | Việc | |---|---| | S3 Access Point | kiểm soát truy cập theo prefix ← câu này | | Object Lambda Access Point | BIẾN ĐỔI dữ liệu khi đọc (che PII, đổi định dạng) | | Multi-Region Access Point | định tuyến tới bucket ở Region gần nhất |

Object Lambda Access Point rất thú vị:

Cùng một object trong S3:
    Đội A đọc qua access point thường  → dữ liệu đầy đủ
    Đội B đọc qua Object Lambda AP     → PII đã bị che
        ↓
    Không cần lưu hai bản dữ liệu

Điều kiện quan trọng: bucket policy phải UỶ QUYỀN cho access point.

{"Effect": "Allow",
 "Principal": {"AWS": "*"},
 "Action": "*",
 "Resource": ["arn:aws:s3:::kho-log-trung-tam",
              "arn:aws:s3:::kho-log-trung-tam/*"],
 "Condition": {"StringEquals":
   {"s3:DataAccessPointAccount": "123456789012"}}}

Thiếu statement này thì access point không hoạt động — quyền hiệu lực là giao của bucket policy và access point policy.

Ba cách phân quyền theo prefix — bảng so sánh: | Cách | Mở rộng | Bảo trì | |---|---|---| | Access Point | ✅ rất tốt | ✅ mỗi dịch vụ độc lập | | IAM policy với prefix | tốt | phải sửa chính sách của từng principal | | Bucket policy chung | ❌ giới hạn 20 KB | ❌ một chính sách khổng lồ |

Và IAM policy với prefix vẫn là cách phổ biến cho quy mô nhỏ:

{"Effect": "Allow", "Action": "s3:ListBucket",
 "Resource": "arn:aws:s3:::kho-log-trung-tam",
 "Condition": {"StringLike": {"s3:prefix": ["ban-hang/*"]}}},
{"Effect": "Allow", "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::kho-log-trung-tam/ban-hang/*"}

Nhớ tách hai statement theo loại ARN — ListBucket áp cho bucket, GetObject áp cho object.

Ba lưu ý về access point: | Lưu ý | Chi tiết | |---|---| | Tên phải duy nhất trong TÀI KHOẢN và REGION | | | Không dùng được với S3 static website | | | Một số thao tác cấp bucket không qua access point được | ví dụ PutBucketPolicy |

Ba biện pháp bổ sung cho data lake: | Biện pháp | Chi tiết | |---|---| | Bật CloudTrail data event | ghi mọi thao tác object-level | | S3 Storage Lens | phân bố dung lượng theo prefix | | Lifecycle rule theo prefix | mỗi dịch vụ một chính sách lưu trữ |

Và IAM Access Analyzer kiểm tra cấu hình:

aws accessanalyzer create-analyzer --analyzer-name phan-tich --type ACCOUNT

Nó phát hiện access point hoặc bucket đang cho phép truy cập rộng hơn dự định.

Ba cách tổ chức prefix cho data lake: | Cách | Ví dụ | |---|---| | Theo dịch vụ | ban-hang/, ton-kho/, luot-xem/ ← câu này | | Theo ngày (Hive partition) | nam=2026/thang=08/ngay=30/ | | Kết hợp | ban-hang/nam=2026/thang=08/ |

Cách kết hợp là tốt nhất — vừa phân quyền theo dịch vụ, vừa cho Athena và Glue quét ít dữ liệu hơn.

Và một lời khuyên: hãy đặt tên access point trùng với tên prefix (ap-ban-hang cho ban-hang/). Khi có hàng chục dịch vụ, việc đối chiếu access point nào phục vụ prefix nào trở thành công việc thường xuyên — và một quy ước đặt tên nhất quán tiết kiệm rất nhiều thời gian tra cứu.

Đáp án

A — Cấp phát Amazon FSx for Windows File Server, mount bằng giao thức SMB trên các máy chủ truyền thông.

Vì sao đúng

Đề nêu ba yêu cầu, và FSx for Windows đáp ứng cả ba với ít công nhất: | Yêu cầu | Cơ chế | |---|---| | Chia sẻ tệp qua giao thức SMB | FSx for Windows phục vụ SMB nguyên bản | | Được quản lý, dễ dựng | AWS lo phần cứng, vá lỗi, sao lưu | | Ít công vận hành nhất | không có máy chủ tệp nào để bảo trì |

FSx for Windows là Windows Server thật do AWS quản lý:

FSx for Windows File Server:
    ✓ giao thức SMB (2.0 đến 3.1.1)
    ✓ tích hợp Active Directory
    ✓ ACL của NTFS, shadow copy, quota
    ✓ AWS lo: vá lỗi, sao lưu tự động, chuyển đổi Multi-AZ

Và việc dựng chỉ là một lệnh:

aws fsx create-file-system --file-system-type WINDOWS   --storage-capacity 2048 --storage-type SSD   --subnet-ids subnet-a subnet-b --security-group-ids sg-fsx   --windows-configuration '{
    "ActiveDirectoryId": "d-1234567890",
    "ThroughputCapacity": 512,
    "DeploymentType": "MULTI_AZ_1",
    "AutomaticBackupRetentionDays": 30}'

Client mount như ổ mạng bình thường:

net use Z: \\amznfsxabc123.congty.local\share

Và với công việc dựng phim, hiệu năng là yếu tố quan trọng: | Cấu hình | Chi tiết | |---|---| | Lưu trữ SSD | cho công việc dựng phim cần I/O cao | | Thông lượng tới 12 GB/giây | tuỳ mức cấp phát | | Data deduplication | tiết kiệm 50–60% với tệp truyền thông trùng lặp |

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

• **C. Dựng Storage Gateway Volume Gateway ở chế độ cached, gắn qua iSCSI rồi tạo hệ thống tệp có bật SMB — đây là phương án gần nhất vì cuối cùng cũng phục vụ được SMB, nhưng nó vòng vo và nhiều công hơn hẳn: Volume Gateway cung cấp thiết bị KHỐI qua iSCSI, bạn phải tự dựng một máy chủ Windows lên trên nó để phơi SMB — thêm một máy phải quản lý mà FSx đã làm sẵn.
• **D. Chạy EC2 Windows và tự cấu hình file share — nhiều công nhất: bạn lo vá lỗi hệ điều hành, sao lưu, sẵn sàng cao, và mở rộng dung lượng. Đúng thứ mà đề muốn tránh.
• **B. Dùng S3 với Transfer Acceleration và signed URL qua HTTPS — sai giao thức: S3 là kho object qua HTTP, không nói SMB. Công cụ dựng phim cần mount ổ đĩa, không gọi API.

Ghi nhớ

Chọn dịch vụ lưu trữ theo giao thức — bảng phải thuộc: | Giao thức | Dịch vụ | |---|---| | SMB (Windows) | FSx for Windows File Server ← câu này | | NFS (Linux) | Amazon EFS | | Lustre (HPC) | FSx for Lustre | | NFS + SMB + iSCSI | FSx for NetApp ONTAP | | NFS (ZFS) | FSx for OpenZFS | | iSCSI (khối) | EBS, Volume Gateway | | HTTP (object) | S3 |

Từ khoá nhận diện:

"SMB", "Windows", "Active Directory", "DFS" → FSx for Windows "NFS", "Linux", "auto-scaling" → EFS "HPC", "parallel", "ML training" → FSx for Lustre "multi-protocol", "NetApp" → FSx for ONTAP

Ba tính năng của FSx for Windows đáng biết: | Tính năng | Chi tiết | |---|---| | Data deduplication | tiết kiệm 50–60% với dữ liệu doanh nghiệp | | Shadow Copy | người dùng tự khôi phục phiên bản cũ của tệp | | User quota | giới hạn dung lượng theo người dùng | | DFS Namespaces và Replication | gộp nhiều file system |

Shadow Copy rất phù hợp với studio truyền thông:

Biên tập viên ghi đè nhầm một bản dựng
    → chuột phải → Previous Versions → khôi phục
    → không cần mở phiếu hỗ trợ

Hai kiểu triển khai: | Kiểu | Đặc điểm | |---|---| | Single-AZ | rẻ hơn, không chịu được mất AZ | | Multi-AZ | standby ở AZ khác, tự chuyển đổi — cho sản xuất |

Ba lựa chọn lưu trữ: | Loại | Phù hợp | |---|---| | SSD | dựng phim, database, độ trễ thấp ← câu này | | HDD | lưu trữ dung lượng lớn, truy cập thưa | | SSD cache trên HDD | cân bằng |

Và thông lượng khai riêng với dung lượng:

ThroughputCapacity: 8 đến 2.048 MB/giây (hoặc cao hơn với thế hệ mới)
    → đổi được sau khi tạo, không gián đoạn

Ba yêu cầu để triển khai: | Yêu cầu | Chi tiết | |---|---| | Active Directory | AWS Managed AD hoặc AD tự quản | | Hai subnet nếu Multi-AZ | | | Security group mở cổng SMB (445) và cổng AD | |

Ba cách di chuyển dữ liệu lên FSx: | Cách | Đặc điểm | |---|---| | AWS DataSync | nhanh, GIỮ ACL và metadata NTFS | | Robocopy | thủ công, khối lượng nhỏ | | Snow Family | hàng chục TB, băng thông kém |

DataSync giữ được ACL là điểm quan trọng — công cụ sao chép thường sẽ làm mất toàn bộ phân quyền NTFS.

Ba lưu ý về hiệu năng cho công việc dựng phim: | Lưu ý | Chi tiết | |---|---| | Chọn SSD, không dùng HDD | dựng phim cần IOPS cao | | Cấp đủ thông lượng | tệp video rất lớn | | Đặt máy trạm cùng AZ với file system | giảm độ trễ và phí chéo AZ |

Và FSx File Gateway cho truy cập từ tại chỗ:

Biên tập viên ở studio tại chỗ:
    → FSx File Gateway cache dữ liệu nóng ở địa phương
    → độ trễ như ổ mạng nội bộ
    → dữ liệu chính vẫn ở FSx trên AWS

Ba lựa chọn cho dữ liệu truyền thông theo vòng đời: | Giai đoạn | Lưu trữ | |---|---| | Đang dựng (nóng) | FSx for Windows SSD ← câu này | | Đã hoàn thành, còn tham chiếu | S3 Standard hoặc Standard-IA | | Lưu trữ dài hạn | S3 Glacier Deep Archive |

Và DataSync chuyển dữ liệu giữa FSx và S3 theo lịch:

aws datasync create-task --source-location-arn <fsx>   --destination-location-arn <s3>   --schedule ScheduleExpression="cron(0 2 * * ? *)"

Đây là cách kiểm soát chi phí cho studio — FSx đắt hơn S3 nhiều lần, nên chỉ giữ dự án đang làm.

Ba lưu ý về chi phí FSx: | Lưu ý | Chi tiết | |---|---| | Tính theo dung lượng CẤP PHÁT | không phải dung lượng dùng | | Thông lượng tính riêng | ảnh hưởng giá đáng kể | | Bật deduplication | giảm dung lượng thật cần cấp |

Và một lời khuyên: hãy bật data deduplication ngay sau khi tạo file system. Với dữ liệu dựng phim — nhiều bản render của cùng cảnh quay, nhiều bản sao của cùng tài nguyên — tỷ lệ trùng lặp thường rất cao, và nó chuyển thẳng thành khoản giảm dung lượng phải cấp phát và trả tiền.

Đáp án

B — Triển khai EC2 tầng web ở HAI Availability Zone sau Elastic Load Balancer; triển khai RDS MySQL ở cấu hình Multi-AZ.

Vì sao đúng

Đề nêu hai dữ kiện quyết định:

① "improve application AVAILABILITY"          → cần sẵn sàng cao
② "all end users would be located in the US"   → không cần nhiều Region

Và "resource-efficient" nghĩa là dùng đúng mức, không thừa: | Tầng | Giải pháp | Lý do | |---|---|---| | Web | hai AZ + ELB | chịu được mất một AZ | | Database | RDS Multi-AZ | tự chuyển đổi, không mất dữ liệu |

Vì sao nhiều AZ đủ mà không cần nhiều Region:

Availability Zone:
    → là các trung tâm dữ liệu CÁCH LY về điện, làm mát, mạng
    → cách nhau đủ xa để không cùng hỏng
    → nhưng đủ gần để độ trễ dưới 2ms
        ↓
    Với người dùng đều ở Mỹ, một Region với nhiều AZ là đủ

Và triển khai nhiều Region gây ra chi phí và độ phức tạp không cần thiết:

Nhiều Region:
    ✗ ELB KHÔNG hoạt động xuyên Region (cần Route 53 hoặc Global Accelerator)
    ✗ phí truyền dữ liệu xuyên Region
    ✗ đồng bộ dữ liệu phức tạp
    ✗ triển khai và giám sát hai nơi

RDS Multi-AZ là lựa chọn đúng cho tầng database:

Multi-AZ:
    → standby ở AZ khác, sao chép ĐỒNG BỘ
    → tự chuyển đổi khi primary hỏng (60–120 giây)
    → RPO = 0, không mất giao dịch nào

aws rds modify-db-instance --db-instance-identifier db-chuoi-cung-ung   --multi-az --apply-immediately

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

• **D. Hai AZ sau ELB, nhưng database dùng read replica thay vì Multi-AZ — đây là phương án gần nhất vì vế tầng web hoàn toàn đúng, nhưng vế database sai mục đích: read replica dùng để mở rộng ĐỌC, không phải cơ chế sẵn sàng cao. Nó sao chép bất đồng bộ (có thể mất dữ liệu) và promote thủ công (không tự chuyển đổi).
• **C. Hai REGION sau ELB, database Multi-AZ — sai về mặt kỹ thuật và lãng phí: ELB không phân phối lưu lượng xuyên Region. Và người dùng đều ở Mỹ nên Region thứ hai không mang lại lợi ích gì.
• **A. Hai Region sau ELB, database read replica — kết hợp cả hai lỗi trên.

Ghi nhớ

Multi-AZ và Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | SẴN SÀNG CAO | MỞ RỘNG ĐỌC | | Sao chép | đồng bộ | bất đồng bộ | | Chuyển đổi | TỰ ĐỘNG | thủ công (promote) | | Standby phục vụ đọc | ❌ (Multi-AZ instance) | ✅ | | Mất dữ liệu khi chuyển đổi | KHÔNG (RPO = 0) | có thể | | Phạm vi | cùng Region | cùng hoặc khác Region |

Từ khoá nhận diện:

"high availability", "automatic failover", "no data loss" → Multi-AZ "scale reads", "reporting queries", "reduce load on primary" → Read replica "disaster recovery across Regions" → Cross-Region read replica

Và hai thứ này KẾT HỢP được:

Multi-AZ (sẵn sàng) + Read replica (mở rộng đọc)
    → cấu hình phổ biến cho ứng dụng sản xuất

Ba kiểu triển khai của RDS: | Kiểu | Đặc điểm | |---|---| | Single-AZ | một instance, chỉ cho dev | | Multi-AZ instance | 1 standby, KHÔNG phục vụ đọc | | Multi-AZ DB cluster | 2 standby CÓ phục vụ đọc, chuyển đổi dưới 35 giây |

Multi-AZ DB cluster là lựa chọn mới đáng cân nhắc — nó cho cả sẵn sàng cao lẫn khả năng đọc từ standby.

Ba tình huống kích hoạt chuyển đổi Multi-AZ: | Tình huống | Chi tiết | |---|---| | Primary hỏng | phần cứng hoặc phần mềm | | AZ mất kết nối | | | Bảo trì có kế hoạch | vá lỗi, đổi cỡ instance |

Và chuyển đổi diễn ra qua DNS:

Endpoint KHÔNG ĐỔI
    → RDS trỏ bản ghi DNS sang standby
    → ứng dụng chỉ cần KẾT NỐI LẠI
        ↓
    ⚠ Java cache DNS vĩnh viễn theo mặc định
    → đặt networkaddress.cache.ttl = 60

Ba phạm vi kiến trúc — chọn đúng mức: | Phạm vi | Chống được | Chi phí | |---|---|---| | Một AZ | không gì | thấp nhất | | Nhiều AZ trong một Region | mất một AZ | trung bình ← câu này | | Nhiều Region | mất cả Region | cao nhất |

Quy tắc: nhiều AZ là mặc định cho sản xuất; nhiều Region chỉ khi có yêu cầu cụ thể (người dùng toàn cầu, hoặc RTO/RPO rất chặt cho thảm hoạ cấp Region).

Ba thành phần của kiến trúc web sẵn sàng cao: | Thành phần | Vai trò | |---|---| | Load balancer | phân phối và kiểm tra sức khoẻ | | Auto Scaling group | thay máy hỏng, co giãn theo tải | | Nhiều AZ | chịu lỗi hạ tầng |

Lưu ý: đề chỉ nêu ELB, nhưng nên có ASG. Không có ASG thì máy hỏng nằm đó không được thay, và hệ thống chỉ "sẵn sàng cao" cho tới lần hỏng thứ hai.

Ba cấu hình ASG quan trọng: | Cấu hình | Giá trị nên dùng | |---|---| | HealthCheckType = ELB | thay máy mà ứng dụng hỏng | | Nhiều subnet ở nhiều AZ | phân bố đều | | MinSize đủ chịu tải khi mất một AZ | |

Ba lưu ý về chi phí Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Giá gấp ĐÔI Single-AZ | trả cho cả standby | | Standby không phục vụ đọc | không tận dụng được | | Vẫn rẻ hơn thời gian ngừng | với ứng dụng sản xuất |

Và Aurora là lựa chọn thay thế đáng cân nhắc: | | RDS Multi-AZ | Aurora | |---|---|---| | Số bản sao dữ liệu | 2 | 6 bản qua 3 AZ | | Chuyển đổi | 60–120 giây | thường dưới 30 giây | | Replica phục vụ đọc | ❌ | ✅ tới 15 | | Tương thích MySQL | ✅ | ✅ |

Aurora thường cho hiệu năng cao hơn với giá tương đương — đáng cân nhắc khi đang ở giai đoạn thiết kế như trong đề.

Ba việc cần làm trước khi go-live: | Việc | Chi tiết | |---|---| | Thử chuyển đổi thật | reboot --force-failover | | Kiểm tra ứng dụng xử lý được lỗi kết nối tạm thời | | | Đặt alarm cho các metric chính | CPU, kết nối, độ trễ |

Và một lời khuyên: hãy thử chuyển đổi RDS trước khi go-live, không phải sau. Nó cho biết ứng dụng mất bao lâu để kết nối lại và có xử lý được ngoại lệ kết nối hay không — hai điều mà chỉ chạy thật mới trả lời được, và phát hiện chúng vào lúc sự cố thật là quá muộn.

Đáp án

A và C.

• A — Mặc định, script trong user data được thực thi với quyền root
• C — Mặc định, user data chỉ chạy trong chu kỳ khởi động ĐẦU TIÊN khi bạn tạo instance

Vì sao đúng

Hai đáp án là hai đặc điểm căn bản của user data:

A — chạy với quyền root:

User data được thực thi bởi cloud-init (Linux) hoặc EC2Launch (Windows)
    → tiến trình này chạy với quyền cao nhất
    → script của bạn chạy với quyền ROOT (Linux) hoặc SYSTEM (Windows)
        ↓
    KHÔNG cần `sudo` trong script

#!/bin/bash
yum update -y                    # chạy được, không cần sudo
yum install -y httpd
systemctl enable --now httpd

C — chỉ chạy ở lần khởi động ĐẦU TIÊN:

Vòng đời mặc định:
    Tạo instance (launch)     → user data CHẠY
    Reboot                    → KHÔNG chạy
    Stop rồi Start            → KHÔNG chạy
        ↓
    cloud-init ghi lại đã chạy rồi và bỏ qua ở lần sau

Và có thể đổi hành vi này nếu cần:

#!/bin/bash
# Dòng này khiến user data chạy MỖI LẦN khởi động
echo 'Content-Type: text/cloud-boothook' > /dev/null

Hoặc với cloud-config:

#cloud-config
cloud_final_modules:
  - [scripts-user, always]

Ba lưu ý bổ sung: | Lưu ý | Chi tiết | |---|---| | Script Linux phải bắt đầu bằng #! | không có thì không chạy | | Kích thước tối đa 16 KB | trước khi mã hoá base64 | | Chạy ở giai đoạn CUỐI của quá trình khởi động | sau khi mạng đã sẵn sàng |

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

• **D. Mặc định, user data được thực thi MỖI LẦN instance khởi động lại — đây là phương án gần nhất và là bẫy chính: nghe rất hợp lý, nhưng mặc định là chỉ lần đầu. Đổi được, nhưng phải cấu hình thêm.
• **B. Khi instance đang chạy, bạn cập nhật user data bằng thông tin đăng nhập root — sai về mặt kỹ thuật: muốn sửa user data thì phải DỪNG instance trước, và điều đó cần quyền IAM (ec2:ModifyInstanceAttribute), không liên quan tới tài khoản root của hệ điều hành hay của AWS.
• **E. Mặc định script KHÔNG có quyền root — sai, ngược lại với A.

Ghi nhớ

User data và Metadata — bảng phân biệt: | | User data | Instance metadata | |---|---|---| | Việc | script chạy lúc khởi động | thông tin VỀ instance | | Endpoint | .../latest/user-data | .../latest/meta-data/ | | Sửa được | ✅ (phải stop trước) | ❌ chỉ đọc | | Ví dụ | cài phần mềm, cấu hình | instance-id, IP, IAM role |

Truy cập cả hai qua địa chỉ 169.254.169.254 (IMDSv2):

TOKEN=$(curl -sX PUT "http://169.254.169.254/latest/api/token"   -H "X-aws-ec2-metadata-token-ttl-seconds: 300")

curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/meta-data/instance-id

curl -s -H "X-aws-ec2-metadata-token: $TOKEN"   http://169.254.169.254/latest/user-data

IMDSv1 và IMDSv2 — điểm quan trọng về bảo mật: | | IMDSv1 | IMDSv2 | |---|---|---| | Cách gọi | GET đơn giản | PUT lấy token rồi mới GET | | Chống SSRF | ❌ dễ bị khai thác | ✅ | | Khuyến nghị | không dùng | bắt buộc dùng |

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

hop-limit 1 ngăn container trong Pod gọi tới metadata — biện pháp bảo mật quan trọng với EKS và ECS.

Ba nơi đặt user data: | Nơi | Chi tiết | |---|---| | Khi chạy instance | --user-data file://script.sh | | Trong launch template | áp cho mọi máy do ASG tạo | | Sửa sau | phải STOP instance trước |

aws ec2 stop-instances --instance-ids i-0abc
aws ec2 modify-instance-attribute --instance-id i-0abc   --user-data file://script-moi.txt
aws ec2 start-instances --instance-ids i-0abc

Ba nơi xem log của user data: | Hệ điều hành | Đường dẫn | |---|---| | Amazon Linux 2023, Ubuntu | /var/log/cloud-init-output.log | | Amazon Linux 2 | /var/log/cloud-init-output.log | | Windows | C:\ProgramData\Amazon\EC2Launch\log\ |

Đây là nơi đầu tiên phải xem khi user data không chạy như mong đợi.

Ba lỗi thường gặp với user data: | Lỗi | Nguyên nhân | |---|---| | Script không chạy gì | thiếu dòng #!/bin/bash ở đầu | | Chạy nhưng thất bại im lặng | không có set -e, lỗi bị bỏ qua | | Chạy trước khi dịch vụ sẵn sàng | thiếu chờ đợi hoặc thử lại |

Mẫu script an toàn:

#!/bin/bash
set -euxo pipefail
exec > >(tee /var/log/khoi-tao.log) 2>&1

yum update -y
yum install -y httpd amazon-cloudwatch-agent
systemctl enable --now httpd

# Báo cho ASG biết đã sẵn sàng
/opt/aws/bin/cfn-signal -e $? --stack ... --resource ... --region ...

Ba lưu ý về bảo mật user data: | Lưu ý | Chi tiết | |---|---| | KHÔNG đặt bí mật trong user data | ai có quyền DescribeInstanceAttribute đều đọc được | | Dùng Secrets Manager hoặc Parameter Store | | | Không ghi mật khẩu ra log | log cloud-init được giữ rất lâu |

Mẫu lấy bí mật đúng cách:

#!/bin/bash
MAT_KHAU=$(aws secretsmanager get-secret-value   --secret-id prod/db/password --query SecretString --output text)

Instance dùng IAM role để lấy — không có bí mật nào nằm trong user data.

Ba lựa chọn thay thế cho user data phức tạp: | Lựa chọn | Phù hợp | |---|---| | AMI dựng sẵn (EC2 Image Builder) | khởi động NHANH HƠN nhiều | | AWS Systems Manager State Manager | cấu hình liên tục, không chỉ lúc khởi động | | Ansible, Chef, Puppet | quản lý cấu hình đầy đủ |

AMI dựng sẵn là lựa chọn tốt nhất cho ASG:

User data cài phần mềm mỗi lần khởi động:
    → máy mới mất vài phút mới sẵn sàng
    → ASG phản ứng chậm với đỉnh tải

AMI đã có sẵn phần mềm:
    → user data chỉ làm cấu hình cuối
    → máy sẵn sàng trong vài chục giây

Và một lời khuyên: hãy giữ user data ngắn và chỉ làm phần cấu hình theo môi trường. Mọi thứ có thể nướng sẵn vào AMI thì nên nướng sẵn — nó vừa rút ngắn thời gian khởi động, vừa loại bỏ rủi ro user data thất bại vì một kho phần mềm bên ngoài tạm thời không truy cập được.

Đáp án

C — Chuyển ứng dụng lên EC2 trong Auto Scaling group sau Application Load Balancer; dùng Aurora Serverless v2 (MySQL) cho tầng database.

Vì sao đúng

Đề nêu năm yêu cầu, và đáp án thoả cả năm: | Yêu cầu | Cơ chế | |---|---| | TỰ CO GIÃN | ASG cho ứng dụng + Aurora Serverless v2 cho database | | Sẵn sàng cao | ASG qua nhiều AZ + Aurora lưu trữ 3 AZ | | TÁCH tầng ứng dụng và database | hai tầng riêng biệt | | Giữ engine tương thích MySQL | Aurora MySQL tương thích hoàn toàn | | Tiết kiệm, ít công vận hành | được quản lý, trả theo lượng dùng |

Vế "tự co giãn ở CẢ HAI tầng" là điểm phân biệt:

Tầng ứng dụng: Auto Scaling group
    → thêm bớt EC2 theo tải

Tầng database: Aurora Serverless v2
    → tự co giãn năng lực (ACU) theo tải, TỪNG GIÂY
    → từ 0,5 ACU tới 256 ACU
        ↓
    Cả hai tầng đều thích ứng — đúng yêu cầu của đề

Aurora Serverless v2 khác v1 rất nhiều: | | v1 (cũ) | v2 | |---|---|---| | Co giãn | nhảy bậc, có gián đoạn | mượt, từng giây, KHÔNG gián đoạn | | Multi-AZ | hạn chế | ✅ đầy đủ | | Read replica | ❌ | ✅ | | Global Database | ❌ | ✅ |

Cấu hình:

aws rds create-db-cluster --db-cluster-identifier cum-noi-dung   --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.05.2   --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=16

aws rds create-db-instance --db-instance-identifier writer-1   --db-cluster-identifier cum-noi-dung   --engine aurora-mysql --db-instance-class db.serverless

Và Aurora cho sẵn sàng cao dựng sẵn:

Tầng lưu trữ Aurora:
    → 6 bản sao dữ liệu qua 3 AZ
    → tự sửa chữa khi phát hiện hỏng
    → chuyển đổi thường dưới 30 giây

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

• **B. EC2 trong target group của ALB, RDS for MySQL Multi-AZ — đây là phương án gần nhất và hoàn toàn hoạt động được, nhưng nó thiếu vế tự co giãn: EC2 nằm trong target group nhưng không nói tới Auto Scaling group, nên số máy cố định. Và RDS Multi-AZ không tự co giãn năng lực tính toán — phải đổi cỡ instance bằng tay.
• **A. Container hoá lên ECS với EC2 launch type, dùng Amazon Neptune — sai loại database: Neptune là database ĐỒ THỊ, không tương thích MySQL và không chạy SQL quan hệ. Đề yêu cầu rõ "MySQL-compatible engine".
• **D. EC2 trong target group của NLB, dùng ElastiCache for Redis làm DATABASE với Redis Streams — sai kiến trúc: ElastiCache là bộ ĐỆM, không phải database bền vững. Và NLB không phù hợp cho ứng dụng web cần định tuyến theo nội dung.

Ghi nhớ

Ba lựa chọn database tương thích MySQL trên AWS: | Lựa chọn | Đặc điểm | |---|---| | RDS for MySQL | MySQL chuẩn, được quản lý | | Aurora MySQL (provisioned) | nhanh hơn tới 5 lần, lưu trữ 3 AZ | | Aurora Serverless v2 | Aurora + tự co giãn năng lực ← câu này |

Từ khoá nhận diện:

"auto-scaling database", "variable workload", "unpredictable" → Aurora Serverless v2 "steady load", "predictable" → Aurora provisioned hoặc RDS | "graph relationships" → Neptune "caching layer" → ElastiCache

Ba khái niệm của Aurora Serverless v2: | Khái niệm | Chi tiết | |---|---| | ACU (Aurora Capacity Unit) | khoảng 2 GiB bộ nhớ + CPU và mạng tương ứng | | MinCapacity | 0,5 ACU — không xuống 0 như v1 | | MaxCapacity | tới 256 ACU |

Lưu ý quan trọng: Serverless v2 KHÔNG dừng hẳn về 0.

v1: dừng hẳn khi không dùng (nhưng khởi động lại mất thời gian)
v2: tối thiểu 0,5 ACU, luôn sẵn sàng
    ↓
    v2 phù hợp cho sản xuất; v1 phù hợp cho dev dùng ngắt quãng

Ba lợi ích của Aurora so với RDS MySQL: | Lợi ích | Chi tiết | |---|---| | Hiệu năng cao hơn tới 5 lần | kiến trúc lưu trữ riêng | | 6 bản sao qua 3 AZ | thay vì 2 bản của Multi-AZ | | Tới 15 read replica, độ trễ dưới 100ms | thay vì 5 replica với độ trễ giây | | Tự mở rộng lưu trữ tới 128 TB | không phải cấp phát trước |

Ba thành phần của kiến trúc web co giãn: | Thành phần | Vai trò | |---|---| | ALB | phân phối theo nội dung, health check | | Auto Scaling group | thêm bớt máy theo tải | | Aurora | tầng dữ liệu tách biệt |

Cấu hình ASG cho ứng dụng web:

aws autoscaling put-scaling-policy   --auto-scaling-group-name asg-noi-dung   --policy-name giu-cpu-50 --policy-type TargetTrackingScaling   --estimated-instance-warmup 300   --target-tracking-configuration '{
    "TargetValue": 50.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"}}'

Ba lưu ý khi tách ứng dụng khỏi database: | Lưu ý | Chi tiết | |---|---| | Database vào PRIVATE subnet | không phơi ra Internet | | Security group tham chiếu SG của web | không dùng CIDR | | Thông tin đăng nhập trong Secrets Manager | không nhúng trong mã |

Và Secrets Manager tự xoay vòng mật khẩu database:

aws secretsmanager rotate-secret --secret-id prod/aurora/mat-khau   --rotation-lambda-arn <arn>   --rotation-rules AutomaticallyAfterDays=30

Ba lưu ý về tệp tải lên (video, ảnh): | Lưu ý | Chi tiết | |---|---| | KHÔNG lưu trên EBS của EC2 | máy khác không thấy, và mất khi máy bị thay | | Dùng S3 cho tệp tải lên | ← quan trọng với ứng dụng có video | | CloudFront trước S3 | phục vụ nhanh và rẻ hơn |

Đây là điều đề chưa nêu nhưng rất quan trọng: ứng dụng quản lý nội dung có video, và với ASG nhiều máy thì tệp phải nằm ở kho dùng chung.

Ba cách xử lý video trên AWS: | Cách | Việc | |---|---| | S3 + CloudFront | lưu và phân phối | | MediaConvert | chuyển mã sang nhiều độ phân giải | | MediaPackage | đóng gói cho phát trực tiếp |

Ba cách giảm tải cho database: | Cách | Đặc điểm | |---|---| | ElastiCache cho truy vấn lặp lại | giảm mạnh tải đọc | | Aurora read replica | mở rộng đọc | | Tối ưu truy vấn và index | thường hiệu quả nhất |

Ba lưu ý về chi phí Aurora Serverless v2: | Lưu ý | Chi tiết | |---|---| | Tính theo ACU-giờ | ~0,12 USD mỗi ACU-giờ | | Đặt MaxCapacity hợp lý | tránh chi phí bất ngờ | | Tối thiểu 0,5 ACU chạy liên tục | có chi phí nền |

Và so sánh với provisioned:

Tải rất biến động (ban ngày cao, ban đêm gần 0):
    → Serverless v2 tiết kiệm đáng kể

Tải ổn định 24/7:
    → provisioned + Reserved Instance rẻ hơn

Và một lời khuyên về lộ trình di chuyển: hãy dùng AWS DMS với CDC để chuyển dữ liệu từ MySQL tại chỗ sang Aurora. Nó cho phép chạy song song và đồng bộ liên tục, nên việc cắt chuyển chỉ mất vài phút thay vì một cửa sổ bảo trì dài — điều quan trọng với ứng dụng đang có lưu lượng tăng.

Đáp án

D — Gắn IAM role phù hợp vào instance profile của EC2 để instance truy cập S3 và DynamoDB.

Vì sao đúng

Đây là thực hành tốt nhất được AWS khuyến nghị, và lý do nằm ở loại thông tin đăng nhập.

Cách IAM role hoạt động với EC2:

Gắn IAM role qua instance profile
    ↓
EC2 tự lấy thông tin đăng nhập TẠM THỜI từ instance metadata
    ↓ SDK và CLI tự tìm thấy, không cần cấu hình gì
    ↓ tự động GIA HẠN trước khi hết hạn
        ↓
    KHÔNG có access key dài hạn nào tồn tại trên máy

Bốn lợi ích so với việc lưu access key: | Lợi ích | Chi tiết | |---|---| | Thông tin đăng nhập TẠM THỜI | tự hết hạn sau vài giờ | | Tự xoay vòng | không ai phải làm gì | | Không có gì để rò rỉ | không nằm trong mã, không trong tệp cấu hình | | Sửa quyền tức thì | đổi policy của role, có hiệu lực ngay |

Cấu hình:

aws iam create-role --role-name vai-tro-ung-dung-anh   --assume-role-policy-document '{"Version":"2012-10-17","Statement":[{
    "Effect":"Allow","Principal":{"Service":"ec2.amazonaws.com"},
    "Action":"sts:AssumeRole"}]}'

aws iam put-role-policy --role-name vai-tro-ung-dung-anh   --policy-name quyen-toi-thieu --policy-document '{
    "Version":"2012-10-17","Statement":[
      {"Effect":"Allow","Action":["s3:GetObject","s3:PutObject"],
       "Resource":"arn:aws:s3:::kho-anh/*"},
      {"Effect":"Allow","Action":["dynamodb:GetItem","dynamodb:UpdateItem","dynamodb:Query"],
       "Resource":"arn:aws:dynamodb:*:*:table/bang-xep-hang"}]}'

aws ec2 associate-iam-instance-profile --instance-id i-0abc   --iam-instance-profile Name=profile-ung-dung-anh

Và trong mã, không cần khai gì:

import boto3
s3 = boto3.client('s3')          # tự lấy thông tin đăng nhập từ metadata
ddb = boto3.resource('dynamodb')

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

• **B. Cấu hình AWS CLI trên EC2 bằng thông tin đăng nhập của một IAM user, ứng dụng gọi shell script — đây là phương án gần nhất vì nó ít nhất dùng IAM user thay vì mã hoá tự chế, nhưng nó vẫn để access key DÀI HẠN nằm trên máy: ai đọc được ~/.aws/credentials hoặc chụp được snapshot của volume đều lấy được. Và gọi CLI qua shell script từ ứng dụng là cách làm kém hiệu quả.
• **A. Mã hoá access key bằng thư viện tự viết rồi lưu trong thư mục bí mật, ứng dụng giải mã khi cần — an ninh qua che giấu: khoá giải mã cũng phải nằm trên máy, nên kẻ tấn công có quyền đọc tệp sẽ lấy được cả hai. Và thư viện mã hoá tự viết là nguồn lỗi bảo mật kinh điển.
• **C. Lưu access key trong tệp cấu hình trong mã nguồn ứng dụng — kém nhất: bí mật nằm trong kho mã nguồn, lan ra mọi bản sao, mọi máy lập trình viên, và mọi lịch sử git.

Ghi nhớ

Bốn cơ chế cấp quyền không cần access key — bảng phải thuộc: | Ngữ cảnh | Cơ chế | |---|---| | EC2 | instance profile (IAM role) ← câu này | | ECS | task role | | EKS | IRSA hoặc EKS Pod Identity | | Lambda | execution role | | Máy ngoài AWS | IAM Roles Anywhere | | CI/CD (GitHub Actions) | OIDC federation |

Ba nơi KHÔNG BAO GIỜ đặt access key:

❌ Trong mã nguồn hoặc kho git
❌ Trên EC2 instance
❌ Trong biến môi trường của container

Thứ tự SDK tìm thông tin đăng nhập:

① Tham số truyền vào code
② Biến môi trường (AWS_ACCESS_KEY_ID...)
③ Tệp ~/.aws/credentials
④ Container credentials (ECS task role)
⑤ Instance metadata (EC2 instance profile)  ← cách đúng

Nếu có access key ở tầng cao hơn, nó sẽ THẮNG instance role — đây là nguyên nhân của lỗi khó hiểu "gắn role rồi mà vẫn AccessDenied".

Ba lưu ý về instance profile: | Lưu ý | Chi tiết | |---|---| | Instance profile là VỎ BỌC của IAM role | console tự tạo khi bạn gắn role | | Gắn và đổi role được khi instance ĐANG CHẠY | không cần dừng máy | | Một instance chỉ có MỘT role | dùng chung cho mọi ứng dụng trên máy |

Dòng cuối là hạn chế đáng lưu ý: nếu một máy chạy nhiều ứng dụng cần quyền khác nhau, hãy tách ra nhiều máy hoặc dùng container với task role riêng.

Bảo vệ instance metadata — rất quan trọng:

aws ec2 modify-instance-metadata-options --instance-id i-0abc   --http-tokens required --http-put-response-hop-limit 1

Vì sao IMDSv2 quan trọng:

IMDSv1: GET đơn giản tới 169.254.169.254
    → lỗ hổng SSRF trong ứng dụng web
    → kẻ tấn công lừa máy chủ tự gọi metadata
    → LẤY ĐƯỢC thông tin đăng nhập của instance role
        ↓
IMDSv2: phải PUT lấy token trước
    → SSRF thông thường không thực hiện được PUT

Ba nguyên tắc cho IAM role của EC2: | Nguyên tắc | Chi tiết | |---|---| | Đặc quyền tối thiểu | chỉ hành động và tài nguyên thật sự cần | | Giới hạn tới tài nguyên cụ thể | arn:aws:s3:::kho-anh/*, không phải * | | Rà soát định kỳ bằng Access Advisor | gỡ quyền không dùng |

Và Access Advisor cho biết dịch vụ nào thực sự được dùng:

aws iam generate-service-last-accessed-details   --arn arn:aws:iam::123456789012:role/vai-tro-ung-dung-anh

Ba công cụ phát hiện bí mật bị lộ: | Công cụ | Việc | |---|---| | git-secrets, truffleHog | quét kho mã nguồn | | Amazon CodeGuru Security | phân tích mã | | GuardDuty | phát hiện access key bị dùng bất thường |

Finding của GuardDuty đáng chú ý:

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration
    → thông tin đăng nhập của EC2 role đang được dùng từ NGOÀI AWS
    → dấu hiệu rõ ràng của việc bị đánh cắp

Ba việc phải làm nếu access key bị lộ: | Việc | Thứ tự | |---|---| | Vô hiệu hoá key ngay | aws iam update-access-key --status Inactive | | Kiểm tra CloudTrail | xem đã bị dùng làm gì | | Xoá key và chuyển sang role | giải pháp căn bản |

Ba lưu ý về VPC endpoint cho S3 và DynamoDB: | Lưu ý | Chi tiết | |---|---| | Gateway endpoint cho cả hai là MIỄN PHÍ | nên luôn tạo | | Tránh phí NAT Gateway | ~0,045 USD/GB | | Lưu lượng không ra Internet | an toàn hơn |

Và một lời khuyên: hãy quét kho mã nguồn tìm access key cũ ngay cả sau khi đã chuyển sang IAM role. Khoá đã từng commit vào git vẫn nằm trong lịch sử mãi mãi, và kẻ tấn công quét GitHub tự động sẽ tìm thấy chúng — xoá khỏi nhánh hiện tại là chưa đủ, phải vô hiệu hoá chính khoá đó.

Đáp án

A — Thiết lập Service Control Policy (SCP) cấm thay đổi CloudTrail, và gắn nó vào các tài khoản của lập trình viên.

Vì sao đúng

Đề nêu một tình huống rất cụ thể: lập trình viên có quyền TÀI KHOẢN ROOT trong tài khoản của họ.

Tài khoản root:
    → toàn quyền tuyệt đối trong tài khoản đó
    → IAM policy KHÔNG giới hạn được root
        ↓
    Cần một cơ chế NẰM TRÊN cả tài khoản

Và SCP là cơ chế duy nhất làm được điều đó:

Service Control Policy:
    → áp ở cấp AWS Organizations
    → đặt TRẦN quyền cho CẢ TÀI KHOẢN
    → áp cho MỌI principal trong tài khoản, KỂ CẢ ROOT
        ↓
    Lập trình viên dù là root cũng không sửa được CloudTrail

SCP cấm thay đổi CloudTrail:

{"Version": "2012-10-17",
 "Statement": [{
   "Sid": "ChanSuaCloudTrail",
   "Effect": "Deny",
   "Action": [
     "cloudtrail:StopLogging",
     "cloudtrail:DeleteTrail",
     "cloudtrail:UpdateTrail",
     "cloudtrail:PutEventSelectors",
     "cloudtrail:RemoveTags"],
   "Resource": "*"}]}

aws organizations create-policy --name chan-sua-cloudtrail   --type SERVICE_CONTROL_POLICY --content file://scp.json

aws organizations attach-policy --policy-id p-abc123   --target-id ou-nhom-lap-trinh-vien

Và điểm đặc biệt quan trọng: SCP KHÔNG áp cho tài khoản QUẢN LÝ.

Tài khoản quản lý (management account) của Organization:
    → SCP KHÔNG có hiệu lực
    → nên đừng chạy tải công việc ở đó
        ↓
    Đặt tài khoản lập trình viên trong OU riêng
    và gắn SCP vào OU đó

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

• **B. Tạo trail mới từ TRONG tài khoản lập trình viên với tuỳ chọn organization trails — đây là phương án gần nhất và organization trail là khái niệm có thật, nhưng nó sai chỗ tạo: organization trail phải được tạo từ tài khoản quản lý. Và quan trọng hơn, nó không NGĂN được lập trình viên tắt hay sửa cấu hình — nó chỉ tạo ra trail, không bảo vệ trail.
• **C. Tạo IAM policy cấm thay đổi CloudTrail và gắn vào tài khoản ROOT — không làm được về mặt kỹ thuật: IAM policy không gắn được vào tài khoản root, và root vốn không bị IAM policy giới hạn.
• **D. Tạo service-linked role cho CloudTrail với điều kiện chỉ cho phép thay đổi từ ARN của tài khoản quản lý — hiểu sai cơ chế: service-linked role là role mà dịch vụ AWS dùng để hành động thay bạn, nó không phải công cụ kiểm soát quyền của người dùng.

Ghi nhớ

Bốn cơ chế giới hạn quyền trên AWS — bảng phải thuộc: | Cơ chế | Áp cho | Ảnh hưởng root | |---|---|---| | Identity policy | user, group, role | ❌ | | Permissions boundary | một user hoặc role | ❌ | | Service Control Policy (SCP) | CẢ TÀI KHOẢN hoặc OU | ✅ ← câu này | | Resource policy | tài nguyên | ✅ (với principal cụ thể) |

SCP là cơ chế DUY NHẤT giới hạn được tài khoản root — đây là điểm cần nhớ nhất.

Ba đặc điểm của SCP: | Đặc điểm | Chi tiết | |---|---| | KHÔNG cấp quyền, chỉ GIỚI HẠN | phải có identity policy cấp quyền song song | | KHÔNG áp cho tài khoản quản lý | đừng chạy tải công việc ở đó | | KHÔNG áp cho service-linked role | AWS cần chúng hoạt động |

Công thức quyền hiệu lực:

Quyền = SCP ∩ identity policy ∩ permissions boundary ∩ session policy
        và KHÔNG có explicit Deny nào ở bất kỳ tầng nào

Hai chiến lược viết SCP: | Chiến lược | Cách | |---|---| | Deny list (phổ biến) | giữ FullAWSAccess, thêm SCP Deny các hành động cấm | | Allow list | gỡ FullAWSAccess, chỉ liệt kê hành động cho phép |

Deny list dễ quản lý hơn nhiều — allow list phải liệt kê từng hành động và rất dễ chặn nhầm.

Năm SCP nên có cho mọi Organization: | SCP | Chặn gì | |---|---| | Chặn tắt CloudTrail | ← câu này | | Chặn tắt GuardDuty, Config, Security Hub | bảo vệ công cụ giám sát | | Giới hạn Region được dùng | tuân thủ và kiểm soát chi phí | | Chặn xoá log và bucket kiểm toán | | | Chặn tạo IAM user (ép dùng Identity Center) | |

Ví dụ giới hạn Region:

{"Effect": "Deny", "NotAction": [
   "iam:*", "organizations:*", "route53:*", "cloudfront:*",
   "support:*", "budgets:*", "waf:*"],
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:RequestedRegion": ["ap-northeast-1", "us-east-1"]}}}

NotAction liệt kê các dịch vụ TOÀN CẦU — chúng chỉ hoạt động ở us-east-1 và không được chặn.

Ba thực hành tốt về cấu trúc CloudTrail cho Organization: | Thực hành | Chi tiết | |---|---| | Tạo ORGANIZATION TRAIL từ tài khoản quản lý | tự áp cho mọi tài khoản, kể cả tài khoản mới | | Ghi vào bucket ở TÀI KHOẢN LOG RIÊNG | lập trình viên không xoá được | | Bật log file validation | chứng minh log không bị sửa |

aws cloudtrail create-trail --name theo-doi-toan-to-chuc   --s3-bucket-name kho-log-kiem-toan   --is-organization-trail --is-multi-region-trail   --enable-log-file-validation

Và bucket log nên ở tài khoản riêng với Object Lock:

Tài khoản log:
    → chỉ đội bảo mật có quyền
    → bucket bật Object Lock (COMPLIANCE)
    → không ai xoá được log, kể cả root của tài khoản đó

Ba cách cấp tài khoản riêng cho lập trình viên: | Cách | Đặc điểm | |---|---| | AWS Control Tower | dựng landing zone với guardrail sẵn | | Account Factory for Terraform | tự động hoá bằng mã | | Tạo thủ công qua Organizations | cho quy mô nhỏ |

Control Tower rất phù hợp với tình huống này:

Control Tower cung cấp:
    ✓ SCP dựng sẵn (gọi là guardrail)
    ✓ CloudTrail và Config bật tự động
    ✓ tài khoản log và audit riêng
    ✓ Account Factory tạo tài khoản mới theo chuẩn

Ba loại guardrail của Control Tower: | Loại | Cơ chế | |---|---| | Preventive | SCP — CHẶN hành động | | Detective | AWS Config rule — phát hiện vi phạm | | Proactive | CloudFormation hook — chặn trước khi tạo |

Ba lưu ý khi triển khai SCP: | Lưu ý | Chi tiết | |---|---| | Thử trên OU thử nghiệm trước | SCP sai có thể khoá cả tài khoản | | Kiểm tra tài khoản quản lý KHÔNG bị ảnh hưởng | nhưng cũng không được bảo vệ | | Ghi tài liệu rõ vì sao chặn | người sau sẽ hỏi |

Và một lời khuyên: hãy đặt cảnh báo cho sự kiện StopLogging và DeleteTrail trong CloudTrail, ngay cả khi đã có SCP chặn. SCP bảo vệ ở tầng phòng ngừa, nhưng cảnh báo cho bạn biết ai đang thử làm điều đó — và một lập trình viên liên tục thử tắt CloudTrail là thông tin đáng chú ý với đội bảo mật.

Đáp án

C — Với từng lập trình viên, định nghĩa một IAM permissions boundary giới hạn các managed policy mà họ được gắn cho chính mình.

Vì sao đúng

Đề nêu hai yêu cầu đối lập nhau, và permissions boundary là cơ chế cân bằng đúng: | Yêu cầu | Cơ chế | |---|---| | Cho lập trình viên TỰ gắn managed policy để thử nghiệm nhanh | vẫn cho quyền iam:AttachUserPolicy | | Nhưng KHÔNG được tự nâng lên AdministratorAccess | boundary đặt TRẦN quyền |

Cách permissions boundary hoạt động:

Permissions boundary là một policy gắn vào user hoặc role
    → nó KHÔNG cấp quyền
    → nó GIỚI HẠN mức quyền TỐI ĐA
        ↓
Quyền hiệu lực = GIAO của (identity policy) và (permissions boundary)

Áp vào tình huống:

Lập trình viên gắn AdministratorAccess cho chính mình
    → identity policy giờ có quyền "*"
    → NHƯNG boundary chỉ cho phép, ví dụ, S3, EC2, Lambda
        ↓
    Quyền hiệu lực = "*" ∩ (S3, EC2, Lambda) = S3, EC2, Lambda
    → KHÔNG thành quản trị viên

Ví dụ boundary:

{"Version": "2012-10-17",
 "Statement": [
   {"Effect": "Allow",
    "Action": ["s3:*", "ec2:*", "lambda:*", "dynamodb:*",
               "logs:*", "cloudwatch:*"],
    "Resource": "*"},
   {"Effect": "Deny",
    "Action": ["iam:PutUserPermissionsBoundary",
               "iam:DeleteUserPermissionsBoundary"],
    "Resource": "*"}]}

Statement thứ hai là bắt buộc — nếu không, lập trình viên tự gỡ boundary của mình.

aws iam put-user-permissions-boundary   --user-name lap-trinh-vien-a   --permissions-boundary arn:aws:iam::123456789012:policy/ranh-gioi-lap-trinh-vien

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

• **D. Đưa lập trình viên vào một IAM group rồi định nghĩa permissions boundary TRÊN GROUP — đây là phương án gần nhất và nghe rất hợp lý về mặt quản lý, nhưng nó không làm được về mặt kỹ thuật: permissions boundary CHỈ gắn được vào IAM USER và IAM ROLE, không gắn vào group được. Đây là điểm phân biệt chính xác của câu hỏi.
• **B. Gắn một IAM policy cấm họ gắn AdministratorAccess — chỉ chặn được một chính sách cụ thể: lập trình viên vẫn có thể gắn PowerUserAccess, hoặc tự viết một inline policy với "Action": "*". Chặn theo tên chính sách là trò đuổi bắt không có hồi kết.
• **A. Tạo Service Control Policy — SCP áp cho CẢ TÀI KHOẢN, nghĩa là nó cũng chặn luôn quản trị viên thật. Và đề nói "trên tài khoản AWS của bạn" — SCP đòi AWS Organizations, và nó là công cụ quá thô cho việc phân biệt giữa các người dùng trong cùng một tài khoản.

Ghi nhớ

Bốn cơ chế giới hạn quyền — bảng phải thuộc: | Cơ chế | Gắn vào | Phạm vi | |---|---|---| | Identity policy | user, GROUP, role | cấp quyền | | Permissions boundary | CHỈ user và role | trần quyền của thực thể đó | | SCP | tài khoản hoặc OU | trần cho cả tài khoản | | Session policy | phiên AssumeRole | trần cho một phiên |

Dòng thứ hai là điểm mấu chốt: boundary KHÔNG gắn vào group được.

Công thức quyền hiệu lực:

Quyền = (identity policy) ∩ (permissions boundary) ∩ (SCP) ∩ (session policy)
        và KHÔNG có explicit Deny nào

Chỉ cần một tầng không cho phép là hành động bị từ chối.

Ba trường hợp dùng permissions boundary: | Trường hợp | Chi tiết | |---|---| | Ngăn NÂNG QUYỀN | ← câu này | | Uỷ quyền tạo IAM role an toàn | lập trình viên tự tạo role nhưng không vượt trần | | Giới hạn quyền của một vai trò cụ thể | |

Trường hợp thứ hai rất mạnh:

{"Effect": "Allow", "Action": ["iam:CreateRole", "iam:AttachRolePolicy"],
 "Resource": "*",
 "Condition": {"StringEquals":
   {"iam:PermissionsBoundary":
     "arn:aws:iam::123456789012:policy/ranh-gioi-lap-trinh-vien"}}}

Lập trình viên TỰ tạo được IAM role cho ứng dụng
    → nhưng BẮT BUỘC phải gắn boundary
    → role họ tạo không bao giờ vượt trần

Ba statement cần có trong policy của lập trình viên: | Statement | Việc | |---|---| | Cho phép gắn managed policy cho chính mình | để thử nghiệm nhanh | | CẤM gỡ hoặc sửa permissions boundary của mình | bắt buộc | | CẤM sửa chính policy boundary | iam:CreatePolicyVersion trên ARN đó |

Thiếu hai statement cấm là boundary trở nên vô nghĩa:

Lập trình viên có iam:PutUserPermissionsBoundary
    → tự thay boundary bằng cái rộng hơn
    → hoặc tự xoá boundary
        ↓
    Phải chặn tường minh

Ba cách nâng quyền mà lập trình viên có thể thử: | Cách | Boundary chặn được | |---|---| | Gắn AdministratorAccess cho mình | ✅ | | Viết inline policy với Action: "*" | ✅ | | Tạo role có quyền admin rồi assume | ✅ nếu ép boundary khi tạo role | | Gỡ boundary của chính mình | ✅ nếu có statement Deny |

Ba lưu ý về permissions boundary: | Lưu ý | Chi tiết | |---|---| | Boundary KHÔNG cấp quyền | phải có identity policy song song | | Deny trong boundary thắng mọi Allow | như mọi policy | | Không áp cho resource policy xuyên tài khoản | trong một số trường hợp |

SCP và permissions boundary — chọn cái nào: | | Permissions boundary | SCP | |---|---|---| | Phạm vi | một user hoặc role | cả tài khoản hoặc OU | | Cần Organizations | ❌ | ✅ | | Ảnh hưởng root | ❌ | ✅ | | Phù hợp | phân biệt giữa người dùng trong một tài khoản ← câu này | ranh giới ở cấp tổ chức |

Ba biện pháp bổ sung nên có: | Biện pháp | Chi tiết | |---|---| | Tách TÀI KHOẢN cho dev và prod | cách ly mạnh hơn mọi policy | | Bật CloudTrail alarm cho sự kiện IAM | phát hiện thử nâng quyền | | Rà soát quyền định kỳ | Access Advisor, Credential Report |

Và alarm cho sự kiện nâng quyền:

aws logs put-metric-filter --log-group-name /aws/cloudtrail   --filter-name gan-quyen-admin   --filter-pattern '{($.eventName = "AttachUserPolicy") &&
                     ($.requestParameters.policyArn = "*AdministratorAccess*")}'   --metric-transformations metricName=GanQuyenAdmin,metricNamespace=BaoMat,metricValue=1

Ba công cụ kiểm chứng: | Công cụ | Việc | |---|---| | IAM Policy Simulator | thử hành động với boundary đang áp | | IAM Access Analyzer | phát hiện quyền quá rộng | | CloudTrail | xem lời gọi bị từ chối vì boundary |

Và một lời khuyên: hãy kiểm chứng boundary bằng cách thử nâng quyền thật. Đăng nhập bằng tài khoản lập trình viên, gắn AdministratorAccess cho chính mình, rồi thử một hành động nằm ngoài boundary — nó phải trả về AccessDenied. Đây là loại cấu hình mà đọc chính sách bằng mắt rất dễ bỏ sót một kẽ hở.