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

Đáp án

B — Triển khai lại ứng dụng trong một PLACEMENT GROUP.

Vì sao đúng

Yêu cầu là giảm độ trễ giữa các node, và placement group kiểu cluster sinh ra chính xác cho việc đó.

⚠ Điểm mấu chốt — cluster placement group đặt máy SÁT NHAU:

Cluster placement group
        ↓
    Các instance được đặt GẦN NHAU VỀ VẬT LÝ
    trong CÙNG MỘT Availability Zone
        ↓
    → cùng rack, hoặc rất gần nhau
        ↓
    Kết quả:
      - độ trễ giữa các node RẤT THẤP
      - băng thông mạng cao (tới 10-100 Gbps
        giữa các instance trong nhóm)
      - ít biến thiên độ trễ (jitter)
        ↓
    → đúng yêu cầu "very low latency between nodes"

⚠ Ba kiểu placement group — chọn đúng kiểu:

CLUSTER    ← đề này
        ↓
    Sát nhau, MỘT AZ
    → độ trễ thấp nhất, băng thông cao nhất
    → dùng cho HPC, tính toán phân tán,
      big data, machine learning
    → đánh đổi: mất AZ là mất tất cả

SPREAD
        ↓
    Mỗi instance một PHẦN CỨNG RIÊNG
    → tối đa 7 instance mỗi AZ
    → dùng cho vài máy quan trọng, cần cách ly lỗi

PARTITION
        ↓
    Chia thành các phân vùng, mỗi phân vùng
    một nhóm rack riêng
    → dùng cho HDFS, Cassandra, Kafka
    → tối đa 7 phân vùng mỗi AZ

⚠ Ghép thêm ENA và Elastic Fabric Adapter cho độ trễ thấp nhất:

Enhanced Networking (ENA)
        ↓
    → thông lượng cao hơn, độ trễ thấp hơn,
      ít biến thiên hơn
    → hầu hết loại máy hiện đại đã bật sẵn

Elastic Fabric Adapter (EFA)
        ↓
    → bỏ qua hệ điều hành khi truyền
      (OS bypass)
    → cho HPC và ML dùng MPI hoặc NCCL
    → độ trễ thấp hơn nữa

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

• D (triển khai lại trong MỘT Availability Zone) — đây là phương án gần nhất và đúng một phần: cùng AZ thì độ trễ thấp hơn so với qua AZ. Nhưng trong một AZ vẫn có nhiều trung tâm dữ liệu và nhiều rack, nên độ trễ vẫn cao hơn hẳn so với cluster placement group. Không phải câu trả lời đầy đủ.

• A (triển khai lại trong một subnet riêng) — subnet là khái niệm LOGIC, không quyết định vị trí vật lý của máy. Không ảnh hưởng gì tới độ trễ.

• C (triển khai lại trong Auto Scaling group) — ASG lo co giãn và chịu lỗi, không ảnh hưởng tới độ trễ giữa các node. (Tuy ASG có thể dùng KÈM placement group.)

Ghi nhớ

⚠ Ba kiểu placement group — bảng phải thuộc: | Kiểu | Bố trí | Dùng cho | |---|---|---| | Cluster | sát nhau, MỘT AZ | HPC, big data, ML — độ trễ thấp nhất | | Spread | mỗi máy một phần cứng riêng, nhiều AZ | vài máy quan trọng, cần cách ly lỗi | | Partition | nhóm rack riêng cho mỗi phân vùng | HDFS, Cassandra, Kafka | | Giới hạn | Spread 7 máy/AZ, Partition 7 phân vùng/AZ | | | Chi phí | miễn phí | |

Từ khoá nhận diện:

"độ trễ RẤT THẤP giữa các node" → cluster placement group "tránh nhiều máy hỏng cùng lúc" → spread placement group "CSDL phân tán theo phân vùng" → partition placement group "HPC, MPI, huấn luyện mô hình phân tán" → cluster + EFA "chịu được mất một AZ" → KHÔNG dùng cluster — trải nhiều AZ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy đã ở trong nhóm chưa | describe-instances --query '...Placement.GroupName' | | Độ trễ có giảm không | sockperf hoặc ping trước/sau | | Băng thông thật là bao nhiêu | iperf3 giữa hai node |

Và một lời khuyên rất thực tế khi dựng cluster placement group: khởi chạy toàn bộ số máy cần thiết trong một lệnh duy nhất. AWS phải tìm chỗ trống liền kề nhau, nên xin mười máy cùng lúc dễ thành công hơn nhiều so với xin từng máy một — và nếu thêm máy vào một nhóm đã chạy lâu, khả năng gặp InsufficientInstanceCapacity là rất thật.

Đáp án

D — Dùng SERVICE QUOTAS để xin TĂNG HẠN MỨC EC2.

Vì sao đúng

Lỗi InstanceLimitExceeded nói thẳng nguyên nhân: đã chạm hạn mức số instance (tính theo vCPU) của tài khoản trong Region đó.

⚠ Điểm mấu chốt — hạn mức EC2 nay tính bằng vCPU:

Trước đây: giới hạn theo SỐ INSTANCE mỗi loại
        ↓
Hiện nay: giới hạn theo SỐ vCPU theo HỌ MÁY
        ↓
    Ví dụ: "Running On-Demand Standard
    (A, C, D, H, I, M, R, T, Z) instances"
      → mặc định thường vài trăm vCPU
        ↓
    Một m5.4xlarge = 16 vCPU
        ↓
    → triển khai hàng loạt máy lớn
      chạm trần rất nhanh
        ↓
    → và trần là THEO REGION, THEO TÀI KHOẢN

⚠ Xin tăng ở đâu và mất bao lâu:

Service Quotas console
        ↓
    Tìm "Running On-Demand Standard instances"
        ↓
    Request quota increase → khai số vCPU cần
        ↓
    Một số yêu cầu ĐƯỢC DUYỆT TỰ ĐỘNG (vài phút)
    Yêu cầu lớn → qua Support, có thể vài NGÀY
        ↓
    → với sự kiện lớn: XIN TRƯỚC vài ngày

⚠ Và các loại hạn mức EC2 tách bạch nhau:

On-Demand Standard   → họ A, C, D, H, I, M, R, T, Z
On-Demand G/VT       → GPU đồ hoạ
On-Demand P          → GPU tính toán
On-Demand Inf/Trn    → chip suy luận/huấn luyện
Spot                 → hạn mức RIÊNG cho Spot
Dedicated Hosts      → riêng theo họ máy
        ↓
    → tăng hạn mức Standard KHÔNG giúp gì
      cho Spot hay GPU

Xem thêm câu #11822 (lô 127): cùng chủ đề chạm hạn mức — ở đó là hạn mức 5 VPC mỗi Region khiến CloudFormation stack thất bại. Khoá nhất quán.

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

• C (dùng EC2 console để xin tăng hạn mức EBS) — đây là phương án gần nhất vì cũng là xin tăng hạn mức, nhưng sai loại hạn mức: lỗi là về số instance, không phải về dung lượng EBS. (Và nơi xin tăng là Service Quotas, không phải EC2 console.)

• B (khởi chạy ở một Availability Zone khác) — hạn mức vCPU áp cho CẢ REGION, không theo từng AZ. Đổi AZ không giúp gì.

• A (khởi chạy ở một VPC khác trong cùng Region) — hạn mức không liên quan gì tới VPC. Cùng một tài khoản, cùng một Region thì cùng một trần.

Ghi nhớ

⚠ Các lỗi về năng lực và hạn mức — đừng nhầm: | Lỗi | Nghĩa | Cách xử lý | |---|---|---| | InstanceLimitExceeded | chạm HẠN MỨC của tài khoản | xin tăng qua Service Quotas | | InsufficientInstanceCapacity | AWS hết năng lực ở AZ đó lúc này | đổi AZ, đổi loại máy, hoặc thử lại sau | | VcpuLimitExceeded | chạm hạn mức vCPU | xin tăng | | RequestLimitExceeded | gọi API quá nhanh | backoff luỹ thừa | | Client.VolumeLimitExceeded | chạm hạn mức EBS | xin tăng hạn mức EBS |

Từ khoá nhận diện:

"InstanceLimitExceeded" → Service Quotas, xin tăng vCPU "InsufficientInstanceCapacity" → năng lực của AWS, không phải hạn mức — đổi AZ/loại máy "cần chắc chắn có máy" → Capacity Reservation "sắp chạm hạn mức" → CloudWatch alarm trên AWS/Usage "tài khoản mới cần hạn mức cao" → Quota Request Template

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạn mức hiện tại | Service Quotas → tìm "Running On-Demand Standard instances" | | Đang dùng bao nhiêu | chỉ số AWS/Usage, hoặc cộng vCPU từ describe-instances | | Yêu cầu tăng tới đâu rồi | list-requested-service-quota-change-history |

Và một điều rất dễ gây bất ngờ với người mới quen hệ thống hạn mức mới: con số hạn mức là vCPU, không phải số máy. Một hạn mức "640" nghe rất rộng rãi, nhưng nếu đội máy của bạn dùng m5.4xlarge thì đó chỉ là 40 instance — và đây chính là lý do một đợt triển khai theo lô có thể chạy trơn tru vài lô đầu rồi đột ngột dừng lại.

Đáp án

D — Cấu hình IP-BASED DOMAIN ACCESS POLICY trên Amazon ES, thêm câu lệnh Allow chứa các dải CIDR RIÊNG của từng văn phòng chi nhánh.

Vì sao đúng

Đề có hai ràng buộc quan trọng: chỉ cho phép từ các chi nhánh, và GIỮ NGUYÊN DỮ LIỆU hiện có.

⚠ Điểm mấu chốt — ràng buộc "preserve existing data" loại hai phương án:

Domain đang có PUBLIC ENDPOINT
        ↓
    Muốn chuyển vào VPC
        ↓
    → KHÔNG chuyển tại chỗ được
    → phải TẠO DOMAIN MỚI trong VPC
      rồi di chuyển dữ liệu sang
        ↓
    Đề nói "while preserving existing data"
        ↓
    → phương án B và C đều đòi dựng lại domain
    → không thoả ràng buộc này

⚠ Giải pháp giữ nguyên domain — dùng access policy theo IP:

{
  "Effect": "Allow",
  "Principal": { "AWS": "*" },
  "Action": "es:*",
  "Resource": "arn:aws:es:...:domain/ten-domain/*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": [
        "10.10.0.0/16",
        "10.20.0.0/16"
      ]
    }
  }
}

    → chỉ request đến TỪ các dải IP đó
      mới được chấp nhận
    → mọi nơi khác trên internet bị TỪ CHỐI

⚠ Vì sao dùng IP RIÊNG của chi nhánh chứ không phải IP công cộng:

Người dùng kết nối qua SITE-TO-SITE VPN
        ↓
    Lưu lượng đi qua đường hầm VPN vào VPC
        ↓
    IP nguồn mà AWS nhìn thấy là
    IP RIÊNG của mạng chi nhánh
        ↓
    → khai đúng các dải CIDR riêng đó
        ↓
    (Nếu họ đi thẳng qua internet thì mới
     phải khai IP công cộng của văn phòng)

Xem thêm câu #11930 (cùng lô): ghi nhớ về việc Amazon Elasticsearch Service đã đổi tên thành Amazon OpenSearch Service từ tháng 9/2021 — cùng một dịch vụ, tên mới.

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

• C (dựng lại domain trong private subnet của VPC và đặt IP-based policy) — đây là phương án gần nhất và về bảo mật thì tốt hơn hẳn, nhưng chuyển domain vào VPC đòi tạo domain MỚI và di chuyển dữ liệu — trái ràng buộc "giữ nguyên dữ liệu hiện có" mà đề nêu rõ.

• B (dựng lại domain trong VPC với security group cho phép CIDR của chi nhánh) — cùng vấn đề như C: phải dựng lại domain.

• A (identity-based policy với ARN của từng kết nối VPN làm Allow statement) — kết nối VPN không phải là một IAM principal; không có cách nào cấp quyền cho một "ARN của VPN connection".

Ghi nhớ

⚠ Ba cách bảo vệ truy cập OpenSearch — bảng phải thuộc: | Cách | Nội dung | |---|---| | Domain access policy theo IP | aws:SourceIp với dải CIDR — dùng được với public endpoint | | Domain access policy theo IAM | principal là IAM user/role — request phải được ký SigV4 | | VPC access | domain nằm trong VPC, dùng security group — an toàn nhất | | Fine-grained access control | phân quyền tới index, document, field | | Kết hợp | VPC + FGAC + Cognito cho Dashboards |

Từ khoá nhận diện:

"giới hạn theo IP mà giữ nguyên domain" → IP-based access policy "an toàn nhất, chấp nhận dựng lại" → chuyển domain vào VPC "phân quyền tới từng index" → fine-grained access control "đăng nhập Dashboards bằng danh tính công ty" → Cognito + IdP "chuyển domain vào VPC" → KHÔNG chuyển tại chỗ được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách hiện tại | describe-domain-config → AccessPolicies | | Chặn có đúng không | thử gọi endpoint từ ngoài dải cho phép — phải nhận 403 | | IP nguồn AWS nhìn thấy | bật audit log, hoặc kiểm tra từ chính máy ở chi nhánh |

Và một hướng đi nên đặt vào lộ trình dù hôm nay chọn IP-based policy: chuyển domain vào VPC ở lần bảo trì lớn tiếp theo. Chính sách theo IP là biện pháp hợp lý khi không được phép dựng lại domain, nhưng endpoint vẫn nằm trên internet công cộng — nghĩa là chỉ cần một sai sót khi chỉnh sửa chính sách là toàn bộ dữ liệu lộ ra ngoài, một rủi ro mà mô hình VPC loại bỏ hoàn toàn.

Đáp án

C — Khai Principal là "*" và dùng aws:PrincipalOrgID làm ĐIỀU KIỆN.

Vì sao đúng

Đây là mẫu chuẩn của AWS để chia sẻ tài nguyên cho toàn bộ một tổ chức mà không mở công khai.

⚠ Điểm mấu chốt — Principal và Condition đóng hai vai khác nhau:

Principal: "*"
        ↓
    Nghĩa là "bất kỳ ai" — NHƯNG chưa xong
        ↓
Condition: aws:PrincipalOrgID = o-xxxxxxxxxx
        ↓
    → LỌC LẠI: chỉ danh tính THUỘC tổ chức đó
        ↓
    Kết quả:
      - mọi tài khoản trong tổ chức: ĐỌC ĐƯỢC
      - người ngoài, người ẩn danh: BỊ TỪ CHỐI
        ↓
    → không hề công khai

⚠ Chính sách viết đầy đủ:

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": ["s3:GetObject", "s3:ListBucket"],
  "Resource": [
    "arn:aws:s3:::bucket-dung-chung",
    "arn:aws:s3:::bucket-dung-chung/*"
  ],
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgID": "o-abc123xyz"
    }
  }
}

Chú ý HAI Resource:
    bucket        → cho s3:ListBucket
    bucket/*      → cho s3:GetObject
        ↓
    Thiếu /* → không đọc được đối tượng nào

⚠ Vì sao đây là cách HIỆU QUẢ NHẤT:

Liệt kê từng account id (phương án D)
        ↓
    → tài khoản MỚI vào tổ chức
      → PHẢI SỬA chính sách
    → tài khoản rời đi
      → phải nhớ gỡ ra
    → chính sách phình to, có giới hạn kích thước
        ↓
aws:PrincipalOrgID
        ↓
    → tài khoản mới TỰ ĐỘNG có quyền
    → tài khoản rời tổ chức TỰ ĐỘNG mất quyền
    → chính sách luôn ngắn gọn

Xem thêm câu #11852 (lô 128): cùng kỹ thuật — bucket policy với Condition (aws:sourceVpce) để giới hạn nguồn truy cập. Khoá nhất quán.

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

• B (khai aws:PrincipalOrgID làm PRINCIPAL với giá trị là organization ID) — đây là phương án gần nhất và dùng đúng khoá, nhưng sai vị trí: aws:PrincipalOrgID là một khoá ĐIỀU KIỆN, không phải một principal. Trường Principal chỉ nhận ARN, account id, dịch vụ AWS, hoặc "*".

• D (liệt kê toàn bộ số tài khoản trong một mảng làm principal) — hoạt động được nhưng không hiệu quả: phải cập nhật mỗi khi tổ chức thay đổi, và bucket policy có giới hạn 20 KB.

• A (khai tài khoản quản lý của tổ chức làm principal) — chỉ cấp quyền cho đúng tài khoản đó, không cấp cho các tài khoản thành viên.

Ghi nhớ

⚠ Trường Principal nhận những gì — bảng phải thuộc: | Hợp lệ | Ví dụ | |---|---| | ARN của IAM user/role | arn:aws:iam::111122223333:role/Doc | | Account id hoặc root ARN | "111122223333" hoặc arn:aws:iam::111122223333:root | | Dịch vụ AWS | {"Service": "cloudtrail.amazonaws.com"} | | "*" | bất kỳ ai — PHẢI kèm Condition | | KHÔNG hợp lệ | aws:PrincipalOrgID (đó là khoá điều kiện) | | Không hợp lệ | tên IAM group |

Từ khoá nhận diện:

"chia sẻ cho toàn tổ chức" → Principal: "*" + aws:PrincipalOrgID "không được public" → luôn kèm Condition khi dùng "*" "chỉ một OU cụ thể" → aws:PrincipalOrgPaths "chỉ từ VPC của mình" → aws:sourceVpce hoặc aws:SourceVpc "ép mã hoá khi tải lên" → Deny + Null trên s3:x-amz-server-side-encryption

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bucket có bị public không | IAM Access Analyzer — phải không báo public | | Người ngoài tổ chức có vào được không | thử từ một tài khoản ngoài — phải 403 | | Người trong tổ chức đọc được không | aws s3 ls s3://bucket từ một tài khoản thành viên |

Và một cấu hình rất nên bật cùng lúc với chính sách này: Block Public Access ở cấp tài khoản. Nó không cản trở việc chia sẻ trong tổ chức — vì aws:PrincipalOrgID không phải là truy cập công khai — nhưng nó là lưới an toàn nếu sau này có ai đó vô tình xoá mất mệnh đề Condition, biến một bucket nội bộ thành bucket mở ra internet chỉ bằng một lần chỉnh sửa.

Đáp án

A — Cấu hình file system ở chế độ PROVISIONED THROUGHPUT.

Vì sao đúng

Đề có một manh mối rất đặc trưng: "khối lượng dữ liệu không thay đổi nhiều" nhưng độ trễ tăng khi tải cao.

⚠ Điểm mấu chốt — chế độ Bursting gắn thông lượng với DUNG LƯỢNG:

EFS Bursting Throughput (chế độ cũ, mặc định)
        ↓
    Thông lượng cơ sở tỉ lệ với DUNG LƯỢNG lưu trữ
      khoảng 50 KB/s cho mỗi GB
        ↓
    File system NHỎ → thông lượng cơ sở THẤP
        ↓
    Có BURST CREDIT để vượt lên tạm thời
        ↓
    Tải cao kéo dài → CREDIT CẠN
        ↓
    → thông lượng bị bóp về mức cơ sở
    → ĐỘ TRỄ TĂNG
        ↓
    Dữ liệu ít mà tải cao
      → đúng kịch bản tệ nhất của Bursting

⚠ Provisioned Throughput tách thông lượng khỏi dung lượng:

Provisioned Throughput
        ↓
    Bạn KHAI THẲNG mức MB/s cần
        ↓
    → độc lập hoàn toàn với dung lượng
    → không có credit để cạn
    → thông lượng ổn định mọi lúc
        ↓
    Đúng cho: dữ liệu ít, truy cập nhiều

⚠ Nhưng lựa chọn hiện đại còn tốt hơn — Elastic Throughput:

EFS Elastic Throughput (mặc định cho file system mới)
        ↓
    Tự co giãn theo nhu cầu thật
        ↓
    → không phải đoán mức cần
    → không có credit
    → chỉ trả tiền cho lượng dữ liệu ĐỌC/GHI thật
        ↓
    Phù hợp nhất khi tải BIẾN ĐỘNG
        ↓
    Provisioned vẫn tốt hơn khi:
      tải cao ỔN ĐỊNH và đoán được
      → chi phí rẻ hơn Elastic

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

• B (cấu hình chế độ Bursting Throughput) — đây là phương án gần nhất vì cũng là một chế độ thông lượng, nhưng Bursting chính là chế độ đang gây ra vấn đề. Chuyển sang nó (hoặc giữ nguyên) không giải quyết gì.

• D (xoá các tệp không dùng khỏi file system) — đi ngược lại: với chế độ Bursting, dung lượng ÍT HƠN nghĩa là thông lượng cơ sở THẤP HƠN, làm vấn đề tệ thêm.

• C (bật mã hoá khi truyền) — mã hoá không cải thiện hiệu năng; nếu có thì nó thêm một chút chi phí tính toán.

Ghi nhớ

⚠ Ba chế độ thông lượng của EFS — bảng phải thuộc: | Chế độ | Cơ chế | Dùng khi | |---|---|---| | Elastic | tự co giãn, trả theo lượng đọc/ghi | tải BIẾN ĐỘNG — mặc định hiện nay | | Provisioned | khai thẳng MB/s | tải cao ỔN ĐỊNH, dữ liệu ít | | Bursting | thông lượng theo DUNG LƯỢNG + burst credit | dữ liệu lớn, tải nhẹ | | Triệu chứng Bursting cạn | BurstCreditBalance về 0, độ trễ tăng | |

Từ khoá nhận diện:

"dữ liệu ít, tải cao, độ trễ tăng" → Provisioned (hoặc Elastic) Throughput "tải biến động khó đoán" → Elastic Throughput "độ trễ EFS cao" → kiểm tra BurstCreditBalance trước tiên "cần thông lượng cực cao cho HPC" → FSx for Lustre "chi phí EFS cao" → lifecycle policy chuyển sang IA / Archive

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cạn credit không | vẽ BurstCreditBalance trong khung giờ chậm | | Đang ở chế độ nào | describe-file-systems → ThroughputMode | | Thông lượng thật là bao nhiêu | PermittedThroughput và MeteredIOBytes |

Và một điều nghe rất phản trực giác nhưng đúng với chế độ Bursting: file system càng ít dữ liệu thì càng chậm. Đó là lý do một số đội từng "khắc phục" bằng cách nạp thêm dữ liệu rác vào EFS để tăng thông lượng cơ sở — một cách làm có hiệu quả thật nhưng rất lãng phí, và Provisioned hoặc Elastic Throughput chính là câu trả lời đúng cho vấn đề đó.

Đáp án

A — Instance store volume KHÔNG được gắn vào máy EC2.

Vì sao đúng

Đây là một chi tiết rất dễ nhầm: chỉ số DiskReadBytes của EC2 KHÔNG đo hoạt động của EBS.

⚠ Điểm mấu chốt — hai họ chỉ số đĩa hoàn toàn khác nhau:

DiskReadBytes / DiskWriteBytes
DiskReadOps  / DiskWriteOps
        ↓
    → ĐO INSTANCE STORE (ổ đĩa cục bộ, ephemeral)
        ↓
    Máy KHÔNG CÓ instance store
        ↓
    → chỉ số luôn bằng 0
    → đúng hiện tượng trong đề

VolumeReadBytes / VolumeWriteBytes
VolumeReadOps  / VolumeWriteOps
VolumeQueueLength, VolumeIdleTime
        ↓
    → ĐO EBS VOLUME
        ↓
    Namespace: AWS/EBS

⚠ Vì sao rất nhiều máy có chỉ số này bằng 0:

Phần lớn loại instance hiện đại
      (t3, m5, c5, r5…)
        ↓
    KHÔNG CÓ instance store
        ↓
    → DiskReadBytes luôn 0
    → hoàn toàn bình thường, không phải lỗi
        ↓
Các họ CÓ instance store:
    hậu tố `d`   → m5d, c5d, r5d, i3, i4i
    họ lưu trữ   → d3, h1
        ↓
    → chỉ những máy này mới có số liệu

⚠ Và nhớ: chỉ số đĩa của hypervisor KHÔNG cho biết dung lượng còn trống:

Muốn biết ổ còn bao nhiêu chỗ
        ↓
    → PHẢI cài CloudWatch agent
    → chỉ số disk_used_percent
        ↓
    Hypervisor chỉ thấy HOẠT ĐỘNG đọc ghi,
    không thấy bên trong file system

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

• B (EBS volume không được gắn vào máy) — đây là phương án gần nhất và là nhầm lẫn phổ biến nhất về chủ đề này, nhưng hoạt động của EBS được đo bằng VolumeReadBytes, không phải DiskReadBytes. Hơn nữa mọi máy EBS-backed đều có ít nhất một volume gốc, nên tình huống này gần như không thể xảy ra.

• C (chưa cài CloudWatch agent) — DiskReadBytes là chỉ số có sẵn từ hypervisor, không cần agent. Agent chỉ cần cho bộ nhớ và dung lượng đĩa đã dùng.

• D (chưa bật detailed monitoring) — detailed monitoring chỉ tăng tần suất từ 5 phút xuống 1 phút, không thêm chỉ số mới và không làm giá trị 0 thành khác 0.

Ghi nhớ

⚠ Chỉ số đĩa — đo cái gì, bảng phải thuộc: | Chỉ số | Đo gì | Namespace | |---|---|---| | DiskReadBytes / DiskWriteBytes | INSTANCE STORE | AWS/EC2 | | DiskReadOps / DiskWriteOps | INSTANCE STORE | AWS/EC2 | | VolumeReadBytes / VolumeWriteBytes | EBS | AWS/EBS | | VolumeQueueLength | hàng đợi I/O của EBS — cao là nghẽn | AWS/EBS | | EBSReadBytes / EBSWriteBytes | EBS, nhìn từ phía instance (máy hỗ trợ) | AWS/EC2 | | disk_used_percent | dung lượng đã dùng — CẦN AGENT | CWAgent |

Từ khoá nhận diện:

"DiskReadBytes bằng 0" → máy không có instance store — bình thường "hoạt động của EBS" → VolumeReadBytes, namespace AWS/EBS "dung lượng đĩa còn lại" → CloudWatch agent "detailed monitoring" → chỉ đổi TẦN SUẤT, không thêm chỉ số "EBS chậm" → VolumeQueueLength, EBSIOBalance%, EBSByteBalance%

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Máy có instance store không | describe-instances → xem InstanceStoreSupported của loại máy | | Hoạt động EBS thế nào | CloudWatch → namespace AWS/EBS → VolumeReadBytes | | Ổ còn bao nhiêu chỗ | cài CloudWatch agent, hoặc df -h trên máy |

Và một hệ quả thực tế của sự nhầm lẫn này: nhiều đội dựng dashboard theo dõi I/O bằng DiskReadBytes rồi thấy đường đồ thị phẳng lì ở 0 và kết luận hệ thống rất nhàn. Trong khi thực tế toàn bộ hoạt động đọc ghi đang diễn ra trên EBS và được ghi ở một namespace hoàn toàn khác — nên khi chọn chỉ số cho dashboard, hãy kiểm tra namespace trước khi tin vào một đường đồ thị đẹp.

Đáp án

A — Thêm tài khoản thứ hai làm KEY USER trong key policy của customer managed KMS key, rồi COPY và CHIA SẺ snapshot với tài khoản đích bằng chính khoá đó.

Vì sao đúng

Có một quy tắc rất cứng: chia sẻ snapshot mã hoá thì phải chia sẻ CẢ KHOÁ.

⚠ Điểm mấu chốt — snapshot mã hoá không tự đọc được ở tài khoản khác:

Snapshot được mã hoá bằng CMK ở tài khoản A
        ↓
    Chia sẻ snapshot với tài khoản B
        ↓
    Tài khoản B THẤY snapshot
        ↓
    Nhưng KHÔNG có quyền dùng khoá
        ↓
    → không copy được, không khôi phục được
    → lỗi AccessDenied liên quan tới KMS
        ↓
    → PHẢI cấp quyền dùng khoá cho tài khoản B
      trong KEY POLICY

⚠ Quyền KMS cần cấp cho tài khoản đích:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::<tai-khoan-B>:root"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey",
    "kms:CreateGrant",
    "kms:GenerateDataKey*",
    "kms:ReEncrypt*"
  ],
  "Resource": "*"
}

⚠ Và một quy tắc TUYỆT ĐỐI phải nhớ:

KHOÁ MẶC ĐỊNH CỦA AWS (aws/rds)
        ↓
    KHÔNG chia sẻ liên tài khoản được
    KHÔNG sửa key policy được
        ↓
    → snapshot mã hoá bằng aws/rds
      KHÔNG BAO GIỜ chia sẻ được
        ↓
    → BẮT BUỘC dùng CUSTOMER MANAGED KEY
        ↓
    Đây là lý do phương án D sai

⚠ Quy trình đầy đủ, ba bước:

1. Tài khoản A: sửa KEY POLICY,
   thêm tài khoản B làm key user
        ↓
2. Tài khoản A: chia sẻ snapshot
     modify-db-snapshot-attribute
       --attribute-name restore
       --values-to-add <tai-khoan-B>
        ↓
3. Tài khoản B: COPY snapshot về,
   mã hoá lại bằng KHOÁ CỦA CHÍNH HỌ
     copy-db-snapshot --kms-key-id <CMK-cua-B>
        ↓
    → tài khoản B có bản độc lập
    → A xoá snapshot cũng không ảnh hưởng

Xem thêm câu #11867 (lô 128): cùng chủ đề chia sẻ snapshot RDS, ở đó trọng tâm là snapshot TỰ ĐỘNG không chia sẻ được, phải dùng snapshot THỦ CÔNG. Khoá nhất quán.

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

• D (copy snapshot rồi mã hoá bằng KHOÁ MẶC ĐỊNH của AWS, thêm tài khoản thứ hai làm key user) — đây là phương án gần nhất và quy trình gần đúng, nhưng không thêm key user vào khoá mặc định aws/rds được — key policy của khoá do AWS quản lý là không sửa được.

• C (tạo bản copy KHÔNG mã hoá rồi chia sẻ) — vi phạm thẳng yêu cầu "CSDL phải luôn được mã hoá". Và đó cũng là một rủi ro bảo mật thật.

• B (dùng Lambda trích dữ liệu ra S3 rồi Lambda thứ hai tạo lại snapshot) — tự dựng lại một quy trình rất phức tạp cho việc mà AWS đã có sẵn cơ chế; rủi ro mất hoặc sai dữ liệu rất cao.

Ghi nhớ

⚠ Chia sẻ snapshot RDS — bảng phải thuộc: | Loại snapshot | Chia sẻ được | |---|---| | Manual, KHÔNG mã hoá | được, đơn giản | | Manual, mã hoá bằng CUSTOMER MANAGED KEY | được — phải chia sẻ CẢ KHOÁ | | Manual, mã hoá bằng aws/rds | KHÔNG BAO GIỜ | | Automated snapshot | KHÔNG — phải copy thành manual trước | | Chia sẻ công khai | KHÔNG với snapshot mã hoá |

Từ khoá nhận diện:

"chia sẻ snapshot mã hoá" → customer managed key + chia sẻ key policy "snapshot tự động" → KHÔNG chia sẻ được — copy thành manual trước "khoá mặc định aws/rds" → không chia sẻ liên tài khoản được "tự động hoá việc sao chép định kỳ" → AWS Backup với cross-account copy "mã hoá CSDL đã tồn tại" → snapshot → copy có mã hoá → restore

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Snapshot đã chia sẻ chưa | describe-db-snapshot-attributes | | Key policy có đúng không | get-key-policy --key-id ... --policy-name default | | Tài khoản đích copy được không | ở tài khoản B: copy-db-snapshot — lỗi thường là thiếu quyền KMS |

Và một lời khuyên nên áp dụng ngay từ khi tạo CSDL: luôn mã hoá bằng customer managed key thay vì khoá mặc định aws/rds. Chi phí gần như không đáng kể, nhưng nó giữ cho bạn khả năng chia sẻ snapshot, khả năng kiểm toán việc dùng khoá qua CloudTrail, và khả năng thu hồi quyền truy cập — ba thứ mà khoá mặc định không bao giờ cho bạn.

Đáp án

B — Dùng SERVICE QUOTAS để xin TĂNG HẠN MỨC EC2.

Vì sao đúng

Lỗi InstanceLimitExceeded có đúng một nghĩa: tài khoản đã chạm hạn mức số instance (tính bằng vCPU) trong Region đó.

⚠ Điểm mấu chốt — hạn mức theo TÀI KHOẢN và theo REGION:

InstanceLimitExceeded
        ↓
    Không phải AWS hết máy
    Không phải AZ nào có vấn đề
        ↓
    → là TRẦN do AWS đặt cho tài khoản của bạn
        ↓
    Phạm vi: THEO REGION, THEO TÀI KHOẢN
        ↓
    → đổi AZ, đổi VPC, đổi subnet
      đều KHÔNG giúp gì

⚠ Đơn vị hạn mức nay là vCPU:

"Running On-Demand Standard
 (A, C, D, H, I, M, R, T, Z) instances"
        ↓
    Tính bằng SỐ vCPU, không phải số máy
        ↓
    m5.4xlarge = 16 vCPU
    → hạn mức 640 vCPU chỉ đủ cho 40 máy
        ↓
    → chạm trần nhanh hơn nhiều so với cảm giác

⚠ Xin tăng và chuẩn bị trước:

Service Quotas console
        ↓
    Tìm đúng quota → Request increase
        ↓
    Một số duyệt TỰ ĐỘNG trong vài phút
    Yêu cầu lớn → qua Support, có thể vài NGÀY
        ↓
    Đề nói "ahead of an expected increase in demand"
        ↓
    → xin TRƯỚC vài ngày là việc phải làm
    → và đặt alarm ở 80% để lần sau biết sớm

Xem thêm câu #11945 (CÙNG LÔ): gần như cùng một câu hỏi, cùng đáp án Service Quotas. Chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là D, ở đây là B). Và #11822 (lô 127): cùng chủ đề chạm hạn mức, ở đó là hạn mức 5 VPC mỗi Region. Khoá nhất quán ở cả ba câu.

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

• D (khởi chạy ở một Availability Zone khác) — đây là phương án gần nhất và đúng cho một lỗi KHÁC: InsufficientInstanceCapacity (AWS tạm hết năng lực ở AZ đó). Nhưng hạn mức thì áp cho cả Region, nên đổi AZ không giúp gì.

• A (khởi chạy ở một VPC khác) — hạn mức không liên quan gì tới VPC.

• C (thêm máy vào một placement group) — placement group ảnh hưởng tới VỊ TRÍ ĐẶT MÁY, không nâng hạn mức. (Thực tế nó còn có thể làm khó hơn vì đòi năng lực liền kề nhau.)

Ghi nhớ

⚠ Hai lỗi rất dễ nhầm — bảng phải thuộc: | Lỗi | Nghĩa | Cách xử lý | |---|---|---| | InstanceLimitExceeded | chạm HẠN MỨC của tài khoản | xin tăng qua Service Quotas | | InsufficientInstanceCapacity | AWS tạm hết năng lực ở AZ đó | đổi AZ, đổi loại máy, thử lại sau | | VcpuLimitExceeded | chạm hạn mức vCPU | xin tăng | | RequestLimitExceeded | gọi API quá nhanh | backoff luỹ thừa | | SpotMaxPriceTooLow | giá Spot đặt quá thấp | nâng giá trần |

Từ khoá nhận diện:

"InstanceLimitExceeded" → Service Quotas "InsufficientInstanceCapacity" → đổi AZ hoặc loại máy — không phải hạn mức "phải chắc chắn có máy" → Capacity Reservation "sắp chạm hạn mức" → CloudWatch alarm trên AWS/Usage "chuẩn bị cho đợt tăng tải đã biết trước" → xin tăng hạn mức TRƯỚC vài ngày

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạn mức hiện tại | Service Quotas → "Running On-Demand Standard instances" | | Đang dùng bao nhiêu vCPU | chỉ số AWS/Usage, hoặc cộng từ describe-instances | | Yêu cầu tăng tới đâu | list-requested-service-quota-change-history |

Và một việc rất nên làm ngay sau khi xử lý xong sự cố này: đặt CloudWatch alarm ở mức 80% hạn mức vCPU cho mọi Region đang dùng. Chi phí gần như bằng không, và nó biến một sự cố phát hiện giữa lúc triển khai thành một thông báo đến vài tuần trước đó — đúng khoảng thời gian cần để một yêu cầu nâng hạn mức lớn được duyệt.

Đáp án

B và E — MÔ TẢ (describe) các load balancer, và GỌI (invoke) một hàm AWS Lambda.

Vì sao đúng

Chính sách cấp bốn nhóm quyền, và chỉ cần đọc kỹ dấu * đặt ở đâu.

⚠ Điểm mấu chốt — đọc từng dòng Action:

"rds:CreateDBInstance"
        ↓
    → CHỈ tạo instance RDS
    → KHÔNG có Delete, KHÔNG có Modify

"elasticloadbalancing:*"
        ↓
    → MỌI hành động với load balancer
    → bao gồm DescribeLoadBalancers  ← đáp án B

"lambda:*"
        ↓
    → MỌI hành động với Lambda
    → bao gồm InvokeFunction         ← đáp án E

"sns:ListTopics*"
        ↓
    → chỉ các action BẮT ĐẦU bằng ListTopics
    → KHÔNG có DeleteTopic

⚠ Vì sao lambda:* KHÔNG cho tạo IAM role:

Tạo role cho Lambda cần:
        ↓
    iam:CreateRole
    iam:AttachRolePolicy
    iam:PassRole
        ↓
    Đây là các action của DỊCH VỤ IAM,
    không phải của Lambda
        ↓
    → `lambda:*` không bao gồm chúng
    → phương án C sai
        ↓
    Đây là bẫy rất hay gặp: mỗi tiền tố dịch vụ
    chỉ phủ action của CHÍNH dịch vụ đó

⚠ Và một điều nữa cần nhớ về Resource: "*":

Resource: "*"
        ↓
    → mọi tài nguyên trong tài khoản
        ↓
    Kết hợp với `lambda:*` và
    `elasticloadbalancing:*`
        ↓
    → người mới này XOÁ được mọi hàm Lambda
      và mọi load balancer
        ↓
    → chính sách QUÁ RỘNG cho một người mới vào

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

• A (xoá một CSDL RDS) — đây là phương án gần nhất vì chính sách có nhắc tới RDS, nhưng chỉ cấp đúng rds:CreateDBInstance. Xoá cần rds:DeleteDBInstance — không có trong danh sách.

• D (xoá một SNS topic) — chính sách chỉ cấp sns:ListTopics*. Xoá cần sns:DeleteTopic.

• C (tạo IAM role cho một hàm Lambda) — cần iam:CreateRole và iam:PassRole, thuộc dịch vụ IAM, không nằm trong lambda:*.

Ghi nhớ

⚠ Đọc một IAM policy — bảng phải thuộc: | Trường | Ý nghĩa | |---|---| | Version | luôn là "2012-10-17" — không phải ngày tháng bạn đặt | | Effect | Allow hoặc Deny | | Action | dichvu:HanhDong — wildcard * áp trong CÙNG dịch vụ | | Resource | ARN — "*" là mọi tài nguyên | | Principal | chỉ có trong resource policy, không có trong identity policy | | Condition | ràng buộc thêm |

Từ khoá nhận diện:

"dichvu:*" → mọi action CỦA DỊCH VỤ ĐÓ, không lan sang dịch vụ khác "iam:PassRole" → cần khi giao một role cho dịch vụ khác dùng "chính sách quá rộng" → IAM Access Analyzer, siết theo dữ liệu thật "Deny thắng Allow" → explicit Deny luôn thắng "chính sách không có tác dụng" → kiểm tra SCP, permissions boundary, Resource

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Một action cụ thể có được phép không | IAM Policy Simulator | | Người dùng thực sự dùng gì | Access Advisor, tab "Last accessed" | | Vì sao bị từ chối | CloudTrail — errorMessage nói rõ chính sách nào chặn |

Và một công cụ nên dùng thay cho việc đọc chính sách bằng mắt: IAM Policy Simulator. Nó nhận vào một danh tính, một action và một tài nguyên, rồi trả lời cho phép hay từ chối kèm lý do — bao gồm cả ảnh hưởng của SCP và permissions boundary, những thứ rất khó suy ra chỉ bằng cách đọc một tài liệu JSON đơn lẻ.

Đáp án

C — Dùng AWS SECRETS MANAGER: tạo secret cho CSDL, chọn instance RDS, cấu hình lịch XOAY TỰ ĐỘNG, và sửa hàm Lambda đọc thông tin đăng nhập từ đó.

Vì sao đúng

Đề đòi hai thứ — không lưu mật khẩu dạng thô, và xoay mỗi 30 ngày — với ít công vận hành nhất. Chỉ Secrets Manager làm cả hai sẵn có.

⚠ Điểm mấu chốt — xoay mật khẩu là việc khó, và Secrets Manager làm sẵn:

Chọn "Credentials for Amazon RDS database"
        ↓
    Chọn instance RDS trong danh sách
        ↓
    AWS TỰ TẠO hàm Lambda xoay mật khẩu
      (từ template có sẵn cho từng động cơ)
        ↓
    Đặt chu kỳ: 30 ngày
        ↓
    → KHÔNG viết một dòng mã xoay nào

⚠ Và chiến lược bốn nhãn giữ cho ứng dụng không đứt:

AWSCURRENT   → bản đang dùng
AWSPENDING   → bản mới, đang được kiểm thử
AWSPREVIOUS  → bản trước, giữ để lùi lại
        ↓
    Bốn bước: createSecret → setSecret
              → testSecret → finishSecret
        ↓
    → chỉ đổi AWSCURRENT khi bản mới
      ĐÃ KẾT NỐI THÀNH CÔNG
    → không có khoảng thời gian mất kết nối

⚠ Lambda đọc secret thế nào cho hiệu quả:

Gọi GetSecretValue qua SDK
        ↓
    Quyền: secretsmanager:GetSecretValue
    trên ĐÚNG ARN của secret đó
        ↓
    CACHE trong biến toàn cục
    → tái sử dụng qua các lần gọi
    → làm mới khi gặp lỗi xác thực
        ↓
    Hoặc dùng LAMBDA EXTENSION của
    Parameter Store & Secrets Manager
    → có cache sẵn, không phải tự viết

Xem thêm câu #11844 (lô 128): gần như cùng một câu hỏi, cùng đáp án Secrets Manager với xoay tự động. Chỉ khác chữ cái vì bộ đề xáo thứ tự phương án (ở đó là D, ở đây là C). Khoá nhất quán.

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

• A (Parameter Store SecureString, tự viết Lambda xoay, hẹn giờ bằng EventBridge) — đây là phương án gần nhất và hoàn toàn khả thi, cũng thoả yêu cầu không lưu dạng thô. Nhưng Parameter Store KHÔNG có cơ chế xoay tích hợp: bạn phải tự viết, tự kiểm thử, tự xử lý cửa sổ chuyển đổi. Trái với "hiệu quả vận hành nhất".

• B (dùng KMS mã hoá mật khẩu rồi lưu vào biến môi trường) — mỗi lần xoay phải cập nhật biến môi trường và triển khai lại hàm; rất nhiều việc và dễ sót.

• D (dùng ACM tạo chứng chỉ công khai tự xoay 30 ngày, xác thực CSDL bằng chứng chỉ) — hiểu sai vai trò của ACM: chứng chỉ công khai dùng cho TLS của website, không phải để xác thực người dùng CSDL. (Xác thực không mật khẩu cho RDS là IAM database authentication, một cơ chế khác hẳn.)

Ghi nhớ

⚠ Secrets Manager ↔ Parameter Store — bảng phải thuộc: | | Secrets Manager | Parameter Store | |---|---|---| | Xoay tự động | CÓ — tích hợp sẵn với RDS, Redshift, DocumentDB | KHÔNG — phải tự viết | | Chi phí | có phí mỗi secret mỗi tháng | Standard MIỄN PHÍ | | Sao chép đa Region | có sẵn | không | | Chia sẻ liên tài khoản | resource policy | không trực tiếp | | Dùng khi | bí mật cần XOAY | cấu hình, tham số |

Từ khoá nhận diện:

"xoay mật khẩu tự động" → Secrets Manager, luôn luôn "lưu cấu hình, miễn phí" → Parameter Store "ít công vận hành nhất" → dùng tính năng có sẵn, đừng tự viết "mật khẩu trong biến môi trường" → luôn SAI "bỏ hẳn mật khẩu CSDL" → IAM database authentication

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lịch xoay đã bật chưa | describe-secret → RotationEnabled | | Xoay có hỏng không | CloudWatch Logs của hàm xoay | | Ứng dụng có chịu được không | rotate-secret --rotate-immediately ở staging |

Và một việc rất nên làm sau khi bật xoay tự động: đặt CloudWatch alarm cho lỗi của chính hàm xoay. Đây là tác vụ chỉ chạy mỗi 30 ngày một lần, nên nếu nó hỏng lặng lẽ thì bạn sẽ chỉ biết vào lúc tệ nhất — khi mật khẩu cũ hết hiệu lực và mọi hàm Lambda đồng loạt mất kết nối tới CSDL.