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

Đáp án

C — Scheduled event do AWS quản lý; bạn không thể tự cấu hình scheduled event cho instance của mình.

Vì sao đúng

Câu hỏi khai thác một nhầm lẫn về thuật ngữ: "scheduled event" của EC2 không phải là việc bạn lên lịch, mà là việc AWS thông báo cho bạn.

⚠ Điểm mấu chốt: scheduled event là AWS báo cho bạn biết trước về việc họ sắp làm với hạ tầng:

Phần cứng bên dưới instance của bạn cần bảo trì
        ↓
    AWS tạo một scheduled event và thông báo trước
        ↓
    Bạn thấy nó trong console EC2, trong Health Dashboard, qua email
        ↓
    → bạn quyết định: để AWS làm theo lịch, hay tự stop/start sớm hơn
        ↓
    → nhưng bạn KHÔNG tạo ra sự kiện này

Bốn loại scheduled event thường gặp:

⚠ Bạn thường chủ động xử lý được trước hạn:

Nhận thông báo instance retirement
        ↓
    Tự stop rồi start instance vào thời điểm bạn chọn
        ↓
    → máy chuyển sang phần cứng mới, sự kiện được huỷ
        ↓
    → chủ động tốt hơn để AWS làm vào lúc bạn không kiểm soát

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

• A (dùng Amazon EventBridge để cấu hình scheduled event cho EC2) — đây là phương án gần nhất và EventBridge thật sự chạy được việc theo lịch: bạn dùng nó để tự động stop/start instance, chạy Systems Manager document, gọi Lambda. Nhưng đó là sự kiện của bạn, không phải "scheduled event" mà EC2 dùng để chỉ thông báo bảo trì của AWS. Câu hỏi hỏi về khái niệm thứ hai.

• B (dùng CloudWatch Agent) — agent thu thập chỉ số và log, nó không lên lịch gì cả.

• D (dùng CloudWatch Alarm) — alarm phản ứng theo ngưỡng của chỉ số, không phải theo lịch.

Ghi nhớ

⚠ Phân biệt hai khái niệm hay bị lẫn — bảng phải thuộc: | Khái niệm | Ai tạo | Việc | |---|---|---| | EC2 scheduled event | AWS | thông báo bảo trì hạ tầng | | EventBridge scheduled rule | bạn | chạy hành động theo lịch cron |

Từ khoá nhận diện:

"scheduled events for instances" → AWS quản lý, không tự cấu hình được "chạy việc gì đó theo lịch" → EventBridge scheduled rule CloudWatch agent → thu thập dữ liệu, không lên lịch CloudWatch alarm → phản ứng theo ngưỡng, không theo lịch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có sự kiện nào đang chờ không | describe-instance-status --include-all-instances | | Máy nào dùng instance store | những máy này cần xử lý khác khi retirement | | Có ai nhận được thông báo không | kiểm địa chỉ liên hệ trong Account settings |

Và một lời khuyên: hãy bắt sự kiện AWS Health bằng EventBridge và đẩy vào kênh mà đội vận hành thật sự đọc. Thông báo scheduled event mặc định đi tới địa chỉ email liên hệ của tài khoản — thường là một hòm thư mà không ai mở, hoặc thuộc về người đã rời công ty. AWS báo trước cho bạn hàng tuần để bạn kịp chủ động, nhưng cảnh báo đó chỉ có giá trị nếu nó tới được người có thể hành động. Một rule EventBridge đẩy sang Slack biến một email bị bỏ qua thành một việc cụ thể trong lịch làm việc.

Đáp án

D — Với Lambda function được cấu hình làm target của EventBridge, bạn phải cung cấp resource-based policy; IAM role sẽ không có tác dụng.

Vì sao đúng

EventBridge dùng hai cơ chế cấp phép khác nhau tuỳ theo loại target, và Lambda thuộc nhóm thứ hai.

⚠ Điểm mấu chốt: một số dịch vụ tự quyết định ai được gọi mình, thay vì để người gọi mang quyền tới:

EventBridge gọi Kinesis
        ↓
    Nó assume IAM role của rule → role đó có quyền ghi vào Kinesis
        ↓
EventBridge gọi Lambda
        ↓
    Lambda kiểm resource-based policy của CHÍNH NÓ:
    "events.amazonaws.com có được phép invoke tôi không?"
        ↓
    → IAM role của rule không tham gia vào quyết định này

aws lambda add-permission --function-name xu-ly-su-kien \
  --statement-id cho-eventbridge --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn arn:aws:events:ap-southeast-1:111122223333:rule/luat-cua-toi

Khi bạn thêm target qua console, AWS tự thêm quyền này — nên lỗi thường xuất hiện khi cấu hình bằng CLI, SDK hoặc IaC.

⚠ Luôn đặt --source-arn để tránh confused deputy:

Không có source-arn
        ↓
    Bất kỳ rule EventBridge nào trong bất kỳ tài khoản nào cũng gọi được hàm
        ↓
    → giới hạn đúng ARN của rule là thực hành bắt buộc

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

• B (IAM role cấu hình sai, xoá rồi tạo lại với quyền cần thiết và gắn lại vào rule) — đây là phương án gần nhất và nó là phản xạ hợp lý với một lỗi quyền. Nhưng với target là Lambda, IAM role không được dùng tới bất kể nó có quyền gì — dựng lại role bao nhiêu lần cũng không sửa được lỗi. Đây chính là điều đề đã quan sát: "role không được dùng khi gọi Lambda".

• A (không nên dùng AWS CLI để thêm quyền cho EventBridge target) — ngược lại: CLI chính là cách đúng để thêm resource-based policy khi bạn không dùng console.

• C (với Lambda, EventBridge dựa trên ACL để định nghĩa quyền) — không có ACL trong ngữ cảnh này; cơ chế đúng tên là resource-based policy.

Ghi nhớ

⚠ Hai cơ chế cấp phép cho EventBridge target — bảng phải thuộc: | Cơ chế | Target | |---|---| | IAM role của rule | Kinesis, SQS, Step Functions, ECS task, Systems Manager | | Resource-based policy | Lambda, SNS, S3, CloudWatch Logs, API Gateway |

Từ khoá nhận diện:

Lambda làm target của EventBridge → resource-based policy, không phải IAM role "IAM role không được dùng" → đúng, đó là hành vi mong đợi với Lambda "ACL cho quyền EventBridge" → LUÔN SAI, không tồn tại cấu hình qua console → quyền được thêm tự động cấu hình qua CLI hoặc IaC → phải tự thêm add-permission

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hàm có quyền chưa | aws lambda get-policy --function-name <ten> | | Rule có khớp không | dùng chức năng test event pattern trong console | | Có lời gọi thất bại không | chỉ số FailedInvocations |

Và một lời khuyên: hãy gắn dead-letter queue cho mọi EventBridge rule quan trọng. Khi rule khớp một sự kiện nhưng không gọi được target — vì thiếu quyền, vì hàm bị throttle, vì target đã bị xoá — sự kiện đó biến mất vĩnh viễn, và chỉ số FailedInvocations tăng lên một con số mà không ai đang nhìn. Với DLQ, sự kiện được giữ lại để bạn xử lý sau khi sửa nguyên nhân, thay vì phải đi tìm xem mình đã mất những gì.

Đáp án

A — Invalidate tệp khỏi CloudFront distribution để nó bị gỡ ngay lập tức.

Vì sao đúng

Đề đòi gỡ một tệp khỏi CloudFront càng nhanh càng tốt. Invalidation là cơ chế dựng riêng cho việc đó.

⚠ Điểm mấu chốt: invalidation là cách duy nhất gỡ nội dung khỏi cache TRƯỚC khi TTL hết hạn:

Không có invalidation
        ↓
    Phải chờ TTL hết hạn ở từng điểm biên
        ↓
    Với TTL mặc định 24 giờ → nội dung lỗi tồn tại cả ngày
        ↓
Invalidation
        ↓
    CloudFront đánh dấu bản cache là không hợp lệ ở mọi điểm biên
        ↓
    → request tiếp theo phải lấy lại từ origin

aws cloudfront create-invalidation --distribution-id E1ABCDEF \
  --paths "/trang-loi.html"

⚠ Invalidation miễn phí có hạn mức — vượt là tính tiền:

1.000 đường dẫn đầu tiên mỗi tháng: miễn phí
        ↓
    Sau đó tính phí theo từng đường dẫn
        ↓
    Dùng ký tự đại diện /* tính là MỘT đường dẫn
        ↓
    → nhưng nếu phải invalidate thường xuyên, hãy đổi cách: dùng versioned URL

Cách bền hơn cho nội dung hay thay đổi là đưa phiên bản vào tên tệp (app-v2.js), khi đó không bao giờ cần invalidate.

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

• C (theo mặc định CloudFront cache 24 giờ nên không thể gỡ tệp trước thời gian đó) — đây là phương án gần nhất và nó nêu đúng TTL mặc định. Nhưng kết luận sai: invalidation tồn tại chính để phá vỡ giới hạn đó. Đây là bẫy dựa trên một nửa sự thật.

• B (chỉ định default root object để chỉ hiện object đó thay vì trang lỗi) — default root object là tệp trả về khi người dùng gọi tới URL gốc của distribution. Nó không gỡ được một tệp cụ thể khỏi cache.

• D (dùng CloudFront policy để kiểm soát người dùng thấy gì) — cache policy và origin request policy điều khiển cách cache và cách gọi origin, không xoá nội dung đã cache.

Ghi nhớ

⚠ Bốn cách kiểm soát nội dung cache của CloudFront — bảng phải thuộc: | Cách | Khi nào | |---|---| | Invalidation | gỡ ngay nội dung đã cache — dùng khi khẩn cấp | | Versioned URL | đổi tên tệp mỗi lần cập nhật — cách bền nhất | | TTL ngắn | nội dung đổi thường xuyên | | Cache-Control từ origin | điều khiển ở mức từng object |

Từ khoá nhận diện:

"gỡ tệp khỏi CloudFront ngay" → invalidation "không thể gỡ trước 24 giờ" → SAI, invalidation làm được "default root object" → tệp trả về ở URL gốc, không phải công cụ gỡ cache cần cập nhật nội dung thường xuyên → versioned URL thay vì invalidate liên tục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Invalidation xong chưa | get-invalidation, xem Status | | Điểm biên còn cache không | curl -I xem header X-Cache | | Đã dùng bao nhiêu invalidation | theo dõi số lượng trong tháng |

Và một lời khuyên: hãy chuyển sang versioned URL nếu bạn thấy mình invalidate nhiều hơn vài lần mỗi tháng. Invalidation là công cụ chữa cháy: nó đúng cho tình huống của đề — một trang lỗi cần gỡ gấp — nhưng nếu nó trở thành một bước trong quy trình triển khai hằng ngày, bạn đang trả tiền cho nó và vẫn phải chờ vài phút mỗi lần. Với tên tệp có phiên bản, việc triển khai chỉ là tải lên tệp mới và cập nhật tham chiếu, và cache cũ tự nhiên trở nên vô hại vì không ai còn gọi tới nó.

Đáp án

B — Các subnet trong cùng một VPC đã liên lạc được với nhau mà không cần cấu hình gì thêm.

Vì sao đúng

Đây là kiến thức nền của VPC: mọi subnet trong một VPC đều định tuyến được tới nhau theo mặc định.

⚠ Điểm mấu chốt: local route là mục mặc định trong mọi route table và không thể gỡ bỏ:

VPC 10.0.0.0/16
        ↓
    Mọi route table đều có mục: 10.0.0.0/16 → local
        ↓
    → subnet public và subnet private định tuyến tới nhau bình thường
        ↓
    → "public" và "private" chỉ khác nhau ở chỗ có route ra internet gateway hay không

Thứ duy nhất còn phải kiểm là security group của RDS:

aws ec2 authorize-security-group-ingress --group-id sg-rds \
  --protocol tcp --port 3306 --source-group sg-app

⚠ Định tuyến thông không có nghĩa là kết nối được — security group vẫn phải cho phép:

Local route đảm bảo gói tin ĐI TỚI được
        ↓
    Security group của RDS quyết định có NHẬN không
        ↓
    → thiếu rule inbound là timeout, dù mạng hoàn toàn thông

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

• C (tạo security group cho phép kết nối từ subnet khác trong VPC) — đây là phương án gần nhất và security group thật sự cần được cấu hình đúng để RDS nhận kết nối. Nhưng câu hỏi hỏi về cách cho hai subnet liên lạc, và ở tầng đó thì không cần làm gì cả. Security group là lớp kiểm soát truy cập, không phải cơ chế kết nối — và cách viết đúng là tham chiếu security group của ứng dụng, không phải dải CIDR của subnet.

• A (cấu hình VPC peering để hai subnet liên lạc) — peering nối hai VPC KHÁC NHAU. Trong cùng một VPC, nó không áp dụng và cũng không tạo được.

• D (dùng Elastic IP để khởi tạo liên lạc giữa subnet private và public) — Elastic IP là địa chỉ công cộng, dùng để tài nguyên với ra Internet hoặc để Internet với vào. Nó hoàn toàn không liên quan tới việc định tuyến nội bộ trong VPC.

Ghi nhớ

⚠ Bốn điều nền tảng về VPC — bảng phải thuộc: | Điều | Nội dung | |---|---| | Local route | mọi subnet trong VPC tới được nhau, không xoá được | | Public subnet | có route 0.0.0.0/0 tới internet gateway | | Private subnet | không có route đó | | Subnet | nằm trong một AZ duy nhất |

Từ khoá nhận diện:

"subnet trong cùng VPC liên lạc" → mặc định đã được, không cần cấu hình "VPC peering trong cùng một VPC" → LUÔN SAI, peering nối hai VPC "Elastic IP để liên lạc nội bộ" → SAI, EIP là địa chỉ công cộng không kết nối được dù cùng VPC → kiểm security group và NACL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gói tin có tới không | VPC Flow Logs | | Đường đi có thông không | VPC Reachability Analyzer | | Security group cho ai vào | describe-security-groups |

Và một lời khuyên: hãy dùng VPC Reachability Analyzer khi hai tài nguyên trong cùng VPC không kết nối được. Nó phân tích toàn bộ đường đi — route table, security group, NACL, ENI — và chỉ thẳng ra thành phần nào đang chặn, thay vì để bạn kiểm từng lớp một. Với một VPC đơn giản thì việc kiểm tay không tốn nhiều thời gian, nhưng trong một mạng có nhiều subnet, nhiều security group tham chiếu lẫn nhau và vài NACL do người khác viết, nó biến một buổi chiều dò tìm thành một câu trả lời trong hai phút.

Đáp án

A — Dùng Amazon CloudWatch Events để lên lịch chụp EBS snapshot tự động.

Vì sao đúng

Đề cần chụp snapshot theo lịch, vài phút một lần, không cần viết mã. CloudWatch Events (nay là EventBridge) làm được trực tiếp.

⚠ Điểm mấu chốt: EventBridge gọi trực tiếp API của EC2 — không cần Lambda trung gian:

Scheduled rule kích hoạt
        ↓
    Target là "EC2 CreateSnapshot API call"
        ↓
    → EventBridge tự gọi API, không có hàm nào phải viết và bảo trì

aws events put-rule --name chup-snapshot --schedule-expression "rate(15 minutes)"

⚠ Ngày nay Data Lifecycle Manager là công cụ chuyên dụng và tốt hơn cho việc này:

Amazon Data Lifecycle Manager (DLM)
        ↓
    Chụp theo lịch, nhắm theo tag, tự giữ số bản theo chính sách
    Tự XOÁ snapshot cũ — thứ mà scheduled rule không làm
    Sao chép sang Region khác nếu cần
        ↓
    → MIỄN PHÍ, chỉ trả tiền lưu trữ snapshot

Với bộ đề này, CloudWatch Events là khoá đáp án; nhưng trong thực tế hôm nay, DLM là lựa chọn nên dùng.

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

• D (dùng AWS Lambda để khởi tạo snapshot tự động vài phút một lần) — đây là phương án gần nhất và nó hoàn toàn chạy được: rất nhiều hệ thống làm đúng như vậy. Nhưng nó thiếu phần kích hoạt theo lịch — bản thân Lambda không tự chạy, nó vẫn cần EventBridge gọi. Và viết một hàm để làm việc mà EventBridge gọi API trực tiếp được là thêm mã phải bảo trì mà không nhận lại gì.

• B (dùng SNS để kích hoạt Lambda chụp snapshot) — SNS không phải bộ lập lịch; nó phát tán thông báo khi có ai đó publish. Vẫn cần một thứ khác kích hoạt theo lịch.

• C (snapshot tự động là mục cấu hình được từ màn hình EC2 trong console) — không có tuỳ chọn nào như vậy trong console EC2. Lịch chụp snapshot được cấu hình qua DLM, EventBridge, hoặc AWS Backup.

Ghi nhớ

⚠ Bốn cách tự động chụp EBS snapshot — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Data Lifecycle Manager | chuyên dụng, miễn phí, tự xoá bản cũ, sao chép Region | | AWS Backup | tập trung nhiều loại tài nguyên, có vault và chính sách | | EventBridge scheduled rule | gọi API trực tiếp, không tự dọn bản cũ | | EventBridge + Lambda | linh hoạt nhất, phải viết mã |

Từ khoá nhận diện:

"chụp snapshot theo lịch" → DLM hoặc EventBridge "Lambda tự chạy theo lịch" → vẫn cần EventBridge kích hoạt "SNS để lên lịch" → SAI, SNS là phát tán thông báo "cấu hình snapshot tự động trong console EC2" → không tồn tại cần tự xoá bản cũ → DLM hoặc AWS Backup

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Snapshot có được tạo đúng lịch không | lịch sử của DLM policy hoặc EventBridge | | Snapshot cũ có được dọn không | đếm số snapshot theo thời gian | | Chi phí lưu trữ | Cost Explorer, lọc theo EBS:SnapshotUsage |

Và một lời khuyên: hãy luôn đặt chính sách giữ lại (retention) cùng lúc với việc lên lịch chụp. Đây là chỗ chi phí tăng âm thầm nhất: snapshot là gia tăng nên mỗi bản chỉ tốn phần dữ liệu đã đổi, và với chu kỳ vài phút thì mỗi bản rất nhỏ — không có gì đáng báo động ở tuần đầu. Nhưng chúng tích luỹ liên tục và không bao giờ tự biến mất, nên sau vài tháng bạn có hàng chục nghìn snapshot và một dòng chi phí lưu trữ mà không ai giải thích được. EventBridge scheduled rule không dọn giúp bạn; DLM và AWS Backup thì có.

Đáp án

B — Cài CloudWatch Agent trên mọi instance và gắn IAM ROLE cho EC2 để agent chạy được.

Vì sao đúng

Câu hỏi kiểm tra hai điều: agent có tự cài không, và cấp quyền cho EC2 bằng cách nào.

⚠ Điểm mấu chốt: EC2 nhận quyền qua IAM ROLE, không bao giờ qua IAM USER:

IAM role gắn vào instance profile
        ↓
    EC2 lấy thông tin đăng nhập TẠM THỜI từ metadata service
        ↓
    Tự động xoay vòng, không có bí mật nào nằm trên máy
        ↓
IAM user (phương án D)
        ↓
    Nghĩa là access key dài hạn phải nằm đâu đó trên máy
        ↓
    → không gắn được vào instance, và là thực hành bảo mật tệ

aws iam attach-role-policy --role-name EC2CloudWatchRole \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

aws ec2 associate-iam-instance-profile --instance-id i-0abc \
  --iam-instance-profile Name=EC2CloudWatchProfile

⚠ Security group không liên quan tới việc agent gửi được dữ liệu hay không:

Security group kiểm soát lưu lượng VÀO instance
        ↓
    Agent gửi dữ liệu ĐI RA — mặc định outbound đã mở
        ↓
    → thứ agent cần là QUYỀN (IAM), không phải rule mạng
        ↓
    → trừ khi instance ở private subnet không có đường ra: khi đó cần
      NAT gateway hoặc VPC endpoint cho CloudWatch

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

• C (cài agent và gắn security group cần thiết để agent chạy được) — đây là phương án gần nhất và nó đúng ở vế cài agent. Nhưng security group không cấp quyền: nó lọc lưu lượng mạng, còn thứ agent thiếu khi không gửi được dữ liệu là quyền gọi API CloudWatch. Đây là bẫy trộn lẫn tầng mạng với tầng danh tính.

• D (cài agent và gắn IAM USER cho EC2) — không gắn IAM user vào EC2 được. Cơ chế duy nhất là instance profile chứa một role.

• A (cấu hình CloudWatch từ console, AWS tự cài và cấu hình agent) — AWS không tự cài agent. Chỉ số cơ bản (CPU, mạng, status check) có sẵn không cần agent, nhưng mọi chỉ số bên trong hệ điều hành đều đòi cài đặt.

Ghi nhớ

⚠ Chỉ số có sẵn so với cần agent — bảng phải thuộc: | Có sẵn | Cần agent | |---|---| | CPUUtilization | bộ nhớ | | NetworkIn, NetworkOut | dung lượng đĩa còn trống | | StatusCheckFailed | swap, số tiến trình | | DiskReadOps (instance store) | log ứng dụng |

Từ khoá nhận diện:

cấp quyền cho EC2 → IAM role qua instance profile "gắn IAM user cho EC2" → LUÔN SAI "security group để agent chạy" → SAI, đó là tầng mạng "AWS tự cài agent" → SAI, phải tự cài cần chỉ số bộ nhớ hoặc đĩa → bắt buộc có agent

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có chạy không | amazon-cloudwatch-agent-ctl -a status | | Instance có role không | describe-instances, xem IamInstanceProfile | | Dữ liệu có tới không | tìm namespace CWAgent trong CloudWatch |

Và một lời khuyên: hãy lưu cấu hình agent trong SSM Parameter Store thay vì ghi tệp trên từng máy. Agent đọc được cấu hình trực tiếp từ Parameter Store, nghĩa là bạn sửa một chỗ và áp cho cả đội máy bằng một lệnh Systems Manager — thay vì phải sửa tệp trên từng instance rồi khởi động lại agent. Với một đội vài chục máy thì khác biệt là một buổi chiều; với vài trăm máy thì đó là khác biệt giữa việc làm được và không.

Đáp án

B — Bật S3 versioning trên mọi bucket dùng trong dự án.

Vì sao đúng

Đề đòi khôi phục được object khi bị xoá nhầm. Versioning là cơ chế duy nhất trong bốn phương án làm được điều đó.

⚠ Điểm mấu chốt: với versioning, thao tác xoá KHÔNG xoá dữ liệu — nó chỉ đặt một delete marker:

Người dùng gọi DeleteObject
        ↓
    S3 tạo một "delete marker" làm phiên bản mới nhất
        ↓
    Các phiên bản cũ VẪN CÒN nguyên
        ↓
    → khôi phục = xoá delete marker đi
        ↓
    → object trở lại ngay lập tức

aws s3api put-bucket-versioning --bucket du-lieu-du-an \
  --versioning-configuration Status=Enabled

# khôi phục: xoá delete marker
aws s3api delete-object --bucket du-lieu-du-an \
  --key bao-cao.pdf --version-id <id-cua-delete-marker>

⚠ Versioning làm tăng chi phí lưu trữ — luôn đi kèm lifecycle rule:

Mỗi lần ghi đè tạo một phiên bản mới
        ↓
    Mọi phiên bản đều tính tiền lưu trữ
        ↓
    → đặt NoncurrentVersionExpiration để dọn bản cũ sau N ngày
    → và ExpiredObjectDeleteMarker để dọn delete marker mồ côi

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

• A (bật S3 Object Lock để khoá mọi object trong dự án) — đây là phương án gần nhất và Object Lock thật sự bảo vệ dữ liệu khỏi bị xoá. Nhưng nó là công cụ quá cứng cho tình huống này: Object Lock áp mô hình WORM cho tuân thủ pháp lý — trong chế độ compliance thì không ai xoá được, kể cả root, kể cả khi cố ý cho tới hết thời hạn giữ. Với một bucket làm việc chung mà nhiều đội cần cập nhật và dọn dẹp bình thường, đó là ràng buộc gây tê liệt. Ngoài ra Object Lock đòi versioning phải bật trước — nên versioning vẫn là nền tảng.

• C (dùng S3 bucket owner condition để giới hạn truy cập cho người dùng ngoài ý muốn) — đó là cơ chế kiểm soát truy cập, ngăn người không có quyền. Nhưng đề mô tả một lập trình viên có quyền hợp lệ xoá nhầm — kiểm soát truy cập không giải quyết được lỗi thao tác của người có quyền.

• D (dùng S3 replication để nhân bản object quan trọng nhằm tránh mất do xoá nhầm) — replication mặc định KHÔNG nhân bản thao tác xoá theo cách bảo vệ bạn, và nếu bật DeleteMarkerReplication thì delete marker cũng được sao chép sang bucket đích. Nó bảo vệ trước sự cố Region, không bảo vệ trước lỗi con người.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ dữ liệu S3 — bảng phải thuộc: | Cơ chế | Chống gì | |---|---| | Versioning | xoá nhầm, ghi đè nhầm | | MFA Delete | xoá vĩnh viễn phiên bản — đòi mã MFA | | Object Lock | xoá và ghi đè trong thời hạn giữ — cho tuân thủ | | Replication | mất Region, mất bucket |

Từ khoá nhận diện:

"khôi phục object bị xoá nhầm" → versioning "tuân thủ WORM, không ai được xoá" → Object Lock "chống người không có quyền" → bucket policy, IAM "replication để chống xoá nhầm" → SAI, delete marker cũng được sao chép Object Lock → đòi versioning bật trước

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Versioning đã bật chưa | get-bucket-versioning | | Có phiên bản cũ nào không | list-object-versions | | Chi phí có phình không | S3 Storage Lens, xem dung lượng theo phiên bản |

Và một lời khuyên: hãy bật versioning cùng lúc với lifecycle rule dọn phiên bản cũ, đừng bật riêng versioning rồi tính sau. Versioning không có nút "giới hạn số phiên bản": mỗi lần ghi đè tạo thêm một bản và tất cả đều tính tiền, mãi mãi. Với một bucket mà nhiều đội cùng cập nhật tệp hằng ngày, dung lượng thực tế có thể lớn gấp nhiều lần con số bạn nhìn thấy khi liệt kê object — vì danh sách mặc định chỉ hiện phiên bản hiện hành. Khoản chênh lệch đó chỉ lộ ra trên hoá đơn, thường là vài tháng sau.

Đáp án

B — Dùng blue/green deployment của Elastic Beanstalk để tách RDS instance khỏi môi trường A; tạo môi trường mới (B) với thông tin kết nối tới RDS đã tách.

Vì sao đúng

Đề đòi tách cơ sở dữ liệu khỏi môi trường Beanstalk mà không có downtime và không lệch dữ liệu.

⚠ Điểm mấu chốt: RDS gắn trong môi trường Beanstalk sẽ BỊ XOÁ khi môi trường bị chấm dứt:

RDS tạo bên trong môi trường Beanstalk
        ↓
    Nó là một tài nguyên của môi trường đó
        ↓
    Chấm dứt môi trường → cơ sở dữ liệu bị xoá theo
        ↓
    → đây là lý do người ta muốn tách nó ra

Quy trình blue/green để tách:

1. Ở môi trường A: đổi retention policy của RDS thành "Retain"
2. Dựng môi trường B, KHÔNG gắn RDS, khai endpoint của RDS qua biến môi trường
3. Kiểm thử môi trường B
4. Swap URL giữa A và B
5. Chấm dứt môi trường A — RDS được giữ lại nhờ bước 1

⚠ Bước đầu tiên là quan trọng nhất và dễ quên nhất:

Quên đổi retention policy thành Retain
        ↓
    Chấm dứt môi trường A
        ↓
    → cơ sở dữ liệu bị xoá cùng với nó
        ↓
    → và đó là môi trường đang thử nghiệm một sản phẩm quan trọng

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

• C (chụp snapshot rồi chấm dứt môi trường hiện tại, tạo môi trường mới từ snapshot mà không gắn RDS) — đây là phương án gần nhất và nó đạt được kết quả cuối cùng đúng. Nhưng nó vi phạm hai yêu cầu: chấm dứt môi trường gây downtime, và khôi phục từ snapshot nghĩa là mất dữ liệu phát sinh sau thời điểm chụp — đúng thứ "database sync issues" mà đề nói phải tránh. Đề nhấn mạnh đây là sản phẩm quan trọng đang thử nghiệm.

• A (không hỗ trợ tách RDS khỏi môi trường đang chạy, phải chấm dứt sau khi chụp snapshot) — sai về sự thật: blue/green chính là cách được AWS ghi nhận để làm việc này.

• D (dùng Immutable deployment để làm kiến trúc đáng tin cậy, chấm dứt môi trường đầu khi tự tin) — immutable deployment là một chính sách triển khai mã trong cùng một môi trường: nó dựng một nhóm instance mới rồi chuyển sang. Nó không tách được tài nguyên RDS ra khỏi môi trường.

Ghi nhớ

⚠ Hai cách gắn cơ sở dữ liệu với Beanstalk — bảng phải thuộc: | Cách | Vòng đời | |---|---| | RDS trong môi trường | bị xoá khi môi trường bị chấm dứt — chỉ hợp cho dev/test | | RDS bên ngoài, kết nối qua biến môi trường | độc lập — khuyến nghị cho production |

Từ khoá nhận diện:

"tách RDS khỏi môi trường Beanstalk" → blue/green "không downtime, không lệch dữ liệu" → giữ nguyên cơ sở dữ liệu, đổi môi trường "chụp snapshot rồi dựng lại" → có downtime và mất dữ liệu mới "immutable deployment" → chính sách triển khai mã, không tách tài nguyên trước khi chấm dứt môi trường → đổi retention policy thành Retain

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Retention policy của RDS | kiểm cấu hình môi trường trước khi chấm dứt | | Môi trường B có kết nối được không | chạy thử toàn bộ luồng nghiệp vụ | | Swap có thành công không | kiểm CNAME của cả hai môi trường |

Và một lời khuyên: hãy đổi retention policy của RDS thành "Retain" ngay bây giờ, đừng chờ tới lúc chuẩn bị chấm dứt môi trường. Đây là thao tác một dòng và nó biến một sai lầm không thể sửa thành một sai lầm vô hại: nếu ai đó chấm dứt môi trường vì bất kỳ lý do gì — dọn dẹp nhầm, script tự động, một thao tác vội — cơ sở dữ liệu vẫn còn. Với chính sách mặc định, cùng một thao tác đó xoá vĩnh viễn dữ liệu của một sản phẩm đang thử nghiệm, và không có nút hoàn tác nào.

Đáp án

B — Dùng Stack policy để bảo vệ các tài nguyên quan trọng khỏi bị cập nhật ngoài ý muốn.

Vì sao đúng

Đề đòi khoá tài nguyên quan trọng khỏi mọi thao tác cập nhật hoặc xoá trong CloudFormation. Stack policy là cơ chế dựng riêng cho việc đó.

⚠ Điểm mấu chốt: stack policy chặn ngay tại thao tác cập nhật stack — không cần đụng tới IAM:

Ai đó chạy update-stack với template xoá một tài nguyên được bảo vệ
        ↓
    CloudFormation đọc stack policy
        ↓
    Thấy Deny cho tài nguyên đó
        ↓
    → cập nhật bị chặn, tài nguyên còn nguyên

{
  "Statement": [
    {"Effect": "Allow", "Action": "Update:*", "Principal": "*", "Resource": "*"},
    {"Effect": "Deny", "Action": "Update:*", "Principal": "*",
     "Resource": "LogicalResourceId/CoSoDuLieuChinh"}
  ]
}

⚠ Stack policy CHỈ áp cho thao tác update-stack — nó không chặn được delete-stack:

Stack policy bảo vệ tài nguyên trong lúc CẬP NHẬT stack
        ↓
    Nhưng nếu ai đó xoá cả stack
        ↓
    → stack policy không ngăn được
        ↓
    → cần thêm TERMINATION PROTECTION cho stack
    → và DeletionPolicy: Retain cho tài nguyên quan trọng

Ba lớp này bổ sung cho nhau và nên dùng cùng lúc.

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

• C (dùng revision control để bảo vệ tài nguyên khỏi cập nhật ngoài ý muốn) — đây là phương án gần nhất và quản lý phiên bản template là thực hành tốt: nó cho bạn lịch sử, review, và khả năng quay lại. Nhưng nó không chặn được gì: một người có quyền vẫn chạy update-stack với template bất kỳ, và Git không tham gia vào thời điểm đó. Revision control bảo vệ quy trình, stack policy bảo vệ tài nguyên.

• A (dùng nested stack để giữ cấu hình ở stack cha ngay cả khi stack con mất) — nested stack là cách tổ chức template, không phải cơ chế bảo vệ. Xoá một stack con vẫn xoá tài nguyên trong đó.

• D (dùng parameter constraint để chỉ định danh tính nào được cập nhật stack) — parameter constraint giới hạn GIÁ TRỊ mà người dùng nhập vào (kiểu dữ liệu, khoảng cho phép, mẫu chuỗi). Nó không liên quan tới danh tính; kiểm soát ai được làm gì là việc của IAM.

Ghi nhớ

⚠ Bốn lớp bảo vệ tài nguyên CloudFormation — bảng phải thuộc: | Lớp | Chặn gì | |---|---| | Stack policy | cập nhật lên tài nguyên nhất định trong update-stack | | Termination protection | xoá cả stack | | DeletionPolicy: Retain | giữ lại tài nguyên khi stack hoặc tài nguyên bị xoá | | IAM policy | ai được gọi API CloudFormation |

Từ khoá nhận diện:

"khoá tài nguyên khỏi cập nhật" → stack policy "ngăn xoá cả stack" → termination protection "giữ tài nguyên lại khi stack bị xoá" → DeletionPolicy: Retain "revision control" → bảo vệ quy trình, không chặn thao tác "parameter constraint" → giới hạn giá trị nhập, không phải danh tính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Stack policy hiện tại | aws cloudformation get-stack-policy | | Termination protection đã bật chưa | describe-stacks, xem EnableTerminationProtection | | Tài nguyên nào sẽ bị thay thế | đọc Replacement trong change set |

Và một lời khuyên: hãy dùng cả ba lớp cùng lúc: stack policy, termination protection, và DeletionPolicy: Retain. Mỗi cái chặn một đường khác nhau, và một mình không cái nào đủ: stack policy không ngăn được việc xoá cả stack, termination protection không ngăn được một lần cập nhật làm thay thế cơ sở dữ liệu, và DeletionPolicy không ngăn được việc thay đổi cấu hình tài nguyên. Sự cố mà đề mô tả — một thao tác của con người xoá mất dịch vụ quan trọng — có thể đến từ bất kỳ đường nào trong ba đường đó.

Đáp án

C — Dùng CloudFormation StackSets kết hợp AWS Organizations để triển khai và quản lý IAM role trên nhiều tài khoản cùng lúc.

Vì sao đúng

Đề đòi tự động hoá việc tạo IAM role trên nhiều tài khoản, và công ty đã dùng AWS Organizations. StackSets sinh ra đúng cho tình huống đó.

⚠ Điểm mấu chốt: StackSets với Organizations tự áp cho tài khoản MỚI — đó là khác biệt lớn nhất so với template thường:

CloudFormation template thường (phương án A)
        ↓
    Phải chạy thủ công ở TỪNG tài khoản
    Tài khoản mới → ai đó phải nhớ chạy
        ↓
StackSets nhắm theo OU với automatic deployment
        ↓
    Tài khoản mới gia nhập OU → stack tự được triển khai
        ↓
    → không có bước nào phải nhớ

aws cloudformation create-stack-set --stack-set-name iam-roles \
  --template-body file://roles.yaml --permission-model SERVICE_MANAGED \
  --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

aws cloudformation create-stack-instances --stack-set-name iam-roles \
  --deployment-targets OrganizationalUnitIds=ou-abc-123 --regions ap-southeast-1

⚠ IAM là tài nguyên toàn cầu — chỉ triển khai vào MỘT Region cho mỗi tài khoản:

Triển khai stack set chứa IAM role vào nhiều Region
        ↓
    Region đầu tiên tạo role thành công
    Region thứ hai gặp lỗi "role already exists"
        ↓
    → với IAM, chọn đúng một Region làm nơi triển khai

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

• A (tạo CloudFormation template và dùng lại để tạo IAM role ở từng tài khoản) — đây là phương án gần nhất và template là đúng công cụ mô tả tài nguyên. Nhưng nó thiếu phần triển khai tự động: ai đó vẫn phải đăng nhập vào từng tài khoản và chạy stack. Với một công ty đang mở rộng và liên tục tạo tài khoản mới, đó chính là quy trình thủ công gây ra lỗi mà đề đang muốn loại bỏ.

• D (dùng AWS Resource Access Manager tích hợp với Organizations để triển khai và quản lý tài nguyên chia sẻ) — sai công cụ. RAM chia sẻ tài nguyên hiện có (subnet, transit gateway, Resolver rule) để tài khoản khác dùng chung — nó không tạo tài nguyên mới, và không chia sẻ được IAM role.

• B (dùng AWS Directory Service với Organizations để tự gắn IAM role cho người dùng Active Directory) — nhầm bài toán. Directory Service quản lý danh tính người dùng, không tự động hoá việc tạo IAM role trên nhiều tài khoản.

Ghi nhớ

⚠ Hai mô hình quyền của StackSets — bảng phải thuộc: | Mô hình | Đặc điểm | |---|---| | Self-managed | bạn tự tạo role AWSCloudFormationStackSetAdministrationRole và ExecutionRole ở mỗi tài khoản | | Service-managed | dùng Organizations — nhắm theo OU, có automatic deployment |

Từ khoá nhận diện:

"triển khai ra nhiều tài khoản" → StackSets "đã dùng Organizations" → service-managed permission model "tài khoản mới cũng phải có" → automatic deployment "RAM để tạo IAM role" → SAI, RAM chia sẻ tài nguyên có sẵn "Directory Service để tạo role" → SAI, đó là quản lý danh tính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tài khoản nào đã có stack | list-stack-instances | | Có tài khoản nào lỗi không | trạng thái OUTDATED hoặc FAILED của stack instance | | Tài khoản mới có tự nhận không | thêm một tài khoản vào OU và quan sát |

Và một lời khuyên: hãy cân nhắc IAM Identity Center thay vì tự tạo IAM role ở từng tài khoản, nếu mục tiêu là cấp quyền cho con người. StackSets là câu trả lời đúng cho câu hỏi này và cho các role dành cho ứng dụng và dịch vụ. Nhưng nếu những role đang được tạo thủ công là để nhân viên đăng nhập, thì Identity Center giải quyết bài toán ở một tầng cao hơn: bạn định nghĩa permission set một lần và gán cho nhóm người dùng theo từng tài khoản, không có role nào phải triển khai và đồng bộ. Vấn đề "role tạo thiếu quyền" mà đề mô tả thường biến mất hoàn toàn khi chuyển sang mô hình đó.