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

Đáp án

C — Thêm câu lệnh Deny vào BUCKET POLICY, với Resource là arn:aws:s3:::digitalcloud-encrypted/* và điều kiện Null trên s3:x-amz-server-side-encryption.

Vì sao đúng

Phương án C đúng ở ba điểm mà các phương án khác sai ít nhất một.

⚠ Điểm thứ nhất — phải là BUCKET POLICY, không phải IAM policy:

Bucket policy (resource-based)
        ↓
    Áp cho MỌI người gọi tới bucket đó
        ↓
    → kể cả người dùng ở tài khoản khác
    → kể cả role mới tạo sau này
        ↓
IAM policy (identity-based)
        ↓
    Chỉ áp cho user/role được gắn chính sách
        ↓
    → người khác vẫn ghi được không mã hoá
    → phải nhớ gắn cho từng danh tính

⚠ Điểm thứ hai — Resource phải có /*:

s3:PutObject là thao tác trên ĐỐI TƯỢNG
        ↓
    Resource phải là:  arn:aws:s3:::bucket/*
        ↓
    Khai là arn:aws:s3:::bucket (không có /*)
        ↓
    → không khớp hành động nào
    → chính sách VÔ TÁC DỤNG
        ↓
    → đây chính là chỗ phương án B sai (ngoài việc dùng IAM policy)

⚠ Điểm thứ ba — điều kiện Null là cách khai đúng:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::digitalcloud-encrypted/*",
  "Condition": {
    "Null": { "s3:x-amz-server-side-encryption": "true" }
  }
}

    "Null": { "<khoá>": "true" }
        ↓
    → khớp khi header đó KHÔNG CÓ MẶT trong request
        ↓
    → Deny mọi PutObject không khai mã hoá

⚠ Muốn ép ĐÚNG MỘT LOẠI mã hoá thì dùng StringNotEquals:

"Condition": {
  "StringNotEquals": {
    "s3:x-amz-server-side-encryption": "aws:kms"
  }
}

Xem thêm câu #11620: cùng chủ đề ép mã hoá nhưng phân biệt mã hoá KHI LƯU với mã hoá KHI TRUYỀN (aws:SecureTransport).

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

• B (thêm cùng câu lệnh đó vào IAM user permissions policy) — đây là phương án gần nhất và cú pháp gần đúng, nhưng sai hai chỗ: nó là IAM policy (chỉ áp cho một danh tính, không phủ được mọi người gọi), và Resource là arn:aws:s3:::digitalcloud-encrypted/ — thiếu dấu *, nên không khớp đối tượng nào. (Ngoài ra IAM policy không có trường Principal.)

• A (bật S3 Default Encryption) — đây là một biện pháp rất tốt và nên bật, nhưng nó không ÉP ai cả: nó âm thầm mã hoá các đối tượng không khai gì. Nếu yêu cầu bảo mật là "phải từ chối request không mã hoá" thì Default Encryption không đáp ứng — nó không từ chối gì.

• D (sinh presigned URL cho thao tác PUT với cờ mã hoá rồi gửi cho người dùng) — chỉ áp cho một request cụ thể đã được ký. Nó không ràng buộc mọi đường ghi khác vào bucket.

Ghi nhớ

⚠ Hai cách tiếp cận mã hoá S3 — bảng phải thuộc: | | Default Encryption | Bucket policy với Deny | |---|---|---| | Cơ chế | âm thầm mã hoá nếu client không khai | TỪ CHỐI request không khai | | Client biết không | không | có — nhận lỗi 403 | | Ép loại khoá cụ thể | có (chọn SSE-KMS) | có, chặt chẽ hơn | | Dùng khi | muốn mọi thứ được mã hoá | yêu cầu tuân thủ đòi TỪ CHỐI | | Thực hành tốt | dùng CẢ HAI | |

Từ khoá nhận diện:

"ÉP mã hoá, phải từ chối nếu không có" → bucket policy với Null hoặc StringNotEquals "bảo đảm mọi thứ được mã hoá" → Default Encryption "ép HTTPS" → aws:SecureTransport: false → Deny "ép đúng một khoá KMS" → s3:x-amz-server-side-encryption-aws-kms-key-id "Resource không có /*" → chính sách vô tác dụng với PutObject

⚠ Hành động S3 và Resource — nhắc lại vì đây là bẫy lặp lại nhiều lần: | Hành động | Resource | |---|---| | s3:PutObject, s3:GetObject, s3:DeleteObject | arn:aws:s3:::bucket/* | | s3:ListBucket, s3:GetBucketLocation | arn:aws:s3:::bucket | | Cách nhớ | thao tác trên ĐỐI TƯỢNG → có /* |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách có chặn đúng không | thử put-object không kèm header mã hoá — phải nhận 403 | | Bucket dùng loại mã hoá gì | get-bucket-encryption | | Còn tệp cũ chưa mã hoá không | S3 Inventory |

Và một lời khuyên nên áp dụng cho mọi bucket chịu yêu cầu tuân thủ: dùng CẢ Default Encryption LẪN bucket policy Deny. Default Encryption bảo đảm không có tệp nào lọt qua mà chưa mã hoá; bucket policy Deny bảo đảm bạn phát hiện được ứng dụng nào đang ghi sai cách — vì nó nhận lỗi 403 rõ ràng thay vì được âm thầm sửa hộ.

Đáp án

B — Security Group không cho phép lưu lượng vào từ mạng gia đình trên cổng SSH.

Vì sao đúng

Manh mối nằm ở hai chi tiết: kết nối TIMEOUT và trước đó vẫn kết nối được từ mạng công ty.

⚠ Điểm mấu chốt — Security Group thường chỉ cho phép dải IP của văn phòng:

Luật inbound của instance:
        SSH (22) từ 203.0.113.0/24  ← dải IP văn phòng
        ↓
    Người quản trị làm việc ở nhà
        ↓
    IP nhà là một địa chỉ HOÀN TOÀN KHÁC
        ↓
    → không khớp luật nào → gói tin bị bỏ IM LẶNG
        ↓
    → client chờ mãi → TIMEOUT

⚠ Vì sao "timeout" là manh mối quan trọng nhất:

TIMEOUT (chờ mãi không có phản hồi)
        ↓
    → gói tin bị BỎ IM LẶNG ở tầng mạng
    → Security Group, NACL, hoặc route table

CONNECTION REFUSED (bị từ chối ngay)
        ↓
    → gói tin ĐÃ TỚI máy
    → nhưng không có dịch vụ nào lắng nghe cổng đó
    → sshd chưa chạy, hoặc chạy ở cổng khác

PERMISSION DENIED (publickey)
        ↓
    → mạng hoàn toàn thông, TCP đã bắt tay xong
    → vấn đề ở KHOÁ hoặc tên người dùng

⚠ Cách sửa — và cách sửa TỐT HƠN:

Cách nhanh:
    Thêm IP nhà vào luật inbound của Security Group
        ↓
    → nhưng IP nhà thường ĐỘNG, đổi liên tục
    → phải sửa lại mỗi lần nhà mạng cấp IP mới

Cách tốt hơn:
    Dùng Session Manager
        ↓
    → KHÔNG cần mở cổng 22 cho ai cả
    → phân quyền bằng IAM, thu hồi tức thì
    → có log toàn bộ phiên làm việc
    → làm việc từ đâu cũng được

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

• C (mạng gia đình không có tuyến tới Internet Gateway trong route table) — đây là phương án gần nhất vì route table đúng là một nghi phạm cho lỗi timeout. Nhưng route table là khái niệm của VPC; mạng gia đình không có route table nào trong AWS. Nếu route table của subnet sai thì kết nối từ văn phòng cũng đã hỏng.

• A (IAM role gắn với instance không cho phép SSH từ mạng nhà) — IAM hoàn toàn không liên quan tới SSH. IAM role gắn vào instance là để ứng dụng TRÊN máy gọi được dịch vụ AWS.

• D (key pair không cho phép kết nối từ mạng nhà) — key pair là mật mã, không có khái niệm địa chỉ mạng. Nếu sai khoá thì lỗi sẽ là Permission denied (publickey), không phải timeout.

Ghi nhớ

⚠ Ba loại lỗi khi kết nối SSH và ý nghĩa — bảng phải thuộc: | Lỗi | Nghĩa | Nghi phạm | |---|---|---| | Connection timed out | gói bị bỏ im lặng | Security Group, NACL, route table, không có IP công cộng | | Connection refused | tới máy nhưng không ai nghe | sshd chưa chạy, sai cổng | | Permission denied (publickey) | mạng thông, sai chứng chỉ | sai khoá, sai user, sai quyền tệp | | Host key verification failed | khoá host đổi | máy đã bị dựng lại |

Từ khoá nhận diện:

"timeout khi SSH" → Security Group, NACL, route table "connection refused" → dịch vụ chưa chạy trên máy "permission denied (publickey)" → khoá hoặc tên user sai "IP nhà thay đổi liên tục" → Session Manager, đừng sửa SG mỗi lần "IAM role cho SSH" → KHÔNG LIÊN QUAN

Ba việc kiểm chứng: | Việc | Cách | |---|---| | IP hiện tại của bạn là gì | curl https://checkip.amazonaws.com | | Security Group cho phép gì | describe-security-groups — đọc JSON | | Gói bị chặn ở đâu | VPC Flow Logs, tìm bản ghi REJECT |

Và một lời khuyên rút ra từ chính tình huống làm việc từ xa này: hãy chuyển hẳn sang Session Manager thay vì tiếp tục thêm IP vào Security Group. Danh sách IP văn phòng là một mô hình sinh ra từ thời mọi người ngồi cùng một toà nhà — với đội làm việc phân tán, nó biến thành một danh sách phình to, đầy những dải địa chỉ không ai nhớ vì sao lại có ở đó, và mỗi mục trong đó là một cánh cửa mở ra internet.

Đáp án

C — Dùng luật quản lý sẵn encrypted-volumes của AWS Config, khai ID của CMK trong tham số luật.

Vì sao đúng

Yêu cầu của đề là kiểm tra xem các volume EBS đã gắn có được mã hoá bằng đúng CMK hay không — đây là bài toán PHÁT HIỆN và TUÂN THỦ, đúng việc của AWS Config.

⚠ Điểm mấu chốt — encrypted-volumes nhận tham số khoá:

AWS Config bật luật quản lý sẵn: encrypted-volumes
        ↓
    Tham số tuỳ chọn: kmsId
        ↓
    Không khai kmsId → chỉ kiểm "có mã hoá hay không"
    CÓ khai kmsId  → kiểm "có mã hoá bằng ĐÚNG khoá đó không"
        ↓
    → đúng yêu cầu của đề: một CMK cụ thể

⚠ Và cách nó chạy:

Config ghi lại cấu hình mọi volume EBS
        ↓
    Mỗi khi cấu hình ĐỔI → đánh giá lại luật
        ↓
    Volume không khớp → NON_COMPLIANT
        ↓
    → bảng điều khiển Config hiện danh sách vi phạm
    → EventBridge bắt sự kiện thay đổi tuân thủ
    → SNS báo cho đội vận hành
    → hoặc SSM Automation TỰ SỬA
        ↓
    Lưu ý: luật này chỉ soi volume ĐANG GẮN vào instance

⚠ Nhưng phát hiện chưa đủ — nên ghép với NGĂN CHẶN:

NGĂN CHẶN (chặn từ đầu)
        ↓
    Bật "EBS encryption by default" ở từng Region
      + đặt CMK mặc định là chính khoá đó
        ↓
    → mọi volume mới TỰ ĐỘNG mã hoá đúng khoá
        ↓
    Thêm SCP chặn ec2:CreateVolume khi
      ec2:Encrypted = false
        ↓
PHÁT HIỆN (bắt cái lọt lưới)
        ↓
    AWS Config encrypted-volumes với kmsId
        ↓
    → bắt volume tạo trước khi bật chính sách

Xem thêm câu #11734: cùng cặp khái niệm ngăn chặn ↔ phát hiện, ở đó là mã hoá dữ liệu lưu trữ chứ không phải EBS.

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

• B (dùng luật quản lý sẵn cloudtrail-encryption-enabled hoặc tương tự về CloudTrail) — đây là phương án gần nhất về hình thức vì cũng là luật Config, nhưng nó kiểm mã hoá của log CloudTrail, không phải volume EBS. Sai đối tượng.

• A (viết luật Config tuỳ chỉnh bằng Lambda) — về kỹ thuật thì làm được, nhưng khi đã có luật quản lý sẵn làm đúng việc đó kèm tham số khoá, viết Lambda là tự thêm mã phải bảo trì, phải trả tiền chạy, và phải tự xử lý phân trang lẫn giới hạn tần suất API.

• D (dùng Trusted Advisor để kiểm mã hoá EBS) — Trusted Advisor không có kiểm tra nào về mã hoá volume EBS theo một CMK cụ thể. Nó tập trung vào chi phí, hiệu năng, khả năng chịu lỗi, hạn mức và một số kiểm tra bảo mật cố định — không tuỳ biến được theo khoá của bạn.

Ghi nhớ

⚠ Ngăn chặn ↔ phát hiện ↔ khắc phục — bảng phải thuộc: | Loại | Công cụ | Đặc điểm | |---|---|---| | Ngăn chặn | SCP, IAM policy, bucket policy, encryption by default | chặn TRƯỚC khi việc xảy ra | | Phát hiện | AWS Config, Security Hub, GuardDuty, Inspector | báo SAU khi việc đã xảy ra | | Khắc phục | SSM Automation, Config remediation, Lambda | tự sửa cái đã phát hiện | | Thực hành tốt | dùng cả ba tầng | |

Từ khoá nhận diện:

"kiểm tra xem có tuân thủ không" → AWS Config "ngăn không cho tạo" → SCP hoặc IAM policy "tự động sửa khi phát hiện" → Config remediation + SSM Automation "mọi volume mới phải mã hoá" → EBS encryption by default "tổng hợp phát hiện từ nhiều dịch vụ" → Security Hub

⚠ Các luật Config quản lý sẵn về mã hoá — hay ra thi: | Luật | Kiểm gì | |---|---| | encrypted-volumes | volume EBS ĐANG GẮN có mã hoá không; kèm kmsId thì kiểm đúng khoá | | ec2-ebs-encryption-by-default | Region đã bật mã hoá mặc định chưa | | s3-bucket-server-side-encryption-enabled | bucket có mã hoá mặc định | | rds-storage-encrypted | instance RDS có mã hoá | | efs-encrypted-check | file system EFS có mã hoá | | cloud-trail-encryption-enabled | log CloudTrail có mã hoá — phương án B nhầm sang đây | | dynamodb-table-encrypted-kms | bảng DynamoDB dùng KMS |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Volume nào chưa mã hoá | Config → luật encrypted-volumes → Non-compliant resources | | Region đã bật mặc định chưa | get-ebs-encryption-by-default | | CMK mặc định là khoá nào | get-ebs-default-kms-key-id |

Và một lưu ý về phạm vi mà nhiều người bỏ sót: encrypted-volumes chỉ đánh giá volume đang GẮN vào instance. Volume rời — thứ hay còn sót lại sau khi ai đó xoá máy mà quên xoá đĩa — sẽ không xuất hiện trong danh sách vi phạm, nên muốn phủ hết thì cần thêm một luật tuỳ chỉnh hoặc một truy vấn Config Advanced Query quét toàn bộ AWS::EC2::Volume.

Đáp án

C — Cấu hình chính sách co giãn THEO LỊCH (scheduled scaling) để tăng số máy trước khung giờ hai tiếng đó.

Vì sao đúng

Chi tiết quyết định nằm ở chỗ: khung giờ tăng tải đã BIẾT TRƯỚC và lặp lại đều đặn.

⚠ Điểm mấu chốt — biết trước thì đừng chờ phản ứng:

Co giãn ĐỘNG (dynamic)
        ↓
    Chờ CloudWatch thu thập chỉ số (~1 phút)
    → chờ alarm chuyển trạng thái (thường 2-3 chu kỳ)
    → khởi chạy máy mới (1-2 phút)
    → chờ health check của ELB (2-5 phút)
        ↓
    Tổng: 5-10 PHÚT SAU khi tải đã tăng
        ↓
    → người dùng đầu giờ cao điểm chịu độ trễ

Co giãn THEO LỊCH (scheduled)
        ↓
    Máy đã sẵn sàng TRƯỚC khi lưu lượng tới
        ↓
    → không có khoảng trũng nào

⚠ Cách cấu hình đúng:

Hai hành động theo lịch mỗi ngày:

  Trước giờ cao điểm 15-20 phút:
      DesiredCapacity  = 10
      MinSize          = 10
        ↓
  Sau giờ cao điểm:
      DesiredCapacity  = 2
      MinSize          = 2
        ↓
Kết hợp thêm co giãn ĐỘNG làm lưới an toàn
        ↓
    → lịch lo phần TẢI ĐOÁN ĐƯỢC
    → động lo phần BẤT NGỜ vượt dự kiến

⚠ Nhớ đặt sớm hơn khung giờ thật:

Máy mới cần thời gian:
    khởi chạy → khởi động HĐH → khởi động ứng dụng
    → qua được health check
        ↓
    Thường 3-5 phút, ứng dụng nặng có thể 10 phút
        ↓
    → đặt lịch SỚM HƠN ít nhất 15 phút

Xem thêm câu #11764: cũng hỏi chọn kiểu co giãn nào, nhưng ở đó khoá là co giãn ĐỘNG vì trigger là một ngưỡng CPU chứ không phải khung giờ định sẵn. Hai khoá khác nhau vì ràng buộc trong đề khác nhau, không mâu thuẫn: biết trước THỜI ĐIỂM → theo lịch; chỉ biết NGƯỠNG → động.

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

• A (dùng co giãn động dựa trên CPUUtilization) — đây là phương án gần nhất và vẫn hoạt động, nhưng nó phản ứng CHẬM: máy chỉ được thêm sau khi CPU đã cao, tức là sau khi người dùng đã chịu độ trễ. Khi thời điểm đã biết trước thì phản ứng là lựa chọn kém hơn dự phòng. (Nên bật kèm làm lưới an toàn, nhưng không phải câu trả lời chính.)

• B (tăng vĩnh viễn MinSize lên mức của giờ cao điểm) — giải quyết được hiệu năng nhưng trả tiền cho 24 giờ để dùng 2 giờ — đắt gấp khoảng 12 lần phần thực sự cần.

• D (dùng co giãn dự đoán — predictive scaling — với dữ liệu lịch sử) — đây là một lựa chọn hợp lý và cũng đúng về mặt kỹ thuật, nhưng nó cần ít nhất 24 giờ dữ liệu (khuyến nghị 14 ngày) để học mẫu hình, và khi khung giờ đã chính xác, cố định và biết trước thì co giãn theo lịch đơn giản hơn, tức thời hơn, và không phụ thuộc mô hình dự đoán.

Ghi nhớ

⚠ Bốn kiểu co giãn Auto Scaling — bảng phải thuộc: | Kiểu | Dùng khi | Ví dụ | |---|---|---| | Theo lịch (scheduled) | biết TRƯỚC thời điểm | giờ hành chính, khung giờ cao điểm cố định | | Động (dynamic) | tải bất ngờ, chỉ biết ngưỡng | CPU > 70% | | Dự đoán (predictive) | có mẫu hình lặp lại, cần ML | tải theo mùa | | Thủ công | thay đổi một lần | sự kiện đặc biệt |

Từ khoá nhận diện:

"mỗi ngày từ 9h đến 11h", "biết trước khung giờ" → theo lịch "tải tăng bất ngờ", "khi CPU vượt" → động "có mẫu hình nhưng không cố định giờ" → dự đoán "phản ứng chậm quá" → theo lịch, hoặc giảm chu kỳ đo "đắt vì chạy cả ngày" → theo lịch, giảm về đêm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch có chạy không | describe-scheduled-actions, và tab Activity của ASG | | Máy có kịp sẵn sàng không | so giờ InService với giờ bắt đầu cao điểm | | Có tiết kiệm thật không | Cost Explorer, lọc theo tag của ASG |

Và một cấu hình nên áp dụng cùng lúc: giữ CẢ lịch LẪN chính sách động. Lịch bảo đảm đủ máy đúng lúc cho phần tải đã biết; chính sách động vẫn ở đó để xử lý cái ngày mà lưu lượng cao hơn mọi ngày khác — vì khung giờ thì đoán được, còn quy mô thì không phải lúc nào cũng vậy.

Đáp án

A — Gửi LỜI MỜI từ tổ chức trung tâm tới từng tài khoản đang có.

Vì sao đúng

AWS Organizations có đúng hai cách đưa một tài khoản vào tổ chức, và tài khoản đã tồn tại từ trước chỉ dùng được một trong hai.

⚠ Điểm mấu chốt — hai cách, và cách nào áp cho tình huống nào:

Tài khoản MỚI
        ↓
    Tạo thẳng trong tổ chức
      (CreateAccount)
        ↓
    → tự động là thành viên, không cần mời

Tài khoản ĐÃ CÓ SẴN  ← tình huống của đề
        ↓
    Tổ chức trung tâm GỬI LỜI MỜI (InviteAccountToOrganization)
        ↓
    Chủ tài khoản đó ĐỒNG Ý lời mời
        ↓
    → tài khoản trở thành thành viên

⚠ Vì sao bắt buộc phải có bước ĐỒNG Ý:

Tài khoản AWS thuộc quyền sở hữu của người tạo ra nó
        ↓
    Vào tổ chức đồng nghĩa với:
      - bị SCP áp trần quyền
      - hoá đơn gộp về tài khoản quản lý
      - tài khoản quản lý có thể tác động tới nó
        ↓
    → đây là thay đổi lớn về quyền và chi phí
        ↓
    → AWS BẮT BUỘC chủ tài khoản phải đồng ý
    → không có cách nào ép một tài khoản vào tổ chức

⚠ Quy trình đầy đủ:

1. Tài khoản quản lý gửi lời mời
     (theo email gốc hoặc theo account ID)
        ↓
2. Lời mời hiện ra ở tài khoản kia
     Organizations console → Invitations
     và một email được gửi tới địa chỉ gốc
        ↓
3. Chủ tài khoản bấm Accept
     (lời mời hết hạn sau 15 NGÀY)
        ↓
4. Tài khoản vào tổ chức, đưa vào OU phù hợp
        ↓
5. Áp SCP, bật CloudTrail tổ chức, bật Config aggregator

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

• D (đăng nhập vào từng tài khoản rồi tự thêm vào tổ chức trung tâm) — đây là phương án gần nhất vì chủ tài khoản đúng là người phải hành động, nhưng thứ tự sai: không có thao tác "tự tham gia một tổ chức". Chủ tài khoản chỉ có thể chấp nhận một lời mời đã được gửi.

• B (dùng AWS IAM để thêm từng tài khoản vào tổ chức) — IAM quản lý danh tính TRONG một tài khoản, không quản lý quan hệ giữa các tài khoản. Không có API IAM nào làm việc này.

• C (tạo tổ chức mới trong từng tài khoản rồi ghép vào tổ chức trung tâm) — tổ chức KHÔNG LỒNG NHAU được. Một tài khoản chỉ thuộc đúng một tổ chức, và một tài khoản đã tạo tổ chức riêng thì phải xoá tổ chức đó trước mới nhận lời mời được.

Ghi nhớ

⚠ Hai cách vào tổ chức — bảng phải thuộc: | | Tạo mới trong tổ chức | Mời tài khoản có sẵn | |---|---|---| | API | CreateAccount | InviteAccountToOrganization | | Cần đồng ý | không | CÓ — chủ tài khoản phải Accept | | Rời tổ chức | phải bổ sung thông tin thanh toán trước | rời được ngay | | Hạn lời mời | — | 15 ngày |

Từ khoá nhận diện:

"tài khoản đã có sẵn, đưa vào tổ chức" → gửi LỜI MỜI "tạo tài khoản mới cho phòng ban" → CreateAccount / Account Factory "giới hạn quyền cho cả một nhóm tài khoản" → SCP áp lên OU "gộp hoá đơn" → Consolidated Billing, bật sẵn "tự động hoá việc dựng tài khoản mới" → Control Tower + Account Factory

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức có những ai | list-accounts | | Lời mời đang chờ | list-handshakes-for-organization | | Tài khoản có ở tổ chức nào chưa | describe-organization ngay trong tài khoản đó |

Và một việc dễ bị bỏ sót sau khi gom tài khoản về: các tài khoản cá nhân này thường có IAM user với access key dùng lâu ngày, được tạo từ trước khi có ai để mắt tới. Đưa được tài khoản vào tổ chức mới chỉ giải quyết phần quản trị và hoá đơn — phần rủi ro thật nằm ở những khoá đó, và nên quét bằng IAM Credential Report ngay trong tuần đầu tiên.

Đáp án

B — Tạo PERMISSION SET trong AWS SSO rồi gán chúng cho người dùng hoặc nhóm trong Directory Service.

Vì sao đúng

Sau khi đã có thư mục (directory) và bật quyền truy cập, bước còn thiếu là định nghĩa NGƯỜI DÙNG ĐƯỢC LÀM GÌ ở tài khoản nào — và trong AWS SSO (nay là IAM Identity Center), đó chính là permission set.

⚠ Điểm mấu chốt — permission set là gì:

Permission set
        ↓
    Một tập quyền, mô tả bằng:
      - AWS managed policy, và/hoặc
      - inline policy, và/hoặc
      - customer managed policy (theo tên)
        ↓
    Gán bộ ba:  NGƯỜI DÙNG/NHÓM  +  TÀI KHOẢN  +  PERMISSION SET
        ↓
    IAM Identity Center TỰ TẠO một IAM role
      trong tài khoản đích, ứng với permission set đó
        ↓
    → người dùng đăng nhập một lần
    → thấy danh sách tài khoản và vai được phép

⚠ Vì sao KHÔNG phải tự tạo IAM role — đây là điểm phân biệt với phương án C:

Bạn ĐỊNH NGHĨA permission set
        ↓
    Identity Center tự tạo role
      AWSReservedSSO_<tên>_<hash>
        ↓
    Sửa permission set → role ở MỌI tài khoản tự cập nhật
        ↓
    → không phải chạm tay vào từng tài khoản
    → đây chính là giá trị của Identity Center

⚠ Trình tự cấu hình đầy đủ:

1. Bật IAM Identity Center trong tài khoản quản lý
        ↓
2. Chọn NGUỒN DANH TÍNH
     Identity Center directory | Active Directory | IdP ngoài (SAML)
        ↓
3. TẠO PERMISSION SET  ← bước của đề
        ↓
4. Gán: người dùng/nhóm × tài khoản × permission set
        ↓
5. Người dùng vào cổng truy cập AWS, đăng nhập một lần

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

• C (tạo IAM role ở từng tài khoản rồi gán người dùng vào các role đó qua AWS SSO) — đây là phương án gần nhất và mô tả đúng thứ thực sự xảy ra bên dưới, nhưng Identity Center tự làm việc đó. Tự tạo role tay là bỏ đi toàn bộ giá trị của dịch vụ và tạo ra công việc bảo trì ở từng tài khoản.

• A (tạo SCP trong Organizations rồi gắn cho người dùng/nhóm trong Directory Service) — SCP gắn vào TÀI KHOẢN hoặc OU, không bao giờ gắn vào người dùng. Và SCP chỉ giới hạn quyền tối đa chứ không cấp quyền nào.

• D (tạo IAM user trong tài khoản quản lý rồi dùng SSO gán họ vào các tài khoản) — đi ngược lại toàn bộ mục đích của SSO: Identity Center sinh ra để không phải quản lý IAM user nữa.

Ghi nhớ

⚠ IAM Identity Center — bảng phải thuộc: | Khái niệm | Nội dung | |---|---| | Permission set | tập quyền → thành IAM role trong tài khoản đích | | Gán | bộ ba người dùng/nhóm × tài khoản × permission set | | Nguồn danh tính | Identity Center directory / Active Directory / IdP SAML 2.0 | | Role sinh ra | tên bắt đầu bằng AWSReservedSSO_ | | Giá | miễn phí | | Điều kiện | dùng chung với AWS Organizations |

Từ khoá nhận diện:

"đăng nhập MỘT lần cho nhiều tài khoản" → IAM Identity Center "đã có Active Directory sẵn" → AD Connector hoặc AWS Managed AD "đã có Okta / Entra ID / Ping" → IdP ngoài qua SAML 2.0 "giới hạn quyền TỐI ĐA của cả tài khoản" → SCP, không phải permission set "vẫn cần IAM user" → gần như luôn sai trong đề hiện đại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai được vào tài khoản nào | list-account-assignments | | Role sinh ra trông thế nào | IAM console của tài khoản đích, tìm AWSReservedSSO_ | | Người dùng thấy gì | mở cổng truy cập AWS bằng chính tài khoản đó |

Và một lưu ý về tên gọi khi đọc tài liệu: AWS SSO đã đổi tên thành IAM Identity Center từ năm 2022. Đề thi và tài liệu cũ vẫn dùng tên cũ, hai tên chỉ đúng một dịch vụ — nhưng khi tra tài liệu chính thức thì phải tìm theo tên mới, vì trang cũ đã được chuyển hướng và các API cũng mang tiền tố sso-admin.

Đáp án

A và C — Thêm CloudFront để cache nội dung tĩnh, và bật EC2 Auto Scaling cho tầng web.

Vì sao đúng

Đề mô tả hai điểm nghẽn khác nhau, và mỗi phương án đúng chữa một điểm.

⚠ Điểm nghẽn thứ nhất — nội dung tĩnh đi quá xa:

Người dùng ở khắp nơi
        ↓
    Ảnh, CSS, JS lấy thẳng từ bucket S3 ở MỘT Region
        ↓
    Người dùng xa Region đó phải chờ độ trễ vòng trái đất
        ↓
CloudFront
        ↓
    Cache ở hơn 400 điểm hiện diện gần người dùng
        ↓
    → lần đầu lấy từ S3, các lần sau phục vụ tại chỗ
    → giảm độ trễ mạnh nhất ở đúng phần nặng nhất của trang

⚠ Điểm nghẽn thứ hai — chỉ có ĐÚNG HAI máy web, cố định:

Hai instance, không co giãn
        ↓
    Lưu lượng tăng → CPU và bộ nhớ cạn
        ↓
    → thời gian phản hồi tăng
    → tải lâu đúng như đề mô tả
        ↓
Auto Scaling
        ↓
    Thêm máy khi tải cao, bớt máy khi tải thấp
        ↓
    → giữ thời gian phản hồi ổn định
    → thêm cả khả năng tự thay máy hỏng

⚠ Vì sao hai phương án này bổ sung cho nhau chứ không trùng lặp:

CloudFront    → giảm tải phần TĨNH, giảm độ trễ theo địa lý
Auto Scaling  → giải quyết phần ĐỘNG, giảm nghẽn theo tải
        ↓
    CloudFront cũng gián tiếp giúp tầng web:
      request tĩnh không còn chạm tới ALB

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

• E (bật định tuyến theo độ trễ trong Route 53) — đây là phương án gần nhất và liên quan thật tới độ trễ, nhưng định tuyến theo độ trễ chỉ có tác dụng khi hạ tầng đã được triển khai ở NHIỀU Region. Đề chỉ có một kiến trúc ở hai AZ trong cùng một Region — không có Region thứ hai để định tuyến sang.

• B (chuyển nội dung tĩnh từ S3 về chính máy web) — đi ngược hoàn toàn: nó dồn thêm tải lên đúng tầng đang quá tải, mất khả năng mở rộng gần như vô hạn của S3, và làm mỗi máy web phải giữ một bản sao dữ liệu.

• D (chuyển nội dung động từ máy web sang S3) — S3 không chạy được mã phía máy chủ. Nó chỉ phục vụ tệp tĩnh; nội dung động cần máy tính toán.

Ghi nhớ

⚠ Chẩn đoán "trang tải chậm" — bảng đáng thuộc: | Triệu chứng | Nguyên nhân thường gặp | Cách chữa | |---|---|---| | Ảnh, CSS, JS chậm | xa về địa lý | CloudFront | | Chậm khi đông người | thiếu máy | Auto Scaling | | Truy vấn CSDL chậm | thiếu chỉ mục, thiếu replica | read replica, ElastiCache | | Chậm ở mọi lúc, mọi nơi | mã ứng dụng | X-Ray, profiling | | Chỉ chậm ở một khu vực | thiếu hiện diện khu vực | CloudFront hoặc Global Accelerator |

Từ khoá nhận diện:

"người dùng toàn cầu, nội dung tĩnh chậm" → CloudFront "chậm vào giờ cao điểm" → Auto Scaling "cần định tuyến theo độ trễ" → phải có NHIỀU Region trước đã "đọc CSDL nghẽn" → read replica hoặc ElastiCache "TCP/UDP, không phải HTTP" → Global Accelerator, không phải CloudFront

Ba việc kiểm chứng: | Việc | Cách | |---|---| | CloudFront có cache tốt không | tỉ lệ CacheHitRate trong CloudWatch | | Tầng web có nghẽn không | TargetResponseTime của ALB, CPUUtilization của ASG | | Người dùng thực sự thấy gì | CloudWatch RUM, hoặc kiểm tra từ nhiều khu vực |

Và một thứ tự làm việc nên theo: đo trước khi sửa. Trong bốn thứ có thể chậm — mạng, tầng web, CSDL, mã ứng dụng — đề này đã cho đủ manh mối để chỉ ra hai cái đầu, nhưng ở hệ thống thật thì TargetResponseTime của ALB và CacheHitRate của CloudFront sẽ nói cho bạn biết ngay điểm nghẽn nằm ở đâu, trước khi bỏ tiền vào bất kỳ dịch vụ nào.

Đáp án

D — Dùng Tag Editor trong tài khoản MỚI để tạo tag, rồi vào Billing and Cost Management ở TÀI KHOẢN THANH TOÁN (payer) để đánh dấu chúng là cost allocation tag.

Vì sao đúng

Câu này kiểm tra một điểm duy nhất: hai bước diễn ra ở hai tài khoản khác nhau.

⚠ Điểm mấu chốt — gắn tag ở đâu, kích hoạt tag ở đâu:

BƯỚC 1 — GẮN TAG lên tài nguyên
        ↓
    Làm trong TÀI KHOẢN SỞ HỮU tài nguyên
      (tài khoản mới của phòng ban)
        ↓
    Công cụ: Tag Editor, hoặc gắn lúc tạo tài nguyên,
             hoặc CloudFormation/Terraform
        ↓
BƯỚC 2 — KÍCH HOẠT làm cost allocation tag
        ↓
    CHỈ làm được ở TÀI KHOẢN QUẢN LÝ / THANH TOÁN
        ↓
    Billing and Cost Management → Cost Allocation Tags
    → chọn tag → Activate
        ↓
    → tag mới xuất hiện trong Cost Explorer và CUR

⚠ Vì sao phải ở tài khoản thanh toán:

Trong AWS Organizations, DỮ LIỆU CHI PHÍ gộp về
  tài khoản quản lý
        ↓
    Tài khoản thành viên không thấy hoá đơn tổng
        ↓
    → chỉ tài khoản quản lý mới cấu hình được
      cách chi phí được phân loại
        ↓
    Cost allocation tag là một chiều phân loại chi phí
        ↓
    → nên nó thuộc về tài khoản quản lý

⚠ Và một chi tiết về thời gian rất hay bị bỏ qua:

Tag phải TỒN TẠI trên ít nhất một tài nguyên
        ↓
    → mới hiện ra trong danh sách để kích hoạt
        ↓
    Sau khi kích hoạt: mất tới 24 GIỜ mới có dữ liệu
        ↓
    → và KHÔNG áp ngược cho chi phí trong quá khứ
        ↓
    → kích hoạt tag NGAY khi dựng tài khoản, đừng đợi

Xem thêm câu #11590, #11636 và #11663: cùng chủ đề cost allocation tag, xoay quanh sự phân biệt giữa tag do AWS sinh ra và tag do người dùng định nghĩa.

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

• A (tạo tag ở tài khoản mới rồi đánh dấu cost allocation tag NGAY TẠI tài khoản mới) — đây là phương án gần nhất, bước một hoàn toàn đúng, chỉ sai ở bước hai: màn hình Cost Allocation Tags không dùng được ở tài khoản thành viên trong một tổ chức.

• B (tạo tag mới ngay trong Billing and Cost Management của tài khoản thanh toán) — không tạo tag ở màn hình đó được. Màn hình Cost Allocation Tags chỉ liệt kê các tag đã tồn tại trên tài nguyên để bạn bật/tắt.

• C (tạo tag trong Billing and Cost Management của tài khoản mới) — sai cả hai vế: không tạo tag ở màn hình billing được, và tài khoản thành viên cũng không có màn hình đó.

Ghi nhớ

⚠ Hai loại cost allocation tag — bảng phải thuộc: | Loại | Tiền tố | Ai tạo | |---|---|---| | Do AWS sinh | aws: | AWS tự gắn — aws:createdBy, aws:cloudformation:stack-name | | Do người dùng định nghĩa | user: trong CUR | bạn tự gắn — Department, Project, Environment | | Sửa được không | aws: không sửa, không xoá được | user: toàn quyền | | Đều phải | KÍCH HOẠT ở tài khoản quản lý | |

Từ khoá nhận diện:

"cost allocation tag, tài khoản thành viên" → gắn ở đó, KÍCH HOẠT ở tài khoản quản lý "chi phí theo phòng ban / dự án" → user-defined tag + Cost Explorer "chi phí theo tài khoản" → không cần tag, Cost Explorer nhóm sẵn "dữ liệu chi phí chi tiết nhất" → Cost and Usage Report (CUR) "tag mà không thấy trong Cost Explorer" → chưa kích hoạt, hoặc chưa qua 24 giờ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tag đã kích hoạt chưa | tài khoản quản lý → Billing → Cost Allocation Tags | | Tài nguyên nào thiếu tag | Tag Editor, hoặc luật Config required-tags | | Chi phí theo tag | Cost Explorer → Group by → Tag |

Và một việc nên làm ngay khi dựng bất kỳ tài khoản mới nào: kích hoạt sẵn bộ tag chuẩn của công ty ở tài khoản quản lý trước khi tài nguyên đầu tiên được tạo. Kích hoạt không áp ngược cho quá khứ, nên mỗi ngày chậm trễ là một ngày chi phí không quy được về phòng ban nào — và đó đúng là phần dữ liệu mà người ta cần nhất khi cuối quý phải giải trình hoá đơn.

Đáp án

B — Khởi chạy các instance EC2 trong PRIVATE SUBNET.

Vì sao đúng

Yêu cầu của đề rất tuyệt đối: máy chủ KHÔNG được gửi lưu lượng ra internet. Chỉ có một thứ quyết định điều đó — route table của subnet.

⚠ Điểm mấu chốt — public hay private là do ROUTE TABLE:

PUBLIC SUBNET
        ↓
    Route table có:  0.0.0.0/0  →  Internet Gateway
        ↓
    → máy có IP công cộng thì ra internet được

PRIVATE SUBNET
        ↓
    Route table KHÔNG có tuyến nào ra IGW
    (và không có NAT Gateway)
        ↓
    → gói tin đi ra không biết đường nào
    → KHÔNG THỂ tới internet, bất kể cấu hình gì khác

⚠ Vì sao đây là biện pháp mạnh nhất trong bốn phương án:

Không có tuyến = không có đường đi
        ↓
    → không phụ thuộc vào security group ai đó lỡ mở
    → không phụ thuộc vào việc máy có IP công cộng hay không
    → chặn ở tầng ĐỊNH TUYẾN, tầng thấp nhất và chắc nhất

⚠ Nhưng máy vẫn cần nói chuyện với dịch vụ AWS — dùng VPC endpoint:

Không có NAT, không có IGW
        ↓
    Nhưng vẫn cần gọi S3, SSM, KMS, CloudWatch…
        ↓
    VPC ENDPOINT
        ↓
    Gateway endpoint (miễn phí):  S3, DynamoDB
    Interface endpoint (PrivateLink):  hầu hết dịch vụ còn lại
        ↓
    → lưu lượng đi trong mạng AWS, KHÔNG qua internet
    → thoả đúng yêu cầu "dữ liệu không rời khỏi công ty"

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

• A (bảo đảm máy không có Elastic IP) — đây là phương án gần nhất và đúng một nửa: không có IP công cộng thì không ai từ internet gọi VÀO được. Nhưng nếu subnet có tuyến ra NAT Gateway, máy vẫn gửi lưu lượng RA internet bình thường — đúng điều đề muốn cấm.

• C (tạo NAT gateway kiểu "blackhole" để chặn truy cập ra ngoài) — không có khái niệm "blackhole NAT gateway". NAT Gateway sinh ra để cho phép kết nối ra internet; dùng nó để chặn là mâu thuẫn với chính chức năng của nó.

• D (dùng instance store để không có dữ liệu lưu lại) — nhầm bài toán: instance store nói về nơi lưu dữ liệu, không nói gì về đường đi của lưu lượng mạng. Dữ liệu vẫn rò ra ngoài được qua mạng.

Ghi nhớ

⚠ Bốn tổ hợp mạng của subnet — bảng phải thuộc: | Cấu hình | Ra internet | Vào từ internet | |---|---|---| | Public subnet + IP công cộng | có | có | | Public subnet, không IP công cộng | không | không | | Private subnet + NAT Gateway | CÓ | không | | Private subnet, không NAT | KHÔNG | không | | Đề muốn cấm hẳn | dòng cuối cùng | |

Từ khoá nhận diện:

"không được gửi gì ra internet" → private subnet, KHÔNG NAT "ra internet được nhưng không ai vào được" → private subnet + NAT Gateway "vẫn cần gọi dịch vụ AWS" → VPC endpoint "muốn quản trị máy mà không mở cổng" → Session Manager + 3 interface endpoint "chặn theo tên miền" → Route 53 Resolver DNS Firewall hoặc Network Firewall

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Subnet có ra internet được không | đọc route table, tìm 0.0.0.0/0 | | Máy có thực sự bị cô lập không | SSH vào rồi thử curl https://example.com — phải treo rồi timeout | | Có kết nối lạ nào không | VPC Flow Logs, lọc đích ngoài dải nội bộ |

Và một cách kiểm tra nghiêm túc hơn cho môi trường xử lý dữ liệu nhạy cảm: đọc route table của mọi subnet bằng script chứ không bằng mắt trên console. Một VPC thật thường có hàng chục subnet, và chỉ cần một subnet bị gắn nhầm route table có tuyến ra NAT là toàn bộ cam kết cô lập bị vô hiệu — mà trên giao diện thì mọi thứ trông vẫn hoàn toàn bình thường.

Đáp án

D — Dùng CloudWatch agent cho CẢ máy EC2 lẫn máy tại chỗ để đẩy chỉ số MemoryUtilization về CloudWatch.

Vì sao đúng

Điểm mấu chốt là CloudWatch agent chạy được trên máy ngoài AWS, nên không cần hai hệ thống giám sát khác nhau.

⚠ Điểm mấu chốt — vì sao phải cần agent:

CloudWatch mặc định chỉ thấy phía HYPERVISOR
        ↓
    Có sẵn: CPUUtilization, NetworkIn/Out,
            DiskReadBytes, StatusCheck…
        ↓
    KHÔNG có sẵn:
      - bộ nhớ đã dùng
      - dung lượng đĩa đã dùng (mức file system)
      - danh sách tiến trình
        ↓
    Vì đó là thông tin BÊN TRONG hệ điều hành khách
        ↓
    → phải cài agent mới lấy được

⚠ Và agent dùng chung cho cả hai môi trường:

Máy EC2
        ↓
    Cài agent, gắn IAM ROLE có CloudWatchAgentServerPolicy

Máy tại chỗ (on-premises)
        ↓
    Cài CÙNG agent đó
    → xác thực bằng một trong hai cách:
        SSM Hybrid Activation  (khuyến nghị), hoặc
        một IAM user riêng với access key
        ↓
KẾT QUẢ
        ↓
    Cùng một namespace, cùng một dashboard,
    cùng một alarm
        ↓
    → so sánh trực tiếp được giữa hai môi trường
    → đúng nghĩa "đơn giản nhất" mà đề hỏi

Xem thêm câu #11800: cùng về CloudWatch agent, ở đó trọng tâm là namespace tuỳ chỉnh mà agent ghi chỉ số vào.

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

• B (dùng CloudWatch agent cho EC2, dùng phần mềm bên thứ ba cho máy tại chỗ) — đây là phương án gần nhất và hoạt động được, nhưng nó tạo ra hai hệ thống: hai nơi xem, hai nơi đặt cảnh báo, hai định dạng dữ liệu, và không so sánh trực tiếp được — trong khi đề đang tìm một rò rỉ bộ nhớ xuất hiện ở cả hai bên. Rõ ràng không phải cách "đơn giản nhất".

• A (viết script hoặc dùng ứng dụng bên thứ ba cho cả hai) — tự làm lại đúng thứ AWS đã cung cấp sẵn và miễn phí, kèm theo gánh nặng bảo trì.

• C (tạo Auto Scaling group cho cả hai rồi xem chỉ số bộ nhớ của ASG) — sai hai lần: ASG không quản lý được máy tại chỗ, và ASG không sinh ra chỉ số bộ nhớ nào cả.

Ghi nhớ

⚠ Chỉ số có sẵn ↔ chỉ số cần agent — bảng phải thuộc: | Có sẵn (không cần agent) | Cần CloudWatch agent | |---|---| | CPUUtilization | mem_used_percent | | NetworkIn / NetworkOut | disk_used_percent | | DiskReadBytes / DiskWriteOps (mức volume) | swap_used_percent | | StatusCheckFailed | log của hệ điều hành và ứng dụng | | — | số tiến trình, chỉ số của procstat |

Từ khoá nhận diện:

"bộ nhớ", "dung lượng đĩa đã dùng" → CloudWatch agent, LUÔN LUÔN "máy tại chỗ và máy EC2 cùng lúc" → CloudWatch agent chạy được cả hai "CPU" → có sẵn, không cần agent "chỉ số mỗi 1 phút" → detailed monitoring (có phí) "gửi log ứng dụng lên" → cũng chính agent này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có chạy không | amazon-cloudwatch-agent-ctl -a status | | Chỉ số đã lên chưa | CloudWatch → Metrics → namespace CWAgent | | Máy tại chỗ đã đăng ký chưa | Systems Manager → Fleet Manager, tìm id mi-* |

Và một lưu ý khi so sánh hai môi trường: đặt cùng một namespace và cùng bộ dimension cho cả EC2 lẫn máy tại chỗ, chỉ khác nhau ở một dimension như Environment=onprem|aws. Làm vậy thì một đồ thị duy nhất vẽ được cả hai đường, và nếu rò rỉ xuất hiện đồng thời ở cả hai bên thì nguyên nhân gần như chắc chắn nằm trong mã ứng dụng chứ không phải ở hạ tầng bên nào.