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

Đáp án

A — Trust policy (chính sách tin cậy).

Vì sao đúng

Đề hỏi rất hẹp: chính sách RESOURCE-BASED duy nhất mà dịch vụ IAM hỗ trợ. Trong IAM, "tài nguyên" ở đây chính là IAM role, và chính sách gắn lên nó là trust policy.

⚠ Điểm mấu chốt — trust policy trả lời câu hỏi "AI được đóng vai này":

Một IAM role có HAI chính sách, hỏi hai câu khác nhau:

    Trust policy (resource-based)
        → AI được phép đóng vai này
        → khai trong trường "Principal"

    Permissions policy (identity-based)
        → đóng vai rồi thì LÀM ĐƯỢC GÌ
        → khai trong "Action" và "Resource"

Ví dụ trust policy:

{
  "Effect": "Allow",
  "Principal": { "Service": "ec2.amazonaws.com" },
  "Action": "sts:AssumeRole"
}

⚠ Dấu hiệu nhận biết một chính sách là resource-based:

Có trường "Principal"
        ↓
    → đó là resource-based policy
        ↓
Không có "Principal" (vì principal chính là identity được gắn)
        ↓
    → đó là identity-based policy

⚠ Và đây là điểm phân biệt quan trọng nhất trong thực tế:

Cùng một tài khoản
        ↓
    Chỉ cần MỘT trong hai chính sách Allow là đủ

KHÁC tài khoản
        ↓
    CẢ HAI đều phải Allow:
        - trust policy ở tài khoản có role
        - chính sách IAM ở tài khoản của người gọi
        ↓
    → thiếu một bên, lỗi trả về GIỐNG HỆT nhau

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

• D (SCP của AWS Organizations) — đây là phương án gần nhất vì SCP cũng "áp lên nhiều người". Nhưng SCP không phải resource-based policy: nó là trần quyền (permissions guardrail) áp cho tài khoản hoặc OU, và nó thuộc dịch vụ Organizations, không phải IAM. SCP cũng không tự cấp quyền gì.

• B (Permissions boundary) — cũng là một trần quyền, nhưng gắn vào một IAM user hoặc role cụ thể. Nó dùng cú pháp chính sách nhưng đóng vai trò giới hạn tối đa, không phải resource-based.

• C (Access control list — ACL) — ACL là cơ chế cũ của S3 (và một vài dịch vụ khác), không thuộc dịch vụ IAM, và không dùng ngôn ngữ chính sách JSON của IAM.

Ghi nhớ

⚠ Các loại chính sách trên AWS — bảng phải thuộc: | Loại | Gắn vào | Có Principal | |---|---|---| | Identity-based | user, group, role | không | | Resource-based | tài nguyên (bucket, queue, key, IAM role) | CÓ | | Permissions boundary | user hoặc role | không — là trần quyền | | SCP | tài khoản hoặc OU | không — là trần quyền | | ACL | S3 (cũ) | — | | Session policy | truyền khi gọi AssumeRole | không |

Từ khoá nhận diện:

"resource-based policy của IAM" → trust policy "ai được đóng vai này" → trust policy "đóng vai rồi làm được gì" → permissions policy "trần quyền cho cả tài khoản" → SCP "trần quyền cho một user" → permissions boundary "có trường Principal" → resource-based

⚠ Thứ tự đánh giá quyền — bảng quyết định mọi câu hỏi IAM: | Bước | Nội dung | |---|---| | 1 | Explicit Deny — thắng tất cả, ở bất kỳ loại chính sách nào | | 2 | SCP — không cho phép thì dừng | | 3 | Resource-based policy — Allow ở đây có thể đủ (cùng tài khoản) | | 4 | Permissions boundary | | 5 | Session policy | | 6 | Identity-based policy | | Mặc định | implicit deny |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trust policy hiện tại | get-role, xem AssumeRolePolicyDocument | | Ai đã đóng vai | CloudTrail sự kiện AssumeRole | | Quyền hiệu lực thật | IAM Policy Simulator |

Và một cảnh báo về một hiểu nhầm rất phổ biến: "Principal": {"AWS": "arn:aws:iam::123456789012:root"} KHÔNG có nghĩa là "chỉ tài khoản root" — nó nghĩa là cả tài khoản đó, tức là mọi user và role trong tài khoản ấy đều có thể được cấp quyền đóng vai. Muốn thắt chặt thật sự thì hãy khai đích danh ARN của role được phép, và cân nhắc thêm điều kiện sts:ExternalId khi bên kia là đối tác ngoài tổ chức.

Đáp án

B, E — hai điểm cần nhớ về organization trail:

• E — Tài khoản thành viên NHÌN THẤY được organization trail, nhưng KHÔNG sửa hay xoá được nó.
• B — Mặc định CloudTrail chỉ ghi thao tác ở MỨC BUCKET. Muốn ghi thao tác ở mức đối tượng thì phải bật S3 data event.

Vì sao đúng

⚠ Điểm E — mô hình phân quyền của organization trail:

Tài khoản QUẢN LÝ (hoặc delegated administrator) tạo trail
        ↓
    Trail tự động áp cho MỌI tài khoản thành viên,
    ở MỌI Region
        ↓
    Tài khoản thành viên:
        - THẤY trail trong console của mình (chỉ đọc)
        - KHÔNG sửa, KHÔNG xoá, KHÔNG tắt được
        ↓
    → đúng ý đồ: không tài khoản nào tự xoá dấu vết của mình

⚠ Điểm B — sự phân biệt tốn kém nhất trong CloudTrail:

Management event (MIỄN PHÍ một bản sao, bật sẵn)
        ↓
    CreateBucket, DeleteBucket, PutBucketPolicy...
    → thao tác lên CHÍNH BUCKET

Data event (CÓ PHÍ, phải tự bật)
        ↓
    GetObject, PutObject, DeleteObject...
    → thao tác lên TỪNG ĐỐI TƯỢNG bên trong
        ↓
    → "ai đã tải tệp mật này về" chỉ có ở data event

Rất nhiều đội chỉ phát hiện điều này khi cần điều tra một vụ rò rỉ dữ liệu — và nhận ra CloudTrail không hề ghi lại lần tải tệp đó.

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

• A (tài khoản thành viên không truy cập được organization trail, cũng không truy cập được bucket S3 chứa log) — đây là phương án gần nhất và vế thứ hai thường đúng trong thực tế (bucket log nằm ở tài khoản quản lý). Nhưng vế thứ nhất sai: tài khoản thành viên thấy được trail ở chế độ chỉ đọc — đó chính là nội dung của phương án E.

• C (mặc định log file của CloudTrail không được mã hoá) — sai: CloudTrail mã hoá log bằng SSE-S3 theo mặc định. (Bạn có thể chuyển sang SSE-KMS để kiểm soát chặt hơn và có nhật ký dùng khoá.)

• D (không có thứ gì gọi là Organization Trail) — sai hoàn toàn; đây là một tính năng có thật và là cách làm được khuyến nghị cho môi trường nhiều tài khoản.

Ghi nhớ

⚠ Ba loại sự kiện của CloudTrail — bảng phải thuộc: | Loại | Ghi gì | Chi phí | |---|---|---| | Management event | thao tác quản trị — tạo, xoá, đổi cấu hình | miễn phí (một bản sao) | | Data event | thao tác lên dữ liệu — GetObject, gọi Lambda, DynamoDB item | CÓ PHÍ | | Insights event | phát hiện tần suất API bất thường | có phí |

Từ khoá nhận diện:

"ai đã tải/xoá một TỆP trong S3" → data event "ai đã tạo/xoá bucket, đổi policy" → management event (miễn phí) "log cho toàn bộ tổ chức" → organization trail "tài khoản thành viên xoá được trail" → SAI, không xoá được "CloudTrail không mã hoá" → SAI, mặc định SSE-S3

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trail có đang ghi không | get-trail-status, xem IsLogging | | Có bao phủ mọi Region không | IsMultiRegionTrail: true | | Data event đã bật chưa | get-event-selectors |

Và một lời khuyên về tổ chức tài khoản: hãy uỷ quyền quản lý CloudTrail cho một tài khoản Security chuyên trách (delegated administrator), thay vì vận hành từ tài khoản quản lý. Tài khoản quản lý của Organizations là tài khoản quyền lực nhất và không bị SCP ràng buộc — nên nguyên tắc chung là dùng nó càng ít càng tốt, và chuyện kiểm toán hằng ngày chắc chắn không nên nằm ở đó.

Đáp án

D — Mục Parameters KHÔNG cho phép dùng Conditions.

Vì sao đúng

Lý do rất logic khi hiểu thứ tự CloudFormation xử lý một template.

⚠ Điểm mấu chốt — Parameters được đọc TRƯỚC khi Conditions được tính:

1. Người dùng nhập giá trị cho Parameters
        ↓
2. CloudFormation dùng các giá trị đó để TÍNH Conditions
        ↓
3. Conditions được áp cho Resources và Outputs
        ↓
    → tới lúc Conditions có kết quả thì
      Parameters ĐÃ ĐƯỢC XỬ LÝ XONG
        ↓
    → không thể quay lại tạo tham số có điều kiện

Nói ngắn gọn: Conditions phụ thuộc vào Parameters, nên Parameters không thể phụ thuộc ngược lại vào Conditions.

⚠ Ba nơi dùng Condition được:

Resources — tạo tài nguyên hay không
    MayDuPhong:
      Type: AWS::EC2::Instance
      Condition: LaMoiTruongProd

Outputs — xuất giá trị hay không
    Outputs:
      DiaChiDuPhong:
        Condition: LaMoiTruongProd
        Value: !GetAtt MayDuPhong.PublicIp

Conditions — điều kiện lồng nhau
    Conditions:
      LaProd: !Equals [!Ref MoiTruong, "prod"]
      LaProdVaCoBackup: !And [!Condition LaProd, !Condition CoBackup]

⚠ Vậy nếu muốn "tham số có điều kiện" thì làm sao:

Dùng AllowedValues để giới hạn giá trị hợp lệ
Dùng Default để có giá trị mặc định
Dùng AllowedPattern để ràng buộc định dạng
        ↓
    Rồi để Conditions quyết định TÀI NGUYÊN nào được tạo
        ↓
    → tham số vẫn luôn tồn tại, chỉ là có thể không được dùng tới

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

(Ba mục còn lại đều dùng Condition được, nên không phải đáp án.)

• B (Conditions) — đây là phương án gần nhất và nghe rất tự mâu thuẫn, nên dễ chọn. Nhưng chính mục này dùng được điều kiện lồng nhau qua các hàm !And, !Or, !Not, !Condition — tức là một điều kiện xây trên điều kiện khác.

• A (Resources) — đây là nơi dùng Condition phổ biến nhất.

• C (Outputs) — cũng gắn Condition cho từng output được.

Ghi nhớ

⚠ Các mục của template CloudFormation — bảng phải thuộc: | Mục | Bắt buộc | Dùng Condition | |---|---|---| | AWSTemplateFormatVersion | không | — | | Description | không | — | | Metadata | không | — | | Parameters | không | KHÔNG | | Mappings | không | không | | Conditions | không | có (lồng nhau) | | Transform | không | — | | Resources | CÓ | có | | Outputs | không | có |

Từ khoá nhận diện:

"mục nào không dùng được Conditions" → Parameters "tạo tài nguyên tuỳ môi trường" → Condition trên Resources "chọn AMI theo Region" → Mappings + !FindInMap "chia sẻ giá trị cho stack khác" → Outputs + Export "dùng SAM hoặc macro" → Transform

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Template có hợp lệ không | validate-template | | Điều kiện có đúng như mong đợi không | tạo change set rồi xem tài nguyên nào sẽ được tạo | | Lỗi cú pháp sớm | cfn-lint — bắt được nhiều lỗi trước khi triển khai |

Và một mẹo rất hữu dụng ít người biết: AWS::NoValue cho phép bạn bỏ hẳn một thuộc tính chứ không chỉ đổi giá trị của nó. Điều này quan trọng vì nhiều thuộc tính của AWS có hành vi mặc định khác hẳn khi không được khai so với khi khai bằng chuỗi rỗng hay null — và !If [DieuKien, <giá trị>, !Ref "AWS::NoValue"] là cách duy nhất diễn đạt "trong trường hợp này thì đừng khai thuộc tính đó".

Đáp án

B — Tạo một bản ghi CNAME.

Vì sao đúng

Chi tiết quyết định nằm ở đích đến: yourapp.freehosting.com — đó là một TÊN MIỀN của bên thứ ba, không phải tài nguyên AWS và cũng không phải một địa chỉ IP.

⚠ Điểm mấu chốt — CNAME trỏ tên miền này sang tên miền khác:

www.yourdomain.com  →  CNAME  →  yourapp.freehosting.com
        ↓
    Trình duyệt hỏi Route 53
        ↓
    Route 53 trả về: "hãy hỏi tiếp yourapp.freehosting.com"
        ↓
    Trình duyệt phân giải tiếp tên đó, lấy IP thật
        ↓
    → nhà cung cấp đổi IP lúc nào cũng được,
      bạn không phải sửa gì

⚠ Vì sao KHÔNG dùng Alias record — đây là bẫy chính:

Alias record là tính năng RIÊNG của Route 53
        ↓
    Nó CHỈ trỏ được tới TÀI NGUYÊN AWS:
        - CloudFront distribution
        - Application/Network Load Balancer
        - S3 static website endpoint
        - API Gateway, Elastic Beanstalk
        - VPC endpoint, Global Accelerator
        - hoặc một record khác trong CÙNG hosted zone
        ↓
    → KHÔNG trỏ tới tên miền bên ngoài AWS được

⚠ Và một hạn chế của CNAME phải nhớ đời:

CNAME KHÔNG dùng được cho ZONE APEX (tên miền gốc)
        ↓
    yourdomain.com       → KHÔNG tạo CNAME được (chuẩn DNS cấm)
    www.yourdomain.com   → CNAME được
        ↓
    Đề hỏi "www.yourdomain.com" → hợp lệ
        ↓
    Muốn trỏ chính yourdomain.com tới tài nguyên AWS
        ↓
    → dùng ALIAS (đây là lý do Alias tồn tại)

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

• D (tạo Alias record) — đây là phương án gần nhất và là câu trả lời đúng khi đích là tài nguyên AWS. Nhưng freehosting.com là bên thứ ba, nên Alias không dùng được. Đây chính là ranh giới mà câu hỏi kiểm tra.

• C (tạo A record) — A record trỏ tới một địa chỉ IPv4 cụ thể. Bạn không biết IP của nhà cung cấp, và họ có thể đổi nó bất cứ lúc nào mà không báo — ứng dụng sẽ chết mà không rõ nguyên nhân.

• A (tạo PTR record) — PTR dùng cho phân giải ngược (từ IP ra tên miền), thường phục vụ máy chủ thư điện tử. Hoàn toàn không liên quan.

Ghi nhớ

⚠ CNAME và Alias — bảng phải thuộc, đây là câu hỏi kinh điển của Route 53: | | CNAME | Alias | |---|---|---| | Chuẩn | DNS tiêu chuẩn | riêng của Route 53 | | Trỏ tới | bất kỳ tên miền nào | chỉ tài nguyên AWS hoặc record cùng zone | | Zone apex (yourdomain.com) | KHÔNG được | ĐƯỢC | | Chi phí truy vấn | có tính phí | MIỄN PHÍ | | Health check tự động | không | có với một số tài nguyên | | TTL | bạn đặt | theo tài nguyên AWS |

Từ khoá nhận diện:

"trỏ tới tên miền bên ngoài AWS" → CNAME "trỏ tới ALB, CloudFront, S3 website" → Alias "trỏ tên miền GỐC (zone apex)" → Alias (CNAME không được) "trỏ tới một địa chỉ IP" → A (IPv4) hoặc AAAA (IPv6) "phân giải ngược từ IP" → PTR "máy chủ thư điện tử" → MX "xác minh sở hữu tên miền" → TXT

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Record đã lan chưa | dig www.yourdomain.com CNAME | | Đích phân giải ra gì | dig yourapp.freehosting.com | | Chi phí truy vấn | Alias miễn phí, CNAME tính phí |

Và một lời khuyên về vận hành DNS: hãy hạ TTL xuống thấp vài ngày TRƯỚC khi định chuyển đổi nhà cung cấp, rồi nâng lại sau khi xong. TTL là thời gian mà các resolver trên khắp thế giới còn giữ câu trả lời cũ — với TTL 24 giờ, một lần chuyển đổi có thể mất trọn một ngày mới lan hết, và trong suốt thời gian đó bạn không có cách nào thúc nó nhanh hơn.

Đáp án

D — Rolling.

Vì sao đúng

Đề nêu hai ràng buộc, và chỉ Rolling thoả cả hai:

⚠ Điểm mấu chốt — Rolling cập nhật tại chỗ theo từng lô, không thêm máy:

Fleet 4 máy, kích thước lô = 2
        ↓
    Rút 2 máy khỏi load balancer → cập nhật → đưa lại
        ↓
    Trong lúc đó: 2 máy còn lại vẫn chạy BẢN CŨ
        ↓
    Lô 1 xong (bản mới) + lô 2 chưa (bản cũ)
        ↓
    → HAI PHIÊN BẢN CÙNG PHỤC VỤ  ← đúng yêu cầu
    → tổng số máy KHÔNG ĐỔI       ← không thêm chi phí

⚠ Cái giá của Rolling — phải biết để trả lời đúng các câu hỏi khác:

Trong lúc triển khai, dung lượng phục vụ GIẢM
        ↓
    4 máy → còn 2 máy gánh toàn bộ lưu lượng
        ↓
    → nếu đang ở giờ cao điểm thì có thể quá tải
        ↓
    Muốn giữ nguyên dung lượng
        ↓
    → dùng "Rolling with additional batch"
    → nhưng nó THÊM MÁY, tức là THÊM CHI PHÍ

Đây chính là ranh giới giữa đáp án D và phương án C.

Xem thêm câu #11628 và #11688: cùng chủ đề triển khai Beanstalk nhưng ràng buộc khác nhau — #11628 cần rút ngắn thời gian nâng cấp mà không hy sinh tính sẵn sàng (Golden AMI + Blue/Green); #11688 cần phút chết tối thiểu và quay lui nhanh (Blue/Green). Ba câu không mâu thuẫn: ràng buộc của đề quyết định kiểu triển khai.

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

• C (Rolling with additional batches) — đây là phương án gần nhất và cũng cho hai phiên bản cùng phục vụ. Nhưng nó thêm một lô máy mới trước khi cập nhật, tức là phát sinh chi phí — trái với ràng buộc rõ ràng của đề.

• A (Immutable) — dựng một Auto Scaling group mới hoàn toàn với đầy đủ số máy, rồi mới chuyển lưu lượng. Trong lúc đó bạn trả tiền cho gấp đôi số máy — chi phí cao nhất trong các lựa chọn.

• B (All at once) — cập nhật toàn bộ fleet cùng lúc, nên không có lúc nào hai phiên bản cùng phục vụ, và có phút chết. Trượt yêu cầu thứ nhất.

Ghi nhớ

⚠ Sáu kiểu triển khai của Elastic Beanstalk — bảng phải thuộc: | Kiểu | Phút chết | Thêm máy | Hai phiên bản cùng chạy | Quay lui | |---|---|---|---|---| | All at once | CÓ | không | không | triển khai lại | | Rolling | không | không | CÓ | triển khai lại | | Rolling with additional batch | không | CÓ (một lô) | CÓ | triển khai lại | | Immutable | không | CÓ (gấp đôi) | CÓ | nhanh — bỏ ASG mới | | Traffic splitting | không | có | CÓ (canary) | nhanh | | Blue/Green (swap URL) | không | CÓ (gấp đôi) | có | TỨC THÌ |

Từ khoá nhận diện:

"hai phiên bản cùng chạy, KHÔNG thêm chi phí" → Rolling "giữ nguyên dung lượng phục vụ" → Rolling with additional batch hoặc Immutable "quay lui tức thì" → Blue/Green (swap URL) "thử với một phần nhỏ người dùng" → Traffic splitting (canary) "nhanh nhất, chấp nhận gián đoạn" → All at once (chỉ hợp môi trường dev) "an toàn nhất trong các kiểu tại chỗ" → Immutable

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Triển khai đang ở lô nào | event log của môi trường | | Máy nào đang chạy phiên bản nào | trang Health của môi trường, cột Deployment ID | | Hỏng thì dừng ở đâu | Beanstalk dừng lại nếu một lô trượt health check |

Và một cảnh báo về hậu quả khó chịu nhất của Rolling: nếu một lô triển khai thất bại, môi trường sẽ mắc kẹt ở trạng thái hỗn hợp — một phần máy chạy bản mới, một phần chạy bản cũ, và Beanstalk dừng lại chờ bạn xử lý. Đó là lý do vì sao nhiều đội chọn Immutable dù tốn hơn: khi hỏng, bạn chỉ cần bỏ đi cái Auto Scaling group mới, còn fleet cũ chưa hề bị đụng tới.

Đáp án

B — Với DB cluster tương thích MySQL, bạn bật slow query log, general log hoặc audit log để thấy hoạt động của cơ sở dữ liệu.

Vì sao đúng

Aurora Serverless có một đặc điểm kiến trúc quan trọng: bạn không có instance để đăng nhập vào xem log.

⚠ Điểm mấu chốt — Aurora Serverless bắt buộc phải đẩy log ra CloudWatch:

Aurora Serverless v1 nối qua một PROXY FLEET
        ↓
    Máy chủ cơ sở dữ liệu được cấp phát và thu hồi liên tục
        ↓
    → KHÔNG có instance cố định để tải tệp log về
        ↓
    → cách DUY NHẤT để giữ log là
      BẬT chúng và cho xuất sang CloudWatch Logs

⚠ Ba loại log của MySQL/Aurora — mỗi loại một mục đích:

⚠ Cách bật — qua DB cluster parameter group:

slow_query_log            = 1
long_query_time           = 1          (giây)
general_log               = 1          (chỉ khi cần gỡ lỗi)
server_audit_logging      = 1
server_audit_events       = CONNECT,QUERY,TABLE
        ↓
Rồi khai xuất sang CloudWatch:
    EnableCloudwatchLogsExports = [audit, error, general, slowquery]

⚠ Với Aurora Serverless v1 còn một chi tiết riêng:

Aurora Serverless v1 chỉ hỗ trợ log qua CloudWatch
        ↓
    → không tải tệp log về được như Aurora thường
        ↓
    Aurora Serverless v2 giống Aurora provisioned hơn
        ↓
    → linh hoạt hơn nhiều về log và về tính năng

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

• C (Aurora Serverless đã tích hợp CloudWatch, log được gửi tự động) — đây là phương án gần nhất và đúng một nửa: Aurora có tích hợp CloudWatch, và chỉ số đúng là tự động. Nhưng log thì KHÔNG tự động — bạn phải bật từng loại log và khai xuất chúng. Đây là bẫy trung tâm của câu hỏi.

• A (xem log trực tiếp từ console RDS) — với Aurora thường thì được, nhưng Aurora Serverless v1 không có instance để hiển thị tệp log; console không có mục đó.

• D (không xem được log, phải liên hệ AWS Support) — sai; vế "nối qua proxy fleet" là mô tả đúng kiến trúc, nhưng kết luận thì sai hoàn toàn — log hoàn toàn lấy được qua CloudWatch.

Ghi nhớ

⚠ Aurora Serverless v1 và v2 — bảng phải thuộc: | | v1 | v2 | |---|---|---| | Co giãn | theo bậc, có thể dừng hẳn về 0 | liên tục, mượt, tối thiểu 0,5 ACU | | Thời gian co giãn | hàng chục giây | dưới một giây | | Kết nối | qua proxy fleet | như Aurora thường | | Read replica | không | có | | Multi-AZ | có (tự động) | có | | Log | chỉ qua CloudWatch | linh hoạt hơn |

Từ khoá nhận diện:

"log của Aurora Serverless" → bật log rồi xuất sang CloudWatch Logs "log tự động gửi" → SAI, phải bật thủ công "truy vấn nào chậm" → slow query log hoặc Performance Insights "ai kết nối, chạy lệnh gì" → audit log "chỉ số cấp hệ điều hành" → Enhanced Monitoring "chỉ số cơ sở dữ liệu" → tự động vào CloudWatch, không cần bật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Log đã bật chưa | describe-db-clusters, xem EnabledCloudwatchLogsExports | | Tham số đã áp chưa | describe-db-cluster-parameters, trạng thái phải in-sync | | Log group ở đâu | /aws/rds/cluster/<ten>/audit, /slowquery, /error, /general |

Và một lời khuyên rất thực tế: hãy đặt retention cho các log group của RDS ngay khi bật log. Log group của CloudWatch mặc định giữ vĩnh viễn, và audit log của một cơ sở dữ liệu bận rộn tích tụ rất nhanh — nhiều đội chỉ phát hiện điều này khi thấy CloudWatch Logs bỗng chiếm một phần đáng kể hoá đơn, cho những dòng log mà không ai đọc lại kể từ tuần đầu tiên.

Đáp án

C — Chọn Amazon EC2 Dedicated Host.

Vì sao đúng

Cụm từ quyết định trong đề là "cấu hình ở MỨC SOCKET" — và chỉ Dedicated Host cho bạn nhìn thấy tầng đó.

⚠ Điểm mấu chốt — chỉ Dedicated Host phơi bày phần cứng vật lý:

Dedicated Instance
        ↓
    Phần cứng KHÔNG chia sẻ với tài khoản khác
        ↓
    Nhưng bạn KHÔNG thấy số socket, số lõi, không biết
    instance nằm trên máy vật lý nào
        ↓
    → phần mềm tính giấy phép theo socket KHÔNG dùng được

Dedicated Host
        ↓
    Bạn thuê nguyên MỘT MÁY CHỦ VẬT LÝ
        ↓
    → thấy số SOCKET và số LÕI VẬT LÝ
    → biết instance nào nằm trên host nào
    → host giữ nguyên qua các lần stop/start (host affinity)
        ↓
    → đúng yêu cầu của giấy phép BYOL

⚠ Vì sao giấy phép phần mềm lại đòi điều này:

Oracle, Windows Server, SQL Server, SUSE...
        ↓
    Tính tiền theo SỐ SOCKET hoặc SỐ LÕI VẬT LÝ
        ↓
    Nhà cung cấp phần mềm yêu cầu bằng chứng
    rằng phần mềm chỉ chạy trên đúng số socket đã mua
        ↓
    → phải chứng minh được vị trí vật lý
    → chỉ Dedicated Host làm được

⚠ Và AWS còn có công cụ riêng cho việc này:

AWS License Manager
        ↓
    Khai quy tắc giấy phép (số socket, số lõi, số vCPU)
        ↓
    → tự động ngăn khởi chạy instance vượt hạn mức giấy phép
    → theo dõi mức sử dụng giấy phép
    → sinh báo cáo cho kỳ kiểm toán của nhà cung cấp

Xem thêm câu #11672: cùng lựa chọn giữa Dedicated Instance và Dedicated Host, nhưng ở đó yêu cầu chỉ là phần cứng riêng với chi phí thấp nhất, nên đáp án là Dedicated Instance. Hai câu không mâu thuẫn: chi tiết "mức socket" mới là thứ đẩy sang Dedicated Host.

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

• A (Dedicated Instance) — đây là phương án gần nhất và cũng cho phần cứng riêng, nhưng nó không phơi bày socket và lõi vật lý, nên không đáp ứng được yêu cầu về giấy phép của đề.

• B (Reserved Instances) — mô hình GIÁ, không phải mô hình thuê phần cứng. RI không quyết định instance chạy trên phần cứng dùng chung hay riêng.

• D (On-Demand instances) — cũng là mô hình giá, và mặc định chạy trên phần cứng dùng chung.

Ghi nhớ

⚠ Ba mô hình thuê phần cứng của EC2 — bảng phải thuộc: | Tenancy | Phần cứng riêng | Thấy socket/lõi | Tính tiền | |---|---|---|---| | default (shared) | không | không | theo instance, rẻ nhất | | dedicated | có | KHÔNG | theo instance | | host | có | CÓ | theo HOST |

Từ khoá nhận diện:

"giấy phép theo socket/lõi", "BYOL" → Dedicated Host "phần cứng riêng, rẻ nhất" → Dedicated Instance "cần biết instance nằm trên host nào" → Dedicated Host "quản lý và kiểm toán giấy phép" → AWS License Manager "On-Demand / RI / Spot" → mô hình GIÁ, không phải tenancy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Host có bao nhiêu socket/lõi | describe-hosts, xem HostProperties | | Instance đang ở host nào | describe-instances, xem Placement.HostId | | Giấy phép còn bao nhiêu | AWS License Manager dashboard |

Và một lời khuyên trước khi ký hợp đồng hạ tầng: hãy để bộ phận pháp chế xác nhận điều khoản giấy phép TRƯỚC khi chọn giữa Dedicated Instance và Dedicated Host. Khoản chênh lệch chi phí giữa hai lựa chọn là đáng kể và kéo dài nhiều năm — nhưng một cuộc kiểm toán giấy phép mà bạn không chứng minh được số socket vật lý còn đắt hơn thế rất nhiều lần.

Đáp án

D — Tạo backup plan trong AWS Backup, gắn tag theo môi trường (Production, Development, Testing), tạo một chính sách cho production và một cho non-production, rồi lên lịch theo chính sách sao lưu của tổ chức.

Vì sao đúng

Đề nêu ba yêu cầu, và AWS Backup là dịch vụ duy nhất đáp ứng cả ba mà không phải tự viết gì:

⚠ Điểm mấu chốt — AWS Backup gom mọi loại tài nguyên vào một chính sách:

Một backup plan duy nhất bao phủ:
        EBS, EC2, RDS, Aurora, DynamoDB
        EFS, FSx, Storage Gateway
        S3, DocumentDB, Neptune, Redshift
        VMware tại chỗ
        ↓
    Chọn tài nguyên theo TAG
        ↓
    → tài nguyên mới gắn đúng tag là TỰ ĐỘNG được sao lưu
    → không phải sửa chính sách mỗi lần thêm máy

⚠ Sao lưu chéo Region và chéo tài khoản — khai ngay trong plan:

Rules:
  - RuleName: hang-ngay-prod
    ScheduleExpression: "cron(0 17 * * ? *)"
    Lifecycle: { DeleteAfterDays: 35 }
    CopyActions:
      - DestinationBackupVaultArn: "arn:aws:backup:us-east-1:...:backup-vault/dr-vault"
        Lifecycle: { MoveToColdStorageAfterDays: 30, DeleteAfterDays: 365 }

⚠ Và thứ khiến AWS Backup vượt trội cho môi trường nhiều tài khoản:

Backup Policy gắn vào OU trong AWS Organizations
        ↓
    Mọi tài khoản trong OU đó tự động áp chính sách
        ↓
    Tài khoản thành viên KHÔNG sửa hay xoá được
        ↓
    → tài khoản mới thêm vào tổ chức được bảo vệ NGAY
    → đúng bài toán "nhiều tài khoản" của đề

Và một tính năng riêng đáng nhớ: Backup Vault Lock — chế độ compliance khiến không ai xoá được bản sao lưu, kể cả root.

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

• A (dùng Amazon Data Lifecycle Manager) — đây là phương án gần nhất và DLM đúng là công cụ tốt cho snapshot theo tag. Nhưng nó chỉ hỗ trợ EBS snapshot và AMI, không bao phủ RDS, DynamoDB, EFS, và không có cơ chế chính sách chéo tài khoản như Organizations Backup Policy.

• C (dùng Systems Manager Maintenance Windows để lên lịch tác vụ sao lưu) — làm được nhưng phải tự viết runbook cho từng loại tài nguyên, tự lo sao chép chéo Region, tự tổng hợp báo cáo — nghĩa là tự dựng lại AWS Backup bằng tay.

• B (dùng EventBridge dựng workflow sao lưu) — cũng tự chế: phải tự viết Lambda cho từng loại tài nguyên, tự quản vòng đời, tự lo xử lý lỗi và thử lại.

Ghi nhớ

⚠ Bốn công cụ sao lưu trên AWS — bảng phải thuộc: | Công cụ | Phạm vi | |---|---| | AWS Backup | mọi dịch vụ, mọi tài khoản, mọi Region — tập trung | | Data Lifecycle Manager (DLM) | chỉ EBS snapshot và AMI, theo tag | | Snapshot thủ công / tự động của RDS | chỉ RDS | | S3 Versioning + Replication | chỉ S3 |

Từ khoá nhận diện:

"sao lưu tập trung, nhiều tài khoản, nhiều Region" → AWS Backup "chỉ EBS snapshot theo tag" → DLM (rẻ hơn, đơn giản hơn) "không ai xoá được bản sao lưu" → Backup Vault Lock (compliance mode) "báo cáo tuân thủ sao lưu" → AWS Backup Audit Manager "khôi phục về một thời điểm bất kỳ" → PITR (RDS, DynamoDB, S3)

⚠ Backup Vault Lock — hai chế độ, khác nhau một trời một vực: | Chế độ | Gỡ được không | |---|---| | Governance | tài khoản có quyền đặc biệt gỡ được | | Compliance | KHÔNG AI gỡ được, kể cả root — có cửa sổ nguội 3 ngày |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài nguyên nào đang được bảo vệ | Protected resources trong console | | Có tài nguyên nào bị bỏ sót không | Backup Audit Manager, hoặc Config rule về tag | | Khôi phục có chạy không | diễn tập khôi phục thật, đo cả thời gian |

Và lời khuyên quan trọng nhất về sao lưu, đúng cho mọi kiến trúc: hãy đặt backup vault ở một tài khoản AWS RIÊNG mà đội vận hành hằng ngày không có quyền xoá. Toàn bộ giá trị của một bản sao lưu nằm ở chỗ nó sống sót qua đúng sự cố đã phá huỷ bản gốc — và với mã độc tống tiền hay một tài khoản bị chiếm quyền, bản sao lưu nằm cùng tài khoản với dữ liệu gốc thường bị xoá trước tiên.

Đáp án

D — Tạo một image từ instance, khởi chạy instance mới từ image đó với loại máy mong muốn, rồi gỡ Elastic IP từ máy cũ và gắn sang máy mới để dịch vụ không gián đoạn.

Vì sao đúng

Hai từ khoá của đề quyết định toàn bộ: instance store-backed và đổi loại instance.

⚠ Điểm mấu chốt — instance store-backed KHÔNG đổi loại máy được:

Đổi loại instance đòi phải STOP máy
        ↓
    Instance store-backed KHÔNG STOP ĐƯỢC
        ↓
    (đĩa gắn thẳng vào host, stop là mất sạch dữ liệu,
     nên AWS không cho phép thao tác này)
        ↓
    → cách DUY NHẤT: tạo AMI mới rồi khởi chạy máy mới

⚠ Quy trình đầy đủ:

1. Tạo instance store-backed AMI
       (dùng công cụ ec2-bundle-vol, đóng gói lên S3)
        ↓
2. Khởi chạy instance MỚI từ AMI đó, chọn loại máy mới
        ↓
3. Chuyển ELASTIC IP từ máy cũ sang máy mới
        ↓
4. Kiểm tra, rồi chấm dứt máy cũ

⚠ Và đây là lý do phải là ELASTIC IP chứ không phải IP công cộng thường:

IP công cộng TỰ ĐỘNG (auto-assigned)
        ↓
    Gắn cứng với instance, KHÔNG chuyển đi đâu được
        ↓
    Máy mới nhận một IP khác hoàn toàn
        ↓
Elastic IP
        ↓
    Là tài nguyên ĐỘC LẬP của tài khoản bạn
        ↓
    → gỡ khỏi máy này, gắn vào máy khác trong vài giây
    → khách hàng vẫn gọi vào đúng địa chỉ cũ

Chính chi tiết này phân biệt đáp án D với phương án C.

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

• C (tạo image, khởi chạy máy mới, và "IP công cộng có thể chuyển theo instance") — đây là phương án gần nhất và hai bước đầu hoàn toàn đúng. Nhưng vế cuối sai: IP công cộng tự động KHÔNG chuyển được. Chỉ Elastic IP mới làm được điều đó.

• A (không đổi cỡ được, hãy chuyển ổ gốc sang EBS rồi dùng EBS volume để di chuyển) — không có cách chuyển tại chỗ từ instance store-backed sang EBS-backed. Muốn đổi thì vẫn phải dựng máy mới từ một AMI EBS-backed.

• B (không đổi cỡ được, hãy chọn máy mới và chuyển ứng dụng sang) — vế đầu đúng nhưng vế sau quá mơ hồ: "chuyển ứng dụng sang" bằng cách nào? Nó bỏ qua đúng cơ chế cần thiết (tạo AMI) và bỏ qua việc giữ địa chỉ.

Ghi nhớ

⚠ Instance store-backed và EBS-backed — bảng phải thuộc: | | Instance store-backed | EBS-backed | |---|---|---| | Stop được | KHÔNG | có | | Đổi loại instance | KHÔNG — phải tạo máy mới | có (stop → modify → start) | | Dữ liệu khi terminate | mất sạch | volume có DeleteOnTermination: false thì còn | | Thời gian khởi động | chậm hơn (phải tải từ S3) | nhanh | | Ổ gốc | đĩa gắn vào host | EBS volume | | Tạo AMI | ec2-bundle-vol + upload S3 | create-image |

Từ khoá nhận diện:

"instance store-backed, đổi loại máy" → tạo AMI → máy mới → chuyển Elastic IP "stop instance store-backed" → KHÔNG ĐƯỢC "giữ nguyên địa chỉ khi thay máy" → Elastic IP (không phải IP công cộng thường) "EBS-backed đổi loại máy" → stop → modify-instance-attribute → start "dữ liệu tạm, hiệu năng cao nhất" → instance store

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Instance thuộc loại nào | describe-instances, xem RootDeviceType (instance-store hay ebs) | | Elastic IP đã chuyển chưa | describe-addresses, xem InstanceId | | Máy mới chạy đúng chưa | kiểm tra ứng dụng trước khi chấm dứt máy cũ |

Và một lời khuyên về kiến trúc rút ra từ chính tình huống này: nếu bạn còn đang chạy instance store-backed cho hệ thống sản xuất, hãy coi đây là dịp để chuyển sang EBS-backed. Không stop được, không đổi loại máy được, không snapshot được theo cách thông thường — mọi thao tác vận hành bình thường đều trở thành một cuộc di chuyển máy chủ, và cái giá đó lớn hơn nhiều so với chút hiệu năng I/O mà phần lớn ứng dụng không hề dùng tới.

Đáp án

B — CMK bị xoá một ngày trước nên nó đang ở trạng thái PendingDeletion; chỉ cần huỷ lệnh xoá là khôi phục được khoá.

Vì sao đúng

KMS có một cơ chế bảo vệ được thiết kế đúng cho tình huống này: không có cách nào xoá một CMK ngay lập tức.

⚠ Điểm mấu chốt — mọi lệnh xoá CMK đều có thời gian chờ bắt buộc:

Gọi ScheduleKeyDeletion
        ↓
    Khoá chuyển sang trạng thái PendingDeletion
        ↓
    Thời gian chờ: 7 tới 30 ngày (mặc định 30)
        ↓
    Trong thời gian này:
        - khoá KHÔNG dùng được (không mã hoá, không giải mã)
        - nhưng khoá VẪN TỒN TẠI
        - CancelKeyDeletion khôi phục được hoàn toàn
        ↓
    Đề nói mới một ngày → CHẮC CHẮN còn khôi phục được

⚠ Cách khôi phục — hai lệnh:

# 1. Huỷ lệnh xoá — khoá trở về trạng thái Disabled
aws kms cancel-key-deletion --key-id <key-id>

# 2. Bật lại khoá — bước này rất hay bị quên
aws kms enable-key --key-id <key-id>

Bước thứ hai quan trọng: sau khi huỷ xoá, khoá quay về trạng thái Disabled, chứ không tự bật lại. Chưa enable-key thì dữ liệu vẫn chưa đọc được.

⚠ Vì sao AWS thiết kế thời gian chờ này:

Xoá một CMK = MẤT VĨNH VIỄN mọi dữ liệu đã mã hoá bằng nó
        ↓
    Không có bản sao lưu nào cứu được
    AWS cũng KHÔNG giữ bản sao khoá của khách hàng
        ↓
    → hậu quả không thể đảo ngược
        ↓
    → nên AWS bắt buộc một cửa sổ 7–30 ngày để kịp nhận ra sai lầm

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

• C (thông báo cho người dùng về việc mất dữ liệu) — đây là phương án gần nhất về mặt hậu quả, và sẽ đúng nếu thời gian chờ đã trôi qua. Nhưng mới một ngày, khoá vẫn còn nguyên — không có dữ liệu nào bị mất cả.

• A (liên hệ AWS Support để lấy CMK từ bản sao lưu của họ) — AWS KHÔNG giữ bản sao khoá của khách hàng. Đó chính là điều làm nên giá trị của KMS trong các tiêu chuẩn tuân thủ: phần khoá bí mật không bao giờ rời khỏi HSM và không ai ở AWS truy cập được.

• D (tài khoản root khôi phục được CMK) — root không có đặc quyền nào trong chuyện này. Sau khi thời gian chờ trôi qua, khoá mất vĩnh viễn với mọi principal.

Ghi nhớ

⚠ Các trạng thái của một KMS key — bảng phải thuộc: | Trạng thái | Dùng được | Ghi chú | |---|---|---| | Enabled | có | bình thường | | Disabled | không | bật lại được bất cứ lúc nào | | PendingDeletion | không | huỷ xoá được trong 7–30 ngày | | PendingImport | không | chờ nhập key material | | Unavailable | không | với custom key store |

Từ khoá nhận diện:

"lỡ xoá CMK, chưa quá 30 ngày" → cancel-key-deletion + enable-key "AWS giữ bản sao khoá" → LUÔN SAI "root khôi phục được khoá" → LUÔN SAI "tạm ngưng dùng khoá" → disable-key (an toàn hơn nhiều so với xoá) "khoá phải trong HSM riêng" → CloudHSM key store hoặc External Key Store

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khoá đang ở trạng thái nào | describe-key, xem KeyState | | Còn bao lâu nữa thì mất | describe-key, xem DeletionDate | | Ai đã lên lịch xoá | CloudTrail sự kiện ScheduleKeyDeletion |

Và một biện pháp phòng ngừa đáng thiết lập ngay: hãy tạo một CloudWatch alarm hoặc quy tắc EventBridge cho sự kiện CloudTrail ScheduleKeyDeletion. Lệnh xoá một CMK là một trong số rất ít thao tác trên AWS mà hậu quả là mất dữ liệu vĩnh viễn không cứu được — và cửa sổ 7 tới 30 ngày chỉ cứu được bạn nếu có ai đó thật sự nhận ra chuyện đã xảy ra trong khoảng thời gian ấy.