Ngân hàng đề — AWS Certified Solutions Architect Professional

Đáp án

B — Dùng GitHub webhook để kích hoạt CodePipeline; dùng plugin Jenkins cho AWS CodeBuild để chạy unit test; gửi cảnh báo tới SNS topic khi build hỏng; triển khai blue/green bằng AWS CodeDeploy.

Vì sao đúng

Đề nêu ba yêu cầu, và mỗi mảnh của phương án B lo một cái, đồng thời giữ nguyên công cụ đội đang dùng.

⚠ Điểm mấu chốt: webhook là cơ chế GitHub dùng để báo sự kiện — websocket thì không:

Webhook: GitHub gửi một HTTP POST tới endpoint khi có commit
        ↓
    Đây là cách GitHub tích hợp với mọi hệ CI/CD
        ↓
WebSocket: giao thức kết nối hai chiều liên tục cho ứng dụng thời gian thực
        ↓
    → GitHub KHÔNG dùng websocket để báo sự kiện repository
    → "GitHub websockets" trong phương án A và C là thứ không tồn tại

Đây là điểm loại rõ ràng nhất của câu hỏi, và nó chỉ khác nhau một từ.

Vì sao plugin Jenkins cho CodeBuild. Đội đã có Jenkins và quen với nó. Plugin này cho phép Jenkins giao việc build cho CodeBuild — giữ được quy trình quen thuộc mà không phải tự vận hành đội máy build:

// Jenkinsfile
stage('Build') {
  steps {
    awsCodeBuild projectName: 'ung-dung-web',
                 credentialsType: 'keys',
                 region: 'ap-southeast-1',
                 sourceControlType: 'jenkins'
  }
}

⚠ Blue/green cho EC2 chuyển tải bằng cách đổi target group của ALB — không chờ DNS:

CodeDeploy dựng Auto Scaling group mới với phiên bản mới
        ↓
    Chờ mọi instance qua health check
        ↓
    Đổi listener của ALB sang target group mới
        ↓
    → chuyển tức thì; có sự cố thì chuyển ngược trong vài giây

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

• D (GitHub webhook — đúng, nhưng dùng AWS X-Ray cho unit test và static code analysis, và triển khai in-place all-at-once) — đây là phương án gần nhất và nó chọn đúng webhook. Nhưng nó hỏng ở hai chỗ. X-Ray là công cụ theo dõi phân tán (distributed tracing) — nó ghi lại đường đi của request qua các dịch vụ để tìm nút thắt; nó không chạy unit test và không phân tích mã tĩnh. Và in-place all-at-once là chiến lược triển khai rủi ro nhất: cập nhật mọi instance cùng lúc, có downtime, và lùi lại nghĩa là triển khai lại từ đầu — trái thẳng hai yêu cầu "no downtime" và "easily rolled back".

• C (GitHub websockets, plugin Jenkins cho CodeBuild — đúng, nhưng in-place all-at-once) — chọn đúng công cụ test nhưng sai cả cơ chế kích hoạt lẫn chiến lược triển khai.

• A (GitHub websockets, X-Ray cho unit test, blue/green) — chọn đúng chiến lược triển khai nhưng sai cả hai thứ còn lại.

Bốn phương án này là một ma trận 2×2 của hai quyết định (webhook/websocket và blue-green/in-place), cộng thêm biến thể công cụ test — chỉ một ô đúng cả ba.

Ghi nhớ

⚠ Bốn công cụ hay bị gán nhầm vai — bảng phải thuộc: | Công cụ | Việc thật | |---|---| | X-Ray | theo dõi request qua các dịch vụ, tìm nút thắt | | CodeBuild | biên dịch, chạy test, phân tích mã | | CodeDeploy | triển khai artifact đã dựng | | CodePipeline | điều phối các giai đoạn |

Từ khoá nhận diện:

"GitHub triggers the pipeline" → webhook "GitHub websockets" → LUÔN SAI, không tồn tại "X-Ray for unit testing" → LUÔN SAI, X-Ray là tracing "no downtime" + "easily rolled back" → blue/green "in-place, all-at-once" khi đề đòi không downtime → SAI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Webhook có tới không | lịch sử delivery trong cài đặt repository GitHub | | Cảnh báo có gửi không | cố ý làm hỏng một build và chờ | | Lùi lại có nhanh không | diễn tập chuyển ngược trong môi trường thử |

Và một lời khuyên: hãy mở trang lịch sử delivery của webhook trên GitHub khi pipeline không chạy, trước khi đi tìm lỗi ở phía AWS. Đây là chỗ tích hợp hay đứt mà không để lại dấu vết ở phía bạn: GitHub gửi POST, nhận về một mã lỗi, ghi lại trong lịch sử của chính nó, rồi thôi — không có gì xuất hiện trong CloudWatch, không có sự kiện nào trong CodePipeline, vì pipeline chưa từng được gọi. Từ phía AWS, mọi thứ trông hoàn toàn bình thường: không lỗi, không cảnh báo, chỉ là không có lần chạy nào. Trang lịch sử webhook cho bạn cả request lẫn response, và thường trả lời câu hỏi trong một phút.

Đáp án

A, D — hai bước di chuyển 150 máy ảo và 50 TB dữ liệu trong 90 ngày với gián đoạn tối thiểu:

• A — Di chuyển máy ảo bằng AWS Application Migration Service (MGN).
• D — Chuyển dữ liệu NAS lên AWS bằng AWS Storage Gateway.

Vì sao đúng

Bốn dữ kiện của đề quyết định lời giải: cấu hình VM tuỳ biến sâu, 50 TB truy cập không thường xuyên nhưng phải tức thì khi cần, đường 1 Gbps rảnh phần lớn thời gian, 90 ngày.

⚠ Điểm mấu chốt: 1 Gbps rảnh ban đêm là ĐỦ cho 50 TB trong 90 ngày — nên Snowball là thừa:

1 Gbps ở hiệu suất thực tế ~70%
        ↓
    Khoảng 7,5 TB mỗi ngày nếu chạy 24 giờ
    Khoảng 2,5 TB mỗi đêm nếu chỉ chạy ngoài giờ làm việc
        ↓
    50 TB / 2,5 TB ≈ 20 đêm
        ↓
    → thừa sức trong 90 ngày, không cần chờ vận chuyển thiết bị

Vì sao Storage Gateway chứ không phải chỉ chuyển dữ liệu một lần. Đề nói dữ liệu được truy cập không thường xuyên nhưng phải tức thì. File gateway giữ một bản đệm cục bộ và lưu dữ liệu trong S3, nên ứng dụng vẫn truy cập qua giao thức tệp quen thuộc trong suốt và sau quá trình chuyển — không có thời điểm nào dữ liệu không với tới được.

# tạo file gateway, dữ liệu nằm trong S3, truy cập qua NFS/SMB
aws storagegateway create-nfs-file-share \
  --gateway-arn <gw> --location-arn arn:aws:s3:::du-lieu-nas \
  --role <role> --default-storage-class S3_STANDARD_IA

⚠ MGN cần băng thông liên tục cho sao chép — phải chia sẻ với việc chuyển dữ liệu NAS:

MGN sao chép 150 máy ảo liên tục
Storage Gateway đẩy 50 TB lên S3
        ↓
    Cả hai dùng chung đường 1 Gbps
        ↓
    → nên đặt lịch: chuyển khối dữ liệu lớn ngoài giờ làm việc,
      MGN giữ nhịp sao chép thay đổi trong giờ

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

• C (chuyển dữ liệu NAS bằng AWS Snowball) — đây là phương án gần nhất và Snowball là công cụ hoàn toàn hợp lệ cho 50 TB. Nhưng với dữ kiện của đề thì nó không cần thiết và còn kém hơn. Băng thông đã đủ như phép tính trên, nên lợi thế chính của Snowball không được dùng tới. Quan trọng hơn, Snowball tạo ra một khoảng thời gian dữ liệu không có ở đâu cả: sau khi sao chép lên thiết bị và gửi đi, phải chờ vận chuyển và nhập — trong khi đề nói dữ liệu phải truy cập được tức thì khi cần. Storage Gateway giữ được tính liên tục đó. Snowball cũng là quy trình một lần, còn gateway phục vụ luôn giai đoạn vận hành sau di chuyển.

• B (dựng EC2 mới và cài lại toàn bộ ứng dụng) — mâu thuẫn trực tiếp với "VM configurations are highly customized". Cài lại 150 máy tuỳ biến sâu trong 90 ngày là khối lượng công việc khổng lồ, và mỗi máy là một cơ hội để một thiết lập bị bỏ sót. Đây cũng là phương án có gián đoạn lớn nhất.

• E (sao chép dữ liệu ít truy cập từ NAS bằng AWS SMS) — sai công cụ. Server Migration Service di chuyển MÁY CHỦ, không di chuyển tệp — nó tạo AMI từ máy ảo, không đồng bộ dữ liệu NAS. Và SMS đã được thay thế bởi AWS Application Migration Service (MGN), chính là thứ phương án A dùng.

Ghi nhớ về chất lượng câu hỏi

⚠ AWS Server Migration Service (SMS) đã được thay bằng Application Migration Service (MGN):

AWS ngừng nhận khách hàng mới cho SMS và khuyến nghị chuyển sang MGN
        ↓
    MGN sao chép ở mức khối, liên tục, downtime cắt chuyển chỉ vài phút
        ↓
    → phương án E vốn đã sai vì dùng công cụ di chuyển máy chủ cho dữ liệu tệp,
      và còn nhắc một dịch vụ đã lỗi thời

Đề này dùng MGN ở phương án A, tức là đã được cập nhật một phần — nhưng phương án E vẫn giữ tên cũ.

Ghi nhớ

⚠ Bốn công cụ chuyển dữ liệu — bảng phải thuộc: | Công cụ | Dùng khi | |---|---| | DataSync | chuyển theo lịch qua mạng, tự xác minh | | Storage Gateway | cần truy cập liên tục trong và sau khi chuyển | | Snow Family | băng thông không đủ, khối lượng rất lớn | | S3 Transfer Acceleration | tải lên S3 từ nơi xa |

Từ khoá nhận diện:

"highly customized VMs" → rehost bằng MGN, không dựng lại "internet connection mostly idle" → băng thông đủ, không cần Snowball "infrequent access but must be immediate" → Storage Gateway hoặc S3 Standard-IA "AWS SMS" → đã bị MGN thay thế "reinstall all applications" khi cấu hình tuỳ biến → SAI, rủi ro và tốn công

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Băng thông thực tế | đo bằng iperf ngoài giờ làm việc | | MGN có bắt kịp không | trạng thái sao chép trong console MGN | | Dữ liệu có đủ không | so số tệp và dung lượng hai đầu |

Và một lời khuyên: hãy đo băng thông thực tế ngoài giờ làm việc trước khi cam kết lịch di chuyển, đừng lấy con số danh nghĩa của đường truyền. Một đường 1 Gbps hiếm khi cho 1 Gbps thực: có giới hạn của nhà mạng, có lưu lượng nền không ai biết tới, có giới hạn ở chính thiết bị đầu cuối, và với các luồng TCP đường dài thì cửa sổ truyền cũng ảnh hưởng đáng kể. Khoảng cách giữa 1 Gbps trên hợp đồng và 400 Mbps thực tế là khoảng cách giữa "xong trong 20 đêm" và "xong trong 50 đêm" — và trong một dự án có hạn chót cứng là ngày rời khỏi trung tâm dữ liệu, đó là khác biệt quyết định giữa việc kịp và không kịp.

Đáp án

A — Triển khai mỗi ứng dụng vào một môi trường AWS Elastic Beanstalk single-instance, không có load balancer.

Vì sao đúng

Ba dữ kiện của đề quyết định lời giải: hơn 100 ứng dụng web đơn giản, không còn được phát triển, không được dùng nhiều.

⚠ Điểm mấu chốt: Elastic Beanstalk là mức trừu tượng cao nhất mà vẫn chạy được mã hiện có không cần sửa:

Đưa gói mã lên → Beanstalk tự dựng EC2, security group, vá lỗi nền tảng,
                  giám sát sức khoẻ, gom log, triển khai phiên bản
        ↓
    Bạn không quản máy chủ, không viết template hạ tầng
        ↓
    Nhưng mã ứng dụng KHÔNG cần sửa — khác hẳn với việc chuyển sang container
      hay serverless

Vì sao single-instance, không load balancer. Đề nói ứng dụng không được dùng nhiều. Môi trường single-instance:

Với hơn 100 ứng dụng, phí ALB cho mỗi cái sẽ vượt xa chi phí tính toán.

eb init ung-dung-01 --platform php-8.2 --region ap-southeast-1
eb create ung-dung-01-prod --single    # không load balancer

⚠ Beanstalk vẫn cần bạn cập nhật nền tảng — không phải hoàn toàn không đụng tới:

AWS phát hành phiên bản nền tảng mới (vá bảo mật cho PHP, Node.js...)
        ↓
    Môi trường không tự nâng cấp theo mặc định
        ↓
    → bật Managed Platform Updates để tự cập nhật trong maintenance window
        ↓
    → thiếu bước này thì sau vài năm bạn có 100 môi trường chạy nền tảng đã hết hỗ trợ

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

• B (dùng AWS SMS tạo AMI cho từng máy ảo, chạy AMI trên EC2) — đây là phương án gần nhất và rehost là chiến lược hợp lý cho ứng dụng không còn phát triển. Nhưng nó không giảm được công vận hành: bạn nhận về hơn 100 EC2 instance phải tự vá hệ điều hành, tự giám sát, tự sao lưu — chính là những việc mà Beanstalk làm giúp. Với ứng dụng web đơn giản trên các nền tảng Beanstalk hỗ trợ sẵn, rehost thô là bỏ lỡ mức trừu tượng cao hơn mà không nhận lại gì. Ngoài ra AWS SMS đã được thay bằng Application Migration Service (MGN).

• C (tái cấu trúc thành container Docker, triển khai lên ECS sau ALB) — nhiều công nhất trong bốn phương án. Phải viết Dockerfile cho hơn 100 ứng dụng, dựng pipeline build image, quản task definition và service. Với ứng dụng không còn được phát triển, khoản đầu tư đó không bao giờ hoàn vốn. Và ALB cho từng ứng dụng ít dùng là chi phí thừa.

• D (dùng EBS cross-Region replication để tạo AMI cho mỗi ứng dụng) — mô tả một cơ chế không tồn tại theo cách này. EBS có cross-Region snapshot copy, không phải "replication" tạo AMI, và bản thân việc sao chép snapshot giữa các Region không liên quan gì tới việc di chuyển ứng dụng từ trung tâm dữ liệu tại chỗ lên AWS.

Ghi nhớ

⚠ Bốn mức trừu tượng cho ứng dụng web — bảng phải thuộc, xếp theo công vận hành: | Mức | Bạn quản gì | Sửa mã | |---|---|---| | EC2 | hệ điều hành, runtime, ứng dụng | không | | Elastic Beanstalk | chỉ mã ứng dụng | không | | ECS/Fargate | container image + task definition | phải đóng gói | | Lambda | chỉ hàm | thường phải viết lại |

Từ khoá nhận diện:

"LOWEST operational overhead" + ứng dụng web chuẩn → Elastic Beanstalk "not heavily utilized" → single-instance, không load balancer "not being developed" → không đầu tư tái kiến trúc "AWS SMS" → đã bị MGN thay thế "refactor to containers" cho ứng dụng cũ ít dùng → quá nhiều công

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có chạy trên nền tảng không | triển khai thử một ứng dụng đại diện trước | | Nền tảng có được cập nhật không | kiểm Managed Platform Updates đã bật chưa | | Chi phí thực tế | so tổng chi phí 100 môi trường single-instance với 100 EC2 tự quản |

Và một lời khuyên: hãy bật Managed Platform Updates ngay khi tạo môi trường, đừng để sau. Đây là chỗ lời hứa "ít công vận hành" của Beanstalk lặng lẽ tan biến: môi trường chạy hoàn hảo trong nhiều năm, ứng dụng vẫn phục vụ, không có lỗi nào — trong khi phiên bản nền tảng bên dưới ngày càng cũ và cuối cùng rơi khỏi danh sách được hỗ trợ. Lúc đó bạn không còn cập nhật từng bước được nữa mà phải nhảy qua nhiều phiên bản một lúc, với hơn một trăm môi trường, cho những ứng dụng mà không ai còn nhớ cách kiểm thử. Việc bật một hộp kiểm lúc tạo môi trường tốn năm giây; việc bỏ qua nó tốn một dự án.

Đáp án

D — Dùng agent của Application Discovery Service cho máy chủ vật lý và Hyper-V; dùng Agentless Discovery Connector cho VMware; lưu dữ liệu thu thập trong S3, truy vấn bằng Athena, sinh báo cáo bằng QuickSight.

Vì sao đúng

Đề có hai loại hypervisor và một yêu cầu về báo cáo. Phương án D là phương án duy nhất ghép đúng công cụ với từng môi trường.

⚠ Điểm mấu chốt: Agentless Connector CHỈ hoạt động với VMware vCenter — Hyper-V không có tương đương:

Agentless Discovery Connector
        ↓
    Là một máy ảo cắm vào vCenter, hỏi vCenter về kho máy ảo
        ↓
    Phụ thuộc hoàn toàn vào API của VMware
        ↓
    → Hyper-V và máy vật lý KHÔNG dùng được cách này
        ↓
    → chúng phải cài Discovery Agent bên trong hệ điều hành

Đây là kiến thức phân biệt phương án D với B, và là lý do phải dùng cả hai cơ chế.

Về đường ống báo cáo. Application Discovery Service cho phép xuất dữ liệu thu thập ra S3, và từ đó:

Dữ liệu thu thập → S3 (định dạng CSV/Parquet)
        ↓
    Athena truy vấn bằng SQL
        ↓
    QuickSight vẽ dashboard cho người không dùng SQL

Đây là bộ ba chuẩn của AWS cho phân tích dữ liệu trong S3 — serverless, không có cụm nào phải dựng.

⚠ Agent thấy được nhiều hơn Connector — và phần chênh lệch chính là quan hệ phụ thuộc: | | Agentless Connector | Discovery Agent | |---|---|---| | Kho máy, CPU, RAM, đĩa | có | có | | Tiến trình đang chạy | không | có | | Kết nối mạng giữa các máy | không | có | | Công cài đặt | một lần cho cả vCenter | từng máy |

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

• C (dùng Discovery Agent cho cả máy vật lý lẫn mọi VM, lưu trong EFS, truy vấn và báo cáo bằng Athena) — đây là phương án gần nhất và phần thu thập của nó chạy được: agent cài được trên máy ảo VMware, chỉ là tốn công hơn Connector. Nó hỏng ở tầng lưu trữ. Athena truy vấn dữ liệu trong Amazon S3, không truy vấn EFS — đó là ràng buộc cơ bản của dịch vụ. Và phương án này bỏ luôn phần sinh báo cáo trực quan mà đề nêu: Athena trả về kết quả truy vấn, còn "generate reports" cho người dùng nghiệp vụ là việc của QuickSight.

• A (SSM agent cho máy vật lý, Agentless Connector cho mọi VM, lưu và báo cáo bằng Redshift) — hai lỗi. Systems Manager agent không phải công cụ khảo sát di chuyển — nó dùng để quản lý máy (chạy lệnh, vá lỗi, kiểm kê phần mềm), không đẩy dữ liệu vào Application Discovery Service. Và Agentless Connector không dùng được cho Hyper-V. Redshift thì là kho dữ liệu phân tích, quá nặng cho khối lượng metadata khảo sát và tốn chi phí cụm chạy liên tục.

• B (Agentless Connector cho cả máy vật lý lẫn mọi VM, lưu S3, truy vấn bằng S3 Select, báo cáo bằng Kibana trên EC2) — lặp lại lỗi Connector không dùng được cho máy vật lý và Hyper-V. S3 Select chỉ truy vấn được trong phạm vi một object, không join hay tổng hợp trên nhiều tệp như Athena. Và dựng Kibana trên EC2 là thêm hạ tầng phải vận hành, đi ngược tinh thần serverless của bộ ba S3-Athena-QuickSight.

Ghi nhớ

⚠ Hai chế độ khảo sát của Application Discovery Service — bảng phải thuộc: | | Agentless Connector | Discovery Agent | |---|---|---| | Cài ở đâu | máy ảo cắm vào vCenter | trong hệ điều hành | | Chỉ dùng được với | VMware | mọi thứ: vật lý, Hyper-V, VMware, cloud khác | | Thấy phụ thuộc mạng | không | có | | Công cài | một lần | từng máy |

Từ khoá nhận diện:

"VMware and Hyper-V" → cần CẢ Connector lẫn Agent "dependencies between servers" → bắt buộc có Agent "generate reports" → S3 + Athena + QuickSight "Athena truy vấn EFS" → LUÔN SAI, Athena đọc S3 "SSM agent để khảo sát di chuyển" → SAI, đó là công cụ quản lý máy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã thấy đủ máy chưa | so số máy trong Migration Hub với kiểm kê thật | | Có dữ liệu phụ thuộc chưa | mở đồ thị Network Connections của vài máy | | Athena có đọc được không | chạy SELECT * LIMIT 10 sau khi xuất dữ liệu ra S3 |

Và một lời khuyên: hãy đối chiếu số máy mà công cụ khảo sát nhìn thấy với bản kiểm kê vật lý, ngay từ tuần đầu tiên. Đây là thiếu sót không tạo ra bất kỳ triệu chứng nào: nếu Connector chỉ cắm vào một trong hai vCenter, hoặc agent không cài được trên một nhóm máy vì chính sách bảo mật nội bộ, thì Migration Hub vẫn hiển thị một danh sách đầy đủ và mạch lạc — chỉ là danh sách của những máy nó biết. Không có màn hình nào liệt kê những máy nó không biết. Kế hoạch di chuyển sẽ được lập trên bức tranh thiếu đó, và phần thiếu chỉ lộ ra vào tuần cuối cùng trước khi rời trung tâm dữ liệu.

Đáp án

C — Dùng DynamoDB Streams bắt và gửi thay đổi tới Lambda; Lambda đẩy bản ghi vào Kinesis Data Streams; phân tích bất thường bằng Kinesis Data Analytics; gửi thông báo SNS khi phát hiện hành vi bất thường.

Vì sao đúng

Đề đòi ghi lại mọi thay đổi trên item trong vòng 30 phút. Chi tiết quyết định là từ "changes to items" — thay đổi ở mức dữ liệu, không phải ở mức API quản lý.

⚠ Điểm mấu chốt: CloudTrail KHÔNG ghi thao tác trên item của DynamoDB theo mặc định — đây là chỗ phương án A sai:

CloudTrail management event
        ↓
    Ghi CreateTable, UpdateTable, DeleteTable... — thao tác trên chính BẢNG
        ↓
    KHÔNG ghi PutItem, UpdateItem, DeleteItem
        ↓
DynamoDB Streams
        ↓
    Ghi từng thay đổi ở mức ITEM, kèm ảnh trước và sau
        ↓
    → đây mới là nguồn dữ liệu cho yêu cầu của đề

(CloudTrail có data event cho DynamoDB, nhưng phải bật riêng và tính phí; phương án A không nhắc tới điều đó, chỉ nói "capture all the APIs that change the tables".)

# Lambda đọc Streams rồi đẩy sang Kinesis để phân tích
import boto3, json
kinesis = boto3.client('kinesis')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        kinesis.put_record(
            StreamName='giao-dich-phan-tich',
            Data=json.dumps(ban_ghi['dynamodb']),
            PartitionKey=ban_ghi['dynamodb']['Keys']['giao_dich_id']['S'])

⚠ StreamViewType quyết định bạn thấy được gì — chọn sai là mất thông tin cần cho phân tích gian lận: | Giá trị | Ghi lại | |---|---| | KEYS_ONLY | chỉ khoá | | NEW_IMAGE | bản ghi sau khi đổi | | OLD_IMAGE | bản ghi trước khi đổi | | NEW_AND_OLD_IMAGES | cả hai — cần thiết để biết cái gì đã đổi |

Phát hiện gian lận cần so sánh trước và sau, nên phải là giá trị cuối.

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

• D (dùng event pattern trong CloudWatch Events để bắt sự kiện API của DynamoDB, Lambda phân tích, SNS cảnh báo) — đây là phương án gần nhất và kiến trúc của nó rất hợp lý: EventBridge → Lambda → SNS là mẫu chuẩn. Nhưng nó dựa trên cùng nguồn dữ liệu sai như phương án A. EventBridge nhận sự kiện DynamoDB thông qua CloudTrail, nên nó cũng chỉ thấy các thao tác quản lý bảng, không thấy PutItem hay UpdateItem. Với yêu cầu "all changes to items", nguồn duy nhất đúng là Streams. Đây là bẫy tinh vi vì phương án đúng về mọi mặt trừ chỗ nó lấy dữ liệu.

• A (CloudTrail bắt mọi API thay đổi bảng, SNS khi phát hiện bất thường qua lọc sự kiện CloudTrail) — cùng vấn đề nguồn dữ liệu. Thêm nữa, CloudTrail có độ trễ giao log thường tới 15 phút và log được ghi theo lô vào S3 — với yêu cầu 30 phút thì sát nút, và không có cơ chế "lọc sự kiện để phát hiện bất thường" sẵn có trong CloudTrail.

• B (sao chép bảng DynamoDB sang Hive trên EMR mỗi giờ rồi phân tích) — vi phạm thẳng yêu cầu thời gian: chu kỳ một giờ vượt quá 30 phút. Nó cũng rất tốn kém (một cụm EMR chạy để quét toàn bảng mỗi giờ) và tiêu thụ read capacity của bảng production. Đây là mẫu phân tích theo lô đặt vào một bài toán cần luồng.

Ghi nhớ

⚠ Bốn nguồn dữ liệu về DynamoDB — bảng phải thuộc: | Nguồn | Ghi lại | |---|---| | DynamoDB Streams | thay đổi ở mức ITEM, giữ 24 giờ | | CloudTrail management event | thao tác trên bảng (Create, Update, Delete Table) | | CloudTrail data event | thao tác trên item — phải bật riêng, tính phí | | CloudWatch metric | số liệu vận hành, không phải nội dung |

Từ khoá nhận diện:

"all changes to ITEMS" → DynamoDB Streams "real time" / "within N minutes" → Streams, không phải batch "CloudTrail để bắt PutItem" → SAI theo mặc định, cần data event "copy to EMR every hour" khi yêu cầu 30 phút → SAI về thời gian "phân tích luồng" → Kinesis Data Analytics (nay là Managed Service for Apache Flink)

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Streams có bật không | describe-table, xem StreamSpecification | | Có tụt lại sau không | IteratorAge của Lambda đọc Streams | | Có mất bản ghi không | so số thay đổi với số bản ghi đã xử lý |

Và một lời khuyên: hãy đặt cảnh báo trên IteratorAge của hàm đọc Streams, và nhớ rằng Streams chỉ giữ dữ liệu 24 giờ. Đây là chỗ một hệ thống giám sát tự nó hỏng một cách âm thầm: nếu hàm xử lý bắt đầu chậm hơn tốc độ thay đổi — vì một truy vấn phụ trợ chậm đi, vì một đợt giao dịch lớn — nó không thất bại mà chỉ tụt lại dần. Không có lỗi nào, không có bản ghi nào bị từ chối. Nhưng khi độ trễ vượt quá 24 giờ, những bản ghi chưa xử lý rơi khỏi Streams vĩnh viễn — và đó chính là những thay đổi mà đội bảo mật cần nhìn thấy nhất, vì chúng xảy ra trong đợt hoạt động bất thường nhất.

Đáp án

C — Dùng Auto Scaling group cho tầng web và bật DynamoDB auto scaling.

Vì sao đúng

Đề đòi kiến trúc chịu được đỉnh tải với ít công phát triển nhất. Cả hai tầng đều có cơ chế co giãn dựng sẵn, không cần sửa một dòng mã.

⚠ Điểm mấu chốt: cả hai đều là thay đổi CẤU HÌNH, không phải thay đổi mã — đó là nghĩa của "LEAST development effort":

Auto Scaling group: đưa EC2 hiện có vào group, đặt chính sách co giãn
        ↓
    Ứng dụng không biết gì, không sửa gì
        ↓
DynamoDB auto scaling: bật trên bảng, đặt mục tiêu tận dụng
        ↓
    Ứng dụng vẫn gọi cùng API
        ↓
    → không có mã nào phải viết, không có kiến trúc nào phải đổi

Điều này phân biệt C với mọi phương án còn lại — chúng đều đòi viết lại ứng dụng ở mức nào đó.

# DynamoDB auto scaling cho write capacity
aws application-autoscaling register-scalable-target \
  --service-namespace dynamodb --resource-id table/don-hang \
  --scalable-dimension dynamodb:table:WriteCapacityUnits \
  --min-capacity 5 --max-capacity 4000

aws application-autoscaling put-scaling-policy \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration \
  'TargetValue=70,PredefinedMetricSpecification={PredefinedMetricType=DynamoDBWriteCapacityUtilization}'

⚠ Auto scaling phản ứng theo CloudWatch nên mất vài phút — với đỉnh rất đột ngột thì on-demand tốt hơn:

Đỉnh tải tăng trong vài giây
        ↓
    CloudWatch alarm cần vài chu kỳ để kích hoạt
        ↓
    → trong khoảng đó vẫn có thể bị throttle
        ↓
    → nếu đỉnh cực ngắn và rất cao, cân nhắc DynamoDB on-demand

Với đề này, "major sales events" là những sự kiện kéo dài hàng giờ nên auto scaling kịp phản ứng.

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

• A (Auto Scaling group cho web, thêm SQS và Lambda để ghi vào DynamoDB) — đây là phương án gần nhất và nó thật sự là kiến trúc tốt hơn về mặt kỹ thuật: đệm ghi bằng SQS làm phẳng đỉnh và bảo vệ tầng dữ liệu, đây là mẫu rất phổ biến. Nhưng nó đòi viết lại phần ghi của ứng dụng: thay vì gọi DynamoDB trực tiếp, ứng dụng phải đẩy tin nhắn vào SQS, và phải viết một Lambda mới để tiêu thụ. Nó cũng đổi ngữ nghĩa từ ghi đồng bộ sang bất đồng bộ — người dùng không còn nhận xác nhận ngay rằng đơn hàng đã lưu, nên tầng giao diện cũng phải đổi theo. Với tiêu chí LEAST development effort, đó là quá nhiều so với việc bật một tính năng có sẵn.

• B (chuyển ứng dụng web sang Lambda, tăng read/write capacity của DynamoDB) — đòi viết lại toàn bộ ứng dụng web theo mô hình hàm không trạng thái. Và tăng capacity thủ công không phải là co giãn: bạn cấp theo đỉnh và trả tiền mức đó suốt thời gian còn lại, hoặc cấp thấp và bị throttle khi cao điểm.

• D (chuyển sang Lambda, cấu hình DynamoDB dùng global tables) — cùng vấn đề viết lại, cộng thêm một hiểu nhầm: global table dùng để sao chép đa Region, phục vụ tính sẵn sàng và độ trễ toàn cầu — nó không giải quyết vấn đề dung lượng trong một Region. Bảng vẫn bị throttle như cũ nếu capacity không đủ.

Ghi nhớ

⚠ Bốn cách xử lý đỉnh tải trên DynamoDB — bảng phải thuộc: | Cách | Công sức | Hợp với | |---|---|---| | Auto scaling (provisioned) | chỉ cấu hình | đỉnh kéo dài hàng giờ, đoán được xu hướng | | On-demand | chỉ đổi chế độ | đỉnh rất đột ngột, khó đoán | | Scheduled scaling | cấu hình | đỉnh vào giờ biết trước | | SQS đệm ghi | phải viết mã | khi cần bảo vệ tuyệt đối tầng dữ liệu |

Từ khoá nhận diện:

"LEAST development effort" → bật tính năng có sẵn, không viết mã "scale to handle peak traffic" → Auto Scaling + DynamoDB auto scaling "global tables" để chữa nghẽn dung lượng → SAI, đó là đa Region "tăng capacity" thủ công → không phải co giãn chuyển sang Lambda khi đề đòi ít công → viết lại toàn bộ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bị throttle không | ReadThrottleEvents và WriteThrottleEvents | | Auto scaling có kích hoạt không | lịch sử scaling của Application Auto Scaling | | GSI có bị nghẽn riêng không | chỉ số throttle theo từng index |

Và một lời khuyên: hãy bật auto scaling cho cả các GSI, đừng chỉ bật cho bảng chính. Đây là chỗ nghẽn xuất hiện ở nơi không ai nhìn: mỗi GSI có dung lượng đọc ghi riêng, và một ghi vào bảng chính có thể kéo theo ghi vào nhiều index. Khi một GSI hết capacity, DynamoDB throttle luôn cả thao tác ghi vào bảng chính — nghĩa là bảng của bạn ngừng nhận dữ liệu vì một chỉ mục phụ, trong khi mọi chỉ số của bảng chính đều cho thấy dung lượng còn dư. Thông báo lỗi không nói rõ index nào, và bạn sẽ tăng capacity cho bảng nhiều lần trước khi nghĩ tới việc nhìn xuống từng index.

Đáp án

D — Tạo Amazon EFS với performance mode Max I/O và mount trên mọi EC2 instance trong cụm.

Vì sao đúng

Đề nêu bốn ràng buộc, và ràng buộc cuối cùng quyết định lựa chọn giữa hai chế độ của EFS.

⚠ Điểm mấu chốt: hai performance mode của EFS đánh đổi ngược nhau — chọn theo thứ bạn cần nhiều hơn:

General Purpose
        ↓
    Độ trễ THẤP NHẤT cho mỗi thao tác
    Nhưng trần khoảng 35.000 thao tác/giây
        ↓
Max I/O
        ↓
    Thông lượng tổng CAO HƠN NHIỀU, gần như không giới hạn thao tác
    Đổi lại độ trễ mỗi thao tác cao hơn một chút
        ↓
    → cụm big data với "numerous instances" và "substantial throughput"
      rơi rõ vào vế thứ hai

Đề dùng đúng cụm từ "substantial throughput levels" và "numerous instances" — đó là mô tả của Max I/O.

aws efs create-file-system \
  --performance-mode maxIO \
  --throughput-mode elastic \
  --encrypted

# mount trên mỗi node
sudo mount -t efs -o tls fs-0abc123:/ /du-lieu

⚠ Performance mode KHÔNG đổi được sau khi tạo — phải chọn đúng ngay từ đầu:

Tạo file system với General Purpose
        ↓
    Sau này phát hiện chạm trần thao tác
        ↓
    → không có lệnh nào đổi sang Max I/O
        ↓
    → phải tạo file system mới và chuyển toàn bộ dữ liệu sang

Đây là lý do câu hỏi này quan trọng trong thực tế, không chỉ trong bài thi.

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

• C (EFS với General Purpose performance mode) — đây là phương án gần nhất và nó chỉ khác đáp án đúng một tham số: cùng dịch vụ, cùng cách mount, cùng đáp ứng POSIX và nhiều AZ. General Purpose thậm chí là chế độ mặc định và đúng cho phần lớn khối lượng công việc, vì nó cho độ trễ thấp nhất. Nhưng nó có trần khoảng 35.000 thao tác mỗi giây, và một cụm phân tích dữ liệu lớn với nhiều node đọc ghi song song sẽ chạm trần đó. Khi chạm trần, biểu hiện là độ trễ tăng vọt và thông lượng đứng yên — đúng thứ đề muốn tránh khi nhấn mạnh "substantial throughput levels".

• B (tạo một EBS io2 volume và gắn vào MỌI instance trong cụm) — sai về bản chất. EBS là khối lưu trữ gắn với một instance; Multi-Attach có tồn tại nhưng chỉ với io1/io2, giới hạn 16 instance, chỉ trong cùng một AZ, và không có hệ thống tệp dùng chung — muốn nhiều máy cùng ghi thì phải dùng cluster file system tự quản. Đề nói cụm trải nhiều AZ, nên phương án này không khả thi.

• A (Storage Gateway file gateway với NFS share trỏ vào S3, mount trên mỗi instance) — sai công cụ. File gateway sinh ra cho môi trường lai — nó chạy tại chỗ để cho ứng dụng cũ truy cập S3 qua NFS/SMB. Dùng nó bên trong AWS để chia sẻ tệp giữa các EC2 là đường vòng: thêm một máy trung gian, thêm điểm hỏng, và thông lượng bị giới hạn bởi chính gateway đó.

Ghi nhớ

⚠ Hai trục cấu hình của EFS — bảng phải thuộc: | Trục | Lựa chọn | |---|---| | Performance mode | General Purpose (độ trễ thấp) / Max I/O (thông lượng cao) | | Throughput mode | Bursting / Provisioned / Elastic (tự co giãn, khuyến nghị) | | Storage class | Standard / One Zone / IA / Archive |

Từ khoá nhận diện:

"POSIX-compliant" + nhiều instance → EFS "substantial throughput" / "thousands of clients" → Max I/O độ trễ thấp nhất, ít client → General Purpose | "EBS gắn vào mọi instance" → SAI, EBS không phải hệ thống tệp dùng chung "HPC gắn kết chặt" → FSx for Lustre, không phải EFS

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có chạm trần thao tác không | chỉ số PercentIOLimit — gần 100% nghĩa là General Purpose đã hết | | Thông lượng thực tế | MeteredIOBytes, TotalIOBytes | | Có mount target ở mọi AZ chưa | thiếu là node ở AZ đó truy cập qua AZ khác, thêm độ trễ và phí |

Và một lời khuyên: hãy theo dõi PercentIOLimit ngay từ khi cụm còn nhỏ, đừng chờ tới lúc chậm. Đây là chỉ số duy nhất cho biết bạn đang tiến gần trần thao tác của General Purpose, và nó là loại giới hạn không báo lỗi: khi chạm trần, EFS không từ chối request mà chỉ xếp hàng — nên biểu hiện là độ trễ tăng dần và thông lượng không nhích lên dù bạn thêm node. Đội vận hành sẽ đi tìm nguyên nhân ở CPU, ở mạng, ở chính ứng dụng, trong khi nguyên nhân là một tham số đã được chốt từ lúc tạo file system và không sửa được nữa — cách duy nhất là dựng file system mới và chuyển hết dữ liệu sang.

Đáp án

D — Dựng S3 gateway VPC endpoint trong VPC và gắn endpoint policy cho phép các thao tác cần thiết trên bucket đó.

Vì sao đúng

Con số quyết định nằm trong đề: khoảng 1 TB object mới mỗi ngày đi từ EC2 trong private subnet lên S3, và đường đi hiện tại là qua NAT gateway.

⚠ Điểm mấu chốt: NAT gateway tính tiền theo TỪNG GB đi qua — và gateway endpoint thì hoàn toàn miễn phí:

Qua NAT gateway
        ↓
    Phí theo giờ cho mỗi NAT + phí xử lý cho MỖI GB
        ↓
    1 TB mỗi ngày ≈ 30 TB mỗi tháng chỉ riêng lưu lượng S3
        ↓
Qua S3 gateway endpoint
        ↓
    Không phí theo giờ, KHÔNG phí xử lý dữ liệu
        ↓
    → khoản tiết kiệm lớn nhất trong toàn bộ kiến trúc này

Ngoài chi phí, đường đi cũng an toàn hơn: lưu lượng không rời khỏi mạng AWS, không đi qua Internet gateway.

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-private-1a rtb-private-1b \
  --policy-document file://chinh-sach-endpoint.json

⚠ Gateway endpoint hoạt động bằng cách thêm route — phải khai đúng route table:

Tạo endpoint mà không gắn route table của private subnet
        ↓
    Không có tuyến nào trỏ tới prefix list của S3
        ↓
    → lưu lượng vẫn đi qua NAT như cũ
        ↓
    → endpoint tồn tại, hiện "available", và hoàn toàn không có tác dụng

Đây là lỗi cấu hình phổ biến nhất với gateway endpoint, và nó không sinh ra bất kỳ cảnh báo nào.

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

• C (thay NAT gateway bằng NAT instance, thêm route từ private subnet tới NAT instance) — đây là phương án gần nhất và nó thật sự giảm được chi phí: NAT instance rẻ hơn NAT gateway ở mức phí cố định, và đây là một lựa chọn hợp lệ trong một số kiến trúc. Nhưng nó đi ngược yêu cầu "reduce manual effort" của đề: NAT instance là EC2 bạn phải tự vá lỗi, tự giám sát, tự dựng cơ chế sẵn sàng cao (NAT gateway có sẵn tính sẵn sàng trong AZ, NAT instance thì không). Và với 1 TB mỗi ngày, một NAT instance sẽ trở thành nút thắt băng thông trước khi tiết kiệm được gì đáng kể. Quan trọng nhất: nó vẫn để lưu lượng S3 đi qua một chặng trung gian, trong khi gateway endpoint bỏ hẳn chặng đó và miễn phí.

• A (chuyển EC2 sang public subnet, bỏ NAT gateway) — tiết kiệm được tiền nhưng phá vỡ bảo mật, thứ đề nói phải giữ nguyên. Đặt máy xử lý ảnh vào subnet công khai nghĩa là chúng có địa chỉ công cộng và nằm trong tầm với trực tiếp từ Internet.

• B (gắn EFS vào EC2 và lưu ảnh trên EFS) — đổi kho lưu trữ chứ không giải quyết vấn đề. EFS đắt hơn S3 nhiều lần cho cùng dung lượng, nên với 1 TB mỗi ngày thì chi phí sẽ tăng chứ không giảm. Nó cũng không đụng gì tới NAT gateway nếu ứng dụng vẫn cần gọi ra ngoài.

Ghi nhớ

⚠ Hai loại VPC endpoint — bảng phải thuộc, chú ý cột chi phí: | | Gateway endpoint | Interface endpoint | |---|---|---| | Dịch vụ hỗ trợ | chỉ S3 và DynamoDB | hầu hết dịch vụ AWS | | Cơ chế | mục trong route table | ENI có IP riêng | | Chi phí | MIỄN PHÍ | phí theo giờ + theo GB | | Security group | không gắn được | gắn được | | Từ mạng tại chỗ | không dùng được | dùng được qua DX/VPN |

Từ khoá nhận diện:

"reduce cost" + lưu lượng S3 lớn qua NAT → S3 gateway endpoint "reduce manual effort" → loại NAT instance "maintain security" → loại chuyển sang public subnet "gateway endpoint" → miễn phí, chỉ S3 và DynamoDB cần truy cập từ on-premises → interface endpoint, gateway không dùng được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Route đã có chưa | kiểm route table của private subnet có prefix list của S3 | | Lưu lượng có còn qua NAT không | chỉ số BytesOutToDestination của NAT gateway phải giảm mạnh | | Endpoint policy có chặn nhầm không | thử thao tác hợp lệ từ instance |

Và một lời khuyên: hãy theo dõi chỉ số lưu lượng của NAT gateway sau khi tạo endpoint, và xác nhận nó thật sự giảm. Đây là chỗ một tối ưu chi phí trông như đã hoàn thành mà thực ra chưa làm gì: gateway endpoint được tạo thành công, hiện trạng thái available trong console, và bạn đánh dấu công việc là xong. Nhưng nếu nó không được gắn vào đúng route table của các private subnet, lưu lượng S3 vẫn tiếp tục đi qua NAT gateway y như trước — không có lỗi, không có cảnh báo, ứng dụng chạy hoàn hảo, và hoá đơn tháng sau không đổi. Con số duy nhất nói ra sự thật là lượng byte đi qua NAT gateway, và nó phải giảm gần bằng chính lượng dữ liệu bạn đang đẩy lên S3.

Đáp án

A, C — hai lựa chọn cho ứng dụng khai báo chi phí với ít công vận hành nhất:

• A — Đưa front end lên S3 phục vụ qua CloudFront; back end dùng API Gateway với Lambda proxy integration.
• C — Lưu dữ liệu khai báo trong S3; dùng Athena và QuickSight sinh báo cáo với S3 làm nguồn dữ liệu.

Vì sao đúng

Hình thái tải của đề rất đặc trưng: nộp dồn vào thứ Sáu hằng tuần, gần như im ắng những ngày khác, cộng với báo cáo cuối tháng.

⚠ Điểm mấu chốt: tải dồn một ngày mỗi tuần là trường hợp mà serverless thắng đậm nhất:

EC2 hoặc ECS
        ↓
    Phải giữ dung lượng nền chạy suốt 7 ngày
    Sáu ngày trong đó gần như không có ai dùng
        ↓
Lambda + API Gateway
        ↓
    Thứ Sáu: co giãn tức thì theo số request
    Sáu ngày còn lại: gần như không tốn gì
        ↓
    → và không có máy nào để vá, để giám sát, để co giãn

Vì sao S3 + Athena cho báo cáo (C). Dữ liệu khai báo là bản ghi ghi một lần, đọc theo lô cuối tháng — đúng mô hình mà S3 và Athena phục vụ. Không có cụm nào chạy giữa các kỳ báo cáo:

SELECT phong_ban, sum(so_tien) AS tong
FROM khai_bao
WHERE nam = '2026' AND thang = '09'
GROUP BY phong_ban;

⚠ Athena tính tiền theo byte quét — nên phân vùng theo tháng ngay từ đầu:

Ghi vào S3 theo tiền tố nam=2026/thang=09/
        ↓
    Báo cáo cuối tháng chỉ quét đúng phân vùng đó
        ↓
    → chi phí truy vấn gần như không đổi dù dữ liệu tích luỹ nhiều năm

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

• B (container trên ECS sau ALB, Service Auto Scaling và lên lịch thêm dung lượng trước giờ cao điểm) — đây là phương án gần nhất và nó thật sự co giãn được: scheduled scaling xử lý đúng mẫu "thứ Sáu hằng tuần". Nhưng nó nhiều việc vận hành hơn hẳn: phải xây và cập nhật container image, quản task definition, cấu hình chính sách co giãn, và trả phí ALB cùng dung lượng nền suốt cả tuần cho một ứng dụng chỉ bận một ngày. Câu "schedule additional capacity ahead of peak" cũng cho thấy con người phải biết trước và duy trì lịch đó — đúng thứ mà "LEAST operational overhead" muốn loại.

• E (EC2 On-Demand sau ALB với Auto Scaling và lên lịch thêm dung lượng) — cùng nhược điểm của B nhưng ở mức thấp hơn nữa: bạn còn phải vá hệ điều hành và quản AMI.

• D (lưu dữ liệu trong Amazon EMR, dùng QuickSight với EMR làm nguồn) — EMR không phải kho lưu trữ; nó là cụm xử lý dữ liệu chạy Spark/Hadoop, và dữ liệu vẫn nằm ở S3 hoặc HDFS. Duy trì một cụm EMR chỉ để chạy báo cáo cuối tháng là chi phí và công vận hành lớn, hoàn toàn ngược với yêu cầu của đề.

Ghi nhớ

⚠ Bốn thành phần của kiến trúc serverless đầy đủ — bảng phải thuộc: | Tầng | Dịch vụ | |---|---| | Front end tĩnh | S3 + CloudFront | | API | API Gateway | | Nghiệp vụ | Lambda | | Dữ liệu | DynamoDB (giao dịch) hoặc S3 + Athena (phân tích) |

Từ khoá nhận diện:

"LEAST operational overhead" → serverless "scale seamlessly based on demand" → Lambda, không phải scheduled scaling "end of month reports" → S3 + Athena + QuickSight "schedule additional capacity" → có can thiệp thủ công, không phải liền mạch "lưu dữ liệu trong EMR" → SAI, EMR là cụm xử lý không phải kho lưu trữ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chi phí truy vấn | cột Data scanned trong lịch sử Athena | | Lambda có bị throttle không | chỉ số Throttles vào thứ Sáu | | Front end có được cache không | CacheHitRate của CloudFront |

Và một lời khuyên: hãy phân vùng dữ liệu theo năm và tháng ngay từ bản ghi đầu tiên, đừng chờ tới khi dữ liệu lớn. Đây là quyết định gần như miễn phí lúc đầu và rất tốn kém về sau: khi dữ liệu chỉ có vài nghìn bản ghi, truy vấn quét toàn bộ vẫn nhanh và rẻ, nên chẳng ai thấy lý do phải phân vùng. Nhưng cấu trúc tiền tố trong S3 là thứ không đổi được bằng một lệnh — muốn phân vùng lại thì phải đọc và ghi lại toàn bộ dữ liệu. Sau ba năm khai báo chi phí, chi phí của một lần dọn dẹp như vậy lớn hơn nhiều so với việc viết đúng đường dẫn ngay từ đầu.

Đáp án

D — Dùng AWS CodeBuild để kiểm thử tự động; dùng CloudFormation change set để đánh giá thay đổi trước khi triển khai; dùng AWS CodeDeploy để áp dụng mẫu blue/green.

Vì sao đúng

Đề nói rõ nguyên nhân sự cố: thay đổi trong CloudFormation template đã gây gián đoạn. Lời giải phải có ba lớp bảo vệ, và phương án D là phương án duy nhất đủ cả ba.

⚠ Điểm mấu chốt: change set cho biết tài nguyên nào sẽ bị THAY THẾ — thứ mà bản diff của template không nói ra:

Sửa một thuộc tính không cập nhật tại chỗ được
        ↓
    CloudFormation sẽ TẠO MỚI rồi XOÁ cái cũ
        ↓
    Với Auto Scaling group hay Launch Template, điều đó nghĩa là
    thay toàn bộ đội máy — chính là nguyên nhân gián đoạn của đề
        ↓
    → change set hiện trường Replacement: True, git diff thì không

aws cloudformation create-change-set \
  --stack-name ung-dung-prod --change-set-name thay-doi-01 \
  --template-body file://ha-tang.yaml

aws cloudformation describe-change-set \
  --stack-name ung-dung-prod --change-set-name thay-doi-01 \
  --query 'Changes[].ResourceChange.{Hanh:Action,Loai:ResourceType,ThayThe:Replacement}'

⚠ Nếu pipeline tự động thực thi change set ngay sau khi tạo thì nó chỉ còn là thủ tục:

Tạo change set → thực thi ngay
        ↓
    Không ai đọc, không cổng kiểm tra nào ở giữa
        ↓
    → giá trị bằng 0
        ↓
    → phải có bước kiểm thử hoặc phê duyệt giữa hai action

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

• C (CodeBuild phát hiện và báo lỗi CloudFormation khi triển khai; triển khai lên stack riêng trong tài khoản test rồi dùng kế hoạch kiểm thử THỦ CÔNG) — đây là phương án gần nhất và việc thử ở tài khoản test trước là thực hành tốt. Nhưng nó dựa vào kiểm thử thủ công, thứ không co giãn theo nhịp thay đổi và dễ bị bỏ qua khi gấp. Quan trọng hơn, nó phát hiện lỗi khi đang triển khai chứ không đánh giá trước, và không có cơ chế triển khai không gián đoạn — nên nếu một thay đổi lọt qua vòng kiểm thử tay, production vẫn hứng trọn.

• B (chuyển mã sang CodeCommit, CodeBuild kiểm thử, dùng CloudFormation StackSets triển khai ra các môi trường để "tận dụng blue/green") — hiểu sai công cụ. StackSets dùng để triển khai cùng một stack ra nhiều TÀI KHOẢN và REGION, không phải cơ chế blue/green. Việc chuyển kho mã từ S3 sang CodeCommit cũng không liên quan gì tới nguyên nhân sự cố. Phương án này thiếu hẳn change set.

• A (CodeDeploy blue/green với CloudFormation thay cho lifecycle hook; thu thập phản hồi người dùng để biết khi nào cần lùi lại) — có phần blue/green đúng, nhưng "gather feedback from users to identify issues" là cơ chế phát hiện tệ nhất có thể: nó nghĩa là người dùng phát hiện lỗi thay cho bạn, sau khi đã bị ảnh hưởng. Nó cũng không có kiểm thử tự động và không có change set.

Ghi nhớ

⚠ Bốn cơ chế bảo vệ stack CloudFormation — bảng phải thuộc: | Cơ chế | Việc | |---|---| | Change set | xem trước thay đổi, thấy Replacement | | Stack policy | chặn cập nhật lên tài nguyên nhất định | | Termination protection | không cho xoá nhầm stack | | Rollback configuration | tự lùi khi CloudWatch alarm kêu trong lúc triển khai | | Drift detection | phát hiện ai sửa tay ngoài template |

Từ khoá nhận diện:

"template changes caused outages" → change set + kiểm thử tự động "evaluate changes ahead of deployment" → change set "gather feedback from users" để phát hiện lỗi → SAI, quá muộn "StackSets để làm blue/green" → SAI, StackSets là đa tài khoản/Region "manual test plans" khi cần lặp lại thường xuyên → không co giãn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có tài nguyên nào bị thay thế không | đọc Replacement trong change set | | Pipeline có chặn được template hỏng không | cố ý đẩy một template sai và xem nó dừng | | Stack có bị sửa tay không | chạy drift detection định kỳ |

Và một lời khuyên: hãy thêm một bước tự động đọc change set và làm pipeline thất bại nếu có tài nguyên trạng thái bị Replacement: True. Con người sẽ không đọc change set mỗi lần — sau vài chục lần thấy nó vô hại, bước đó trở thành một cái nút bấm qua. Nhưng máy thì đọc mỗi lần, không mệt và không vội. Với những tài nguyên mà việc thay thế đồng nghĩa với mất dữ liệu — cơ sở dữ liệu, volume, bucket — một dòng kiểm tra trong CodeBuild là khác biệt giữa một lần triển khai bị chặn lại và một lần khôi phục từ bản sao lưu.