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

Đáp án

D — Tạo SERVICE CONTROL POLICY trong AWS Organizations chặn ec2:RunInstances ở các Region không được duyệt, áp lên ROOT của tổ chức.

Vì sao đúng

Yêu cầu là không một ai trong toàn công ty khởi chạy được EC2 ở Region không được duyệt — và chỉ SCP áp ở root mới phủ được "tất cả mọi người, mọi tài khoản".

⚠ Điểm mấu chốt — SCP là NGĂN CHẶN ở tầng cao nhất:

SCP áp ở ROOT của tổ chức
        ↓
    Áp cho MỌI tài khoản thành viên
    (trừ tài khoản quản lý)
        ↓
    Áp cho MỌI danh tính trong đó:
      - IAM user, IAM role
      - kể cả người có AdministratorAccess
      - kể cả ROOT USER của tài khoản thành viên
        ↓
    → không ai vượt qua được
    → và request bị chặn TRƯỚC KHI máy được tạo

⚠ Cách viết SCP khoá Region:

{
  "Effect": "Deny",
  "Action": "ec2:RunInstances",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": [
        "ap-southeast-1",
        "eu-west-1"
      ]
    }
  }
}

StringNotEquals
        ↓
    → CẤM mọi Region KHÔNG NẰM trong danh sách
    → chỉ hai Region đó chạy được

⚠ Nhưng phải CHỪA các dịch vụ TOÀN CỤC:

Nhiều dịch vụ chạy endpoint ở us-east-1
        ↓
    IAM, Organizations, Route 53,
    CloudFront, Support, Billing…
        ↓
    Khoá Region kiểu chặn TẤT CẢ dịch vụ
        ↓
    → làm đứt luôn IAM và Billing
        ↓
    Cách đúng: dùng NotAction để loại trừ
      "NotAction": ["iam:*","organizations:*",
                    "route53:*","cloudfront:*",
                    "support:*","budgets:*", ...]
        ↓
    Đề này chỉ chặn ec2:RunInstances
    → không vướng vấn đề đó

Xem thêm câu #11878, #11882 (cùng lô) và #11865 (lô 128): cùng chùm SCP. #11878 nhấn vào chiều của toán tử điều kiện, #11882 vào việc SCP thắng cả quyền quản trị IAM.

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

• A (tạo IAM role có điều kiện Region để Deny ec2:RunInstances, gắn role đó vào mọi instance EC2) — đây là phương án gần nhất vì dùng đúng khoá điều kiện, nhưng cách áp dụng sai hoàn toàn: role gắn vào instance quy định quyền của ỨNG DỤNG chạy trên máy, không quy định quyền của người khởi chạy máy. Và IAM policy thì người có quyền quản trị tự gỡ được.

• B (dùng CloudWatch ở mọi Region theo dõi API, SNS báo, Step Functions huỷ máy) — phản ứng SAU khi máy đã chạy: dữ liệu khách hàng có thể đã được xử lý ở Region cấm trong khoảng thời gian đó. Lại rất phức tạp và tốn kém.

• C (tạo bucket policy trong S3 từ chối ec2:RunInstances) — bucket policy chỉ áp cho thao tác trên chính bucket đó. Không có cơ chế nào để một bucket policy chặn được việc tạo EC2.

Ghi nhớ

⚠ Ngăn chặn ↔ Phát hiện ↔ Khắc phục — bảng phải thuộc: | Loại | Công cụ | Đặc điểm | |---|---|---| | Ngăn chặn | SCP, IAM policy, permissions boundary | chặn TRƯỚC khi việc xảy ra | | Phát hiện | Config, Security Hub, GuardDuty | báo sau khi đã xảy ra | | Khắc phục | SSM Automation, Config remediation | tự sửa cái đã phát hiện | | Yêu cầu tuân thủ nghiêm | luôn ưu tiên NGĂN CHẶN | |

Từ khoá nhận diện:

"không ai được làm X" → SCP "chỉ được dùng Region A và B" → SCP với aws:RequestedRegion "phát hiện tài nguyên sai chuẩn" → AWS Config "tự sửa khi phát hiện" → Config + SSM Automation "tài khoản quản lý cũng phải bị chặn" → SCP KHÔNG áp được — đừng chạy tải ở đó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | SCP thực tế đang áp | describe-effective-policy | | Có chặn đúng không | run-instances --dry-run ở Region cấm — phải bị từ chối | | Có gì đang chạy sai chỗ không | Config aggregator, hoặc describe-instances ở mọi Region |

Và một việc nên làm ngay sau khi áp SCP: quét mọi Region để tìm tài nguyên đã tồn tại từ trước. SCP chỉ chặn các request mới — những instance đã chạy ở Region không được duyệt vẫn tiếp tục chạy, vẫn đang xử lý dữ liệu, và chính chúng mới là phần vi phạm mà kiểm toán viên sẽ tìm thấy.

Đáp án

D — Cài và cấu hình UNIFIED CLOUDWATCH AGENT.

Vì sao đúng

Yêu cầu là đẩy log cục bộ lên CloudWatch với ít công vận hành nhất, và unified agent là công cụ chính thức cho việc đó.

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

Log của ứng dụng và hệ điều hành
        ↓
    Nằm trong tệp trên đĩa của máy:
      /var/log/messages
      /var/log/nginx/access.log
      C:\inetpub\logs\...
        ↓
    CloudWatch KHÔNG tự đọc được tệp trên máy
        ↓
    → phải có tiến trình đọc tệp và đẩy đi
    → đó là CloudWatch agent

⚠ "Unified" nghĩa là một agent làm cả hai việc:

Agent hợp nhất (amazon-cloudwatch-agent)
        ↓
    1. THU LOG   → CloudWatch Logs
    2. THU CHỈ SỐ → CloudWatch Metrics
         mem_used_percent, disk_used_percent,
         swap, procstat…
        ↓
    Thay thế hai công cụ cũ:
      CloudWatch Logs agent (đã ngừng)
      script mon-put-instance-data.pl
        ↓
    → một agent, một cấu hình, một nơi cài đặt

⚠ Ít công vận hành nhất — cách triển khai cho cả đội máy:

1. Cấu hình lưu trong SSM PARAMETER STORE
        ↓
    → một bản dùng chung cho mọi máy
    → sửa một chỗ, áp cho tất cả

2. Cài bằng SSM DISTRIBUTOR
        ↓
    → cài và cập nhật hàng loạt

3. STATE MANAGER
        ↓
    → bảo đảm agent LUÔN được cài và ĐANG CHẠY
    → máy mới do ASG khởi chạy cũng tự có

4. Hoặc: cài sẵn vào GOLDEN AMI
        ↓
    → máy mới có agent ngay từ giây đầu

Xem thêm câu #11833 và #11874 (lô 128): cùng nguyên tắc — chỉ số bộ nhớ, đĩa và log đều cần CloudWatch agent. Khoá nhất quán ở cả ba câu.

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

• C (viết script tự đẩy sự kiện lên CloudWatch) — đây là phương án gần nhất và về kỹ thuật thì làm được, nhưng nó tự làm lại thứ AWS đã cung cấp sẵn: phải tự xử lý xoay tệp log, thử lại khi lỗi, giới hạn tần suất API, đóng gói và triển khai. Trái hẳn yêu cầu "ít công vận hành nhất".

• A (cài Amazon Inspector agent) — Inspector quét LỖ HỔNG bảo mật, không thu thập log. (Và Inspector hiện nay dùng SSM Agent chứ không còn agent riêng.)

• B (cấu hình AWS Config chuyển tiếp sự kiện tới CloudWatch) — Config theo dõi THAY ĐỔI CẤU HÌNH tài nguyên, không đọc log bên trong máy.

Ghi nhớ

⚠ Agent nào làm việc gì — bảng phải thuộc: | Agent | Việc | |---|---| | Unified CloudWatch agent | thu LOG và CHỈ SỐ từ trong máy | | SSM Agent | quản lý máy: chạy lệnh, vá lỗi, Session Manager | | Inspector | quét lỗ hổng (nay dựa trên SSM Agent) | | X-Ray daemon | thu vết truy tìm phân tán | | Cài sẵn trên Amazon Linux | SSM Agent có sẵn; CloudWatch agent PHẢI CÀI |

Từ khoá nhận diện:

"đẩy log từ máy lên CloudWatch" → unified CloudWatch agent "chỉ số bộ nhớ, dung lượng đĩa" → cũng chính agent đó "chạy lệnh trên nhiều máy" → SSM Run Command "quét lỗ hổng" → Inspector "theo dõi thay đổi cấu hình" → AWS Config

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có chạy không | amazon-cloudwatch-agent-ctl -a status | | Log đã lên chưa | CloudWatch → Log groups → tìm log stream theo instance id | | Vì sao không lên | log của chính agent: /opt/aws/amazon-cloudwatch-agent/logs/ |

Và một cấu hình rất nên đặt ngay khi tạo log group: hạn lưu trữ. Mặc định CloudWatch Logs giữ log vĩnh viễn, nên một đội máy ghi log đều đặn sẽ âm thầm tích tụ hàng terabyte trong vài năm — và khoản đó thường chỉ được phát hiện khi ai đó ngồi rà lại hoá đơn, rất lâu sau khi những dòng log ấy không còn ai cần đọc nữa.

Đáp án

B — Bật TERMINATION PROTECTION trên các instance EC2 quan trọng.

Vì sao đúng

Yêu cầu là ngăn việc huỷ máy do NHẦM LẪN, và termination protection là tính năng sinh ra chính xác cho việc đó.

⚠ Điểm mấu chốt — nó chặn ở tầng API:

Bật DisableApiTermination = true
        ↓
    Mọi lời gọi TerminateInstances tới máy đó
        ↓
    → bị TỪ CHỐI
        ↓
    Từ console:  nút Terminate bị mờ
    Từ CLI/SDK:  lỗi OperationNotPermitted
        ↓
    Muốn huỷ thật:
      phải TẮT bảo vệ trước — MỘT BƯỚC CÓ CHỦ Ý
        ↓
    → đúng nghĩa "chống nhầm lẫn"

⚠ Nhưng phải biết rõ nó KHÔNG chặn những gì:

KHÔNG chặn:
        ↓
    - Lệnh SHUTDOWN từ BÊN TRONG hệ điều hành
      (nếu InstanceInitiatedShutdownBehavior = terminate)
    - Auto Scaling group thu nhỏ hoặc thay máy không khoẻ
    - Spot instance bị THU HỒI
    - CloudFormation xoá stack
      (trừ khi có DeletionPolicy: Retain)
        ↓
    → mỗi con đường cần một biện pháp riêng

⚠ Bộ bảo vệ đầy đủ cho một máy quan trọng:

1. DisableApiTermination = true      ← chống nhầm tay
2. InstanceInitiatedShutdownBehavior
     = stop  (không phải terminate)  ← chống shutdown từ trong
3. DisableApiStop = true             ← chống dừng nhầm
4. EBS: DeleteOnTermination = false  ← giữ dữ liệu
5. SCP hoặc IAM policy               ← chỉ vài người được huỷ
6. Sao lưu: AWS Backup / snapshot    ← lưới an toàn cuối
7. Tag "Critical=true" + alarm       ← biết khi có ai đụng vào

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

• A (dùng CloudTrail để hạn chế lời gọi terminate-instances) — đây là phương án gần nhất vì CloudTrail đúng là liên quan tới lời gọi API, nhưng CloudTrail chỉ GHI LẠI, không CHẶN. Nó cho biết ai đã huỷ máy — sau khi máy đã biến mất.

• C (dùng AWS Config để hạn chế việc huỷ EC2) — Config là công cụ PHÁT HIỆN: nó đánh giá cấu hình có tuân thủ hay không, không ngăn được hành động nào.

• D (dùng Systems Manager để hạn chế việc huỷ EC2) — SSM quản lý máy (chạy lệnh, vá lỗi, phiên làm việc), không kiểm soát vòng đời instance.

Ghi nhớ

⚠ Bốn cờ bảo vệ instance — bảng phải thuộc: | Cờ | Chặn gì | |---|---| | DisableApiTermination | chặn TerminateInstances qua API/console | | DisableApiStop | chặn StopInstances | | InstanceInitiatedShutdownBehavior | stop hay terminate khi shutdown từ trong máy | | DeleteOnTermination (trên volume) | giữ hay xoá EBS khi máy bị huỷ | | Mặc định | terminate protection TẮT, root volume DeleteOnTermination = true |

Từ khoá nhận diện:

"tránh huỷ nhầm máy quan trọng" → termination protection "giữ dữ liệu khi máy bị huỷ" → DeleteOnTermination = false "chỉ vài người được huỷ máy" → IAM policy hoặc SCP "tránh xoá nhầm tài nguyên trong stack" → DeletionPolicy: Retain + stack policy "tránh xoá nhầm đối tượng S3" → versioning + MFA Delete + Object Lock

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cờ đã bật chưa | describe-instance-attribute --attribute disableApiTermination | | Volume có bị xoá theo không | describe-instances --query '...BlockDeviceMappings' | | Ai đã huỷ máy | CloudTrail, tìm TerminateInstances |

Và một cách bảo vệ bền hơn nhiều so với việc bật cờ trên từng máy: một IAM policy hoặc SCP từ chối ec2:TerminateInstances với điều kiện aws:ResourceTag/Critical = true. Cờ trên instance phụ thuộc vào việc ai đó nhớ bật nó lúc tạo máy, còn một chính sách theo tag thì bảo vệ mọi máy mang tag đó, kể cả những máy được dựng ra vào tháng sau bởi một người chưa từng đọc quy trình này.

Đáp án

B — COMPUTE SAVINGS PLANS 3 năm, thanh toán NO UPFRONT.

Vì sao đúng

Đề có ba ràng buộc, và chỉ một tổ hợp thoả cả ba: chuyển từ EC2 sang Fargate, tối đa hoá giảm giá, và không để cam kết nào bị lãng phí.

⚠ Ràng buộc thứ nhất — sẽ chuyển sang Fargate:

Compute Savings Plans  ← linh hoạt nhất
        ↓
    Áp cho: EC2, FARGATE, LAMBDA
    Mọi Region, mọi họ máy, mọi hệ điều hành
        ↓
    → 6 tháng đầu áp cho EC2
    → sau đó TỰ ĐỘNG áp cho Fargate
    → không phải mua lại, không phải đổi gì
        ↓
EC2 Instance Savings Plans / Reserved Instances
        ↓
    KHOÁ vào một họ máy và một Region
        ↓
    → KHÔNG áp được cho Fargate
    → sau 6 tháng thành cam kết CHẾT

⚠ Ràng buộc thứ hai — tối đa hoá giảm giá:

Thời hạn 3 NĂM  >  1 năm
        ↓
    → mức giảm sâu hơn đáng kể
        ↓
    Và công ty đã DỰ BÁO ĐƯỢC chi phí Fargate
    → cam kết dài hạn là hợp lý

⚠ Ràng buộc thứ ba — không để cam kết bị lãng phí:

NO UPFRONT
        ↓
    Không trả trước đồng nào
    → trả đều theo giờ trong suốt kỳ hạn
        ↓
    → không có khoản tiền nào bị "kẹt"
    → không có phần trả trước nào không dùng tới

Partial / All Upfront
        ↓
    Trả trước một phần hoặc toàn bộ
    → giảm sâu hơn một chút
    → NHƯNG tiền đã trả rồi
      → nếu dùng không hết là mất

⚠ Cơ chế Savings Plans — điểm hay bị hiểu nhầm:

Bạn cam kết một mức CHI TIÊU MỖI GIỜ
      (ví dụ: 10 USD/giờ)
        ↓
    Mọi lượng dùng tới mức đó → giá SP (rẻ)
    Vượt mức đó → giá On-Demand
        ↓
    → KHÔNG cam kết loại máy nào
    → KHÔNG cam kết số lượng máy
    → chỉ cam kết SỐ TIỀN mỗi giờ

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

• A (Compute Savings Plans 3 năm, Partial Upfront) — đây là phương án gần nhất và loại Savings Plans hoàn toàn đúng, chỉ khác ở cách thanh toán. Partial Upfront giảm sâu hơn một chút, nhưng phần trả trước là tiền đã bỏ ra, trái với yêu cầu "không để reservation nào bị bỏ phí".

• C (EC2 Instance Savings Plans 3 năm, Full Upfront) — sai nặng nhất: EC2 Instance SP không áp cho Fargate, nên sau sáu tháng cam kết ba năm này thành vô dụng, mà tiền thì đã trả toàn bộ.

• D (EC2 Reserved Instances 3 năm, Partial Upfront) — RI chỉ áp cho EC2, không áp cho Fargate. Cũng thành cam kết chết sau sáu tháng.

Ghi nhớ

⚠ Ba loại Savings Plans — bảng phải thuộc: | Loại | Áp cho | Mức giảm | |---|---|---| | Compute Savings Plans | EC2, FARGATE, LAMBDA — mọi Region, mọi họ máy | tới 66% | | EC2 Instance Savings Plans | MỘT họ máy trong MỘT Region | tới 72% | | SageMaker Savings Plans | SageMaker | tới 64% | | Thời hạn | 1 hoặc 3 năm | 3 năm giảm sâu hơn | | Thanh toán | No / Partial / All Upfront | trả trước nhiều giảm sâu hơn |

Từ khoá nhận diện:

"sắp chuyển sang Fargate / Lambda" → Compute Savings Plans "tải cố định, chắc chắn không đổi" → EC2 Instance SP (giảm sâu hơn) "không muốn tiền bị kẹt" → No Upfront "cần bảo đảm CÓ máy" → Capacity Reservation hoặc Zonal RI, không phải SP "chịu được gián đoạn" → Spot

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã dùng hết cam kết chưa | Cost Explorer → Savings Plans utilization report | | Còn bao nhiêu chi tiêu chưa phủ | coverage report | | Nên cam kết bao nhiêu | Savings Plans recommendations, chọn khung 7/30/60 ngày |

Và một nguyên tắc rất đáng nhớ khi chọn mức cam kết: cam kết theo mức chi tiêu THẤP NHẤT mà bạn chắc chắn sẽ dùng, không phải theo mức trung bình. Phần vượt lên trên vẫn được tính giá On-Demand bình thường, nên cam kết thấp mà dùng hết luôn tốt hơn cam kết cao rồi lãng phí — nhất là với một công ty đang trong giai đoạn chuyển đổi kiến trúc như trong đề.

Đáp án

D — Chụp SNAPSHOT của instance, COPY snapshot có bật mã hoá, rồi khôi phục thành một instance MỚI.

Vì sao đúng

Có một quy tắc rất cứng của RDS quyết định câu này: không bật mã hoá cho một instance đã tồn tại.

⚠ Điểm mấu chốt — mã hoá RDS chỉ đặt được LÚC TẠO:

Mã hoá RDS
        ↓
    Chỉ khai được KHI TẠO instance
        ↓
    Không có nút "bật mã hoá" cho instance có sẵn
    Không đổi được từ chưa mã hoá → đã mã hoá tại chỗ
        ↓
    → cách duy nhất: TẠO INSTANCE MỚI đã mã hoá
      rồi chuyển dữ liệu sang

⚠ Quy trình bốn bước:

1. Chụp snapshot instance hiện tại
     create-db-snapshot
        ↓
2. COPY snapshot, BẬT mã hoá trong lúc copy
     copy-db-snapshot --kms-key-id <CMK>
        ↓
    → đây là bước "biến" dữ liệu chưa mã hoá
      thành đã mã hoá
        ↓
3. Khôi phục snapshot đã mã hoá thành instance MỚI
     restore-db-instance-from-db-snapshot
        ↓
4. Chuyển ứng dụng sang endpoint mới,
   kiểm chứng, rồi xoá instance cũ

⚠ Giảm gián đoạn khi chuyển:

Cách đơn giản: chấp nhận gián đoạn
        ↓
    Dừng ghi → snapshot → copy → restore → đổi endpoint
    → mất từ vài chục phút tới vài giờ

Cách gián đoạn tối thiểu: DÙNG AWS DMS
        ↓
    Dựng instance mới đã mã hoá
    → DMS với CDC đồng bộ liên tục từ cũ sang mới
    → chuyển đổi chỉ trong vài giây

⚠ Và nhớ khai lại những thứ KHÔNG đi theo snapshot:

Khôi phục từ snapshot KHÔNG giữ:
        ↓
    - Security group
    - Parameter group
    - Option group
    - Cấu hình Multi-AZ
        ↓
    → phải khai lại, nếu không sẽ dùng giá trị mặc định

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

• C (tạo read replica đã mã hoá rồi thăng cấp thành master) — đây là phương án gần nhất và nghe rất hợp lý, nhưng read replica phải CÙNG trạng thái mã hoá với instance chính: một instance chưa mã hoá không tạo được replica đã mã hoá.

• B (mã hoá bản dự phòng ở AZ thứ hai rồi thăng cấp lên làm chính) — bản dự phòng Multi-AZ không phải một thực thể riêng để thao tác; bạn không truy cập, không cấu hình và không thăng cấp nó bằng tay được.

• A (dùng console RDS để bật mã hoá cho CSDL) — không có tuỳ chọn này. Đây chính là điểm mà câu hỏi kiểm tra.

Ghi nhớ

⚠ Mã hoá RDS — bảng phải thuộc: | Đặc điểm | Nội dung | |---|---| | Bật lúc nào | CHỈ khi TẠO instance | | Bật cho instance có sẵn | snapshot → copy CÓ mã hoá → khôi phục | | Tắt mã hoá | KHÔNG BAO GIỜ được | | Phạm vi | dữ liệu, log, sao lưu, snapshot, read replica | | Read replica | phải cùng trạng thái mã hoá với instance chính | | Khoá | AWS managed (aws/rds) hoặc customer managed |

Từ khoá nhận diện:

"mã hoá một CSDL đã tồn tại" → snapshot → copy có mã hoá → restore "chia sẻ snapshot mã hoá sang tài khoản khác" → BẮT BUỘC dùng CMK, và chia sẻ khoá "mã hoá khi truyền" → bật SSL/TLS trong parameter group "chuyển đổi mà gián đoạn tối thiểu" → AWS DMS với CDC "mã hoá EBS đã tồn tại" → cùng cách: snapshot → copy mã hoá → volume mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance đã mã hoá chưa | describe-db-instances --query '...StorageEncrypted' | | Dùng khoá nào | trường KmsKeyId | | Dữ liệu có đủ không | so số bản ghi các bảng chính giữa cũ và mới |

Và một lưu ý về lựa chọn khoá ngay ở bước copy snapshot: nếu có bất kỳ khả năng nào phải chia sẻ snapshot sang tài khoản khác, hãy dùng customer managed key ngay từ đầu. Snapshot mã hoá bằng khoá mặc định aws/rds không chia sẻ liên tài khoản được, và phát hiện điều đó sau khi đã hoàn tất cả quá trình chuyển đổi nghĩa là phải làm lại toàn bộ từ đầu.

Đáp án

C — Bật XOAY KHOÁ TỰ ĐỘNG trên chính customer master key đang dùng.

Vì sao đúng

Yêu cầu có hai vế: xoay khoá tự động, và volume đang mã hoá vẫn đọc được. Cơ chế xoay của KMS thoả cả hai một cách tự nhiên.

⚠ Điểm mấu chốt — xoay giữ lại vật liệu khoá CŨ:

Bật automatic key rotation trên CMK
        ↓
    KMS sinh VẬT LIỆU KHOÁ MỚI mỗi 365 ngày
        ↓
    Vật liệu khoá CŨ được GIỮ LẠI vô thời hạn
        ↓
    → dữ liệu mã hoá bằng vật liệu cũ
      VẪN GIẢI MÃ ĐƯỢC
    → dữ liệu mới dùng vật liệu mới
        ↓
    KEY ID và ARN KHÔNG ĐỔI
        ↓
    → EBS không phải cấu hình lại gì
    → volume vẫn đọc ghi bình thường

⚠ Và với EBS thì còn một tầng nữa — envelope encryption:

CMK (khoá gốc, nằm trong KMS)
        ↓
    Sinh ra DATA KEY cho volume
        ↓
    Data key được CMK mã hoá và lưu kèm volume
        ↓
    Khi máy dùng volume:
      KMS giải mã data key bằng CMK
      → hypervisor dùng data key để mã hoá/giải mã
        ↓
    Xoay CMK KHÔNG đổi data key của volume cũ
        ↓
    → volume vẫn dùng đúng data key của nó
    → hoàn toàn trong suốt với ứng dụng

⚠ Nếu tuân thủ đòi dữ liệu cũ phải dùng khoá MỚI:

Xoay tự động KHÔNG mã hoá lại dữ liệu cũ
        ↓
    Muốn mã hoá lại thì phải:
      snapshot → copy với khoá mới → volume mới
        ↓
    → nhưng đề KHÔNG đòi điều đó
    → đề chỉ đòi "vẫn đọc được"

Xem thêm câu #11873 (lô 128): cùng chủ đề xoay khoá KMS, ở đó trọng tâm là chọn customer managed key thay vì AWS managed key để đáp ứng yêu cầu tuân thủ.

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

• B (tạo một CMK mới trong KMS và bật xoay trên khoá mới) — đây là phương án gần nhất và cũng là một cách xoay khoá hợp lệ (xoay thủ công), nhưng nó không cần thiết ở đây và tạo thêm việc: volume cũ vẫn gắn với CMK cũ, nên bạn phải mã hoá lại toàn bộ mới dùng được khoá mới.

• A (tạo data key mới trong KMS rồi gán cho EBS) — không gán data key thủ công cho EBS được. Data key do EBS và KMS quản lý tự động ở tầng bên dưới.

• D (sao lưu data key hiện tại rồi bật xoay tự động) — bạn không truy cập được data key của volume; nó nằm ở dạng đã mã hoá trong siêu dữ liệu của volume, và không có thao tác "sao lưu" nào.

Ghi nhớ

⚠ Xoay khoá KMS — những điều phải nhớ chính xác: | Đặc điểm | Nội dung | |---|---| | Chu kỳ | 365 ngày mặc định (đặt được 90-2560 ngày) | | Key ID / ARN | KHÔNG ĐỔI | | Vật liệu khoá cũ | GIỮ LẠI — dữ liệu cũ vẫn giải mã được | | Dữ liệu cũ | KHÔNG được mã hoá lại | | Chi phí | không tính thêm cho mỗi phiên bản | | Bật cho | CHỈ customer managed key — AWS managed key tự xoay, không điều khiển được |

Từ khoá nhận diện:

"xoay khoá mà dữ liệu cũ vẫn đọc được" → automatic key rotation "tuân thủ đòi xoay 365 ngày" → customer managed key + bật rotation "nghi khoá bị lộ" → xoay THỦ CÔNG + MÃ HOÁ LẠI dữ liệu "khoá phải do công ty sinh ra" → imported key material — KHÔNG xoay tự động được "mã hoá EBS đã tồn tại" → snapshot → copy có mã hoá → volume mới

⚠ Envelope encryption — mô hình nền tảng của KMS: | Tầng | Nội dung | |---|---| | CMK | nằm trong KMS, KHÔNG BAO GIỜ rời khỏi dịch vụ | | Data key | khoá thật dùng để mã hoá dữ liệu | | Cách lưu | data key được CMK mã hoá rồi lưu KÈM dữ liệu | | Khi đọc | KMS giải mã data key → dịch vụ dùng nó | | Vì sao thế | KMS không xử lý dữ liệu lớn — chỉ xử lý khoá | | Giới hạn | Encrypt/Decrypt trực tiếp chỉ tới 4 KB |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xoay đã bật chưa | get-key-rotation-status --key-id ... | | Đã xoay bao nhiêu lần | list-key-rotations | | Volume dùng khoá nào | describe-volumes --query '...KmsKeyId' |

Và một điều đáng nói rõ với người phụ trách tuân thủ: xoay khoá tự động của KMS làm mới vật liệu khoá, nhưng không mã hoá lại dữ liệu đã có. Với hầu hết khung tuân thủ thì như vậy là đủ — yêu cầu đặt ra là khoá phải được làm mới định kỳ. Nhưng nếu kiểm toán viên đòi dữ liệu cũ cũng phải được bảo vệ bằng vật liệu khoá mới nhất, bạn sẽ cần một quy trình mã hoá lại riêng, và đó là một dự án chứ không phải một công tắc.

Đáp án

C — CHIA SẺ portfolio Service Catalog với tài khoản mới, rồi NHẬP portfolio đó vào tài khoản.

Vì sao đúng

Service Catalog có sẵn cơ chế chia sẻ, nên không cần dựng lại bất cứ thứ gì.

⚠ Điểm mấu chốt — chia sẻ giữ MỘT nguồn sự thật duy nhất:

Chia sẻ portfolio
        ↓
    Portfolio vẫn THUỘC tài khoản gốc
        ↓
    Tài khoản mới NHẬP và dùng
        ↓
    Chủ sở hữu cập nhật một sản phẩm
        ↓
    → thay đổi TỰ ĐỘNG lan tới MỌI tài khoản nhận
    → không phải đồng bộ thủ công
    → không có chuyện mỗi nơi một phiên bản

⚠ Hai cách chia sẻ — cách thứ hai gần như luôn tốt hơn:

Chia sẻ theo TÀI KHOẢN
        ↓
    create-portfolio-share --account-id 111122223333
        ↓
    Bên nhận phải TỰ NHẬP (accept + import)
    → mỗi tài khoản mới là một lần thao tác

Chia sẻ qua ORGANIZATIONS  ← khuyến nghị
        ↓
    create-portfolio-share --organization-node
      Type=ORGANIZATIONAL_UNIT,Value=ou-xxxx
        ↓
    → chia sẻ với cả một OU
    → TÀI KHOẢN MỚI vào OU TỰ CÓ portfolio
    → không thao tác gì thêm

⚠ Nhưng nhớ: launch role phải TỒN TẠI ở tài khoản nhận:

Launch constraint khai một IAM role
        ↓
    Role đó phải CÓ ở tài khoản nơi sản phẩm chạy
        ↓
    → dùng StackSets hoặc CloudFormation
      để dựng sẵn role đó ở mọi tài khoản
        ↓
    Thiếu role → sản phẩm khởi chạy thất bại

Xem thêm câu #11891 (cùng lô): nói rõ bên NHẬN làm được gì và KHÔNG làm được gì với một portfolio được chia sẻ — chỉ dùng, không sửa.

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

• B (viết CloudFormation template để triển khai lại portfolio ở tài khoản mới) — đây là phương án gần nhất và về kỹ thuật thì làm được (Service Catalog có kiểu tài nguyên CloudFormation), nhưng nó tạo ra một bản SAO ĐỘC LẬP: từ đó trở đi hai bản sẽ trôi dạt khỏi nhau, và mỗi lần cập nhật sản phẩm là phải triển khai lại ở mọi nơi.

• A (dùng Lambda gọi DescribePortfolio rồi dựng portfolio mới) — tự viết lại cơ chế đã có sẵn, kèm mã phải bảo trì và vẫn tạo ra bản sao độc lập.

• D (tạo tay portfolio ở tài khoản mới và dựng lại từ đầu) — nhiều công nhất, dễ sai nhất, và hoàn toàn không mở rộng được khi có thêm tài khoản.

Ghi nhớ

⚠ Chia sẻ tài nguyên giữa các tài khoản — bảng đáng thuộc: | Tài nguyên | Cách chia sẻ | |---|---| | Service Catalog portfolio | create-portfolio-share — theo tài khoản hoặc theo OU | | Subnet, Transit Gateway, Route 53 Resolver rule | AWS RAM (Resource Access Manager) | | AMI, EBS snapshot, RDS snapshot | modify-*-attribute thêm account id | | KMS key | key policy | | S3 bucket | bucket policy hoặc Access Point | | Secrets Manager secret | resource policy |

Từ khoá nhận diện:

"nhân bản hạ tầng chuẩn sang tài khoản mới" → chia sẻ portfolio "tài khoản mới TỰ ĐỘNG có" → chia sẻ qua Organizations theo OU "chia sẻ subnet, Transit Gateway" → AWS RAM "triển khai stack ra nhiều tài khoản" → CloudFormation StackSets "dựng cả một landing zone" → Control Tower

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chia sẻ với ai | describe-portfolio-shares | | Bên nhận thấy gì | ở tài khoản đó: list-accepted-portfolio-shares | | Khởi chạy có chạy không | thử một sản phẩm — thường hỏng vì thiếu launch role |

Và một bước rất hay bị bỏ sót khi mở rộng ra tài khoản mới: dựng sẵn IAM launch role ở tài khoản nhận trước khi ai đó thử khởi chạy sản phẩm. Portfolio sẽ hiện ra đầy đủ, danh sách sản phẩm trông hoàn toàn bình thường, và lỗi chỉ xuất hiện ở lần khởi chạy đầu tiên — thường là bởi một người dùng cuối không có cách nào tự hiểu vì sao.

Đáp án

D — Tạo RDS PROXY và trỏ ứng dụng tới endpoint của proxy.

Vì sao đúng

Yêu cầu là giảm THỜI GIAN FAILOVER của CSDL, và RDS Proxy có đúng tính năng đó.

⚠ Điểm mấu chốt — phần lớn thời gian failover nằm ở phía CLIENT:

Failover Multi-AZ không có proxy
        ↓
    1. RDS phát hiện sự cố, thăng cấp standby   ~30-60 giây
    2. Bản ghi DNS của endpoint được cập nhật
    3. CLIENT phải chờ HẾT DNS TTL rồi mới
       phân giải lại                            ← chỗ tốn thời gian
    4. Kết nối cũ trong pool đều hỏng,
       ứng dụng phải mở lại từ đầu
        ↓
    Tổng: thường 60-120 giây, có khi lâu hơn
      (JVM cache DNS vĩnh viễn theo mặc định)

⚠ Có proxy thì client không phải biết gì cả:

Ứng dụng luôn kết nối tới ENDPOINT CỦA PROXY
        ↓
    Endpoint này KHÔNG ĐỔI khi failover
        ↓
    Proxy tự phát hiện failover
    → tự kết nối lại tới node chính MỚI
    → GIỮ nguyên kết nối phía ứng dụng
        ↓
    → AWS công bố giảm thời gian failover
      TỚI 66%
    → và ứng dụng không phải xử lý DNS gì

⚠ Proxy còn giải thêm hai bài toán:

Gộp kết nối (connection pooling)
        ↓
    → hết "too many connections"

Xác thực qua Secrets Manager
        ↓
    → mật khẩu không nằm trong ứng dụng
    → xoay mật khẩu không làm đứt kết nối

Xem thêm câu #11893 (cùng lô): cũng là RDS Proxy, ở đó dùng để giải bài toán "too many connections". Cùng một dịch vụ, hai lợi ích khác nhau — khoá nhất quán.

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

• C (cấu hình Multi-AZ chạy qua nhiều Region) — đây là phương án gần nhất về ý tưởng "làm cho dự phòng mạnh hơn", nhưng Multi-AZ theo định nghĩa là trong MỘT Region. Muốn dự phòng đa Region thì phải dùng read replica xuyên Region hoặc Aurora Global Database — và cả hai failover CHẬM HƠN, không nhanh hơn.

• A (thêm CPU và bộ nhớ cho instance) — không ảnh hưởng tới thời gian failover. Thời gian đó do cơ chế phát hiện, thăng cấp và DNS quyết định, không phải do cỡ máy.

• B (chuyển CSDL về chạy trong MỘT Availability Zone) — bỏ luôn khả năng failover, đi ngược hoàn toàn với mục tiêu của một kiến trúc chịu lỗi.

Ghi nhớ

⚠ Thời gian failover của các lựa chọn — bảng phải thuộc: | Cấu hình | Thời gian failover | |---|---| | RDS Multi-AZ (instance) | 60-120 giây | | RDS Multi-AZ + RDS Proxy | giảm tới 66% | | RDS Multi-AZ DB Cluster | dưới 35 giây | | Aurora | thường dưới 30 giây | | Aurora Global Database | RTO dưới 1 phút (failover có kế hoạch), lâu hơn khi mất Region | | Single-AZ | không có failover |

Từ khoá nhận diện:

"giảm thời gian failover" → RDS Proxy, hoặc chuyển sang Aurora "too many connections" → RDS Proxy "chịu được mất cả một Region" → Aurora Global Database, cross-Region replica "ứng dụng kẹt sau failover" → DNS cache của JVM "tải ĐỌC cao" → read replica

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Failover mất bao lâu thật | chủ động failover ở staging, đo từ log ứng dụng | | Proxy có hoạt động không | describe-db-proxies, và chỉ số DatabaseConnections | | Ứng dụng phục hồi sau bao lâu | đếm số lỗi trong log từ lúc failover tới lúc hết |

Và một phép đo rất đáng làm trước khi kết luận đã cải thiện: đo thời gian phục hồi từ phía ỨNG DỤNG, không phải từ phía CSDL. RDS có thể báo failover xong trong 40 giây, nhưng nếu ứng dụng còn mất thêm hai phút để nhận ra và mở lại kết nối thì người dùng vẫn chịu một sự cố hơn hai phút — và chính khoảng chênh lệch đó là thứ RDS Proxy loại bỏ.

Đáp án

A và B — Cụm Amazon ElastiCache và instance Amazon RDS.

Vì sao đúng

Chỉ những dịch vụ ĐƯỢC QUẢN LÝ mà AWS tự vá mới có khái niệm cửa sổ bảo trì.

⚠ Điểm mấu chốt — cửa sổ bảo trì tồn tại ở đâu:

Dịch vụ được quản lý — AWS TỰ VÁ
        ↓
    RDS / Aurora
    ElastiCache
    Redshift, DocumentDB, Neptune,
    OpenSearch, MSK, DMS…
        ↓
    → AWS cần một khung giờ được phép
      áp bản vá và bảo trì
    → đó là MAINTENANCE WINDOW
        ↓
Dịch vụ bạn tự quản — BẠN vá
        ↓
    EC2  → dùng SSM Patch Manager, tự đặt lịch
        ↓
Dịch vụ không có gì để vá
        ↓
    ELB, Auto Scaling → AWS lo hoàn toàn,
    trong suốt với bạn, KHÔNG có cửa sổ nào

⚠ Cửa sổ bảo trì của RDS và ElastiCache:

Khai theo giờ UTC, dạng:
    ddd:hh24:mi-ddd:hh24:mi
        ↓
    Ví dụ: wed:15:00-wed:16:00
      (22:00-23:00 giờ Việt Nam thứ Tư)
        ↓
    Tối thiểu 30 phút
        ↓
    Không đặt → AWS tự chọn một khung
      ngẫu nhiên trong khối 8 giờ của Region

⚠ Và với EC2 thì cơ chế hoàn toàn khác:

Systems Manager MAINTENANCE WINDOW
        ↓
    Bạn tự tạo, tự đặt lịch cron
    Gắn task: Patch Manager, Run Command…
    Chọn target theo tag hoặc patch group
    Đặt concurrency và error threshold
        ↓
    → về hình thức cũng gọi là "maintenance window"
      nhưng thuộc SSM, không phải thuộc EC2
    → và đề hỏi "tài nguyên nào CẦN cấu hình
      cửa sổ bảo trì" theo nghĩa của dịch vụ

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

• D (Amazon EC2 instances) — đây là phương án gần nhất và cũng cần vá thật, nhưng EC2 không có thuộc tính "maintenance window": việc vá do bạn làm, thường qua SSM Patch Manager với maintenance window của SSM, một cơ chế riêng biệt.

• C (Elastic Load Balancer) — AWS quản lý hoàn toàn, tự vá và tự mở rộng trong suốt, không có cửa sổ nào để cấu hình.

• E (Amazon EC2 Auto Scaling) — là một dịch vụ điều phối, không có phần mềm nào chạy để mà vá.

Ghi nhớ

⚠ Ai vá cái gì — bảng phải thuộc: | Tài nguyên | Ai vá | Có cửa sổ bảo trì | |---|---|---| | RDS / Aurora | AWS | CÓ | | ElastiCache | AWS | CÓ | | Redshift, DocumentDB, Neptune, OpenSearch | AWS | có | | EC2 (hệ điều hành) | BẠN | không — dùng SSM Patch Manager | | ELB, Auto Scaling, S3, Lambda | AWS | không có gì để cấu hình | | Fargate | AWS | không |

Từ khoá nhận diện:

"cửa sổ bảo trì cho CSDL / cache" → RDS và ElastiCache "vá hệ điều hành EC2" → SSM Patch Manager + maintenance window của SSM "vá mà không gián đoạn" → giảm concurrency, hoặc golden AMI + instance refresh "ai chịu trách nhiệm vá" → mô hình trách nhiệm chia sẻ "bảo trì theo lịch của AWS trên một EC2" → stop/start để tránh

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cửa sổ hiện tại là khi nào | describe-db-instances --query '...PreferredMaintenanceWindow' | | Có bản vá nào đang chờ | describe-pending-maintenance-actions | | Cửa sổ của ElastiCache | describe-cache-clusters --query '...PreferredMaintenanceWindow' |

Và một sai lầm rất dễ mắc khi đặt cửa sổ bảo trì: quên rằng nó khai theo giờ UTC. Một đội muốn vá lúc 22 giờ đêm giờ Việt Nam mà gõ thẳng wed:22:00-wed:23:00 sẽ vô tình đặt lịch bảo trì vào 5 giờ sáng hôm sau giờ Việt Nam — vẫn là giờ thấp điểm nên không ai để ý, cho tới ngày đầu tiên có một đợt bảo trì kéo dài.

Đáp án

B — VPC FLOW LOGS.

Vì sao đúng

Câu hỏi rất cụ thể: người dùng có đang kết nối tới ĐÚNG CỔNG hay không. Flow log ghi lại cổng đích của từng luồng.

⚠ Điểm mấu chốt — flow log có trường cổng đích:

Mỗi bản ghi flow log chứa:
        ↓
    srcaddr   → ai gọi
    dstaddr   → gọi tới máy nào
    srcport   → cổng nguồn (ngẫu nhiên, dải cao)
    dstport   → CỔNG ĐÍCH  ← trường cần
    protocol  → 6 = TCP
    action    → ACCEPT / REJECT
        ↓
    Lọc theo IP riêng của máy, xem dstport:
        ↓
      thấy 8121 → người dùng gọi ĐÚNG cổng
      thấy 80 hay 443 → gọi SAI cổng
      không thấy gì → gói KHÔNG TỚI được VPC

⚠ Ba kịch bản và cách đọc:

dstport = 8121, action = ACCEPT
        ↓
    → mạng thông, vấn đề nằm ở ỨNG DỤNG
      (dịch vụ chưa chạy, nghe sai địa chỉ)

dstport = 8121, action = REJECT
        ↓
    → security group chưa mở cổng 8121
    → hoặc NACL chặn

dstport = 80 hoặc 443
        ↓
    → người dùng gõ thiếu cổng trong URL
    → đúng nguyên nhân mà đề nghi ngờ

⚠ Và một chi tiết trong đề đáng chú ý:

"DNS phân giải ra IP RIÊNG trong VPC"
        ↓
    → người dùng phải ở TRONG mạng của công ty
      (qua VPN hoặc Direct Connect)
        ↓
    Nếu họ ở ngoài internet
      → tên miền phân giải ra IP riêng
      → không định tuyến được
      → cũng là một nguyên nhân đáng kiểm tra

Xem thêm câu #11848, #11835, #11872 (lô 128) và #11881 (cùng lô): chùm VPC Flow Logs — đọc phán quyết ACCEPT/REJECT, tìm nguồn lưu lượng lớn, chẩn đoán sau khi đổi cấu hình mạng, và chặn một IP.

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

• A (AWS CloudTrail logs) — đây là phương án gần nhất vì cũng là log của AWS, nhưng CloudTrail ghi lời gọi API tới mặt phẳng điều khiển. Việc một người dùng mở kết nối TCP tới cổng 8121 không phải là một lời gọi API, nên không có bản ghi nào.

• C (Elastic Load Balancer access logs) — không có load balancer nào trong tình huống này: đề nói người dùng kết nối thẳng tới instance qua tên DNS của nó.

• D (Amazon S3 access logs) — ghi request tới bucket S3, hoàn toàn không liên quan.

Ghi nhớ

⚠ Chọn đúng log cho đúng câu hỏi — bảng phải thuộc: | Câu hỏi | Log | |---|---| | Kết nối tới cổng nào, có bị chặn không | VPC Flow Logs | | Mã trạng thái HTTP | ALB / CloudFront access log | | Ai gọi API nào | CloudTrail | | Ứng dụng in ra gì | CloudWatch Logs | | Truy vấn DNS nào được thực hiện | Route 53 Resolver query log | | Cấu hình đã đổi thế nào | AWS Config timeline |

Từ khoá nhận diện:

"đúng cổng hay không", "gói bị chặn ở đâu" → VPC Flow Logs "mã lỗi 5xx" → ALB access log "ai đã sửa security group" → CloudTrail "tên miền phân giải ra gì" → Route 53 Resolver query log "đường đi có thông không" → VPC Reachability Analyzer

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng gọi cổng nào | Flow Logs, stats count(*) by dstPort | | Dịch vụ có nghe không | trên máy: ss -tlnp | grep 8121 | | Đường đi có thông không | VPC Reachability Analyzer |

Và một bước kiểm tra rất nhanh nên làm song song với việc đọc log: chạy ss -tlnp ngay trên chính máy đó. Rất thường xuyên, ứng dụng có nghe ở cổng 8121 nhưng chỉ nghe trên 127.0.0.1 thay vì 0.0.0.0 — khi đó flow log sẽ hiện ACCEPT hoàn toàn bình thường, gói tin tới nơi, mà kết nối vẫn bị từ chối.