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

Đáp án

A — Dùng ConsistentRead = true khi thực hiện GetItem.

Vì sao đúng

Bối cảnh: giao dịch tần suất cao, nhiều lệnh cập nhật cùng một item, và ứng dụng phải luôn đọc được giá trị mới nhất.

DynamoDB có hai mô hình nhất quán khi ĐỌC:

Nguyên nhân của việc đọc phải bản cũ: DynamoDB sao chép dữ liệu sang ba AZ, và việc sao chép mất khoảng một phần nghìn giây. Đọc mặc định có thể rơi vào bản sao chưa kịp cập nhật.

Đặt ConsistentRead = true buộc DynamoDB đọc từ bản sao chính:

kq = table.get_item(Key={'trade_id': 't-123'}, ConsistentRead=True)

Điểm quyết định của câu hỏi: ConsistentRead là tham số của thao tác ĐỌC. Nó chỉ có ở GetItem, Query, Scan, BatchGetItem và TransactGetItems.

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

• B, C, D — đặt ConsistentRead trên PutItem hoặc UpdateItem — thao tác ghi không có tham số này. Lệnh ghi của DynamoDB luôn nhất quán mạnh theo bản chất: ghi xong là đã được cam kết, không có khái niệm "ghi eventually consistent". Đưa ConsistentRead vào lời gọi ghi thì SDK báo lỗi tham số không hợp lệ.
• (B còn sai thêm ở chỗ đặt false, tức là chọn đúng thứ đề đang muốn tránh.)

Ghi nhớ

Ba điều cần thuộc về nhất quán trong DynamoDB:

1. Ghi luôn nhất quán mạnh — không có lựa chọn nào khác
2. Đọc mặc định là eventually consistent — phải khai ConsistentRead=True nếu cần bản mới nhất
3. Đọc từ GSI LUÔN là eventually consistent — không ép nhất quán mạnh được, bất kể tham số

Điều thứ ba là bẫy rất hay gặp: nhiều người đặt ConsistentRead=True khi query một GSI và tưởng đã an toàn — nhưng DynamoDB từ chối tham số đó trên GSI. Cần đọc nhất quán mạnh thì phải dùng bảng gốc hoặc LSI.

Với bài toán tài chính trong đề, nên kết hợp thêm conditional write (optimistic locking) để tránh mất cập nhật khi hai giao dịch ghi đồng thời.

Đáp án

A — Tạo IAM role có quyền S3 ở Account B và đặt Account A làm trusted entity; tạo một role khác (instance profile) ở Account A gắn vào EC2.

Vì sao đúng

Truy cập chéo tài khoản trong IAM luôn cần hai vế đặt đúng chỗ, và đây là chỗ dễ nhầm nhất:

Chiều đi là: EC2 ở Account A cần đi vào Account B để đọc S3. Nên role được assume phải nằm ở Account B, và trust policy của nó phải nêu tên Account A.

EC2 (Account A) → dùng instance profile → sts:AssumeRole
                → nhận thông tin xác thực tạm thời của role ở Account B
                → đọc S3 trong Account B

Vì đây là dữ liệu PII, cách này còn có ưu điểm về kiểm toán: mọi lần assume role được ghi trong CloudTrail của cả hai tài khoản, và quyền có thể thu hồi tức thì bằng cách sửa trust policy.

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

• D. Đặt trust ở Account A, cho Account B là trusted entity — ngược chiều hoàn toàn. Làm vậy nghĩa là Account B được phép vào Account A, đúng ngược với việc cần làm.
• C. Chỉ thêm bucket policy ở Account B — đây là bẫy đáng chú ý, vì nó gần đúng: bucket policy có thể cấp quyền cho principal ở tài khoản khác. Nhưng phương án chỉ nói "cho phép truy cập từ EC2 instance ở Account A" mà không nêu principal cụ thể nào — và EC2 instance không phải một IAM principal có ARN để cấp quyền trực tiếp. Phải là role của instance, và khi ấy vẫn cần identity policy ở phía A. Thiếu vế.
• B. Sao chép AMI sang Account B rồi chạy EC2 ở đó — né tránh vấn đề thay vì giải quyết. Nó buộc di chuyển cả tầng ứng dụng sang tài khoản khác, phá vỡ ranh giới phân tách tài khoản mà công ty đã dựng, và không giải quyết được nếu ứng dụng cần ở lại Account A vì lý do khác.

Ghi nhớ

Câu thần chú cho truy cập chéo tài khoản: trust policy nằm ở nơi bạn muốn ĐẾN, permission policy nằm ở nơi bạn ĐI TỪ.

Thiếu vế nào cũng ra AccessDenied, và thông báo lỗi không cho biết thiếu vế nào — nên khi gỡ lỗi phải kiểm cả hai.

Với S3 chéo tài khoản còn một chi tiết nữa: nếu Account A ghi object vào bucket của Account B, hãy đặt s3:x-amz-acl: bucket-owner-full-control hoặc bật Bucket owner enforced để Account B thực sự sở hữu object nhận được.

Đáp án

A — Cấu hình ứng dụng lấy biến và thông tin xác thực từ AWS Systems Manager Parameter Store, dùng đường dẫn phân cấp cho từng môi trường.

Vì sao đúng

Đề cần lưu nhiều loại biến khác nhau (thông tin xác thực API, URL, khoá) cho nhiều môi trường, với thay đổi mã tối thiểu.

Parameter Store với đường dẫn phân cấp là lời giải gọn nhất:

/ung-dung/dev/api-url
/ung-dung/dev/api-key
/ung-dung/staging/api-url
/ung-dung/staging/api-key
/ung-dung/prod/api-url
/ung-dung/prod/api-key

Ứng dụng chỉ cần biết tên môi trường — phần còn lại giống hệt nhau ở mọi nơi:

moi_truong = os.environ['MOI_TRUONG']          # biến duy nhất khác nhau
tham_so = ssm.get_parameters_by_path(
    Path=f'/ung-dung/{moi_truong}/', WithDecryption=True)

GetParametersByPath lấy toàn bộ nhánh trong một lời gọi — đây là điểm khiến "minimal modifications" thành hiện thực: thêm một biến mới thì chỉ cần tạo tham số, không phải sửa mã và không phải deploy lại.

Kèm theo: dùng SecureString cho thông tin xác thực (mã hoá bằng KMS), phân quyền theo prefix đường dẫn để task ECS của môi trường này không đọc được tham số của môi trường khác, và standard parameter miễn phí.

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

• B. Định nghĩa biến trong ECS task definition — làm được, nhưng mỗi lần đổi một giá trị là phải tạo revision mới của task definition rồi deploy lại service. Với "different environments" thì phải duy trì nhiều bản task definition song song. Nhiều thao tác hơn hẳn, và không mã hoá nếu để dạng biến môi trường thường.
• C. Lưu trong AWS KMS — hiểu sai vai trò: KMS quản lý khoá mã hoá, không lưu giá trị. Bạn không "cất API URL vào KMS" được.
• D. Tệp mã hoá đóng gói cùng ứng dụng — đổi một biến là phải build lại image và deploy lại. Và nó đẻ ra câu hỏi khó nhất: khoá giải mã cất ở đâu? Nếu cũng đóng gói cùng thì việc mã hoá không còn ý nghĩa.

Ghi nhớ

Đề này có cả cấu hình thường lẫn thông tin xác thực và không yêu cầu xoay vòng ⇒ Parameter Store là lựa chọn đúng. Cần xoay vòng mật khẩu CSDL thì mới chuyển sang Secrets Manager.

Đáp án

C — AWS CodeDeploy.

Vì sao đúng

Chi tiết quyết định: cần triển khai lên cả EC2 lẫn máy chủ ảo chạy on-premises.

CodeDeploy là dịch vụ duy nhất trong bốn phương án hỗ trợ on-premises. Nó có ba nền tảng tính toán:

Với máy on-premises, quy trình là: cài CodeDeploy agent, rồi đăng ký instance với CodeDeploy:

aws deploy register-on-premises-instance \
  --instance-name may-chu-noi-bo-01 \
  --iam-session-arn arn:aws:sts::123456789012:assumed-role/CodeDeployRole/may-01
aws deploy add-tags-to-on-premises-instances \
  --instance-names may-chu-noi-bo-01 --tags Key=Moi-truong,Value=production

Deployment group nhắm vào chúng bằng tag, giống hệt cách nhắm EC2 — nên một quy trình duy nhất phủ cả hai môi trường.

Kèm theo là các tính năng triển khai đầy đủ: appspec.yml với lifecycle hook, rolling hoặc blue/green, và rollback tự động theo CloudWatch alarm.

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

• A. Elastic Beanstalk — nền tảng PaaS chỉ chạy trong AWS (EC2, container). Nó không triển khai ra máy chủ on-premises được.
• B. CodeBuild — dịch vụ build và test: biên dịch mã, chạy kiểm thử, tạo artifact. Nó không triển khai gì cả.
• D. CodePipeline — dịch vụ điều phối, nối các stage lại với nhau. Ở stage deploy nó gọi CodeDeploy (hoặc Beanstalk, ECS, CloudFormation). Nó là nhạc trưởng, không phải nhạc công. (Trong thực tế bạn sẽ dùng cả hai: CodePipeline điều phối, CodeDeploy thực thi.)

Ghi nhớ

Vai trò trong bộ công cụ Code: | Dịch vụ | Việc | Ra được on-premises? | |---|---|---| | CodeCommit | lưu mã | — | | CodeBuild | build, test | ❌ | | CodeDeploy | triển khai | ✅ | | CodePipeline | điều phối | qua CodeDeploy |

Ba điều kiện để CodeDeploy chạy được với máy on-premises: cài agent, đăng ký instance với IAM user hoặc role, và máy phải ra được endpoint công khai của CodeDeploy (codedeploy và codedeploy-commands-secure).

Đáp án

D — State "HelloWorld" kiểu Task với thuộc tính Resource trỏ tới ARN của một hàm Lambda.

Vì sao đúng

Trong Amazon States Language, Task state là loại state duy nhất thực hiện công việc thật — nó gọi ra một tài nguyên bên ngoài để làm việc gì đó.

Điểm mấu chốt là thuộc tính Resource: nó cho biết ai làm công việc đó.

"HelloWorld": {
  "Type": "Task",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:function:HelloFunction",  ← ĐƠN VỊ CÔNG VIỆC
  "Next": "AfterHelloWorldState"
}

Resource trỏ được tới rất nhiều thứ: hàm Lambda, ECS task, activity worker, hoặc hơn 200 dịch vụ AWS qua tích hợp SDK (arn:aws:states:::aws-sdk:dynamodb:putItem).

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

• C. "No-op" kiểu Task nhưng không có Resource, chỉ có Result — đây là bẫy tinh vi nhất, và có hai điểm sai. Thứ nhất, Task state bắt buộc phải có Resource — thiếu nó thì template không hợp lệ. Thứ hai, Result cố định là đặc trưng của Pass state, loại state chỉ truyền dữ liệu qua mà không làm việc gì. Đây gần như chắc chắn là một Pass state bị ghi nhầm Type — và dù thế nào thì nó cũng không đại diện cho một đơn vị công việc.
• A. Wait state — tạm dừng state machine trong một khoảng thời gian hoặc tới một thời điểm. Nó không làm gì cả, chỉ chờ.
• B. Fail state — kết thúc state machine với trạng thái thất bại, kèm mã lỗi và nguyên nhân. Cũng không thực hiện công việc nào.

Ghi nhớ

Tám loại state của Amazon States Language: | State | Vai trò | |---|---| | Task | thực hiện công việc — cần Resource | | Choice | rẽ nhánh theo điều kiện | | Wait | chờ | | Parallel | chạy nhiều nhánh song song | | Map | lặp qua một mảng | | Pass | truyền dữ liệu qua, có thể chèn Result cố định | | Succeed | kết thúc thành công | | Fail | kết thúc thất bại |

Mẹo nhận dạng nhanh: chỉ Task có Resource, và chỉ Task thực sự làm việc. Các state khác đều là điều khiển luồng.

Đáp án

B — Dùng API TransactWriteItems của DynamoDB Transactions.

Vì sao đúng

Yêu cầu rất rõ: cập nhật hai bảng cùng lúc theo kiểu all-or-nothing — hoặc cả hai thành công, hoặc không bảng nào bị đụng tới.

TransactWriteItems đảm bảo đúng tính chất ACID đó:

dynamodb.transact_write_items(TransactItems=[
    {'Update': {
        'TableName': 'players',
        'Key': {'player_id': {'S': 'p-123'}},
        'UpdateExpression': 'SET coins = coins - :gia',
        'ConditionExpression': 'coins >= :gia',        # không đủ tiền → HỦY TẤT CẢ
        'ExpressionAttributeValues': {':gia': {'N': '100'}}}},
    {'Update': {
        'TableName': 'items',
        'Key': {'item_id': {'S': 'i-456'}},
        'UpdateExpression': 'SET so_luong = so_luong - :n',
        'ConditionExpression': 'so_luong > :khong',
        'ExpressionAttributeValues': {':n': {'N': '1'}, ':khong': {'N': '0'}}}}
])

Bất kỳ điều kiện nào không thoả — người chơi không đủ xu, hoặc vật phẩm đã hết — thì toàn bộ giao dịch bị huỷ và không có thay đổi nào được ghi. Đúng ngữ nghĩa "all-or-nothing".

Giới hạn cần biết: tối đa 100 thao tác hoặc 4 MB mỗi giao dịch, và mỗi item chỉ xuất hiện một lần. Chi phí gấp đôi so với ghi thường (2 WCU cho mỗi 1 KB) — cái giá của tính nguyên tử.

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

• D. BatchWriteItem — bẫy chính, và khác biệt rất quan trọng: BatchWriteItem KHÔNG phải là giao dịch. Nó chỉ gộp tối đa 25 thao tác vào một lời gọi để giảm round trip; từng thao tác thành công hoặc thất bại độc lập, và những thao tác không xử lý được sẽ trả về trong UnprocessedItems. Kết quả có thể là bảng players bị trừ xu mà bảng items không được cập nhật — chính xác điều đề cấm. Nó cũng không hỗ trợ ConditionExpression.
• A và C. DynamoDB Streams để đồng bộ hai bảng — mô hình eventual consistency: bảng thứ nhất được ghi trước, sau đó Lambda mới cập nhật bảng thứ hai. Trong khoảng giữa, dữ liệu không nhất quán. Và nếu Lambda hỏng thì hai bảng lệch nhau vĩnh viễn mà không có cơ chế hoàn tác nào.

Ghi nhớ

Câu thần chú: "all-or-nothing" hoặc "simultaneously" trong đề ⇒ Transactions, không phải Batch.

Đáp án

D — Cấu hình VPC endpoint cho DynamoDB.

Vì sao đúng

Yêu cầu: EC2 nói chuyện với DynamoDB không đi qua Internet công cộng.

VPC endpoint là cơ chế đúng: nó tạo đường đi hoàn toàn trong mạng lưng của AWS. DynamoDB (cùng với S3) dùng loại gateway endpoint:

aws ec2 create-vpc-endpoint --vpc-id vpc-0abc123 \
  --service-name com.amazonaws.ap-southeast-1.dynamodb \
  --route-table-ids rtb-0def456

Gateway endpoint hoạt động bằng cách thêm một route vào route table, trỏ dải IP của DynamoDB về endpoint thay vì ra Internet Gateway. Traffic không bao giờ rời khỏi mạng AWS.

Ba ưu điểm ngoài vế bảo mật:

• Miễn phí — gateway endpoint không tính phí giờ chạy lẫn phí xử lý dữ liệu
• Bỏ được NAT gateway cho phần traffic này, tiết kiệm đáng kể
• Có endpoint policy để giới hạn được phép gọi bảng nào

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

• A. Internet Gateway — làm ngược lại điều đề yêu cầu: IGW chính là cánh cửa ra Internet công cộng.
• B. NAT Gateway — cũng đi ra Internet, chỉ là giấu IP nguồn. Traffic vẫn rời khỏi mạng AWS, vẫn đi qua hạ tầng công cộng. Và NAT gateway tính phí theo giờ cộng phí xử lý mỗi GB — đắt hơn hẳn endpoint miễn phí.
• C. Định tuyến traffic DynamoDB qua mạng doanh nghiệp bằng VPN — vô lý về mặt kiến trúc: nó đưa traffic ra khỏi AWS, về trung tâm dữ liệu của công ty, rồi lại quay ngược ra Internet để tới DynamoDB. Vòng vèo, chậm, tốn kém, và cuối cùng vẫn đi qua Internet công cộng.

Ghi nhớ

Hai loại VPC endpoint — phân biệt cho rõ: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ | chỉ S3 và DynamoDB | hầu hết các dịch vụ AWS còn lại | | Cơ chế | thêm route vào route table | tạo ENI có IP riêng trong subnet | | Chi phí | miễn phí | tính theo giờ + theo GB | | Từ on-premises | ❌ không dùng được | ✅ dùng qua VPN/Direct Connect | | Security group | không áp dụng | áp dụng |

Nhớ nhanh: S3 và DynamoDB có gateway endpoint miễn phí — hãy luôn bật chúng. Mọi dịch vụ khác dùng interface endpoint và có tính phí.

Đáp án

D — Dùng cờ --dry-run của AWS CLI.

Vì sao đúng

Cần kiểm tra quyền mà không thực sự thực hiện hành động. Đó chính xác là mục đích của --dry-run:

aws ec2 terminate-instances --instance-ids i-1234567890abcdef0 \
  --dry-run --profile developer

AWS kiểm tra đầy đủ quyền rồi trả về một trong hai kết quả, và cả hai đều mang thông tin:

Với tình huống trong đề, kết quả mong đợi là UnauthorizedOperation — xác nhận developer không huỷ được instance.

Điểm quan trọng: không có tài nguyên nào bị đụng tới. Đây là cách duy nhất trong bốn phương án kiểm tra được quyền huỷ instance mà không có nguy cơ huỷ nhầm một instance thật.

Lưu ý: --dry-run chủ yếu được EC2 và một số dịch vụ liên quan hỗ trợ; không phải mọi API của AWS đều có.

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

• A. Tạo một EC2 giả rồi thử xoá — có thể làm được nhưng rủi ro và tốn kém: tốn tiền cho instance, tốn thời gian, và tệ nhất là nếu quyền bị cấu hình sai thì bạn vừa xoá thật một tài nguyên. Trong môi trường production, một lệnh gõ nhầm ID là thảm hoạ.
• C. "Cờ --test của AWS CLI" — không tồn tại. Cờ đúng là --dry-run.
• B. "Lấy policy qua EC2 metadata service rồi dùng IAM policy simulator" — hai lỗi. Metadata service chỉ trả về thông tin xác thực tạm thời của instance profile, không trả về nội dung policy. Và IAM Policy Simulator là công cụ hợp lệ để kiểm tra quyền — nhưng nó không cần metadata service để hoạt động; bạn chọn thẳng user hoặc role trong giao diện. Phương án ghép hai thứ không liên quan.

Ghi nhớ

Ba cách kiểm tra quyền IAM một cách an toàn: | Công cụ | Đặc điểm | |---|---| | --dry-run | kiểm tra thật với danh tính thật, không thực thi | | IAM Policy Simulator | mô phỏng nhiều action cùng lúc, không cần thông tin xác thực thật | | aws sts get-caller-identity | xác nhận đang dùng danh tính nào |

Cặp get-caller-identity + --dry-run là quy trình chuẩn khi làm việc với nhiều profile: xác nhận mình là ai, rồi thử quyền mà không gây hậu quả.

Đáp án

B — Phải thêm rule outbound cho NACL để phản hồi gửi được về client trên dải ephemeral port.

Vì sao đúng

Cấu hình hiện tại:

• Security group: inbound HTTP từ 0.0.0.0/0 ✅, outbound giữ mặc định (cho phép tất cả) ✅
• NACL tuỳ chỉnh: inbound HTTP từ 0.0.0.0/0 ✅, outbound giữ mặc định — và đây là chỗ hỏng

Điểm mấu chốt: NACL tuỳ chỉnh mặc định TỪ CHỐI mọi thứ ở cả hai chiều. Khác hẳn NACL mặc định của VPC (vốn cho phép tất cả). Đề nói "custom Network ACL" và "retained any default outbound rules" — với NACL tuỳ chỉnh, "mặc định" nghĩa là deny all.

Và vì NACL là stateless, phản hồi phải được cho phép tường minh:

Client:54321  ──→  Server:80      ← rule inbound cho phép ✅
Client:54321  ←──  Server:80      ← rule OUTBOUND phải cho phép cổng 1024–65535 ❗

Phản hồi HTTP không đi ra từ cổng 80 — nó đi tới cổng nguồn của client, nằm trong dải ephemeral port. Nên rule cần thêm là:

Rule 100  Outbound  TCP  1024-65535  0.0.0.0/0  ALLOW

Dải ephemeral port khác nhau theo hệ điều hành: Linux thường 32768–60999, Windows 49152–65535, ELB và Lambda 1024–65535. Cấu hình an toàn là mở 1024–65535.

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

• D. "Cần thêm outbound rule trên security group cho cổng HTTP" — sai hai chỗ. Security group stateful nên phản hồi tự động được phép; và outbound mặc định của security group vốn đã cho phép tất cả.
• C. "Cần cấu hình outbound cả trên security group lẫn NACL" — nửa đúng nửa thừa: chỉ NACL cần, security group thì không.
• A. "Cấu hình đã hoàn chỉnh" — trái với triệu chứng: request đi vào được nhưng phản hồi bị NACL chặn ở chiều ra.

Ghi nhớ

Hai điều dễ nhầm nhất và đều xuất hiện trong câu này: NACL tuỳ chỉnh mặc định chặn hết, và stateless nghĩa là phải mở ephemeral port cho chiều về.

Đáp án

A — Đưa các tệp .config vào thư mục .ebextensions/ ở gốc mã nguồn.

Vì sao đúng

Yêu cầu: thay việc SSH vào instance gõ lệnh bằng một cơ chế cấu hình tự động áp dụng.

.ebextensions/ là cơ chế mở rộng chính thức của Elastic Beanstalk. Các tệp .config trong đó được áp dụng tự động ở mỗi lần deploy và mỗi lần instance mới được tạo — nên cấu hình luôn nhất quán, kể cả khi Auto Scaling thêm máy lúc 3 giờ sáng.

# .ebextensions/01-cau-hinh.config
packages:
  yum:
    git: []
    htop: []

files:
  "/etc/nginx/conf.d/tuy-chinh.conf":
    mode: "000644"
    owner: root
    content: |
      client_max_body_size 50M;

option_settings:
  aws:elasticbeanstalk:application:environment:
    JAVA_OPTS: "-Xmx1024m"

container_commands:
  01_migrate:
    command: "java -jar app.jar migrate"
    leader_only: true          # chỉ chạy trên MỘT instance

Ba quy tắc về vị trí và tên: thư mục phải tên đúng .ebextensions, nằm ở gốc gói mã nguồn, và tệp phải có đuôi .config (nội dung YAML hoặc JSON). Các tệp chạy theo thứ tự bảng chữ cái — đó là lý do người ta hay đánh số ở đầu tên.

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

• C. "Triển khai một CloudFormation wrapper" — làm được nhưng phức tạp hơn nhiều lần, và thừa: Beanstalk vốn đã chạy trên CloudFormation bên dưới. Muốn thêm tài nguyên CloudFormation thì cũng khai ngay trong .ebextensions bằng khoá Resources.
• B. "Dùng AWS Lambda hook" — Beanstalk không có khái niệm Lambda hook. Cơ chế mở rộng của nó là .ebextensions và platform hooks (script đặt trong .platform/hooks/ cho Amazon Linux 2 trở lên).
• D. "Dùng SSM Parameter Store làm đầu vào cho cấu hình Beanstalk" — Parameter Store rất hợp để lưu giá trị (mật khẩu, endpoint), và bạn có thể tham chiếu chúng. Nhưng nó không phải cơ chế cấu hình instance: nó không cài gói, không tạo tệp, không chạy lệnh.

Ghi nhớ

Các khoá dùng được trong tệp .config: | Khoá | Làm gì | |---|---| | packages | cài gói (yum, rpm, apt, python, rubygems) | | files | tạo tệp trên instance | | commands | chạy lệnh trước khi ứng dụng được cài | | container_commands | chạy lệnh sau khi cài, trước khi deploy — dùng leader_only: true cho migration | | option_settings | cấu hình môi trường Beanstalk | | Resources | thêm tài nguyên CloudFormation tuỳ ý |

leader_only: true là chi tiết quan trọng nhất trong nhóm này: nó đảm bảo migration CSDL chạy đúng một lần, không phải trên mọi instance.