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

Đáp án

B, D — hai thực hành tốt cần khuyến nghị:

• B — Bật MFA cho người dùng có đặc quyền.
• D — Cấu hình AWS CloudTrail để ghi lại mọi thao tác IAM.

Vì sao đúng

Với một công ty dịch vụ y tế (chịu ràng buộc HIPAA), hai biện pháp này nằm ở hai trụ cột khác nhau và đều bắt buộc.

⚠ Điều B — MFA là lớp phòng thủ chống mất chứng chỉ:

Mật khẩu bị lộ (lừa đảo, dùng lại mật khẩu, rò rỉ)
        ↓
    Không có MFA → kẻ tấn công vào được ngay
        ↓
    Có MFA → còn cần thiết bị vật lý hoặc ứng dụng sinh mã
        ↓
    → chặn được đại đa số vụ chiếm tài khoản
        ↓
    Bắt buộc nhất: MFA cho TÀI KHOẢN GỐC (root)

Có thể ép bằng chính sách IAM:

{
  "Effect": "Deny",
  "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice",
                "iam:ListMFADevices", "sts:GetSessionToken"],
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
  }
}

⚠ Điều D — CloudTrail là nền tảng của mọi kiểm toán:

CloudTrail ghi mọi lời gọi API, trong đó có IAM:
        CreateUser, AttachUserPolicy, CreateAccessKey,
        PutRolePolicy, DeleteUser...
        ↓
    → biết AI đã cấp quyền cho AI, LÚC NÀO
        ↓
    Management event MIỄN PHÍ một bản sao
        ↓
    → không có lý do gì để không bật

Với HIPAA, đây không chỉ là thực hành tốt mà là yêu cầu về nhật ký kiểm toán.

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

• C (dùng chứng chỉ của user để cấp quyền cho EC2 instance) — đây là phương án gần nhất vì nó nghe như một cách "cấp quyền cụ thể" hợp lý. Nhưng nó vi phạm nguyên tắc quan trọng nhất về chứng chỉ: EC2 phải dùng IAM role (instance profile), không bao giờ nhúng access key. Khoá dài hạn nằm trên máy là khoá dài hạn có thể bị đánh cắp, và nó không tự xoay.

• A (cấp quyền tối đa để khỏi phải cấp lại) — trái thẳng nguyên tắc quyền tối thiểu (least privilege), và là công thức dẫn tới sự cố bảo mật.

• E (tạo ít tài khoản rồi dùng chung chứng chỉ giữa các nhân viên) — phá huỷ hoàn toàn khả năng kiểm toán: CloudTrail sẽ ghi lại tên tài khoản dùng chung, nên không bao giờ biết được ai thật sự đã làm gì. Với HIPAA thì đây là vi phạm nghiêm trọng.

Ghi nhớ

⚠ Danh sách thực hành tốt về IAM — bảng phải thuộc: | Thực hành | Nội dung | |---|---| | Bật MFA, đặc biệt cho root | bắt buộc | | Không dùng root cho việc hằng ngày | và xoá access key của root | | Quyền tối thiểu | cấp vừa đủ, mở rộng khi cần | | Dùng ROLE thay cho ACCESS KEY | cho EC2, Lambda, ECS, và cho cả con người | | Mỗi người một danh tính riêng | không dùng chung tài khoản | | Bật CloudTrail | nhật ký kiểm toán | | Xoay và thu hồi chứng chỉ | dùng Credential Report | | Permissions boundary / SCP | trần quyền | | IAM Access Analyzer | tìm quyền thừa và tài nguyên lộ ra ngoài |

Từ khoá nhận diện:

"chống mất chứng chỉ" → MFA "ai đã làm gì" → CloudTrail "cấp quyền cho EC2" → IAM role, KHÔNG BAO GIỜ dùng access key "chia sẻ tài khoản cho tiện" → LUÔN SAI "quyền tối đa cho đỡ phiền" → LUÔN SAI "quản lý danh tính cho nhiều tài khoản" → IAM Identity Center

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ai chưa bật MFA | Credential Report, cột mfa_active | | Khoá nào lâu không dùng | cùng báo cáo, cột access_key_last_used | | Quyền nào đang thừa | Access Advisor cho từng role |

Và một thói quen đáng xây dựng ngay từ đầu: hãy tải Credential Report mỗi tháng và xử lý mọi dòng bất thường. Báo cáo này miễn phí, tạo trong vài giây, và nó phơi bày chính xác những thứ tích tụ âm thầm trong mọi tài khoản AWS — access key của một người đã nghỉ việc từ năm ngoái, một tài khoản quản trị chưa bật MFA, một khoá được tạo ra để thử nghiệm rồi không ai thu hồi.

Đáp án

B — !ImportValue (Fn::ImportValue).

Vì sao đúng

Cross-stack reference là một cặp hai bước, và đề hỏi đúng vế thứ hai: nhận giá trị ở stack đích.

⚠ Điểm mấu chốt — mỗi vế một hàm, ở một stack:

NetworkStack (nguồn) — đã làm xong theo mô tả của đề
    Outputs:
      SubnetId:
        Value: !Ref SubnetUngDung
        Export:
          Name: NetworkStack-SubnetId
        ↓
Stack ứng dụng (đích) — vế mà đề đang hỏi
    Resources:
      MayChu:
        Type: AWS::EC2::Instance
        Properties:
          SubnetId: !ImportValue NetworkStack-SubnetId

⚠ Vì sao !Ref không dùng được ở đây:

!Ref chỉ tham chiếu được:
        - tài nguyên khai TRONG CÙNG template
        - tham số (Parameters) của chính stack đó
        - pseudo parameter (AWS::Region, AWS::AccountId...)
        ↓
    → nó KHÔNG biết gì về stack khác
        ↓
    !ImportValue mới là hàm tra vào danh sách EXPORT
      của tài khoản + Region hiện tại

⚠ Và ba ràng buộc của cơ chế export/import:

1. Tên export DUY NHẤT trong một tài khoản + một Region
2. KHÔNG dùng chéo Region, KHÔNG dùng chéo tài khoản
3. KHÔNG xoá/sửa được export đang có stack khác import
        ↓
    → muốn đổi thì phải sửa stack ĐÍCH trước

Xem thêm câu #11657 và #11668: cùng cơ chế nhưng hỏi ở vế khác — #11657 hỏi trường nào để cung cấp giá trị (Export), #11668 hỏi cả cặp hai bước.

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

• C (!Ref) — đây là phương án gần nhất và là hàm được dùng nhiều nhất trong CloudFormation, nên rất dễ chọn theo phản xạ. Nhưng phạm vi của nó chỉ trong một stack.

• A (!GetAtt) — lấy thuộc tính của một tài nguyên, ví dụ !GetAtt DB.Endpoint.Address. Cũng chỉ hoạt động trong cùng stack. (Nó thường được dùng ở vế Outputs của stack nguồn để lấy giá trị đem đi export.)

• D (!Sub) — thay biến vào một chuỗi, ví dụ !Sub "${AWS::StackName}-SubnetId". Nó thường đi cùng !ImportValue (để dựng tên export động), nhưng bản thân nó không nhập giá trị nào.

Ghi nhớ

⚠ Bốn hàm nội tại hay gặp — bảng phải thuộc: | Hàm | Việc | Phạm vi | |---|---|---| | !Ref | tài nguyên hoặc tham số | cùng stack | | !GetAtt | thuộc tính của tài nguyên | cùng stack | | !ImportValue | giá trị export từ stack khác | cùng tài khoản + Region | | !Sub | thay biến vào chuỗi | mọi nơi |

Từ khoá nhận diện:

"nhận giá trị từ stack khác" → !ImportValue "cung cấp giá trị cho stack khác" → Export trong Outputs "lấy endpoint của RDS, ARN của bucket" → !GetAtt "tham chiếu tài nguyên trong cùng template" → !Ref "chéo Region hoặc chéo tài khoản" → SSM Parameter Store, không phải import/export

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có những export nào | list-exports | | Ai đang dùng một export | list-imports --export-name <ten> | | Vì sao không xoá được stack | thông báo lỗi nêu đích danh export bị dùng |

Và một lưu ý cú pháp rất hay làm người mới mất thời gian: YAML không cho phép lồng hai tag rút gọn (!ImportValue !Sub) trực tiếp với nhau. Khi cần dựng tên export động, phải viết dạng đầy đủ Fn::ImportValue: !Sub "..." — lỗi này báo ra rất mơ hồ, và nó là một trong những chỗ vấp phổ biến nhất khi bắt đầu tách template thành nhiều stack.

Đáp án

A, C — hai cách tối ưu chi phí để tăng tốc tải lên:

• C — Dùng Amazon S3 Transfer Acceleration.
• A — Dùng multipart upload.

Vì sao đúng

Đề nêu hai ràng buộc: tăng tốc tải tệp lớn từ xa và TIẾT KIỆM CHI PHÍ NHẤT. Cả hai giải pháp đều không đòi dựng hạ tầng mạng nào.

⚠ Transfer Acceleration — đi vào mạng riêng của AWS từ điểm gần nhất:

Không có Transfer Acceleration:
    Văn phòng ở Sydney → internet công cộng → bucket ở Virginia
        ↓
    → đi qua nhiều nhà mạng, độ trễ cao, mất gói nhiều

Có Transfer Acceleration:
    Sydney → edge location GẦN NHẤT (vài mili giây)
        ↓
    → từ edge đi tiếp bằng ĐƯỜNG TRỤC RIÊNG CỦA AWS
        ↓
    → tới bucket
        ↓
    → nhanh hơn đáng kể với khoảng cách xa

Bật bằng một công tắc, và dùng endpoint riêng:

ten-bucket.s3-accelerate.amazonaws.com

⚠ Multipart upload — chia tệp lớn thành nhiều mảnh tải SONG SONG:

Tệp video 20 GB
        ↓
    Chia thành nhiều phần, tải ĐỒNG THỜI
        ↓
    → tận dụng hết băng thông sẵn có
    → một phần lỗi chỉ cần tải lại PHẦN ĐÓ
    → tạm dừng và tiếp tục được
        ↓
    AWS KHUYẾN NGHỊ dùng cho tệp > 100 MB
    BẮT BUỘC với tệp > 5 GB

Tin tốt: AWS CLI và SDK tự động dùng multipart cho tệp lớn — thường không phải viết gì thêm.

⚠ Vì sao hai cách này "tiết kiệm chi phí nhất":

Transfer Acceleration → trả theo GB đã tăng tốc, KHÔNG có phí cố định
Multipart upload      → MIỄN PHÍ hoàn toàn
        ↓
    So với VPN hay Direct Connect
        ↓
    → không có phí cổng hằng giờ
    → không có hợp đồng viễn thông
    → không có công sức vận hành

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

• E (dựng nhiều Direct Connect tới các văn phòng châu Âu và Úc) — đây là phương án gần nhất về mặt hiệu quả kỹ thuật (băng thông ổn định nhất). Nhưng nó đắt nhất trong tất cả: phí cổng hằng giờ, phí đối tác viễn thông cho từng địa điểm, và mất hàng tuần tới hàng tháng để triển khai. Trái thẳng ràng buộc chi phí.

• B (dựng nhiều kết nối Site-to-Site VPN) — rẻ hơn Direct Connect nhưng vẫn chạy qua internet công cộng, nên không nhanh hơn việc tải thẳng lên S3; thậm chí còn chậm hơn vì thêm chi phí đóng gói IPsec.

• D (dùng AWS Global Accelerator để tải lên S3) — Global Accelerator cho IP tĩnh anycast và định tuyến qua mạng AWS, nhưng nó dành cho ALB, NLB, EC2 và Elastic IP — không hỗ trợ S3 làm endpoint. Với S3, thứ tương đương chính là Transfer Acceleration.

Ghi nhớ

⚠ Tăng tốc truyền dữ liệu lên S3 — bảng phải thuộc: | Cách | Chi phí | Khi nào dùng | |---|---|---| | Multipart upload | miễn phí | mọi tệp lớn — luôn nên dùng | | Transfer Acceleration | theo GB, không phí cố định | client ở xa bucket | | Snowball | thiết bị vật lý | hàng chục TB tới PB | | DataSync | theo GB | đồng bộ định kỳ, có kiểm chứng toàn vẹn | | Direct Connect | phí cổng + đối tác | cần băng thông ổn định lâu dài |

Từ khoá nhận diện:

"tải lên từ xa chậm, muốn rẻ" → Transfer Acceleration + multipart "tệp rất lớn" → multipart upload "hàng chục TB trở lên" → Snowball "Global Accelerator cho S3" → KHÔNG hỗ trợ "tăng tốc TẢI VỀ cho người dùng" → CloudFront, không phải Transfer Acceleration

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Nhanh hơn bao nhiêu | S3 Transfer Acceleration Speed Comparison tool | | Có upload dở dang không | list-multipart-uploads — rồi đặt lifecycle dọn | | CLI có dùng multipart không | chỉnh multipart_threshold và max_concurrent_requests trong ~/.aws/config |

Và một lời khuyên rẻ tiền mà hiệu quả bất ngờ: hãy chỉnh max_concurrent_requests của AWS CLI trước khi bật Transfer Acceleration. Mặc định CLI chỉ chạy 10 luồng song song; với một đường truyền tốt ở văn phòng, nâng con số đó lên có thể tăng tốc độ đáng kể mà không tốn thêm một đồng nào — hãy đo lại rồi mới quyết định có cần trả tiền cho Transfer Acceleration hay không.

Đáp án

A — Người dùng bị TỪ CHỐI truy cập, vì một trong hai chính sách có Deny tường minh.

Vì sao đúng

Đây là quy tắc nền tảng nhất của IAM, và nó không có ngoại lệ nào.

⚠ Điểm mấu chốt — Explicit Deny thắng mọi Allow:

Chính sách 1: Deny  ec2:*
Chính sách 2: Allow ec2:Describe*
        ↓
    IAM gom TẤT CẢ chính sách áp dụng cho principal
        ↓
    Có bất kỳ Deny nào khớp?
        ↓
    CÓ → TỪ CHỐI, dừng luôn
        ↓
    → không quan tâm có bao nhiêu Allow
    → không quan tâm Allow cụ thể đến đâu

⚠ Ba đặc điểm của cách IAM đánh giá quyền:

1. KHÔNG có thứ tự
        ↓
    Chính sách không được đánh số, không có "cái nào trước"
        ↓
2. Mặc định là TỪ CHỐI NGẦM (implicit deny)
        ↓
    Không có Allow nào → bị từ chối
        ↓
3. Deny TƯỜNG MINH là tuyệt đối
        ↓
    Ghi đè mọi Allow, ở mọi loại chính sách

⚠ Thứ tự đánh giá đầy đủ — bảng quyết định mọi câu hỏi IAM:

1. Có Explicit Deny ở BẤT KỲ đâu?      → TỪ CHỐI
2. SCP có cho phép không?               → không thì TỪ CHỐI
3. Resource-based policy có Allow?      → có thể đủ (cùng tài khoản)
4. Permissions boundary có cho phép?    → không thì TỪ CHỐI
5. Session policy có cho phép?          → không thì TỪ CHỐI
6. Identity-based policy có Allow?      → có thì CHO PHÉP
7. Không rơi vào đâu                    → implicit deny

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

• B (thứ tự chính sách quyết định — chính sách nào trước thì thắng) — đây là phương án gần nhất và là hiểu nhầm phổ biến nhất, vì nhiều hệ thống tường lửa và ACL đúng là xét theo thứ tự. IAM thì không: chính sách không có thứ tự, và kết quả luôn giống nhau dù gắn theo thứ tự nào. (Lưu ý: Network ACL của VPC thì CÓ thứ tự — đừng lẫn hai thứ.)

• C (được truy cập vì có Allow tường minh) — bỏ qua đúng quy tắc quan trọng nhất: Deny thắng Allow.

• D (IAM user rơi vào trạng thái không hợp lệ vì chính sách xung đột) — không có "trạng thái không hợp lệ" nào. Deny và Allow cùng lúc là chuyện hoàn toàn bình thường, và IAM có quy tắc rõ ràng để xử lý.

Ghi nhớ

⚠ Ba quy tắc vàng của IAM — thuộc ba dòng này là trả lời được phần lớn câu hỏi: | Quy tắc | |---| | 1. Mặc định là TỪ CHỐI (implicit deny) | | 2. Allow tường minh cho phép | | 3. DENY TƯỜNG MINH THẮNG TẤT CẢ |

Từ khoá nhận diện:

"vừa có Allow vừa có Deny" → DENY thắng "thứ tự chính sách" → IAM KHÔNG có thứ tự (NACL thì có) "chặn chắc chắn một hành động" → Deny tường minh "trần quyền cho một user" → permissions boundary "trần quyền cho cả tài khoản" → SCP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách nào gây Deny | Policy Simulator | | Có SCP nào chặn không | describe-effective-policy ở cấp tổ chức | | Quyền thật sự của một role | Access Advisor + Policy Simulator |

Và một cách nhớ ngắn gọn không bao giờ sai: trong IAM, một tiếng "không" luôn thắng mọi tiếng "có". Đây chính là điều làm cho SCP và permissions boundary trở thành công cụ đáng tin cậy — bạn không cần rà soát hết mọi chính sách đã gắn cho mọi người để chắc chắn một hành động bị cấm; chỉ cần một Deny đặt đúng chỗ là đủ, và không có chính sách nào thêm vào sau này có thể lật ngược nó.

Đáp án

D — CloudFront Key Pairs.

Vì sao đúng

Trong bốn loại chứng chỉ được liệt kê, chỉ CloudFront key pair là thứ mà tài khoản gốc phải tự tạo.

⚠ Điểm mấu chốt — vì sao chỉ root tạo được:

CloudFront key pair là "trusted signer" ở CẤP TÀI KHOẢN
        ↓
    Nó cấp quyền KÝ signed URL và signed cookie
    cho TOÀN BỘ nội dung của tài khoản
        ↓
    → không phải quyền của một IAM user nào
    → là một thuộc tính của chính tài khoản
        ↓
    → chỉ ROOT tạo và quản lý được
    → IAM user dù có AdministratorAccess cũng KHÔNG tạo được

⚠ Ba loại chứng chỉ còn lại — ai cũng tạo được nếu đủ quyền IAM:

EC2 key pair    → ec2:CreateKeyPair, ec2:ImportKeyPair
IAM password    → iam:CreateLoginProfile, iam:UpdateLoginProfile
IAM access key  → iam:CreateAccessKey
        ↓
    → đều là thao tác IAM thông thường
    → user có quyền tương ứng là làm được

Ghi nhớ về chất lượng câu hỏi

AWS nay KHUYẾN NGHỊ dùng "key group" thay cho CloudFront key pair. Cơ chế mới ra đời sau và tốt hơn hẳn ở mọi mặt:

CloudFront key pair (cách CŨ)
        ↓
    Chỉ ROOT tạo được
    Tối đa 2 khoá đang hoạt động mỗi tài khoản
    Không quản lý bằng IAM được
        ↓
Key group (cách MỚI, AWS khuyến nghị)
        ↓
    IAM user/role có quyền là tạo được — KHÔNG cần root
    Bạn TỰ SINH key pair, chỉ tải PUBLIC KEY lên CloudFront
    Tối đa 100 public key, nhóm thành các key group
    Quản lý và kiểm toán bằng IAM như mọi tài nguyên khác

Khoá đáp án vẫn đúng theo nghĩa hẹp — CloudFront key pair thật sự chỉ root tạo được. Nhưng trong một hệ thống dựng mới hôm nay, không nên dùng cơ chế đó nữa; và câu hỏi phản ánh danh mục tính năng ở thời điểm trước khi key group xuất hiện.

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

• C (IAM User Access Keys) — đây là phương án gần nhất vì access key đúng là chứng chỉ nhạy cảm và root cũng tạo được cho chính mình. Nhưng bất kỳ principal nào có quyền iam:CreateAccessKey đều tạo được access key cho một user — không cần root.

• B (IAM User passwords) — tạo bằng iam:CreateLoginProfile, quyền IAM thông thường.

• A (EC2 Instance Key Pairs) — tạo bằng ec2:CreateKeyPair hoặc nhập khoá có sẵn bằng ec2:ImportKeyPair.

Ghi nhớ

⚠ Những việc CHỈ tài khoản gốc làm được — bảng phải thuộc: | Việc | |---| | Tạo CloudFront key pair (cơ chế cũ) | | Bật/tắt MFA-Delete trên bucket S3 | | Đổi email, tên tài khoản, thông tin thanh toán | | Đổi hoặc huỷ gói AWS Support | | Đóng tài khoản AWS | | Khôi phục quyền khi IAM policy tự khoá chính mình | | Đăng ký GovCloud |

Từ khoá nhận diện:

"chỉ root tạo được" → CloudFront key pair, MFA-Delete "ký signed URL cho CloudFront (cách mới)" → key group, không cần root "khoá SSH cho EC2" → EC2 key pair, quyền IAM thường "chứng chỉ gọi API" → access key — nhưng nên dùng role thay thế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Root có access key không | Credential Report — nếu có thì xoá ngay | | Root đã bật MFA chưa | IAM console, mục Security credentials | | Đang dùng cơ chế ký nào | CloudFront console — key group hay trusted signer |

Và một cảnh báo đáng đặt lên hàng đầu trong mọi tài khoản AWS: hãy tạo cảnh báo cho mỗi lần tài khoản gốc đăng nhập. Root chỉ nên được dùng vài lần trong cả vòng đời một tài khoản, nên mỗi lần nó xuất hiện trong CloudTrail đều đáng để có người nhìn thấy và xác nhận — đó là một trong những tín hiệu cảnh báo sớm rẻ nhất và hiệu quả nhất mà bạn có thể dựng.

Đáp án

D — Với Amazon EC2, quản lý hệ điều hành khách (bao gồm cập nhật và bản vá bảo mật), phần mềm ứng dụng và Security Group là trách nhiệm của KHÁCH HÀNG.

Vì sao đúng

Mô hình trách nhiệm chia sẻ có một đường phân chia rất rõ, và nó dịch chuyển tuỳ theo loại dịch vụ.

⚠ Điểm mấu chốt — với EC2, ranh giới nằm ngay dưới hệ điều hành khách:

AWS chịu trách nhiệm — "SECURITY OF the cloud"
        ↓
    Trung tâm dữ liệu, điện, làm mát, an ninh vật lý
    Phần cứng máy chủ, mạng, tầng ảo hoá (hypervisor)
        ↓
────────────── RANH GIỚI với EC2 ──────────────
        ↓
Khách hàng chịu trách nhiệm — "SECURITY IN the cloud"
        ↓
    HỆ ĐIỀU HÀNH KHÁCH và bản vá của nó
    Phần mềm ứng dụng
    Security Group, NACL
    IAM, mã hoá dữ liệu
    Dữ liệu và phân loại dữ liệu

⚠ Và ranh giới đó DỊCH CHUYỂN theo loại dịch vụ:

IaaS (EC2)
        ↓
    Khách hàng lo nhiều nhất — kể cả vá hệ điều hành

PaaS được quản lý (RDS, ElastiCache)
        ↓
    AWS vá hệ điều hành VÀ công cụ cơ sở dữ liệu
    Khách hàng lo: lược đồ, người dùng DB, mã hoá, Security Group

Serverless (Lambda, S3, DynamoDB)
        ↓
    AWS lo toàn bộ hạ tầng và runtime
    Khách hàng lo: mã nguồn, quyền IAM, cấu hình, dữ liệu

Nguyên tắc chung: càng dùng dịch vụ được quản lý sâu, phần trách nhiệm của bạn càng nhỏ — nhưng phần dữ liệu và phân quyền thì LUÔN LÀ CỦA BẠN.

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

• B (AWS chịu trách nhiệm vá hạ tầng VÀ vá hệ điều hành khách lẫn ứng dụng của khách hàng) — đây là phương án gần nhất và vế đầu đúng: AWS đúng là vá hạ tầng. Nhưng vế sau sai hẳn: vá hệ điều hành khách và ứng dụng là việc của KHÁCH HÀNG với EC2. Đây chính là hiểu nhầm nguy hiểm nhất trong toàn bộ mô hình.

• C (với S3, quản lý hệ điều hành và nền tảng là trách nhiệm khách hàng) — ngược hẳn: S3 là dịch vụ được quản lý hoàn toàn, khách hàng không có hệ điều hành nào để quản. Trách nhiệm của bạn với S3 là quyền truy cập, mã hoá, và phân loại dữ liệu.

• A (AWS chịu trách nhiệm đào tạo khách hàng và nhân viên của khách hàng) — đào tạo nhân viên của bạn là việc của bạn. AWS chỉ chịu trách nhiệm đào tạo nhân viên của chính AWS.

Ghi nhớ

⚠ Mô hình trách nhiệm chia sẻ — bảng phải thuộc: | AWS lo ("OF the cloud") | Khách hàng lo ("IN the cloud") | |---|---| | Trung tâm dữ liệu, an ninh vật lý | Dữ liệu và phân loại dữ liệu | | Phần cứng, mạng vật lý | IAM, quản lý danh tính | | Tầng ảo hoá (hypervisor) | Hệ điều hành khách + bản vá (với EC2) | | Dịch vụ được quản lý (bên dưới) | Ứng dụng và cấu hình | | Tuân thủ hạ tầng (SOC, ISO, PCI) | Security Group, NACL, mã hoá |

Từ khoá nhận diện:

"vá hệ điều hành EC2" → KHÁCH HÀNG "vá hypervisor, phần cứng" → AWS "vá công cụ RDS" → AWS (trong maintenance window) "cấu hình Security Group" → KHÁCH HÀNG, luôn luôn "mã hoá dữ liệu" → KHÁCH HÀNG quyết định bật hay không "an ninh vật lý trung tâm dữ liệu" → AWS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã vá đủ chưa | Patch Manager compliance | | Cấu hình có lệch chuẩn không | AWS Config + Security Hub | | AWS đạt chuẩn gì | AWS Artifact — tải báo cáo SOC, ISO, PCI |

Và một cách diễn đạt ngắn gọn để nhớ suốt đời: AWS lo an ninh CỦA đám mây, bạn lo an ninh TRONG đám mây. Mọi câu hỏi về trách nhiệm đều quy về việc xác định thứ đang bàn nằm ở phía nào của ranh giới — và với EC2, ranh giới đó nằm ngay bên dưới hệ điều hành khách, nghĩa là từ hệ điều hành trở lên đều là phần của bạn.

Đáp án

A — Key policy của CMK phải cấp quyền dùng khoá cho tài khoản bên ngoài (hoặc cho user và role trong tài khoản đó). ĐỒNG THỜI, chính sách IAM ở tài khoản bên ngoài phải uỷ quyền lại cho user và role của họ.

Vì sao đúng

Chia sẻ KMS key liên tài khoản đòi HAI chính sách ở HAI tài khoản — thiếu một bên là hỏng.

⚠ Điểm mấu chốt — hai bước, hai nơi:

Bước 1 — Ở TÀI KHOẢN SỞ HỮU KHOÁ: sửa key policy
{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey", "kms:DescribeKey"],
  "Resource": "*"
}
        ↓
    → mới chỉ là "tài khoản kia ĐƯỢC PHÉP"
    → chưa ai dùng được

Bước 2 — Ở TÀI KHOẢN BÊN NGOÀI: sửa chính sách IAM
{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/xxxx"
}
        ↓
    → giờ user/role cụ thể mới thật sự dùng được

⚠ Vì sao phải cả hai — đây là quy tắc chung của mọi truy cập liên tài khoản:

Cùng một tài khoản
        ↓
    Chỉ cần MỘT trong hai (resource policy hoặc IAM policy) Allow

KHÁC tài khoản
        ↓
    CẢ HAI đều phải Allow
        ↓
    → thiếu bên nào cũng nhận AccessDenied
    → và thông báo lỗi GIỐNG HỆT nhau

⚠ Và "Principal": root ở đây có nghĩa gì:

"arn:aws:iam::444455556666:root"
        ↓
    KHÔNG phải "chỉ tài khoản root của họ"
        ↓
    Mà là "TÀI KHOẢN ĐÓ được phép uỷ quyền cho user/role của mình"
        ↓
    → muốn chặt hơn: khai đích danh ARN của role được phép

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

• C (khai key policy cho tài khoản ngoài, và nhúng key policy vào request đầu tiên của mỗi giao dịch) — đây là phương án gần nhất vì vế đầu đúng. Nhưng vế sau bịa hoàn toàn: key policy là cấu hình lưu ở KMS, không phải thứ gửi kèm request.

• B (dùng AWS Owned CMK để chia sẻ giữa các tài khoản) — ngược hẳn: AWS owned key là khoá AWS sở hữu và dùng chung nội bộ; bạn không thấy nó, không sửa key policy được, nên đó là loại khoá không thể chia sẻ nhất.

• D (dùng service-linked role của KMS để chia sẻ) — service-linked role là role AWS tạo cho chính dịch vụ dùng, không phải cơ chế chia sẻ khoá.

Ghi nhớ

⚠ Ba loại khoá KMS — bảng phải thuộc: | Loại | Sửa key policy | Chia sẻ liên tài khoản | |---|---|---| | AWS owned key | không thấy | KHÔNG | | AWS managed key (aws/s3, aws/ebs) | KHÔNG | KHÔNG | | Customer managed key (CMK) | CÓ | CÓ |

Từ khoá nhận diện:

"chia sẻ khoá giữa các tài khoản" → CMK + key policy + IAM policy ở CẢ HAI bên "AWS managed key chia sẻ được" → LUÔN SAI "chỉ cần sửa một bên" → SAI với liên tài khoản "chia sẻ AMI mã hoá" → cũng phải chia sẻ quyền dùng CMK "khoá dùng chung cho cả tổ chức" → key policy dùng aws:PrincipalOrgID

⚠ Điều tuyệt đối phải nhớ khi viết key policy:

LUÔN để lại một principal quản trị khoá trong key policy
    "Principal": {"AWS": "arn:aws:iam::<tai-khoan>:root"}
    "Action": "kms:*"
        ↓
    Nếu không, và không ai có kms:PutKeyPolicy
        ↓
    → khoá bị ĐÓNG BĂNG VĨNH VIỄN
    → mọi dữ liệu mã hoá bằng nó KHÔNG ĐỌC ĐƯỢC NỮA
    → kể cả root, kể cả AWS Support

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Key policy hiện tại | get-key-policy --policy-name default | | Ai đang dùng khoá | CloudTrail, lọc eventSource = kms.amazonaws.com | | Bên kia dùng được chưa | cho họ chạy thử kms:DescribeKey trên ARN của khoá |

Và một lời khuyên về cách viết key policy cho môi trường nhiều tài khoản: hãy dùng điều kiện aws:PrincipalOrgID thay vì liệt kê từng số hiệu tài khoản. Danh sách tài khoản luôn thay đổi khi tổ chức mở rộng, và mỗi lần thêm một tài khoản mà phải sửa key policy ở nhiều khoá là một cơ hội để ai đó viết sai — trong khi aws:PrincipalOrgID tự đúng mãi mãi và tự loại bỏ tài khoản khi nó rời khỏi tổ chức.

Đáp án

B, D, F — ba điều đúng về instance store và EBS:

• F — Mặc định, dữ liệu trên EBS volume KHÔNG PHẢI ổ gốc vẫn được giữ lại kể cả khi instance bị tắt hoặc chấm dứt.
• B — EBS snapshot chỉ chụp dữ liệu ĐÃ ĐƯỢC GHI XUỐNG volume, nên có thể bỏ sót dữ liệu còn nằm trong bộ đệm của ứng dụng hoặc hệ điều hành.
• D — Nên dùng EBS volume RIÊNG cho hệ điều hành và cho dữ liệu, dù đã có tính năng giữ lại ổ gốc.

Vì sao đúng

⚠ Điều F — DeleteOnTermination mặc định khác nhau giữa hai loại volume:

Ổ GỐC (root volume)
        ↓
    DeleteOnTermination = TRUE   ← xoá theo instance

Ổ DỮ LIỆU (volume gắn thêm)
        ↓
    DeleteOnTermination = FALSE  ← GIỮ LẠI
        ↓
    → đây chính là điều F
    → và cũng là lý do vì sao điều D là lời khuyên đúng

⚠ Điều B — snapshot chỉ thấy những gì đã ghi xuống đĩa:

Ứng dụng ghi dữ liệu
        ↓
    Nằm trong bộ đệm của ứng dụng và của hệ điều hành
        ↓
    Chưa flush xuống EBS
        ↓
    Chụp snapshot lúc này
        ↓
    → dữ liệu trong bộ đệm KHÔNG có trong snapshot
        ↓
    Chữa: fsfreeze (Linux) / VSS (Windows) trước khi chụp,
          hoặc dừng ghi, hoặc chấp nhận crash-consistent

⚠ Điều D — vì sao nên tách ổ hệ điều hành và ổ dữ liệu:

Một ổ duy nhất chứa cả hệ điều hành lẫn dữ liệu
        ↓
    Muốn thay máy, nâng cấp OS, đổi AMI
        ↓
    → phải di chuyển cả dữ liệu theo

Tách hai ổ
        ↓
    → thay máy: chỉ cần tháo ổ dữ liệu, gắn sang máy mới
    → snapshot riêng, lịch sao lưu riêng
    → chọn loại volume riêng (gp3 cho OS, io2 cho dữ liệu)
    → khôi phục nhanh hơn nhiều

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

• C (dữ liệu instance store được giữ khi stop/terminate, nhưng mất khi hibernate) — đây là phương án gần nhất và đảo ngược hoàn toàn sự thật: instance store MẤT khi stop và terminate; còn hibernate thì lại GIỮ được (vì hibernate lưu trạng thái xuống ổ gốc EBS).

• E (mã hoá EBS không hỗ trợ ổ khởi động) — sai; EBS encryption hỗ trợ đầy đủ ổ gốc. (Có một thời kỳ rất xa trước đây thì đúng, nhưng đã hỗ trợ từ lâu.)

• A (snapshot EBS lưu trên S3 và truy cập được bằng S3 API) — đây là bẫy tinh vi: snapshot được lưu trên S3 ở hạ tầng nội bộ của AWS, nhưng chúng nằm trong bucket do AWS quản lý mà bạn không thấy. Bạn thao tác với chúng bằng EC2 API (describe-snapshots, copy-snapshot), không phải S3 API.

Ghi nhớ

⚠ DeleteOnTermination — bảng phải thuộc: | Loại volume | Mặc định | Hệ quả | |---|---|---| | Ổ gốc (root) | true | xoá cùng instance | | Ổ dữ liệu gắn thêm | false | giữ lại | | Đổi được không | được, cả lúc khởi chạy lẫn khi đang chạy | modify-instance-attribute |

Từ khoá nhận diện:

"volume gắn thêm có mất khi terminate không" → KHÔNG, mặc định giữ lại "ổ gốc có mất không" → CÓ, mặc định xoá "instance store khi stop" → MẤT SẠCH "instance store khi hibernate" → GIỮ ĐƯỢC (nhờ lưu xuống ổ gốc EBS) "snapshot truy cập bằng S3 API" → SAI, dùng EC2 API "snapshot có nhất quán không" → crash-consistent, trừ khi freeze trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Volume có bị xoá khi terminate không | describe-instances, xem DeleteOnTermination của từng block device | | Snapshot có nhất quán không | khởi chạy thử một instance từ nó | | Snapshot mồ côi | describe-snapshots --owner-ids self, đối chiếu với AMI còn sống |

Và một quy ước kiến trúc đáng áp dụng từ máy chủ đầu tiên: hãy luôn tách ổ hệ điều hành khỏi ổ dữ liệu. Nó biến việc nâng cấp hệ điều hành, đổi AMI hay thay máy từ một cuộc di chuyển dữ liệu thành một thao tác tháo và gắn volume — và trong một sự cố, khả năng gỡ ổ dữ liệu ra khỏi một máy đang hỏng rồi gắn sang máy khoẻ thường là con đường phục hồi nhanh nhất mà bạn có.

Đáp án

B — CloudTrail.

Vì sao đúng

Câu hỏi của kiểm toán viên là "AI đang gọi API KMS" — và trong toàn bộ danh mục AWS, chỉ CloudTrail trả lời được câu hỏi bắt đầu bằng chữ "ai".

⚠ Điểm mấu chốt — mỗi bản ghi CloudTrail đều mang danh tính người gọi:

Mỗi lời gọi tới KMS sinh một sự kiện chứa:
        userIdentity   → AI gọi (IAM user, role, người đóng vai)
        eventName      → Decrypt, GenerateDataKey, Encrypt...
        eventTime      → LÚC NÀO
        resources      → KHOÁ NÀO
        requestParameters.encryptionContext → cho TÀI NGUYÊN NÀO
        sourceIPAddress, userAgent

⚠ Truy vấn bằng Athena để có đúng báo cáo kiểm toán cần:

SELECT useridentity.arn      AS nguoi_goi,
       eventname             AS thao_tac,
       element_at(resources, 1).arn AS khoa,
       count(*)              AS so_lan
FROM cloudtrail_logs
WHERE eventsource = 'kms.amazonaws.com'
  AND eventtime BETWEEN '2026-08-01' AND '2026-09-01'
GROUP BY 1, 2, 3
ORDER BY so_lan DESC;

⚠ Và một điểm rất quan trọng với KMS:

Lời gọi KMS là MANAGEMENT EVENT
        ↓
    → MIỄN PHÍ trong bản sao đầu tiên của CloudTrail
        ↓
    → không có lý do gì để không ghi lại
        ↓
    (khác với S3 data event — phải bật và có phí)

Nhưng đừng quên: Event history trên console chỉ giữ 90 ngày. Với kiểm toán tuân thủ, phải tạo trail đổ vào S3 để giữ lâu hơn.

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

• D (AWS Config) — đây là phương án gần nhất vì Config đúng là dịch vụ dành cho tuân thủ. Nhưng nó trả lời câu hỏi "tài nguyên đang được CẤU HÌNH thế nào" (khoá có bật xoay tự động không, key policy ra sao), chứ không ghi lại AI đã gọi API nào.

• A (CloudWatch Metrics) — cho số đếm tổng hợp: bao nhiêu lời gọi, bao nhiêu lỗi. Nó không có thông tin danh tính nào.

• C (AWS X-Ray) — truy vết hành trình một request bên trong ứng dụng của bạn, để tìm nút thắt hiệu năng. Không phải công cụ kiểm toán.

Ghi nhớ

⚠ Bốn dịch vụ hay bị nhầm trong bối cảnh tuân thủ — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | CloudTrail | "AI đã gọi API nào, lúc nào" | | AWS Config | "tài nguyên đang cấu hình thế nào, có đúng chuẩn không" | | CloudWatch | "hệ thống đang chạy ra sao" (chỉ số, log) | | X-Ray | "request đi qua đâu, chậm ở đâu" |

Từ khoá nhận diện:

"AI làm gì trên AWS" → CloudTrail "cấu hình có đúng chuẩn không" → AWS Config "ai đã giải mã bằng khoá này" → CloudTrail, sự kiện kms:Decrypt "tổng hợp phát hiện bảo mật" → Security Hub "điều tra một sự cố bảo mật" → Amazon Detective

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trail có đang ghi không | get-trail-status, xem IsLogging | | Log có toàn vẹn không | validate-logs với tệp digest | | Ai gọi KMS nhiều nhất | Athena, nhóm theo useridentity.arn |

Và một lời khuyên khi chuẩn bị cho một đợt kiểm toán: hãy dựng sẵn bảng Athena trên log CloudTrail và lưu lại vài truy vấn mẫu, đừng chờ tới lúc kiểm toán viên hỏi. Log thô của CloudTrail là JSON lồng nhiều tầng, rất khó đọc bằng mắt; một bảng đã phân vùng cùng năm sáu truy vấn viết sẵn biến những câu hỏi kiểu "ai đã chạm vào khoá này trong sáu tháng qua" từ một buổi làm việc căng thẳng thành một lệnh chạy trong ba mươi giây.

Đáp án

B — Volume 100 GiB với 7.500 IOPS là cấu hình KHÔNG hợp lệ.

Vì sao đúng

io1 có một ràng buộc cứng giữa dung lượng và IOPS, và 7.500 vượt qua nó.

⚠ Điểm mấu chốt — tỷ lệ tối đa của io1 là 50:1:

io1: IOPS tối đa = dung lượng (GiB) × 50
        ↓
    100 GiB × 50 = 5.000 IOPS  ← trần cho volume này
        ↓
    A: 3.000  ≤ 5.000  → HỢP LỆ
    C: 5.000  = 5.000  → HỢP LỆ (đúng trần)
    D: 1.000  ≤ 5.000  → HỢP LỆ
    B: 7.500  > 5.000  → KHÔNG HỢP LỆ  ← đáp án

Muốn 7.500 IOPS trên io1 thì phải có volume ít nhất 150 GiB (150 × 50 = 7.500).

⚠ Bảng tỷ lệ của các loại volume — con số phải thuộc:

⚠ Vì sao AWS đặt ra tỷ lệ này:

IOPS được phục vụ bởi phần cứng lưu trữ thật
        ↓
    Một volume rất nhỏ mà đòi IOPS rất cao
        ↓
    → chiếm dụng phần cứng không tương xứng
        ↓
    → nên AWS ràng buộc theo dung lượng
        ↓
    io2 nới tỷ lệ lên 500:1 — cùng 100 GiB
    thì io2 cho tới 50.000 IOPS

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

(Ba cấu hình còn lại đều nằm trong giới hạn, nên chúng hợp lệ và không phải đáp án.)

• C (100 GiB với 5.000 IOPS) — đây là phương án gần nhất và nằm ĐÚNG ở trần: 100 × 50 = 5.000. Hợp lệ, dù không còn chỗ để tăng thêm.

• A (100 GiB với 3.000 IOPS) — thoải mái trong giới hạn.

• D (100 GiB với 1.000 IOPS) — hợp lệ, nhưng lãng phí: với mức IOPS này thì gp3 rẻ hơn nhiều (gp3 cho sẵn 3.000 IOPS miễn phí ở mọi kích thước).

Ghi nhớ

⚠ Các loại EBS volume và giới hạn — bảng phải thuộc: | Loại | Dung lượng | IOPS tối đa | Throughput tối đa | |---|---|---|---| | gp3 | 1 GiB – 16 TiB | 16.000 | 1.000 MB/s | | gp2 | 1 GiB – 16 TiB | 16.000 | 250 MB/s | | io1 | 4 GiB – 16 TiB | 64.000 | 1.000 MB/s | | io2 | 4 GiB – 16 TiB | 64.000 | 1.000 MB/s | | io2 Block Express | 4 GiB – 64 TiB | 256.000 | 4.000 MB/s | | st1 | 125 GiB – 16 TiB | 500 | 500 MB/s | | sc1 | 125 GiB – 16 TiB | 250 | 250 MB/s |

Từ khoá nhận diện:

"io1, tỷ lệ IOPS:GiB" → 50:1 "io2, tỷ lệ" → 500:1 — gấp 10 lần io1 "gp3 cho sẵn bao nhiêu" → 3.000 IOPS và 125 MB/s ở MỌI kích thước "gp2 tính IOPS thế nào" → 3 IOPS mỗi GiB "IOPS cao nhất" → io2 Block Express, 256.000

⚠ Vì sao gp3 thường là câu trả lời tốt hơn io1 trong thực tế:

Cần 3.000 IOPS trên volume 100 GiB
        ↓
    io1: phải trả tiền cho 3.000 PIOPS + dung lượng
    gp3: 3.000 IOPS ĐÃ CÓ SẴN, miễn phí
        ↓
    → gp3 rẻ hơn hẳn
        ↓
    Chỉ nên dùng io1/io2 khi:
        - cần trên 16.000 IOPS
        - cần độ bền cao hơn (io2: 99,999%)
        - cần Multi-Attach

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Volume đang cấu hình gì | describe-volumes, xem VolumeType, Size, Iops | | Có đang chạm trần không | chỉ số VolumeQueueLength — cao là đang xếp hàng | | gp3 có rẻ hơn không | tính lại: gp3 rẻ hơn gp2 và tách riêng phần IOPS |

Và một lời khuyên áp dụng được ngay: trước khi cấp một volume io1, hãy tính xem gp3 có đủ không. Rất nhiều volume io1 đang chạy trong sản xuất được cấu hình ở mức IOPS mà gp3 cung cấp sẵn không mất tiền — chuyển sang gp3 diễn ra tại chỗ, không cần dừng máy, và thường cắt được một phần đáng kể hoá đơn lưu trữ mà không ai nhận ra sự khác biệt về hiệu năng.