Ngân hàng đề — AWS Certified DevOps Engineer Professional

Đáp án

B — Sửa launch template hiện có để tạo phiên bản mới dùng instance type mới, rồi cập nhật Auto Scaling group trỏ sang phiên bản đó.

Vì sao đúng

Đặc điểm cốt lõi: launch template là bất biến theo từng phiên bản. Bạn không sửa được một phiên bản đã tạo — chỉ tạo được phiên bản mới:

# 1. Tạo phiên bản mới dựa trên phiên bản 1
aws ec2 create-launch-template-version --launch-template-id lt-xxxx \
  --source-version 1 --launch-template-data '{"InstanceType":"m6i.xlarge"}'

# 2. Trỏ ASG sang phiên bản mới
aws autoscaling update-auto-scaling-group --auto-scaling-group-name nhom-web \
  --launch-template LaunchTemplateId=lt-xxxx,Version=2

Từ đó, mọi instance được tạo mới sẽ dùng instance type mới. Instance đang chạy không bị ảnh hưởng — đúng yêu cầu của đề ("all new instances that are launched").

Một mẹo vận hành: có thể trỏ ASG vào $Latest hoặc $Default thay vì số phiên bản cụ thể. Nhưng trong production nên ghim số cụ thể — nếu không, một lần tạo phiên bản mới để thử nghiệm sẽ lập tức ảnh hưởng tới production mà không ai bấm nút deploy nào.

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

• A. Tạo môi trường Elastic Beanstalk — thay cả nền tảng triển khai chỉ để đổi một instance type. Hoàn toàn không tương xứng, và đề không hề nói ứng dụng chạy trên Beanstalk.
• C. Tự tạo instance rồi attach vào ASG — thao tác tay, chỉ áp dụng cho đúng những instance đó. Lần scale-out tiếp theo ASG vẫn dùng template cũ và tạo ra instance type cũ. Không giải quyết được vấn đề.
• D. Dùng cấu trúc Overrides — Overrides có thật, nhưng nó thuộc về MixedInstancesPolicy và dùng để khai một danh sách nhiều instance type cho ASG chọn (kết hợp Spot/On-Demand). Câu chữ của phương án — "define a new launch template for individual instance types" — mô tả sai chức năng của nó, và nó cũng không phải cách để đổi instance type mặc định.

Ghi nhớ

Đổi instance type là chuyện chỉ ảnh hưởng instance mới. Muốn thay cả những máy đang chạy thì cần thêm instance refresh.

Đáp án

A, E và F.

• A — Gắn IAM role cho EC2 để Systems Manager quản lý được instance.
• E — Đưa máy chủ on-premises vào SSM bằng Hybrid Activations.
• F — Dùng Systems Manager Maintenance Windows để lên lịch vá ngoài giờ làm việc.

Vì sao đúng

Đề cần vá cho cả EC2 lẫn máy chủ on-premises, cả Linux lẫn Windows, và chỉ vá ngoài giờ hành chính. Systems Manager phủ trọn cả ba bằng một mặt phẳng điều khiển.

Vế EC2 (A). Instance profile với policy AmazonSSMManagedInstanceCore. Không có nó, SSM Agent không đăng ký được và máy không bao giờ hiện ra là managed instance.

Vế on-premises (E). Hybrid Activations là cơ chế chính thức cho máy ngoài AWS:

aws ssm create-activation --default-instance-name may-chu-noi-bo \
  --iam-role SSMServiceRole --registration-limit 50
# Máy chủ đăng ký bằng activation code + activation id

Điểm quan trọng: máy nhận thông tin xác thực tạm thời tự xoay vòng, không phải access key tĩnh. Managed instance loại này có id bắt đầu bằng mi- thay vì i-.

Vế lịch (F). Maintenance Window khai bằng cron/rate, gắn task chạy AWS-RunPatchBaseline:

cron(0 2 ? * SAT *)   # 2 giờ sáng thứ Bảy

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

• B. Automation document cài bản vá mỗi giờ — vi phạm thẳng yêu cầu "chỉ vá ngoài giờ làm việc". Vá giữa giờ cao điểm là cách nhanh nhất gây sự cố.
• C. CloudWatch Events scheduled event để "lên lịch cửa sổ vá" — về nguyên tắc gọi được Run Command theo lịch, nhưng nó thiếu mọi thứ mà maintenance window có: cửa sổ thời gian có điểm kết (không tràn sang giờ làm việc), giới hạn số máy chạy đồng thời, ngưỡng dừng khi lỗi, và báo cáo tập trung.
• D. Tạo IAM access key cho máy chủ on-premises — đây là cách làm cũ và không an toàn: khoá tĩnh nằm trên hàng chục máy chủ, không tự hết hạn, rò rỉ là mất quyền kiểm soát. Hybrid Activations sinh ra chính để thay thế nó.

Ghi nhớ

Bộ ba của Patch Manager: patch baseline (vá nào được duyệt, riêng cho từng OS) + patch group (áp cho máy nào, gắn bằng tag Patch Group) + maintenance window (chạy lúc nào). Document luôn là AWS-RunPatchBaseline, và máy ngoài AWS luôn vào bằng Hybrid Activations.

Đáp án

A, D và F.

• F — Tạo CodeBuild project với GitHub làm source repository.
• A — Thêm tệp buildspec.yml vào mã nguồn.
• D — Cấu hình GitHub webhook để kích hoạt build mỗi khi có push.

Vì sao đúng

Ba mảnh trả lời ba câu hỏi: build ở đâu, build cái gì, build khi nào.

F — build ở đâu. CodeBuild hỗ trợ GitHub làm nguồn trực tiếp, không cần sao chép repo sang CodeCommit.

A — build cái gì. buildspec.yml khai toàn bộ các bước:

version: 0.2
phases:
  install:
    runtime-versions: {nodejs: 20}
  build:
    commands:
      - npm ci
      - npm run build
      - npm test          # kiểm thử, đúng yêu cầu của đề
artifacts:
  files: ['**/*']
  base-directory: 'dist'  # CodeBuild tự đẩy lên bucket S3 đã khai

D — build khi nào. Webhook cho CodeBuild chạy ngay khi có push, không phải chờ polling. Cấu hình một lần, và lọc được theo nhánh hoặc theo sự kiện (PUSH, PULL_REQUEST_CREATED…).

Ba mảnh này là bộ tối thiểu và cũng là bộ đủ — đề không cần pipeline nhiều stage.

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

• B. CodeDeploy application với nền tảng EC2/On-Premises — CodeDeploy dùng để triển khai ứng dụng lên máy chủ. Đề chỉ yêu cầu build, test, rồi đẩy artifact lên S3 — không có bước triển khai nào.
• C. Dựng EC2 để chạy build — quay về tự quản máy chủ build: vá, giám sát, trả tiền cả lúc rảnh. Đó chính là thứ CodeBuild sinh ra để thay thế.
• E. AWS OpsWorks — dịch vụ quản lý cấu hình bằng Chef/Puppet, đã ngừng phát triển, và vốn không phải công cụ CI. "Install dependencies command" là bước cấu hình máy chủ, không phải build ứng dụng.

Ghi nhớ

Với CodeBuild và GitHub có hai cách kích hoạt: webhook (đẩy, tức thì — nên dùng) và source polling qua CodePipeline (kéo, có độ trễ). Và nhớ buildspec.yml phải nằm ở thư mục gốc của repo, trừ khi khai đường dẫn khác trong cấu hình project.

Đáp án

B — Bật access log trên NLB ghi vào S3, bật SSE-S3, cho principal delivery.logs.amazonaws.com quyền ghi, và gắn IAM policy cho đội DevOps để có quyền đọc.

Vì sao đúng

Câu này có bốn phương án rất giống nhau; điểm khác biệt nằm ở hai chi tiết.

Chi tiết 1 — ai được ghi. Log của Elastic Load Balancing được chính dịch vụ AWS ghi vào bucket, nên bucket policy phải cấp cho service principal delivery.logs.amazonaws.com:

{
  "Effect": "Allow",
  "Principal": {"Service": "delivery.logs.amazonaws.com"},
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::log-nlb/AWSLogs/123456789012/*",
  "Condition": {"StringEquals": {"s3:x-amz-acl": "bucket-owner-full-control"}}
}

Chi tiết 2 — ai được đọc. Đây là điểm phân biệt B với A. Đề nói rõ dữ liệu "chỉ đội DevOps được truy cập". Cấp quyền ghi cho dịch vụ không cấp quyền đọc cho ai cả; phải có thêm một IAM policy cho đội DevOps. A dừng lại đúng trước bước này, nên nó đáp ứng thiếu một yêu cầu.

Về mã hoá: SSE-S3 (AES-256) đủ cho yêu cầu "encryption at rest" — và đây là lựa chọn an toàn hơn với log của ELB, xem phần dưới.

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

• A. Đúng mọi thứ trừ việc thiếu vế cấp quyền đọc cho đội DevOps — tức là thiếu đúng một trong ba yêu cầu của đề.
• C. SSE-KMS + cấp quyền ghi cho IAM group của đội DevOps — sai đối tượng: đội DevOps không phải bên ghi log, dịch vụ ELB mới là. Ngoài ra SSE-KMS có ràng buộc quan trọng nêu ở phần ghi nhớ.
• D. SSE-KMS + chỉ cấp quyền ghi — cũng thiếu vế quyền đọc, và cũng vướng ràng buộc KMS.

Ghi nhớ

Ràng buộc rất hay bị hỏi: access log của ELB chỉ hỗ trợ SSE-S3 (AES-256) hoặc SSE-KMS với khoá do khách hàng quản lý — và trong nhiều cấu hình, cách an toàn nhất vẫn là SSE-S3, vì SSE-KMS đòi key policy phải cho delivery.logs.amazonaws.com quyền kms:GenerateDataKey. Thiếu điều đó thì log im lặng không được ghi, không có thông báo lỗi ở đâu cả.

Và nhớ thêm: với NLB, access log chỉ được ghi khi listener dùng TLS — listener TCP/UDP thuần không sinh access log.

Đáp án

D — EC2 trong Auto Scaling group sau ALB ở hai Region, dùng bản ghi Route 53 với geoproximity routing.

Vì sao đúng

Đề có ba yêu cầu, và yêu cầu thứ ba là điểm phân biệt:

1. Độ sẵn sàng rất cao
2. Độ trễ thấp
3. "Traffic sẽ phân bố không đều — vài nơi nhiều hơn hẳn nơi khác"

Geoproximity routing là chính sách duy nhất có bias — tham số cho phép mở rộng hoặc thu hẹp vùng phục vụ của một endpoint:

# Region châu Âu đang quá tải → giảm bias để đẩy bớt traffic sang Region kia
aws route53 change-resource-record-sets --hosted-zone-id Zxxx --change-batch '{
  "Changes": [{"Action": "UPSERT", "ResourceRecordSet": {
    "Name": "game.example.com", "Type": "A", "SetIdentifier": "eu",
    "GeoProximityLocation": {"AWSRegion": "eu-west-1", "Bias": -30},
    "AliasTarget": {...}}}]}'

bias nhận giá trị từ −99 đến +99. Tăng bias thì vùng phục vụ của endpoint đó nở ra, hút thêm người dùng ở xa hơn; giảm bias thì co lại. Đó chính là công cụ để xử lý phân bố tải không đều mà đề nêu — và không chính sách nào khác có nó.

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

• C. Latency-based routing — cho độ trễ thấp rất tốt, nhưng hoàn toàn không điều chỉnh được. Nếu một khu vực đông đúc bất thường, mọi người ở đó vẫn bị dồn vào cùng một Region cho tới khi Region đó quá tải. Thiếu đúng công cụ mà yêu cầu thứ ba đòi hỏi.
• B. Geolocation routing — định tuyến theo vị trí địa lý cứng (châu lục, quốc gia). Không có bias, không xét độ trễ thực tế, và có bẫy riêng: phải khai bản ghi mặc định, thiếu nó thì truy vấn từ vùng không khớp không nhận được câu trả lời nào.
• A. Chỉ dùng CloudFront — CloudFront tuyệt vời cho nội dung tĩnh cache được, nhưng ứng dụng game nhiều người chơi là traffic động, có trạng thái, gần như không cache được. Nó cũng không giải quyết vế "triển khai ở hai Region" và không có cơ chế cân bằng theo khu vực.

Ghi nhớ

Từ khoá nhận dạng: đề nói "phân bố không đều" hoặc "cần dịch chuyển tải giữa các Region" ⇒ geoproximity.

Đáp án

D — Lưu endpoint Aurora trong Systems Manager Parameter Store; tạo EventBridge rule phát hiện sự cố CSDL và gọi Lambda để promote replica rồi cập nhật endpoint trong Parameter Store.

Vì sao đúng

Bài toán có hai nửa, và nửa thứ hai quan trọng không kém.

Nửa 1 — phát hiện và promote. RDS phát sự kiện (RDS event) lên EventBridge khi có sự cố. Rule bắt sự kiện đó và gọi Lambda:

{"source": ["aws.rds"], "detail-type": ["RDS DB Cluster Event"],
 "detail": {"EventCategories": ["failure", "failover"]}}

Lambda gọi promote-read-replica-db-cluster để biến cụm replica cross-Region thành cụm độc lập ghi được.

Nửa 2 — ứng dụng phải biết địa chỉ mới. Đây là điểm mà nhiều người bỏ sót. Promote xong thì endpoint đã đổi; nếu ứng dụng vẫn ghi cứng endpoint cũ thì nó tiếp tục trỏ vào cụm đã chết. Parameter Store giải quyết bằng cách trở thành nguồn sự thật duy nhất về địa chỉ CSDL:

ssm.put_parameter(Name='/prod/db/endpoint', Value=endpoint_moi, Overwrite=True)

Ứng dụng đọc tham số này thay vì ghi cứng, nên failover xong là tự trỏ đúng chỗ.

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

• A. Custom endpoint + CloudTrail phát hiện sự cố CSDL — sai nguồn sự kiện: CloudTrail ghi lời gọi API, nó không báo cáo sự cố hạ tầng của RDS. Sự kiện sức khoẻ CSDL đến từ RDS events. Ngoài ra Aurora custom endpoint không dùng được xuyên Region.
• B. SNS đăng ký "RDS failure notifications từ CloudTrail" — cùng lỗi với A, và còn ghép sai hai dịch vụ: RDS Event Notifications đẩy thẳng vào SNS, không đi qua CloudTrail. Lưu endpoint trong Secrets Manager thì làm được nhưng đó là dịch vụ cho bí mật, không phải cho cấu hình công khai như hostname.
• C. Lambda sửa template CloudFormation để promote replica — cực kỳ mong manh: sửa template rồi cập nhật stack là thao tác chậm (hàng phút tới hàng chục phút), có thể thất bại giữa chừng, và cập nhật stack trong lúc đang có sự cố là lúc tệ nhất để chạy một thao tác có thể rollback.

Ghi nhớ

Ba mảnh của mọi kịch bản DR tự động: phát hiện (EventBridge + RDS events, không phải CloudTrail), hành động (promote), và cập nhật đường dẫn (Parameter Store hoặc Route 53 CNAME). Bỏ mảnh thứ ba là failover thành công về mặt kỹ thuật nhưng ứng dụng vẫn chết.

Ghi chú thêm: với Aurora Global Database, có sẵn managed planned failover và cross-Region failover nhanh hơn hẳn cách tự dựng bằng Lambda — nếu được chọn kiến trúc từ đầu thì đó là hướng nên đi.

Đáp án

A và E.

• E — Dùng AWS WAF geo match statement liệt kê các quốc gia cần chặn.
• A — Dùng AWS WAF IP set statement khai các địa chỉ IP được phép đi qua.

Vì sao đúng

Yêu cầu là chặn theo quốc gia nhưng vẫn cho lập trình viên từ xa vào dù họ ở trong các quốc gia đó. Nghĩa là cần hai luật và thứ tự ưu tiên đúng:

Rule 1 (ưu tiên 0): IP set match  → ALLOW   ← lập trình viên đi qua trước
Rule 2 (ưu tiên 1): Geo match     → BLOCK   ← phần còn lại của các nước đó bị chặn

AWS WAF đánh giá luật theo thứ tự ưu tiên và dừng ở luật khớp đầu tiên có hành động dứt khoát. Đặt IP set allow trước geo block chính là cách diễn đạt "chặn cả nước, trừ những người này".

WAF cũng là công cụ đúng cho phần còn lại của đề: nó có rate-based rule chống HTTP flood, và AWS Managed Rules có nhóm AWSManagedRulesBotControlRuleSet để chặn bot.

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

• B và C. "ALB geo match statement" / "ALB IP set statement" — không tồn tại. ALB định tuyến theo host, path, header, query, phương thức HTTP và IP nguồn ở mức rule cơ bản, nhưng không có khái niệm "geo match" hay "IP set" — đó là thuật ngữ của AWS WAF. Muốn có thì gắn WAF web ACL vào ALB, tức là quay về A và E.
• D. NACL chặn theo quốc gia — NACL làm việc với dải CIDR, không biết quốc gia là gì. Muốn chặn cả một quốc gia bằng NACL thì phải liệt kê hàng nghìn dải IP và cập nhật liên tục, trong khi NACL giới hạn 20 rule (nâng tối đa lên 40). Bất khả thi về mặt kỹ thuật.

Ghi nhớ

Chọn tầng chặn cho đúng: | Tầng | Chặn được theo | Ghi chú | |---|---|---| | WAF | quốc gia, IP set, mẫu chuỗi, tần suất, bot | tầng 7, linh hoạt nhất | | Security group | IP/cổng — chỉ allow | không có rule deny | | NACL | IP/cổng, có deny | giới hạn số rule, không biết quốc gia | | Shield Advanced | DDoS tầng 3/4/7 | có đội ứng cứu |

Và nhớ nguyên tắc thứ tự trong WAF: luật cho phép ngoại lệ phải có priority nhỏ hơn luật chặn diện rộng.

Đáp án

B và D.

• B — Aurora Global Database ở hai Region; sự cố thì promote Region phụ lên nhận ghi.
• D — Triển khai ứng dụng ở hai Region với bản ghi Route 53 failover trỏ tới ALB mỗi bên, kèm health check.

Vì sao đúng

Hai con số định hình mọi thứ: RPO 2 giờ và RTO 10 phút.

Vế dữ liệu (B). RPO 2 giờ là khá thoải mái, nhưng RTO 10 phút thì không thể khôi phục từ backup. Aurora Global Database sao chép ở tầng lưu trữ với độ trễ thường dưới 1 giây (RPO thực tế tốt hơn nhiều so với 2 giờ yêu cầu), và managed failover hoàn tất trong khoảng một phút — dư sức cho RTO 10 phút.

Vế định tuyến (D). Failover routing đúng cho mô hình DR: Region chính nhận toàn bộ traffic, health check phát hiện hỏng thì DNS trỏ sang Region phụ. Đề chỉ nói tới khôi phục sau thảm hoạ, không nói tới độ trễ hay phục vụ toàn cầu — nên đây là mô hình đúng, và cũng rẻ hơn active/active.

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

• A. Hai cụm Aurora riêng đồng bộ bằng AWS DMS — DMS làm được nhưng là công cụ di trú/sao chép logic: chậm hơn, có độ trễ lớn hơn, phải nuôi replication instance, và dễ tụt hậu khi tải ghi cao. Aurora Global Database sao chép ngay ở tầng lưu trữ, tốt hơn hẳn cho DR.
• C. Latency-based routing — bẫy hợp lý nhất. Latency routing dùng khi muốn phục vụ người dùng toàn cầu với độ trễ thấp — tức là cả hai Region đều active. Nhưng đề mô tả một kịch bản DR có RPO/RTO, và với Aurora Global Database thì Region phụ chỉ đọc được, không nhận ghi. Gửi traffic ghi tới đó trong lúc mọi thứ bình thường sẽ hỏng.
• E. Aurora multi-master xuyên Region, active-active — không tồn tại: Aurora multi-master chỉ hoạt động trong một Region (và đã bị ngừng cho Aurora MySQL). Không có chế độ active-active ghi được ở nhiều Region cho Aurora.

Ghi nhớ

RTO 10 phút + RPO 2 giờ nằm đúng ô warm standby, và Aurora Global Database + Route 53 failover chính là hiện thực chuẩn của nó. Và nhớ: latency routing = active/active; failover routing = active/passive.

Đáp án

D — Tạo log destination ở tài khoản trung tâm, subscription trỏ vào đó; tạo Kinesis Data Firehose đăng ký log destination, đích của Firehose là Amazon S3.

Vì sao đúng

Ba yêu cầu: tập trung, an toàn, lưu trữ tiết kiệm.

Cơ chế tập trung. CloudWatch Logs có khái niệm destination dành riêng cho chuyển log xuyên tài khoản:

// Destination policy ở tài khoản trung tâm — cho phép cả OU gửi vào
{"Effect": "Allow",
 "Principal": {"AWS": "*"},
 "Action": "logs:PutSubscriptionFilter",
 "Resource": "arn:aws:logs:ap-southeast-1:<trung-tam>:destination:log-tap-trung",
 "Condition": {"StringEquals": {"aws:PrincipalOrgID": "o-xxxxxxxx"}}}

Điều kiện aws:PrincipalOrgID lo vế an toàn: chỉ tài khoản trong tổ chức gửi được.

Vì sao S3 (vế tiết kiệm). Mục đích là lưu trữ (archiving). S3 rẻ hơn hẳn mọi lựa chọn còn lại, và lifecycle policy chuyển tiếp sang Glacier/Deep Archive còn rẻ hơn nữa.

Vì sao Firehose nối thẳng, không qua Data Streams. Firehose đăng ký trực tiếp vào log destination được; nó tự gom lô, tự nén, tự ghi. Không cần shard, không cần checkpoint, không cần consumer tự viết.

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

• A. …Firehose ghi vào Amazon EFS — EFS là hệ thống tệp NFS, không phải đích hợp lệ của Firehose, và đắt hơn S3 nhiều lần cho việc lưu trữ. Sai cả về khả năng lẫn về chi phí.
• B. …Firehose ghi vào Amazon Redshift — Redshift là đích hợp lệ, nhưng nó là kho dữ liệu phân tích, đòi cụm chạy liên tục. Dùng nó để lưu trữ log là đắt hơn S3 nhiều bậc. Cả A và B còn thừa một tầng Kinesis Data Streams ở giữa mà không cần.
• C. Lambda chép log sang EFS — tự viết consumer (phải tự xử lý lô, lỗi, thử lại), đẩy vào một hệ lưu trữ đắt tiền và không hợp cho archive.

Ghi nhớ

Ba đích hợp lệ của subscription filter: Kinesis Data Streams, Kinesis Data Firehose, Lambda. Và cho log tập trung nhiều tài khoản, mẫu chuẩn là: subscription filter → log destination (tài khoản trung tâm) → Firehose → S3 → lifecycle sang Glacier, bảo vệ bằng điều kiện aws:PrincipalOrgID.

Đáp án

C — Dùng stack export ở template của đội CSDL và Fn::ImportValue ở template của đội ứng dụng web.

Vì sao đúng

Ràng buộc quan trọng nhất: hai đội muốn giữ quy trình review và vòng đời riêng biệt của mình. Nghĩa là hai stack phải độc lập — deploy riêng, cập nhật riêng, không stack nào "sở hữu" stack kia.

Cross-stack reference đúng cho mô hình này:

# Stack CSDL — công bố giá trị
Outputs:
  EndpointCSDL:
    Value: !GetAtt CumCSDL.Endpoint.Address
    Export:
      Name: !Sub "${AWS::StackName}-endpoint-csdl"

# Stack ứng dụng — tiêu thụ giá trị
Resources:
  MayChuUngDung:
    Properties:
      Environment:
        - Name: DB_HOST
          Value: !ImportValue csdl-prod-endpoint-csdl

Kèm theo một cơ chế bảo vệ rất đáng giá: CloudFormation không cho xoá hoặc sửa một export đang được stack khác import. Đội CSDL vô tình xoá endpoint thì lệnh cập nhật thất bại ngay, thay vì âm thầm làm hỏng ứng dụng.

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

• B. Nested stack — tạo quan hệ cha–con: stack cha sở hữu và điều khiển vòng đời của stack con. Xoá cha là xoá con. Điều này phá vỡ thẳng yêu cầu "mỗi đội giữ vòng đời riêng" — một đội sẽ trở thành cấp dưới của đội kia.
• D. Truyền tên và ID tài nguyên qua input parameter — làm được nhưng thủ công và mong manh: phải chép giá trị bằng tay ở mỗi lần deploy, không có ràng buộc nào ngăn đội CSDL đổi hoặc xoá tài nguyên, và không có cách nào biết ai đang phụ thuộc vào cái gì. Export/import làm đúng việc đó một cách tự động và có bảo vệ.
• A. StackSets — công cụ triển khai một template ra nhiều tài khoản/Region. Nó không giải quyết bài toán chia sẻ giá trị giữa hai template khác nhau. Sai công cụ.

Ghi nhớ

Giới hạn cần biết của export: tên export là duy nhất trong một tài khoản + Region, và không import xuyên Region hay xuyên tài khoản được. Cần điều đó thì dùng Parameter Store hoặc AWS RAM thay thế.