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

Đáp án

C — Định nghĩa tệp buildspec.yml ở thư mục gốc.

Vì sao đúng

Câu này kiểm tra hai thứ cùng lúc: đúng tệp và đúng vị trí.

buildspec.yml là tệp cấu hình của CodeBuild, khai toàn bộ các bước build:

version: 0.2
phases:
  install:
    runtime-versions: {java: corretto17}
  pre_build:
    commands:
      - echo "Chuẩn bị build"
  build:
    commands:
      - mvn clean package
  post_build:
    commands:
      - echo "Build xong"
artifacts:
  files: [target/*.jar]
cache:
  paths: ['/root/.m2/**/*']

Vị trí phải là thư mục gốc của gói mã nguồn. CodeBuild tìm ở đó theo mặc định — đặt chỗ khác thì build thất bại với YAML_FILE_ERROR: YAML file does not exist.

(Đổi vị trí được, nhưng phải khai tường minh trong cấu hình project: --buildspec build/buildspec.yml.)

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

• A. buildspec.yml trong thư mục codebuild/ — đúng tệp, sai vị trí. CodeBuild không tự tìm ở thư mục con.
• D. appspec.yml ở thư mục gốc — sai dịch vụ. appspec.yml là tệp của CodeDeploy: nó khai files, permissions và lifecycle hook cho việc triển khai, không phải build.
• B. appspec.yml trong codebuild/ — sai cả hai vế.

Ghi nhớ

Hai tệp cấu hình hay bị lẫn nhất trong bộ Code của AWS: | | buildspec.yml | appspec.yml | |---|---|---| | Dịch vụ | CodeBuild | CodeDeploy | | Nội dung | phases, artifacts, cache, env | files, permissions, hooks | | Vị trí | gốc (đổi được qua cấu hình) | gốc (bắt buộc) |

Bốn phase của buildspec, theo thứ tự:

install → pre_build → build → post_build

Và hai khối trong mỗi phase: | Khối | Chạy khi | |---|---| | commands | các lệnh trước thành công | | finally | luôn luôn, kể cả sau lỗi — dùng để dọn dẹp |

Vài khoá hữu ích khác: cache (tăng tốc build đáng kể với phụ thuộc lớn), env.parameter-store và env.secrets-manager (lấy bí mật mà không ghi cứng), reports (báo cáo kết quả test).

Đáp án

A — 30 WCU.

Vì sao đúng

Phép tính WCU của DynamoDB có hai bước:

Bước 1 — làm tròn kích thước item lên bội số của 1 KB:

4,5 KB  →  làm tròn lên  →  5 KB  (= 5 đơn vị 1 KB)

Bước 2 — nhân với số lần ghi mỗi giây:

5 WCU × 6 lần/giây = 30 WCU

Điểm dễ sai nhất: WCU dùng đơn vị 1 KB, không phải 4 KB như RCU. Hai công thức không đối xứng, và đề thi khai thác điều đó rất nhiều.

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

• B. 24 — có lẽ do làm tròn 4,5 KB xuống 4 KB (4 × 6 = 24). Luôn làm tròn LÊN, không bao giờ xuống.
• D. 15 — có thể do nhầm sang cách tính của RCU eventually consistent (chia đôi).
• C. 46 — không tương ứng với phép tính nào hợp lệ.

Ghi nhớ

Hai công thức cần thuộc, và điểm khác biệt cốt lõi:

WCU — đơn vị 1 KB:

Ghi thường        : ceil(size / 1 KB)       × số_lần_ghi
Transactional ghi : ceil(size / 1 KB) × 2   × số_lần_ghi

RCU — đơn vị 4 KB:

Strongly consistent  : ceil(size / 4 KB)       × số_lần_đọc
Eventually consistent: ceil(size / 4 KB) ÷ 2   × số_lần_đọc
Transactional read   : ceil(size / 4 KB) × 2   × số_lần_đọc

Ba điểm dễ sai nhất:

1. RCU dùng 4 KB, WCU dùng 1 KB — hai con số khác nhau
2. Luôn làm tròn LÊN — item 4,1 KB tốn như item 5 KB (WCU) hoặc 8 KB (RCU)
3. Chỉ RCU có bản eventually consistent rẻ một nửa — WCU không có

(Với chế độ on-demand, bạn không phải tính RCU/WCU — DynamoDB tự co giãn và tính tiền theo request thực tế. Nhưng công thức vẫn cần cho chế độ provisioned và cho đề thi.)

Đáp án

A — Đọc header X-Forwarded-For ở phía backend.

Vì sao đúng

Triệu chứng đúng như mô tả kinh điển: mọi IP ghi nhận được đều là IP của ALB.

Nguyên nhân nằm ở kiến trúc: ALB là proxy ở tầng 7. Nó kết thúc kết nối TCP của client và mở một kết nối mới tới instance. Nên từ góc nhìn của instance, nguồn kết nối chính là ALB.

X-Forwarded-For là header chuẩn (RFC 7239) mà ALB tự động thêm vào mỗi request, mang IP gốc của client:

X-Forwarded-For: 203.0.113.45

Nếu request đi qua nhiều proxy, header tích luỹ theo thứ tự:

X-Forwarded-For: 203.0.113.45, 198.51.100.10, 10.0.0.5
                 ↑ client thật   ↑ proxy 1      ↑ proxy 2

IP đầu tiên là client gốc — đây là quy tắc đọc quan trọng nhất.

ALB thêm ba header cùng lúc, và cả ba đều hữu ích: | Header | Nội dung | |---|---| | X-Forwarded-For | IP gốc của client | | X-Forwarded-Proto | giao thức gốc (http / https) | | X-Forwarded-Port | cổng gốc |

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

• B. X-Forwarded-Proto — mang giao thức (http hoặc https), không mang IP. Hữu ích để biết client dùng HTTPS hay không, nhưng sai câu hỏi.
• C. Sửa frontend để người dùng tự gửi IP của mình — không tin cậy được: client sửa được, giả mạo được, và với client sau NAT thì bản thân họ cũng không biết IP công khai của mình.
• D. Đọc cookie của client — cookie do ứng dụng hoặc load balancer đặt để quản lý phiên (AWSALB cho sticky session). Nó không chứa IP client.

Ghi nhớ

Cách lấy IP client theo loại load balancer: | Loại | Cách | |---|---| | ALB (tầng 7) | header X-Forwarded-For | | NLB (tầng 4) | giữ nguyên IP nguồn với target type instance; hoặc bật Proxy Protocol v2 | | CloudFront | X-Forwarded-For, hoặc header CloudFront-Viewer-Address |

Hai lưu ý thực tế:

• Client giả mạo được X-Forwarded-For — nhưng với ALB thì an toàn, vì ALB ghi đè giá trị client gửi lên
• Với framework web, thường phải bật chế độ tin proxy (server.forward-headers-strategy trong Spring Boot, ProxyFix trong Flask) thì request.remote_addr mới trả về IP thật

Đáp án

B — Hệ thống tiếp tục chạy như hiện tại.

Vì sao đúng

Phân tích các con số trong đề:

Desired capacity : 3
Maximum capacity : 3     ← ĐÃ CHẠM TRẦN
CPU hiện tại     : 80%   (ngưỡng scale: 60%)

Scaling policy muốn thêm instance vì CPU vượt ngưỡng. Nhưng maximum capacity là ranh giới cứng — Auto Scaling không bao giờ vượt qua nó:

Mong muốn : 3 + N
Trần      : 3
Thực tế   : min(3 + N, 3) = 3  →  KHÔNG thêm instance nào

Lịch sử scaling của ASG sẽ ghi lại rõ ràng, đại ý: "Could not scale out because the group is already at its maximum capacity".

Đây là cơ chế bảo vệ có chủ đích: max tồn tại để bạn không bị bất ngờ về chi phí khi scaling policy phản ứng quá đà, hoặc khi có sự cố khiến metric tăng vọt bất thường.

Nhưng nó cũng là một cái bẫy vận hành: hệ thống quá tải mà không tự mở rộng được, và không có cảnh báo nào trừ khi bạn tự đặt. Cách chữa là nâng max, và đặt alarm khi desired chạm max.

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

• A. "Desired lên 4 và maximum cũng lên 4" — Auto Scaling không bao giờ tự động thay đổi maximum capacity. Đó là giá trị bạn khai và chỉ bạn đổi được.
• D. "Desired lên 4 nhưng maximum giữ ở 3" — không hợp lệ về mặt logic: desired không bao giờ vượt quá max. AWS từ chối cấu hình như vậy.
• C. "Hệ thống gửi CloudWatch alarm tới AWS Support" — AWS Support không nhận alarm của bạn. CloudWatch alarm gửi tới các target bạn khai (SNS, Auto Scaling action, EC2 action), không tới AWS.

Ghi nhớ

Ba tham số dung lượng của Auto Scaling group: | Tham số | Vai trò | |---|---| | Minimum | sàn cứng — không bao giờ xuống dưới | | Desired | mức mong muốn hiện tại — scaling policy thay đổi con số này | | Maximum | trần cứng — không bao giờ vượt qua |

Quy tắc: mọi thay đổi đều bị kẹp vào khoảng [min, max].

(Ngoại lệ duy nhất: trong lúc rebalancing giữa các AZ, ASG được phép tạm vượt max thêm 10% hoặc 1 instance — nhưng đó là hành vi nội bộ, không phải do scaling policy.)

Khuyến nghị vận hành: đặt alarm khi GroupDesiredCapacity chạm GroupMaxSize — đó là dấu hiệu hệ thống đang bị chặn khả năng mở rộng, và triệu chứng bên ngoài chỉ là "ứng dụng chậm" mà không rõ lý do.

Đáp án

D và E.

• D — Volume khôi phục từ snapshot đã mã hoá, hoặc bản sao của snapshot đã mã hoá, luôn được mã hoá.
• E — Encryption by default là thiết lập theo REGION. Bật cho một Region thì không tắt được cho từng volume hoặc snapshot trong Region đó.

Vì sao đúng

D — mã hoá lan truyền theo một chiều. Đây là quy tắc rất quan trọng của EBS: trạng thái mã hoá được kế thừa và KHÔNG THỂ đảo ngược:

Volume mã hoá  →  snapshot LUÔN mã hoá
Snapshot mã hoá →  volume tạo từ đó LUÔN mã hoá
Snapshot mã hoá →  copy LUÔN mã hoá (đổi khoá được, nhưng không bỏ mã hoá được)

Nghĩa là một khi dữ liệu đã được mã hoá, không có đường nào đưa nó về trạng thái không mã hoá trong chuỗi snapshot/volume — muốn vậy phải chép dữ liệu ra ngoài ở tầng hệ thống tệp.

E — encryption by default theo Region. Bật một lần cho cả Region:

aws ec2 enable-ebs-encryption-by-default --region ap-southeast-1

Sau đó mọi volume mới trong Region đó đều được mã hoá, và không thể tạo volume không mã hoá — kể cả khi khai Encrypted: false. Đây là guardrail rất mạnh cho tuân thủ.

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

• A. "Snapshot của volume đã mã hoá có thể mã hoá hoặc không" — sai. Theo quy tắc ở trên, snapshot của volume mã hoá LUÔN được mã hoá, không có lựa chọn.
• B. "Có thể mã hoá một volume hoặc snapshot chưa mã hoá bằng KMS SDK" — sai. Không mã hoá volume tại chỗ được. Phải đi qua chuỗi: chụp snapshot → copy-snapshot với --encrypted → tạo volume mới từ bản sao đó. Mã hoá xảy ra ở bước copy, không phải bằng một lời gọi KMS trực tiếp lên volume.
• C. "Encryption by default là thiết lập theo AZ" — sai phạm vi. Nó là theo Region, không theo Availability Zone.

Ghi nhớ

Quy tắc mã hoá EBS — bảng cần thuộc: | Quy tắc | Chi tiết | |---|---| | Không mã hoá/giải mã tại chỗ | luôn phải qua snapshot → copy có mã hoá → volume mới | | Kế thừa một chiều | mã hoá lan sang snapshot và volume con, không bỏ được | | Encryption by default | thiết lập theo Region, áp cho mọi volume mới | | Chia sẻ chéo tài khoản | bắt buộc customer-managed key (khoá mặc định không sửa key policy được) | | Hiệu năng | ảnh hưởng không đáng kể | | Phạm vi bảo vệ | cả at rest lẫn in transit giữa instance và volume |

Khuyến nghị: bật "EBS encryption by default" cho mọi Region đang dùng — một lần cấu hình, và không bao giờ vô tình tạo volume không mã hoá nữa. Đề cũng nói công ty không muốn tự quản lý hạ tầng khoá, nên dùng AWS managed key (aws/ebs) là hợp lý.

Đáp án

C và D.

• C — RDS tự động khởi tạo failover sang standby khi CSDL chính gặp sự cố.
• D — RDS áp dụng cập nhật hệ điều hành bằng cách bảo trì standby trước, promote standby lên primary, rồi mới bảo trì máy cũ.

Vì sao đúng

C — failover tự động. Đây là giá trị cốt lõi của Multi-AZ: khi primary hỏng (lỗi phần cứng, mất AZ, mất mạng), RDS tự chuyển vai trò sang standby trong 1–2 phút, và endpoint không đổi — ứng dụng chỉ cần kết nối lại, không sửa cấu hình gì.

D — cập nhật không gián đoạn kéo dài. Quy trình bảo trì rất thông minh:

1. Vá standby (primary vẫn phục vụ bình thường)
2. Failover — standby thành primary mới
3. Vá máy cũ (nay là standby)

Thời gian gián đoạn chỉ là khoảnh khắc failover, thay vì cả quá trình vá. Đây là lý do Multi-AZ đáng bật cho mọi CSDL production, ngoài vế chống hỏng AZ.

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

• A. "Cập nhật được sao chép bất đồng bộ sang standby" — sai một từ, nhưng là từ quan trọng nhất. Multi-AZ dùng sao chép ĐỒNG BỘ — đó là điều đảm bảo không mất dữ liệu khi failover. (Bất đồng bộ là cơ chế của read replica, và chính vì vậy promote replica có thể mất những lần ghi gần nhất.)
• B. "I/O bị tạm dừng trên primary vì backup không lấy từ standby" — sai chiều. Trong Multi-AZ, backup được chụp từ STANDBY, nên primary không bị ảnh hưởng I/O. Đây là một lợi ích nữa của Multi-AZ mà phương án này nói ngược.
• E. "Standby dùng để phục vụ read request" — sai dứt khoát. Standby của Multi-AZ KHÔNG phục vụ traffic nào cả — nó không có endpoint riêng, không đọc được. Muốn mở rộng đọc thì dùng read replica. (Ngoại lệ: cấu hình Multi-AZ DB cluster mới hơn có hai standby đọc được — nhưng đó là kiến trúc khác với Multi-AZ instance truyền thống.)

Ghi nhớ

Bảng so sánh — đây là cặp bị hỏi nhiều nhất trong toàn bộ chủ đề RDS: | | Multi-AZ standby | Read replica | |---|---|---| | Sao chép | ĐỒNG BỘ | bất đồng bộ | | Failover | tự động, 1–2 phút | promote thủ công | | Phục vụ đọc | ❌ không bao giờ | ✅ | | Mất dữ liệu khi chuyển | không | có thể | | Mục đích | tính sẵn sàng cao | mở rộng đọc | | Phạm vi | cùng Region, khác AZ | cùng hoặc khác Region |

Câu thần chú: Multi-AZ để không chết; read replica để không chậm. Chúng không thay thế nhau — hệ thống production nghiêm túc thường cần cả hai.

Đáp án

D — Triển khai các phiên bản API thành stage riêng với endpoint riêng, và dùng stage variable để cung cấp ngữ cảnh phân biệt phiên bản.

Vì sao đúng

Stage của API Gateway là bản triển khai độc lập của cùng một API, mỗi stage có URL riêng:

https://abc123.execute-api.ap-southeast-1.amazonaws.com/v1
https://abc123.execute-api.ap-southeast-1.amazonaws.com/v2
https://abc123.execute-api.ap-southeast-1.amazonaws.com/test

Và stage variable cho phép mỗi stage trỏ tới một backend khác nhau mà không cần sửa cấu hình API:

Integration URI: arn:aws:lambda:...:function:xu-ly:${stageVariables.alias}

Stage v1   → alias = "v1"    → Lambda alias v1
Stage v2   → alias = "v2"    → Lambda alias v2
Stage test → alias = "test"  → Lambda alias test

Ba lợi ích khớp đúng với đề:

• Cách ly hoàn toàn — deploy lên test không đụng gì tới v1 hay v2
• Cấu hình riêng cho từng stage — throttling, cache, logging, authorizer
• Không tốn thêm chi phí cố định — chỉ trả theo request thực tế

Stage variable cũng truyền được vào Lambda qua context, nên hàm biết mình đang phục vụ phiên bản nào.

Lưu ý bắt buộc: khi integration dùng stage variable, API Gateway không tự thêm quyền vào resource-based policy của Lambda — phải tự thêm cho mọi hàm/alias có thể được gọi.

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

• C. Dùng header X-Version để phân biệt — làm được, nhưng đẩy toàn bộ logic phân biệt phiên bản vào mã Lambda: một hàm phải chứa mọi phiên bản, rẽ nhánh theo header. Rất khó bảo trì, và không cách ly được — lỗi ở phiên bản mới ảnh hưởng cả phiên bản cũ.
• A. Lambda authorizer để định tuyến tới đúng phiên bản — hiểu sai chức năng: authorizer quyết định ai được gọi API, nó không định tuyến. Nó trả về một IAM policy cho phép hay từ chối, không chọn backend.
• B. Resource policy để nhận diện phiên bản — resource policy của API Gateway kiểm soát AI được gọi API (theo IP, VPC endpoint, tài khoản). Nó không phân biệt phiên bản và không truyền ngữ cảnh nào cho Lambda.

Ghi nhớ

Ba cơ chế quản lý phiên bản API, và khi nào dùng cái nào: | Cơ chế | Dùng khi | |---|---| | Stage + stage variable | môi trường/phiên bản tách biệt, thay đổi phá vỡ tương thích | | Canary release | phát hành dần một thay đổi tương thích ngược | | API mới hoàn toàn | API thực sự khác, đội sở hữu khác |

Và nhớ đặc điểm nền tảng của API Gateway: thay đổi cấu hình chỉ có hiệu lực sau khi tạo deployment:

aws apigateway create-deployment --rest-api-id abc123 --stage-name v2

Đáp án

C và D.

• C — Tạo HTTPS listener trên ALB với SSL termination.
• D — Cấu hình chứng chỉ SSL/TLS trên ALB qua AWS Certificate Manager (ACM).

Vì sao đúng

Vấn đề: CPU của web server cao vì phải xử lý mã hoá TLS cho mọi kết nối.

SSL/TLS termination ở ALB dời toàn bộ gánh nặng đó đi:

Client ──HTTPS (mã hoá)──→ ALB ──HTTP (giải mã)──→ EC2
                            ↑
                    ALB làm việc bắt tay TLS
                    EC2 chỉ xử lý HTTP thuần

Bắt tay TLS là phần tốn CPU nhất (trao đổi khoá bất đối xứng), và ALB có phần cứng chuyên dụng cho việc đó. Instance chỉ còn xử lý logic ứng dụng.

D — chứng chỉ từ ACM. Đây không chỉ là chi tiết kỹ thuật mà còn là lợi ích vận hành lớn: | Đặc điểm | ACM | |---|---| | Chứng chỉ công cộng | miễn phí | | Tự gia hạn | ✅ — bỏ hẳn nguy cơ sập vì quên gia hạn | | Tích hợp | ELB, CloudFront, API Gateway | | Khoá riêng | không xuất ra được — an toàn hơn |

Hai phương án này bổ sung nhau: C là cơ chế, D là nguồn chứng chỉ.

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

• A. HTTPS listener với SSL pass-through — đây là bẫy chính, và nó đi ngược mục tiêu: pass-through nghĩa là ALB chuyển traffic mã hoá thẳng tới instance, nên instance vẫn phải giải mã — CPU vẫn cao y nguyên. (Thực tế ALB không hỗ trợ pass-through; đó là tính năng của NLB với TLS listener.)
• E. HTTP listener với SSL pass-through — mâu thuẫn nội tại: listener HTTP thì không có SSL nào để pass-through.
• B. HTTP listener với SSL termination — cũng mâu thuẫn: listener HTTP nhận traffic không mã hoá, nên không có gì để terminate. Muốn terminate thì listener phải là HTTPS.

Ghi nhớ

Với ứng dụng cần mã hoã đầu cuối (yêu cầu tuân thủ), dùng re-encryption: ALB terminate rồi mã hoá lại khi gửi tới instance (target group dùng giao thức HTTPS). CPU instance vẫn phải làm việc, nhưng bạn có thể dùng chứng chỉ tự ký ở chặng trong — ALB không kiểm tra chứng chỉ của target.

Đáp án

B — CloudTrail event log cho CreateVolume không có sẵn cho EBS volume được tạo trong lúc khởi chạy EC2 instance.

Vì sao đúng

Đây là một khoảng trống thật trong CloudTrail, và nó gây bối rối đúng như tình huống trong đề.

Khi bạn tạo volume độc lập, CloudTrail ghi lại đầy đủ:

{"eventName": "CreateVolume",
 "userIdentity": {"userName": "nguyen.van.a"},
 "requestParameters": {"size": 100, "availabilityZone": "ap-southeast-1a"}}

Nhưng khi volume được tạo như một phần của việc khởi chạy instance — qua block device mapping trong RunInstances — thì không có sự kiện CreateVolume riêng. Việc tạo volume là hành động nội bộ của dịch vụ EC2, không phải một lời gọi API riêng của người dùng.

Cách tìm người tạo trong trường hợp này: tra sự kiện RunInstances thay vì CreateVolume:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=RunInstances \
  --start-time 2026-08-01

Sự kiện đó chứa userIdentity (ai khởi chạy instance) và requestParameters.blockDeviceMapping (volume nào được tạo kèm).

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

• C. "Log cho ManageVolume không có sẵn" — API này không tồn tại. Các API của EBS là CreateVolume, DeleteVolume, AttachVolume, DetachVolume, ModifyVolume, CreateSnapshot.
• A. "Metric CloudWatch của EBS bị tắt" — CloudWatch metric đo hiệu năng (IOPS, throughput, độ trễ). Chúng không ghi lại ai tạo tài nguyên — đó là việc của CloudTrail.
• D. "Status check của EBS volume bị tắt" — status check theo dõi tình trạng sức khoẻ của volume. Cũng không liên quan tới kiểm toán hành động.

Ghi nhớ

Hai loại sự kiện CloudTrail: | Loại | Ghi gì | Mặc định | |---|---|---| | Management event | CreateVolume, RunInstances, PutBucketPolicy | bật, miễn phí | | Data event | GetObject, PutObject, Invoke | tắt, có phí |

Và một công cụ bổ sung rất hữu ích cho tình huống này: AWS Config — đề nói công ty đã bật Config. Config ghi lại ảnh chụp cấu hình tài nguyên theo thời gian và có relationship graph, nên tra được volume này gắn với instance nào, và từ đó lần ra sự kiện RunInstances tương ứng.

Nguyên tắc chung khi kiểm toán: CloudTrail nói AI gọi API nào; AWS Config nói CẤU HÌNH đã thay đổi thế nào. Dùng cả hai mới đủ.

Đáp án

A — Tạo IAM role ở Account B có quyền DynamoDB; sửa trust policy của role đó cho phép execution role của Lambda ở Account A assume; và cập nhật execution role của Lambda để được phép gọi AssumeRole.

Vì sao đúng

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

Account A (Lambda)                      Account B (DynamoDB)
┌────────────────────────┐              ┌──────────────────────────┐
│ Execution role         │              │ Role "TruyCapDynamoDB"   │
│  + sts:AssumeRole ────────────────────→ trust policy:            │
│    lên role của B      │  assume      │   Principal = exec role A│
└────────────────────────┘              │ permission policy:       │
                                        │   dynamodb:GetItem, ...  │
                                        └──────────────────────────┘

Mã trong Lambda:

sts = boto3.client('sts')
cred = sts.assume_role(
    RoleArn='arn:aws:iam::<B>:role/TruyCapDynamoDB',
    RoleSessionName='lambda-doc-du-lieu')['Credentials']
db = boto3.resource('dynamodb',
    aws_access_key_id=cred['AccessKeyId'],
    aws_secret_access_key=cred['SecretAccessKey'],
    aws_session_token=cred['SessionToken'])
db.Table('du-lieu').get_item(Key={'id': 'x'})

Chiều đi là A → B, nên role được assume phải nằm ở B (nơi có tài nguyên), và trust policy của nó nêu tên principal ở A.

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

• B. "Sửa trust policy của execution role ở Account A" — ngược chiều. Trust policy phải nằm trên role đích ở B, không phải trên role nguồn ở A. Đây là lỗi hay gặp nhất khi cấu hình cross-account.
• D. "Thêm resource policy vào bảng DynamoDB ở Account B" — đây là bẫy đáng chú ý, và cần biết rõ: DynamoDB đã hỗ trợ resource-based policy từ 2024, nên về nguyên tắc cách này có dùng được. Nhưng assume role là mẫu chuẩn, phổ quát và được khuyến nghị cho truy cập chéo tài khoản — nó cho vết CloudTrail ở cả hai tài khoản và kiểm soát chi tiết hơn.
• C. Nhân bản Lambda sang Account B — né tránh vấn đề thay vì giải quyết: phải duy trì hai bản mã, hai pipeline deploy, và nó phá vỡ ranh giới phân tách tài khoản mà tổ chức đã dựng.

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 mẹo thực dụng:

• Cache thông tin xác thực đã assume (chúng sống 1 giờ mặc định) thay vì gọi AssumeRole ở mỗi lần chạy
• Dùng ExternalId trong trust policy khi bên kia là tổ chức khác — chống confused deputy attack
• Đặt sts:RoleSessionName có ý nghĩa để dễ truy vết trong CloudTrail