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

Đáp án

B — Dùng runbook AWSSupport-ExecuteEC2Rescue để khôi phục instance bị hỏng.

Vì sao đúng

Đây là một Automation runbook do AWS xây sẵn, chính là thứ đội hỗ trợ AWS dùng khi bạn mở ticket về instance không khởi động lên được hay không kết nối được.

⚠ Điểm mấu chốt: nó sửa được cả những lỗi khiến bạn KHÔNG vào được máy để sửa:

Instance hỏng: không SSH/RDP được, không boot lên được
        ↓
    Chạy AWSSupport-ExecuteEC2Rescue
        ↓
    1. Tự dừng instance hỏng
    2. Tách volume gốc ra
    3. Gắn volume đó vào một instance "cứu hộ" tạm
    4. Chạy công cụ EC2Rescue để sửa
    5. Gắn volume trở lại, khởi động lại instance
    6. Xoá instance cứu hộ
        ↓
    → toàn bộ tự động, không cần ai đăng nhập vào máy hỏng

⚠ Nó sửa được những gì:

⚠ Một điều kiện tiên quyết dễ quên:

Runbook cần TẠO instance cứu hộ trong VPC của instance hỏng
        ↓
    → cần subnet dùng được và quyền EC2 tương ứng
        ↓
    → và runbook TỰ TẠO snapshot của volume gốc trước khi động vào
        (đây là lưới an toàn quan trọng, đừng tắt)

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

• A (hiện chưa khôi phục tự động được) — sai; ngoài runbook này, EC2 còn có auto recovery dựng sẵn cho lỗi phần cứng host (StatusCheckFailed_System), và CloudWatch alarm với ec2:recover cũng làm được từ lâu.

• C (AWS-UpdateWindowsAmi) — đây là phương án gần nhất vì nó cũng là một Automation runbook có thật của AWS. Nhưng công việc của nó là cập nhật một AMI Windows (khởi chạy từ AMI, cài bản vá, tạo AMI mới), hoàn toàn không liên quan tới việc cứu một instance đang hỏng.

• D (AWS-UpdateCloudFormationStackWithApproval) — runbook có thật, nhưng dùng để cập nhật một CloudFormation stack sau khi có người phê duyệt. Không dính gì tới instance hỏng.

Ghi nhớ

⚠ Các runbook Automation dựng sẵn hay gặp trong đề — bảng phải thuộc: | Runbook | Việc | |---|---| | AWSSupport-ExecuteEC2Rescue | cứu instance không boot / không kết nối được | | AWS-UpdateWindowsAmi | vá và tạo AMI Windows mới | | AWS-RestartEC2Instance | khởi động lại instance | | AWSSupport-TroubleshootSSH | chẩn đoán lỗi SSH | | AWS-CreateSnapshot | tạo snapshot EBS | | AWSSupport-ResetAccess | đặt lại khoá SSH / mật khẩu quản trị |

Từ khoá nhận diện:

"instance hỏng, không vào được" → AWSSupport-ExecuteEC2Rescue "host phần cứng lỗi" → EC2 auto recovery (StatusCheckFailed_System) "ứng dụng treo nhưng máy vẫn sống" → health check của ASG, thay máy "quên khoá SSH" → AWSSupport-ResetAccess "vá hàng loạt" → Patch Manager

⚠ Ba loại status check của EC2 — phân biệt được là chọn đúng công cụ: | Check | Hỏng nghĩa là | Chữa | |---|---|---| | System status check | hạ tầng AWS lỗi | stop/start (đổi host) hoặc auto recovery | | Instance status check | hệ điều hành hoặc cấu hình của bạn lỗi | EC2Rescue, sửa cấu hình | | EBS status check | volume đính kèm có vấn đề | kiểm tra volume |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance hỏng ở đâu | describe-instance-status — xem system hay instance check trượt | | Xem màn hình máy | get-console-output và ảnh chụp console — hay thấy đúng dòng lỗi boot | | Runbook chạy tới đâu | lịch sử Automation trong Systems Manager console |

Và một lời khuyên: hãy chạy get-console-output trước khi chạy bất kỳ công cụ cứu hộ nào. Đầu ra console thường chỉ thẳng ra nguyên nhân — một dòng fstab sai, một kernel panic, một hệ thống tệp cần fsck — và biết trước nguyên nhân sẽ giúp bạn phân biệt được ca sửa được với ca mà cách nhanh nhất là dựng lại máy mới từ AMI.

Đáp án

A, B, C — ba điều đúng khi đổi loại instance:

• C — Phải DỪNG instance EBS-backed trước khi đổi loại. AWS chuyển instance sang phần cứng mới, nhưng instance id KHÔNG đổi.
• B — Chỉ đổi cỡ được nếu ổ gốc là EBS volume.
• A — Nếu instance nằm trong Auto Scaling group, ASG sẽ đánh dấu instance đã dừng là unhealthy, có thể chấm dứt nó và khởi chạy máy thay thế.

Vì sao đúng

⚠ Điều C — quy trình đổi loại instance:

    stop instance
        ↓
    modify-instance-attribute --instance-type
        ↓
    start instance
        ↓
    → AWS đặt instance lên một host phần cứng khác
    → instance id GIỮ NGUYÊN
    → IP riêng và Elastic IP giữ nguyên
    → IP công cộng tự động thì MẤT (cấp mới khi start)

⚠ Điều B — vì sao instance store không đổi cỡ được:

Ổ gốc là instance store
        ↓
    Đĩa gắn vật lý vào chính host đó
        ↓
    stop = mất dữ liệu (thật ra còn KHÔNG stop được)
        ↓
    → không có cách nào chuyển sang host khác
    → muốn đổi cỡ thì phải dựng máy mới từ AMI

⚠ Điều A — cái bẫy chết người khi instance nằm trong ASG:

Bạn stop instance để đổi loại
        ↓
    ASG health check thấy máy không phản hồi
        ↓
    → đánh dấu unhealthy → CHẤM DỨT nó
        ↓
    → bạn quay lại thì máy đã biến mất, thay bằng máy mới
        ↓
Chữa: đưa instance vào STANDBY trước khi stop
      aws autoscaling enter-standby --instance-ids i-xxx \
          --auto-scaling-group-name ten-asg \
          --should-decrement-desired-capacity

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

• E (instance mới giữ nguyên IP công cộng, IP riêng, Elastic IP và IPv6) — đây là phương án gần nhất và đúng gần hết: IP riêng, Elastic IP và IPv6 thật sự được giữ. Nhưng IP công cộng tự động (auto-assigned) thì MẤT khi dừng máy, và được cấp một địa chỉ khác lúc khởi động lại. Chỉ sai một chi tiết là cả phương án sai — và đây đúng là chi tiết làm hỏng cấu hình DNS của nhiều người.

• D (không có gián đoạn vì AWS chuyển ứng dụng sang máy mới) — sai hoàn toàn: bắt buộc phải dừng máy, nên chắc chắn có gián đoạn. AWS không "chuyển ứng dụng" đi đâu cả.

• F (đổi cỡ được với cả instance store, chỉ khởi động lâu hơn) — sai; instance store-backed không đổi loại được, không phải "chậm hơn".

Ghi nhớ

⚠ Cái gì giữ, cái gì mất khi stop/start một instance — bảng phải thuộc: | Thứ | Sau stop/start | |---|---| | Instance ID | giữ | | IP riêng (private IPv4) | giữ | | Elastic IP | giữ (nếu đã gắn) | | IPv6 | giữ | | IP công cộng tự động | MẤT — cấp địa chỉ mới | | Dữ liệu EBS | giữ | | Dữ liệu instance store | MẤT | | RAM | MẤT | | Host vật lý | đổi sang máy khác |

Từ khoá nhận diện:

"đổi loại instance" → phải stop, ổ gốc phải là EBS "instance trong ASG mà cần bảo trì" → Standby trước "IP công cộng đổi sau khi khởi động lại" → dùng Elastic IP "đổi cỡ mà không gián đoạn" → KHÔNG có, phải thay máy sau ELB "reboot" → KHÔNG đổi host, KHÔNG mất instance store, KHÔNG đổi IP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Loại mới có tương thích không | describe-instance-types, so kiến trúc và loại ổ hỗ trợ | | Instance đã dừng hẳn chưa | phải ở stopped, không phải stopping | | ASG có định thay máy không | Activity history của ASG |

Và một cảnh báo về cách vận hành: stop một instance đang nằm trong Auto Scaling Group là cách nhanh nhất để mất nó. ASG không phân biệt được "máy đang bảo trì có kế hoạch" với "máy vừa chết"; nó chỉ thấy một thành viên không còn khoẻ và làm đúng việc nó sinh ra để làm — chấm dứt và thay thế. Standby, hoặc gỡ hẳn instance khỏi ASG, phải là bước đầu tiên chứ không phải bước nhớ ra sau.

Đáp án

B — Application Load Balancer KHÔNG gửi dữ liệu tới X-Ray.

Vì sao đúng

Trong danh sách dịch vụ mà đề liệt kê, ELB là dịch vụ duy nhất không phải một nút trên bản đồ X-Ray.

⚠ Điểm mấu chốt: ALB chỉ đóng dấu request bằng một header rồi chuyển tiếp, chứ không tự phát segment:

Request đi qua ALB
        ↓
    ALB thêm header X-Amzn-Trace-Id
        ↓
    → chuyển tiếp cho target phía sau
        ↓
    Ứng dụng trên target ĐỌC header đó và phát segment
        ↓
    → nhờ vậy các segment nối được thành một trace
    → nhưng BẢN THÂN ALB không xuất hiện như một nút

Nói cách khác, ALB giúp truy vết nhưng không tham gia truy vết. Đây là lý do trên bản đồ dịch vụ X-Ray, bạn thấy client nối thẳng tới ứng dụng, không có ô nào tên load balancer.

Muốn đo hiệu năng ở tầng cân bằng tải thì phải dùng công cụ khác:

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

• C (không dùng X-Ray để truy vết request tới API Gateway) — đây là phương án gần nhất vì nó cũng nói "dịch vụ X không tích hợp". Nhưng sai: API Gateway tích hợp rất tốt với X-Ray, và thường là điểm bắt đầu của cả trace — bật một công tắc trên stage là xong.

• A (không truy vết được Lambda) — sai; Lambda là một trong những tích hợp chặt nhất, chỉ cần bật Active tracing, và X-Ray còn tự tách riêng thời gian khởi tạo lạnh.

• D (X-Ray không tích hợp S3, phải dùng CloudTrail) — sai; lời gọi tới S3 qua AWS SDK đã được X-Ray SDK bắt và hiện thành subsegment. (CloudTrail thì ghi lời gọi API để kiểm toán, một mục đích hoàn toàn khác.)

Ghi nhớ

⚠ Ba trụ cột quan sát trên AWS — bảng phải thuộc: | Trụ cột | Dịch vụ | |---|---| | Metrics | CloudWatch Metrics | | Logs | CloudWatch Logs | | Traces | X-Ray | | (kiểm toán) | CloudTrail — ai gọi API nào, không phải quan sát hiệu năng |

Từ khoá nhận diện:

"ALB gửi dữ liệu tới X-Ray" → LUÔN SAI "tìm nút thắt cổ chai xuyên nhiều dịch vụ" → X-Ray "độ trễ và lỗi ở tầng load balancer" → chỉ số CloudWatch của ALB "ai gọi API nào lúc mấy giờ" → CloudTrail "bản đồ dịch vụ + log + metric một chỗ" → CloudWatch ServiceLens

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có trace nào tới không | X-Ray console, bản đồ dịch vụ | | Daemon có chạy không | trên EC2 kiểm tra tiến trình và cổng UDP 2000 | | Thiếu quyền không | role phải có xray:PutTraceSegments |

Và một lời khuyên: hãy dùng annotation cho những giá trị bạn sẽ cần tìm kiếm — mã khách hàng, tên phiên bản, mã đơn hàng — và để phần còn lại ở metadata. X-Ray chỉ lọc trace được theo annotation, nên một trace đầy metadata mà không có annotation nào cũng giống như một tủ hồ sơ không có nhãn: dữ liệu vẫn ở đó, nhưng khi sự cố xảy ra lúc hai giờ sáng thì bạn không có cách nào tìm ra đúng request cần xem.

Đáp án

A — Cấu hình bucket S3 làm CUSTOM ORIGIN của CloudFront, rồi hạn chế truy cập bằng CUSTOM HEADER.

Vì sao đúng

Chi tiết quyết định nằm ở một mệnh đề trong đề: bucket "cũng được cấu hình làm website endpoint".

⚠ Điểm mấu chốt: S3 có HAI loại endpoint, và OAI/OAC chỉ dùng được với MỘT trong hai:

REST endpoint: bucket.s3.ap-southeast-1.amazonaws.com
        ↓
    → CloudFront coi là "S3 origin"
    → dùng được OAC / OAI  ← cách chuẩn

Website endpoint: bucket.s3-website-ap-southeast-1.amazonaws.com
        ↓
    → CloudFront coi là "CUSTOM origin" (như một web server bất kỳ)
    → KHÔNG dùng được OAC / OAI
    → phải dùng CUSTOM HEADER làm bí mật chung

Vì sao website endpoint lại phải dùng, thay vì REST endpoint? Vì nó có những thứ REST endpoint không có:

⚠ Cách custom header bảo vệ origin:

CloudFront thêm một header bí mật vào MỌI request tới origin
        Referer: <chuỗi ngẫu nhiên dài>
        ↓
    Bucket policy chỉ cho phép khi header đó đúng
        ↓
    Người dùng gọi thẳng URL S3 → không có header → bị từ chối

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::ten-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "aws:referer": "<chuoi-bi-mat>"
    }
  }
}

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

• D (tạo Origin Access Identity và sửa quyền bucket cho CloudFront dùng OAI) — đây là phương án gần nhất, và trong tình huống thông thường thì đây chính là đáp án đúng. Nhưng đề nói rõ bucket là website endpoint, mà OAI và OAC chỉ hoạt động với REST endpoint. Chọn D là bỏ sót đúng cái chi tiết mà đề cố tình cài vào.

• B (Network ACL với CloudFront) — NACL là cơ chế của VPC, áp cho subnet. S3 và CloudFront không nằm trong VPC của bạn, nên NACL không hề chạm tới chúng.

• C (Security Group với CloudFront) — cùng lý do: Security Group gắn vào ENI trong VPC, không áp được cho bucket S3 hay CloudFront distribution.

Ghi nhớ

⚠ Hai loại endpoint của S3 — bảng phải thuộc: | | REST endpoint | Website endpoint | |---|---|---| | Dạng | bucket.s3.<region>.amazonaws.com | bucket.s3-website-<region>.amazonaws.com | | HTTPS | có | KHÔNG | | OAC / OAI | dùng được | KHÔNG | | Tài liệu chỉ mục, chuyển hướng | không | có | | CloudFront gọi nó là | S3 origin | custom origin |

Từ khoá nhận diện:

"chỉ CloudFront được vào S3" → OAC (nay là chuẩn), hoặc OAI (cũ) "bucket là WEBSITE ENDPOINT" → custom origin + CUSTOM HEADER "Security Group / NACL cho S3 hoặc CloudFront" → LUÔN SAI "chỉ CloudFront được vào ALB" → custom header + WAF, hoặc prefix list của CloudFront "link tải có hạn giờ" → signed URL / signed cookie

⚠ OAC so với OAI — OAC là bản thay thế, nên biết ưu điểm: | | OAI (cũ) | OAC (mới, nên dùng) | |---|---|---| | SSE-KMS | không hỗ trợ tốt | hỗ trợ đầy đủ | | Phương thức | chỉ GET/HEAD | cả PUT, DELETE | | Ký request | SigV4 hạn chế | SigV4 đầy đủ | | Trạng thái | đang bị thay thế | AWS khuyến nghị chuyển sang OAC |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vào thẳng S3 có bị chặn không | curl thẳng URL S3 — phải nhận 403 | | CloudFront có vào được không | curl qua tên miền CloudFront — phải 200 | | Header có tới origin không | bật access log của S3 hoặc CloudFront |

Và một lời khuyên về vận hành: hãy xoay chuỗi bí mật trong custom header định kỳ, và làm việc đó theo hai bước — cho bucket policy chấp nhận cả giá trị cũ lẫn giá trị mới, đổi cấu hình CloudFront, chờ distribution triển khai xong ở mọi edge location, rồi mới bỏ giá trị cũ. Đổi một phát trong khi CloudFront còn đang triển khai nghĩa là trong vài phút, một phần các edge location vẫn gửi header cũ và website của bạn trả 403 cho đúng những khách xui xẻo đó.

Đáp án

C — Sau khi tăng kích thước EBS volume, bạn phải MỞ RỘNG HỆ THỐNG TỆP lên kích thước mới.

Vì sao đúng

Đây là một trong những "cú vấp đầu đời" phổ biến nhất của người mới quản trị AWS: mở rộng volume và mở rộng hệ thống tệp là HAI việc khác nhau, ở hai tầng khác nhau.

⚠ Điểm mấu chốt — ba tầng, và AWS chỉ lo tầng dưới cùng:

Tầng 1: EBS volume        → AWS mở rộng khi bạn bấm Modify
Tầng 2: Bảng phân vùng    → bạn phải tự mở rộng
Tầng 3: Hệ thống tệp      → bạn phải tự mở rộng
        ↓
    Chỉ làm tầng 1 → `df -h` vẫn báo dung lượng CŨ

⚠ Các bước hoàn chỉnh trên Linux:

# 1. Xem thực tế: NVMe đã 100G nhưng phân vùng vẫn 20G
lsblk

# 2. Mở rộng phân vùng (chú ý DẤU CÁCH giữa tên đĩa và số phân vùng)
sudo growpart /dev/nvme0n1 1

# 3. Mở rộng hệ thống tệp — lệnh khác nhau tuỳ loại
sudo resize2fs /dev/nvme0n1p1     # ext4
sudo xfs_growfs -d /              # XFS

# 4. Xác nhận
df -h

Trên Windows thì mở Disk Management → chuột phải vào volume → Extend Volume.

⚠ Tin tốt: toàn bộ việc này làm được khi máy ĐANG CHẠY:

Elastic Volumes cho phép tăng dung lượng, đổi loại volume,
đổi IOPS — mà KHÔNG cần dừng instance, KHÔNG cần tháo volume
        ↓
    → không có phút chết nào

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

• B (phải tháo volume ra rồi gắn lại) — đây là phương án gần nhất vì ngày xưa đúng là phải làm vậy. Từ khi có Elastic Volumes, thay đổi áp dụng ngay khi máy đang chạy; tháo ra gắn lại chỉ gây gián đoạn vô ích, và vẫn không giải quyết được vấn đề vì hệ thống tệp vẫn chưa được mở rộng.

• A (volume mã hoá không hiện thay đổi khi còn gắn vào máy) — bịa. Mã hoá hoàn toàn trong suốt; volume mã hoá mở rộng y hệt volume thường.

• D (Linux tự nhận, chỉ Windows mới phải làm tay) — ngược lại một nửa và sai cả hai vế: cả Linux lẫn Windows đều phải tự mở rộng hệ thống tệp. Không hệ điều hành nào tự làm việc này.

Ghi nhớ

⚠ Hai bước bắt buộc khi tăng dung lượng EBS — bảng phải thuộc: | Bước | Ai làm | |---|---| | Tăng kích thước volume | AWS (Modify Volume) | | Mở rộng phân vùng + hệ thống tệp | BẠN, bên trong hệ điều hành |

Từ khoá nhận diện:

"đã tăng volume mà df vẫn báo cũ" → chưa resize2fs / xfs_growfs "tăng dung lượng có phải dừng máy không" → KHÔNG, Elastic Volumes "muốn GIẢM dung lượng EBS" → KHÔNG GIẢM ĐƯỢC — phải tạo volume mới và chép sang "đổi gp2 sang gp3" → Modify Volume, không gián đoạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | AWS đã mở rộng chưa | describe-volumes-modifications — xem ModificationState | | Hệ điều hành có thấy không | lsblk — so kích thước đĩa với kích thước phân vùng | | Hệ thống tệp đã lớn chưa | df -h |

Và một lời khuyên: hãy đặt cảnh báo CloudWatch trên dung lượng đĩa còn trống, không chỉ trên kích thước volume. Chỉ số đĩa không có sẵn trong CloudWatch — phải cài CloudWatch agent mới có disk_used_percent. Rất nhiều đội chỉ phát hiện đĩa đầy khi ứng dụng đã ngừng ghi log và cơ sở dữ liệu đã từ chối giao dịch, đơn giản vì không ai biết chỉ số đó phải tự bật mới có.

Đáp án

B — Lệnh append GHI ĐÈ thông tin của tệp cấu hình thứ nhất thay vì nối thêm vào.

Vì sao đúng

Bẫy nằm ở chi tiết đề nêu rất rõ: hai tệp có CÙNG TÊN, chỉ khác đường dẫn.

⚠ Điểm mấu chốt: CloudWatch agent phân biệt các mảnh cấu hình bằng TÊN TỆP:

Nạp tệp thứ nhất tên "cau-hinh.json"
        ↓
    Agent lưu thành một mảnh có tên "cau-hinh.json"
        ↓
Nạp tiếp tệp thứ hai CŨNG tên "cau-hinh.json"
        ↓
    → Agent thấy đã có mảnh trùng tên
        ↓
    → GHI ĐÈ mảnh cũ, KHÔNG nối thêm
        ↓
    → chỉ số của tệp thứ nhất biến mất

⚠ Cách làm đúng — đặt tên khác nhau:

# Tệp thứ nhất: chỉ số và log chung cho mọi máy chủ
sudo .../amazon-cloudwatch-agent-ctl -a fetch-config \
     -m ec2 -c file:/opt/cw/chung.json -s

# Tệp thứ hai: TÊN KHÁC → được nối thêm thật sự
sudo .../amazon-cloudwatch-agent-ctl -a append-config \
     -m ec2 -c file:/opt/cw/ung-dung.json -s

Cơ chế gộp giúp tách bạch trách nhiệm rất gọn: một mảnh chung do đội hạ tầng quản lý, một mảnh riêng do đội ứng dụng quản lý — sửa mảnh này không đụng mảnh kia. Nhưng nó chỉ hoạt động khi tên tệp là duy nhất, vì tên tệp chính là khoá định danh.

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

• C (tham số của tệp thứ hai được cộng vào agent đang chạy) — đây là phương án gần nhất và là điều bạn MUỐN xảy ra; nó đúng khi hai tệp có tên khác nhau. Với tên trùng như đề mô tả thì kết quả là ghi đè.

• A (hai agent chạy song song với hai cấu hình) — sai; mỗi máy chỉ chạy MỘT tiến trình CloudWatch agent, không thể có hai bản với hai cấu hình.

• D (agent chỉ có đúng một tệp cấu hình) — sai; chính lệnh append-config tồn tại là để gộp nhiều mảnh.

Ghi nhớ

⚠ Hai lệnh nạp cấu hình của CloudWatch agent — bảng phải thuộc: | Lệnh | Tác dụng | |---|---| | fetch-config | thay thế toàn bộ cấu hình hiện có | | append-config | gộp thêm — nhưng trùng tên tệp là ghi đè |

Từ khoá nhận diện:

"hai tệp cấu hình cùng tên" → cái sau ghi đè cái trước "gộp nhiều mảnh cấu hình" → append-config + tên tệp khác nhau "thay hẳn cấu hình cũ" → fetch-config "hai agent trên một máy" → LUÔN SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent đang dùng cấu hình nào | liệt kê thư mục amazon-cloudwatch-agent.d/ | | Chỉ số có lên không | tìm namespace CWAgent trong CloudWatch | | Vì sao không lên | đọc log của chính agent — lỗi cú pháp JSON hiện ở đó |

Và một lời khuyên: hãy quản lý cấu hình agent bằng SSM Parameter Store thay vì tệp rải rác trên từng máy. Sự cố kiểu câu này rất khó phát hiện vì nó im lặng hoàn toàn: agent vẫn chạy, status vẫn báo running, không có lỗi nào ở đâu — chỉ có một nhóm chỉ số lặng lẽ ngừng xuất hiện, và thường phải tới lúc cần chúng để điều tra sự cố thì mới có người nhận ra.

Đáp án

D — NetworkIn và NetworkOut.

Vì sao đúng

CloudWatch cấp sẵn cho mọi EC2 instance hai chỉ số mạng, và cộng chúng lại chính là tổng lưu lượng mà đề cần.

⚠ Điểm mấu chốt: đây là chỉ số kiểu Sum theo chu kỳ, muốn tổng cả kỳ thì phải chọn đúng thống kê:

Chọn thống kê = Sum, chu kỳ = 1 giờ
        ↓
    Mỗi điểm = tổng số byte trong giờ đó
        ↓
Cộng mọi điểm trong khoảng ngày cần xét
        ↓
    → tổng lưu lượng của instance đó

⚠ Muốn xếp hạng instance nào dùng nhiều băng thông nhất — dùng Metric Math:

Trên CloudWatch console:
    Chọn NetworkIn + NetworkOut cho toàn bộ instance
        ↓
    Thêm biểu thức: SUM(METRICS())  hoặc  m1 + m2
        ↓
    Sắp xếp bảng theo giá trị giảm dần
        ↓
    → thấy ngay instance đứng đầu

Lấy nhanh bằng CLI:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name NetworkOut \
  --dimensions Name=InstanceId,Value=i-xxxxxxxx \
  --start-time 2026-08-01T00:00:00Z --end-time 2026-09-01T00:00:00Z \
  --period 86400 --statistics Sum

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

• B (DataTransfer-Out-Bytes) — đây là phương án gần nhất và nó là một chỉ số CÓ THẬT, nhưng thuộc namespace AWS/Billing (hoặc dữ liệu Cost Explorer), tính lưu lượng ra internet để tính tiền ở mức tài khoản. Nó không tách theo từng instance, nên không trả lời được câu hỏi "instance nào dùng nhiều nhất".

• A (NetworkTotalBytes) — không tồn tại. CloudWatch không có chỉ số cộng sẵn hai chiều; bạn phải tự cộng bằng Metric Math.

• C (DiskReadBytes và DiskWriteBytes) — đây là chỉ số ổ đĩa (instance store), không phải mạng.

Ghi nhớ

⚠ Chỉ số EC2 có sẵn và KHÔNG có sẵn — bảng phải thuộc: | Có sẵn (không cần agent) | Phải cài CloudWatch agent | |---|---| | CPUUtilization | mem_used_percent (bộ nhớ) | | NetworkIn / NetworkOut | disk_used_percent (đĩa còn trống) | | DiskReadBytes / DiskWriteBytes (instance store) | swap_used_percent | | StatusCheckFailed* | chỉ số của tiến trình | | EBSReadBytes / EBSWriteBytes (loại có Nitro) | |

Từ khoá nhận diện:

"tổng lưu lượng mạng của instance" → NetworkIn + NetworkOut, thống kê Sum "chi phí truyền dữ liệu ra internet" → Cost Explorer / AWS/Billing "RAM còn bao nhiêu" → CloudWatch agent, KHÔNG có sẵn "đĩa sắp đầy" → CloudWatch agent (disk_used_percent) "instance nào dùng nhiều nhất" → Metric Math + sắp xếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chỉ số nào cho instance | list-metrics --namespace AWS/EC2 --dimensions ... | | Đơn vị là gì | NetworkIn/Out tính bằng byte, không phải bit | | Dữ liệu cũ còn không | quá 15 tháng thì CloudWatch đã xoá |

Và một cảnh báo khi đọc số: NetworkOut KHÔNG bằng lưu lượng bị tính tiền. Chỉ số này đếm mọi byte đi ra khỏi giao diện mạng — bao gồm lưu lượng tới instance khác trong cùng AZ (miễn phí), tới AZ khác (có phí), và ra internet (có phí, đắt nhất). Lấy NetworkOut nhân đơn giá truyền dữ liệu sẽ ra một con số cao hơn hoá đơn thật khá nhiều; muốn biết chi phí thật thì phải xem Cost Explorer.

Đáp án

B — Cấu hình RDS thành Multi-AZ deployment (triển khai đa vùng sẵn sàng).

Vì sao đúng

Đề hỏi cách "dễ và hiệu quả" để RDS sẵn sàng cao và chống lỗi — và Multi-AZ chính là một công tắc duy nhất.

⚠ Điểm mấu chốt — Multi-AZ hoạt động thế nào:

Bật Multi-AZ
        ↓
    AWS dựng một bản standby ở AZ KHÁC
        ↓
    Sao chép ĐỒNG BỘ mọi giao dịch sang standby
        ↓
Khi primary hỏng (lỗi máy, lỗi AZ, bảo trì)
        ↓
    → tự động failover trong 60–120 giây
    → CNAME trỏ sang standby
        ↓
    → ứng dụng KHÔNG cần đổi chuỗi kết nối

⚠ Ba điều bắt buộc phải rõ về Multi-AZ standby:

Standby KHÔNG phục vụ đọc      ← muốn chia tải đọc thì dùng Read Replica
Standby KHÔNG cần thao tác gì  ← AWS lo hoàn toàn
Standby nằm ở AZ khác          ← nên chịu được cả sự cố một AZ

⚠ Và đây là lý do ứng dụng vẫn nên cấu hình DNS TTL cho đúng:

Failover đổi bản ghi DNS của endpoint RDS
        ↓
    JVM mặc định cache DNS VĨNH VIỄN
        ↓
    → ứng dụng Java vẫn gọi vào IP cũ sau failover
        ↓
    → đặt networkaddress.cache.ttl = 60 hoặc thấp hơn

Chi tiết cuối này chính là nội dung phương án D — đúng nhưng là việc bổ trợ, không phải cách làm RDS sẵn sàng cao.

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

• D (đặt TTL của JVM không quá 60 giây) — đây là phương án gần nhất và là một khuyến nghị thật của AWS, nhưng nó chỉ giúp ứng dụng kết nối lại nhanh SAU khi failover đã xảy ra. Bản thân nó không tạo ra khả năng sẵn sàng cao nào; không có Multi-AZ thì chẳng có gì để failover sang.

• C (bật sao lưu tự động để khôi phục sau sự cố) — sao lưu là khôi phục thảm hoạ, không phải sẵn sàng cao. Khôi phục từ snapshot mất hàng chục phút tới hàng giờ và mất dữ liệu tới điểm khôi phục gần nhất, trong khi Multi-AZ chuyển đổi trong khoảng một phút và không mất giao dịch nào.

• A (mở rộng DB instance khi sắp hết dung lượng) — nói về dung lượng lưu trữ, không liên quan tới sẵn sàng cao. (Việc này nên bật storage autoscaling cho tự động.)

Ghi nhớ

⚠ Multi-AZ so với Read Replica — bảng phải thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Mục đích | sẵn sàng cao | chia tải đọc | | Sao chép | đồng bộ | bất đồng bộ | | Phục vụ đọc | KHÔNG (standby) | CÓ | | Failover | tự động | phải promote thủ công | | Vị trí | AZ khác | cùng AZ, khác AZ, hoặc khác Region |

Từ khoá nhận diện:

"sẵn sàng cao, chịu lỗi" → Multi-AZ "báo cáo làm chậm cơ sở dữ liệu" → Read Replica "khôi phục về một thời điểm bất kỳ" → Point-in-Time Recovery (PITR) "chịu được mất cả một Region" → cross-Region read replica hoặc Aurora Global Database "failover mà endpoint không đổi" → Multi-AZ, đó là điểm mạnh của nó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã bật Multi-AZ chưa | describe-db-instances, xem MultiAZ: true | | Failover có chạy không | reboot-db-instance --force-failover — thử trước khi cần | | Failover mất bao lâu | sự kiện RDS và chỉ số FailoverTime |

Và một lời khuyên: hãy chủ động kích hoạt một lần failover trong giờ bảo trì, ít nhất mỗi quý một lần. Multi-AZ hứa hẹn chuyển đổi trong khoảng một phút, nhưng con số đó chỉ đúng cho phía cơ sở dữ liệu — thời gian ứng dụng của bạn thật sự hồi phục còn phụ thuộc vào DNS cache, connection pool và logic thử lại, và những thứ đó chỉ lộ ra khi bạn thử thật.

Đáp án

C — Nếu một IAM user (có toàn quyền IAM và S3) gắn bucket policy lên bucket mà KHÔNG khai root user của tài khoản là principal, thì chính root user bị từ chối truy cập bucket đó.

Vì sao đúng

Đây là ngoại lệ quan trọng nhất phá vỡ niềm tin phổ biến "root thì làm gì cũng được".

⚠ Điểm mấu chốt: bucket policy là RESOURCE-based policy, và nó áp lên MỌI principal — kể cả root:

Chính sách identity (gắn vào user/role)
        ↓
    → root user không bị ràng buộc bởi loại này

Chính sách resource (bucket policy, key policy...)
        ↓
    → áp lên MỌI người gọi, KHÔNG có ngoại lệ cho root
        ↓
    Bucket policy chỉ Allow cho "arn:...:user/an"
        ↓
    → mọi principal khác nhận IMPLICIT DENY
        ↓
    → kể cả root user của chính tài khoản đó

Ví dụ chính sách gây ra tình huống của đề:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:user/quantri-ung-dung"},
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::bucket-benh-vien/*"
}

Không có Deny nào, nhưng cũng không có Allow nào cho root — mà trong IAM, không được cho phép tức là bị từ chối.

⚠ Cách chữa — dùng chính user đang có quyền để sửa lại chính sách:

Đăng nhập bằng IAM user còn quyền trên bucket
        ↓
    Thêm root vào principal:
        "AWS": "arn:aws:iam::111122223333:root"
    hoặc xoá hẳn bucket policy
        ↓
    → root truy cập lại được ngay

⚠ Trường hợp xấu nhất — không còn ai vào được:

Bucket policy khai Deny cho tất cả, hoặc user được Allow đã bị xoá
        ↓
    → KHÔNG AI sửa được chính sách nữa, kể cả root
        ↓
    → phải mở ticket với AWS Support

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

• D (root có quyền với mọi tài nguyên, liên hệ AWS Support) — đây là phương án gần nhất và vế đầu là điều ai cũng tưởng đúng. Nhưng bucket policy là ngoại lệ, và cách chữa cũng đơn giản hơn nhiều: dùng IAM user đang còn quyền để sửa chính sách. Chỉ khi không còn principal nào vào được thì mới phải nhờ AWS.

• B (bucket này thuộc tài khoản khác, được chia sẻ nên mới hiện ra) — sai; đề nói rõ bucket nằm trong chính tài khoản của công ty. Ngoài ra bucket của tài khoản khác không hiện trong danh sách bucket của bạn dù có được chia sẻ.

• A (AWS vô hiệu hoá chính sách có dấu * trong principal) — bịa hoàn toàn. Chính sách có "Principal": "*" hoàn toàn hợp lệ và thực thi đúng như viết — đó chính là cách người ta vô tình mở bucket ra công khai.

Ghi nhớ

⚠ Root user bị chặn ở đâu — bảng phải thuộc: | Cơ chế | Chặn được root không | |---|---| | Chính sách IAM (identity-based) | KHÔNG | | Bucket policy / resource policy | CÓ | | KMS key policy | CÓ — và đây là chỗ khoá chết dữ liệu vĩnh viễn | | SCP của Organizations | KHÔNG áp cho root của tài khoản quản lý; CÓ áp cho root tài khoản thành viên | | Permissions boundary | không áp cho root |

Từ khoá nhận diện:

"root không vào được bucket của chính mình" → bucket policy thiếu root trong principal "khoá chặt bucket nhưng vẫn mở được" → luôn để lại một principal quản trị trong chính sách "không ai còn quyền sửa chính sách" → AWS Support "chặn mọi tài khoản trong tổ chức" → SCP "bucket lỡ mở công khai" → S3 Block Public Access

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chính sách hiện tại ra sao | get-bucket-policy --bucket <ten> | | Ai thật sự vào được | IAM Policy Simulator hoặc IAM Access Analyzer | | Ai đã sửa chính sách | CloudTrail sự kiện PutBucketPolicy |

Và một cảnh báo nghiêm túc: cùng cái bẫy này ở KMS key policy thì không cứu được. Nếu key policy của một CMK không cho phép bất kỳ principal nào thực hiện kms:PutKeyPolicy, thì khoá đó bị đóng băng vĩnh viễn — và mọi dữ liệu đã mã hoá bằng nó trở thành không đọc được, kể cả với root. Vì vậy tài liệu AWS luôn khuyên để lại "Principal": {"AWS": "arn:aws:iam::<tai-khoan>:root"} với quyền quản trị khoá trong mọi key policy.

Đáp án

A — Dùng AWS Config rules để kiểm tra bucket S3 đã bật logging hay chưa, và thực hiện remediation khi cần.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS Config đáp ứng cả ba mà không phải viết dòng mã nào:

⚠ Điểm mấu chốt — có sẵn cả quy tắc lẫn hành động sửa, chỉ cần bật:

Managed rule: s3-bucket-logging-enabled
        ↓
    Config phát hiện bucket NON_COMPLIANT
        ↓
    Remediation action: AWS-ConfigureS3BucketLogging
        (một runbook SSM Automation dựng sẵn)
        ↓
    → tự bật server access logging cho bucket đó

⚠ Hai chế độ remediation — biết cả hai là hiểu cách triển khai an toàn:

Manual   → Config đánh dấu vi phạm, người xem rồi bấm Remediate
Automatic → Config tự sửa ngay khi phát hiện
        ↓
    Nên bắt đầu bằng Manual để xem nó định sửa gì
    rồi mới chuyển sang Automatic

Điểm mạnh nhất của AWS Config so với tự viết Lambda là lịch sử cấu hình: nó lưu lại tài nguyên đã trông như thế nào ở mọi thời điểm, ai đổi và đổi lúc nào — thứ mà kiểm toán luôn hỏi tới.

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

• C (viết Lambda kiểm tra rồi bắn thông báo SNS) — đây là phương án gần nhất và về mặt kỹ thuật thì làm được. Nhưng nó chỉ báo chứ không sửa, phải tự viết và tự bảo trì mã, tự lo lịch chạy, và không có lịch sử cấu hình. Đề nói rõ "nếu tự sửa được luôn thì hoàn hảo" — Config làm điều đó sẵn.

• B (dùng CloudTrail theo dõi logging, AWS không có tự sửa nên phải dùng Lambda) — sai ở vế thứ hai: AWS Config CÓ cơ chế remediation tự động. Và CloudTrail ghi lời gọi API, nó không cho biết trạng thái cấu hình hiện tại của một bucket.

• D (Trusted Advisor kiểm tra S3 access logging và cấu hình hành động sửa) — Trusted Advisor không có check này cho server access logging, và quan trọng hơn: Trusted Advisor không tự sửa gì cả, nó chỉ khuyến nghị.

Ghi nhớ

⚠ Bốn dịch vụ hay bị nhầm với nhau — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | AWS Config | "tài nguyên đang được cấu hình thế nào, có đúng chuẩn không" | | CloudTrail | "ai đã gọi API nào, lúc nào" | | CloudWatch | "hệ thống đang chạy ra sao" (chỉ số, log) | | Trusted Advisor | "có khuyến nghị gì" — không tự sửa |

Từ khoá nhận diện:

"kiểm tra tuân thủ cấu hình + tự sửa" → AWS Config + remediation "ai đã đổi cái gì" → CloudTrail "nhiều tài khoản, áp chuẩn chung" → Config aggregator + Conformance pack "chặn hẳn không cho làm" → SCP (Config chỉ phát hiện SAU khi đã xảy ra) "tổng hợp phát hiện bảo mật" → Security Hub

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên nào vi phạm | bảng compliance của quy tắc | | Remediation đã chạy chưa | lịch sử Automation trong Systems Manager | | Cấu hình trước đây ra sao | Config timeline của chính tài nguyên đó |

Và một lưu ý về chi phí: AWS Config tính tiền theo số bản ghi cấu hình được ghi lại, và nếu bạn bật ghi cho mọi loại tài nguyên ở mọi Region trong một môi trường có nhiều thay đổi tự động — Auto Scaling lên xuống liên tục, ENI được tạo và xoá — thì hoá đơn có thể lớn hơn dự kiến đáng kể. Hãy chọn đúng loại tài nguyên cần theo dõi thay vì bật tất cả theo phản xạ.