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

Đáp án

A — MessageDeduplicationId.

Vì sao đúng

FIFO queue có hai tham số riêng biệt, và câu này hỏi đúng cái thứ hai:

Đề nói rõ đã có thứ tự theo user_id (tức là MessageGroupId đã được đặt), và giờ cần chống gửi trùng ⇒ MessageDeduplicationId.

Cách hoạt động: SQS ghi nhớ ID này trong cửa sổ khử trùng 5 phút. Message gửi lại với cùng ID trong khoảng đó sẽ được nhận nhưng không đưa vào hàng đợi:

sqs.send_message(
    QueueUrl=url,
    MessageBody=json.dumps(don_hang),
    MessageGroupId=user_id,                    # thứ tự theo người dùng
    MessageDeduplicationId=don_hang['ma_don']  # chống trùng theo mã đơn
)

Dùng một định danh nghiệp vụ ổn định (mã đơn hàng, transaction ID) làm deduplication ID là cách chuẩn: gửi lại do lỗi mạng hay retry đều mang cùng ID, nên không tạo đơn trùng.

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

• B. ContentBasedDeduplication — đây là bẫy sát nhất, vì nó có liên quan tới khử trùng. Nhưng nó là thuộc tính của QUEUE, không phải tham số của message: bật nó thì SQS tự tính SHA-256 của message body làm deduplication ID. Đề hỏi "which message parameter should you set" ⇒ phải là tham số gửi kèm message.

  Và nó cũng kém tin cậy hơn trong nhiều trường hợp: hai đơn hàng khác nhau mà nội dung tình cờ giống hệt sẽ bị coi là trùng; ngược lại, cùng một đơn nhưng có thêm timestamp sẽ không bị coi là trùng.

• D. MessageGroupId — đảm bảo thứ tự, không chống trùng. Đề nói rõ nó đã được dùng cho user_id.

• C. ReceiveRequestAttemptId — dùng để khử trùng ở phía NHẬN: nếu ReceiveMessage bị lỗi mạng và bạn gọi lại với cùng ID, SQS trả về đúng tập message của lần trước. Không liên quan tới việc gửi.

Ghi nhớ

Và nhớ đặc điểm về thông lượng: message cùng MessageGroupId được xử lý tuần tự; message ở các nhóm khác nhau được xử lý song song. Nên chọn MessageGroupId có độ phân tán tốt (như user_id) là cách tăng thông lượng của FIFO queue.

Đáp án

C — Dùng thư mục cục bộ /tmp.

Vì sao đúng

Lambda cấp cho mỗi môi trường thực thi một hệ thống tệp tạm ghi được tại /tmp — và đó là thư mục ghi được duy nhất:

def handler(event, context):
    duong_dan = '/tmp/trung-gian.dat'
    with open(duong_dan, 'wb') as f:
        f.write(du_lieu_lon)
    ket_qua = xu_ly(duong_dan)
    os.remove(duong_dan)        # nên dọn — xem lý do bên dưới
    return ket_qua

Đặc điểm của /tmp: | Đặc điểm | Chi tiết | |---|---| | Dung lượng | 512 MB mặc định, chỉnh được tới 10.240 MB | | Vòng đời | tồn tại theo execution context, không theo lời gọi | | Chi phí | 512 MB đầu miễn phí |

Đặc điểm thứ hai rất quan trọng và hay gây lỗi: /tmp không bị xoá giữa các lần gọi trong cùng một môi trường. Nên nếu không tự dọn, tệp tích lại và hàm sẽ hết dung lượng sau vài trăm lần chạy — với thông báo No space left on device.

Quy tắc: luôn xoá tệp tạm ở cuối handler, hoặc kiểm tra và dọn ở đầu.

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

• A. "Tạo thư mục tmp/ trong gói zip" — thư mục trong gói được giải nén vào /var/task, vốn chỉ đọc. Ghi vào đó sẽ lỗi Read-only file system.
• B. Dùng /opt — đây là nơi layer được giải nén vào, và cũng chỉ đọc.
• D. Dùng S3 bucket — làm được, nhưng không phù hợp cho tệp trung gian bị vứt đi ngay: mỗi lần ghi/đọc là một lời gọi API qua mạng, chậm hơn nhiều lần và tốn tiền. S3 hợp cho dữ liệu cần giữ lại, không phải tệp tạm.

Ghi nhớ

Ba tính năng liên quan tới lưu trữ của Lambda: | | /tmp | Layer (/opt) | EFS | |---|---|---|---| | Ghi được | ✅ | ❌ | ✅ | | Dung lượng | 512 MB – 10 GB | 250 MB (giải nén, tổng) | không giới hạn | | Chia sẻ giữa các lần gọi | trong cùng môi trường | ✅ | ✅ giữa mọi môi trường | | Chia sẻ giữa các hàm | ❌ | ✅ | ✅ |

Cần chia sẻ tệp giữa nhiều lần gọi hoặc nhiều hàm thì dùng EFS gắn vào Lambda; cần tệp tạm vứt đi thì /tmp là đúng và nhanh nhất.

Đáp án

A và B.

• A — Tải toàn bộ mã dưới dạng zip lên S3 và tham chiếu object đó trong khối AWS::Lambda::Function.
• B — Viết mã inline trong CloudFormation ở khối AWS::Lambda::Function, miễn là không có phụ thuộc bên thứ ba.

Vì sao đúng

AWS::Lambda::Function có thuộc tính Code với hai cách khai:

A — từ S3 (cách chính thống cho mọi trường hợp thực tế):

Resources:
  HamXuLy:
    Type: AWS::Lambda::Function
    Properties:
      Handler: index.handler
      Runtime: python3.12
      Role: !GetAtt VaiTro.Arn
      Code:
        S3Bucket: kho-artifact
        S3Key: ham/v1.2.3.zip

B — inline bằng ZipFile (chỉ cho mã rất ngắn):

      Code:
        ZipFile: |
          import json
          def handler(event, context):
              return {'statusCode': 200, 'body': json.dumps('OK')}

Ba giới hạn của cách inline — và chúng giải thích vì sao phương án B có điều kiện "không phụ thuộc bên thứ ba": | Giới hạn | Chi tiết | |---|---| | Kích thước | tối đa 4.096 byte | | Runtime | chỉ Node.js và Python | | Phụ thuộc | chỉ dùng được thư viện chuẩn và AWS SDK |

Nên inline chỉ hợp cho custom resource nhỏ hoặc hàm dán keo vài chục dòng.

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

• C. Mã inline + tham chiếu phụ thuộc dưới dạng zip trên S3 — không kết hợp được. Thuộc tính Code nhận hoặc ZipFile hoặc S3Bucket/S3Key, không nhận cả hai. (Muốn có phụ thuộc thì dùng layer — nhưng đó là tài nguyên riêng, không phải một phần của Code.)
• E. Tải mã lên S3 dưới dạng thư mục và tham chiếu thư mục — S3 không có thư mục thật, và Code cần một object zip cụ thể qua S3Key. Không tham chiếu prefix được.
• D. Tải mã lên CodeCommit rồi tham chiếu repository — CloudFormation không đọc mã từ CodeCommit. Code chỉ nhận S3, ZipFile, hoặc ImageUri (container image trong ECR).

Ghi nhớ

Ba cách khai Code cho Lambda trong CloudFormation: | Cách | Giới hạn | |---|---| | S3Bucket + S3Key | cách chuẩn — 50 MB zip | | ZipFile (inline) | 4 KB, chỉ Node.js/Python, không phụ thuộc | | ImageUri | container image trong ECR, tới 10 GB |

Và trong thực tế, SAM làm việc này gọn hơn nhiều — khai CodeUri: ./src rồi để sam deploy tự nén và tải lên S3:

Transform: AWS::Serverless-2016-10-31
Resources:
  HamXuLy:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: ./src
      Handler: index.handler
      Runtime: python3.12

Đáp án

A — Chụp snapshot của CSDL trước khi nó bị xoá.

Vì sao đúng

Đây là hệ quả trực tiếp của một đặc điểm quan trọng của Elastic Beanstalk: RDS tạo BÊN TRONG môi trường có vòng đời gắn với môi trường đó.

Xoá môi trường Beanstalk  →  RDS instance bị xoá theo  →  dữ liệu MẤT

Nên nếu muốn giữ lại dữ liệu để xem xét sau, phải chụp snapshot trước:

aws rds create-db-snapshot \
  --db-instance-identifier <ten-rds-cua-moi-truong> \
  --db-snapshot-identifier backup-truoc-khi-xoa-2026-08

Snapshot tồn tại độc lập với DB instance, nên nó sống sót sau khi môi trường bị huỷ. Sau này khôi phục thành một RDS mới để khám phá dữ liệu.

Có một cách nữa cũng hợp lệ: đổi deletion policy của RDS trong cấu hình môi trường từ Delete sang Retain hoặc Snapshot. Nhưng phải làm trước khi xoá môi trường — và với tình huống đã lỡ tạo RDS bên trong, chụp snapshot là thao tác trực tiếp nhất.

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

• B. Đổi biến môi trường của Beanstalk — biến môi trường truyền cấu hình cho ứng dụng (endpoint, cờ tính năng). Chúng không ảnh hưởng gì tới vòng đời của tài nguyên trong môi trường.
• C. Chuyển sang worker environment — đổi kiểu môi trường (nhận việc từ SQS thay vì HTTP). Không liên quan gì tới việc giữ lại CSDL.
• D. "Xoá có chọn lọc trong Elastic Beanstalk" — không tồn tại. Không có tuỳ chọn nào cho phép xoá môi trường mà giữ lại một số tài nguyên; việc đó phải làm qua deletion policy của từng tài nguyên.

Ghi nhớ

Quy tắc vàng của Elastic Beanstalk: CSDL production luôn nằm NGOÀI môi trường.

Nếu lỡ tạo bên trong rồi thì quy trình cứu là: chụp snapshot → tạo RDS độc lập từ snapshot → đổi cấu hình môi trường trỏ sang CSDL mới bằng biến môi trường → gỡ RDS khỏi môi trường.

Đáp án

B — Tạo bucket policy.

Vì sao đúng

Bật S3 static website hosting chỉ làm một việc: cho bucket một endpoint web phục vụ HTML. Nó không tự cấp quyền đọc cho ai cả.

Mặc định, mọi object trong S3 là riêng tư. Nên khách truy cập ẩn danh từ Internet sẽ nhận 403 Forbidden cho tới khi bạn cho phép tường minh:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "ChoPhepDocCongKhai",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::www.mycompany.com/*"
  }]
}

Điều kiện kèm theo, và đây là bước hay bị quên nhất: phải tắt Block Public Access cho bucket đó. Từ 2023, AWS bật sẵn cả bốn tuỳ chọn cho mọi bucket mới, nên bucket policy công khai sẽ bị vô hiệu hoá nếu không tắt trước:

aws s3api put-public-access-block --bucket www.mycompany.com \
  --public-access-block-configuration "BlockPublicPolicy=false,RestrictPublicBuckets=false"

Và một chi tiết về Route 53: tên bucket phải TRÙNG KHỚP tên miền (www.mycompany.com) thì alias record mới trỏ vào website endpoint được.

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

• D. Tạo IAM role — IAM role cấp quyền cho danh tính AWS (người dùng, dịch vụ). Khách truy cập website từ Internet là ẩn danh, không có danh tính AWS nào — không có gì để gắn role vào.
• C. Bật CORS — CORS kiểm soát việc trang ở tên miền A đọc tài nguyên ở tên miền B. Ở đây khách truy cập thẳng vào website, cùng một origin — không có tình huống cross-origin nào. (CORS sẽ cần nếu website nạp font hoặc API từ một bucket khác.)
• A. Bật mã hoá — bảo vệ dữ liệu lúc lưu, hoàn toàn không liên quan tới quyền đọc.

Ghi nhớ

Bốn bước để dựng website tĩnh trên S3:

1. Bật static website hosting, khai index.html và error.html
2. Tắt Block Public Access cho bucket đó
3. Thêm bucket policy cho phép s3:GetObject với Principal: "*"
4. Route 53 alias record trỏ vào website endpoint (tên bucket phải khớp tên miền)

Và khuyến nghị cho production: thay vì mở bucket công khai, hãy đặt CloudFront với Origin Access Control (OAC) phía trước. Khi ấy bucket đóng hoàn toàn, chỉ CloudFront đọc được — an toàn hơn, và có thêm HTTPS, cache toàn cầu, WAF.

Đáp án

D — STS không phải cơ chế uỷ quyền được API Gateway hỗ trợ.

Vì sao đúng

API Gateway hỗ trợ đúng bốn cơ chế uỷ quyền, và STS không nằm trong danh sách:

Vai trò thật của STS: nó là dịch vụ phát thông tin xác thực AWS tạm thời — AssumeRole, AssumeRoleWithWebIdentity, GetSessionToken. Nó đứng trước bước gọi API:

Client → STS (AssumeRole) → nhận access key tạm thời
       → ký request bằng SigV4 → API Gateway xác minh chữ ký (cơ chế IAM)

Nói cách khác: STS là nguồn cấp thông tin xác thực, không phải cơ chế xác thực của API Gateway. API Gateway không bao giờ "nói chuyện" với STS; nó chỉ xác minh chữ ký SigV4 — và chữ ký đó có thể được tạo từ khoá dài hạn hoặc khoá tạm thời của STS, API Gateway không phân biệt.

Vì sao các phương án khác sai (tức là chúng đều được hỗ trợ)

• A. Lambda Authorizer — cho phép logic xác thực tuỳ ý, dùng khi phân quyền do bên thứ ba lo.
• B. Cognito User Pools — authorizer dựng sẵn, xác minh JWT do user pool phát ra.
• C. IAM permissions với SigV4 — cơ chế chính thức, phù hợp khi client là dịch vụ AWS hoặc có danh tính AWS.

Ghi nhớ

Cách chọn cơ chế uỷ quyền cho API Gateway: | Bối cảnh | Chọn | |---|---| | Client là dịch vụ AWS hoặc có danh tính AWS | IAM (SigV4) | | Có người dùng cuối tự đăng ký | Cognito user pool | | Hệ phân quyền bên thứ ba, logic tuỳ biến | Lambda authorizer | | OIDC/OAuth2 chuẩn, không muốn viết mã | JWT authorizer (HTTP API) |

Và nhắc lại một lần nữa: API key không phải cơ chế xác thực — nó chỉ để định danh và đo lường theo usage plan.

Đáp án

A — S3 Select.

Vì sao đúng

Yêu cầu: lấy một phần dữ liệu CSV trên S3 — một tháng dữ liệu và 3 trên 10 cột — với chi phí tính toán và mạng tối thiểu.

S3 Select cho phép chạy truy vấn SQL ngay bên trong S3, và chỉ trả về phần dữ liệu khớp:

SELECT s.ten, s.ngay, s.doanh_thu
FROM S3Object s
WHERE s.ngay BETWEEN '2026-08-01' AND '2026-08-31'

r = s3.select_object_content(
    Bucket='kho-du-lieu', Key='doanh-thu.csv',
    ExpressionType='SQL',
    Expression="SELECT s.ten, s.ngay, s.doanh_thu FROM S3Object s WHERE s.ngay LIKE '2026-08%'",
    InputSerialization={'CSV': {'FileHeaderInfo': 'USE'}, 'CompressionType': 'GZIP'},
    OutputSerialization={'CSV': {}})

Vì sao nó tối ưu đúng hai chi phí mà đề nêu: | Chi phí | Cách S3 Select giảm | |---|---| | Mạng | chỉ dữ liệu khớp rời khỏi S3, không phải cả tệp | | Tính toán | S3 lọc giúp, ứng dụng không phải tải về rồi tự lọc |

AWS ghi nhận mức cải thiện tới 400% hiệu năng và giảm đáng kể chi phí truyền dữ liệu so với việc tải cả object về.

Định dạng hỗ trợ: CSV, JSON, Parquet, và tệp nén bằng GZIP hoặc BZIP2.

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

• B. S3 Analytics — phân tích mẫu truy cập của object để khuyến nghị chuyển lớp lưu trữ (Standard → Infrequent Access). Hoàn toàn về chi phí lưu trữ, không đọc được nội dung dữ liệu.
• C. S3 Inventory — sinh báo cáo định kỳ liệt kê object trong bucket (tên, kích thước, lớp lưu trữ, trạng thái mã hoá). Nó là siêu dữ liệu về object, không phải nội dung bên trong.
• D. S3 Access Logs — ghi lại ai đã truy cập object nào. Cũng không đọc được nội dung.

Ghi nhớ

Ba công cụ truy vấn dữ liệu trên S3 — chọn theo quy mô: | Công cụ | Phạm vi | Hợp cho | |---|---|---| | S3 Select | một object | lọc nhanh một tệp | | Athena | nhiều object, cả bucket | truy vấn SQL đầy đủ, có JOIN | | Redshift Spectrum | dữ liệu rất lớn | cần cụm Redshift |

Nhận dạng nhanh: đề nói "một object" + "lấy một phần" ⇒ S3 Select. Nói "phân tích cả tập dữ liệu" ⇒ Athena.

Đáp án

D và E.

• E — Tạo một role ở tài khoản trung tâm và cho phép các role ở từng tài khoản con assume role đó.
• D — Cấu hình X-Ray daemon dùng IAM instance role.

Vì sao đúng

Yêu cầu: gom trace từ nhiều tài khoản AWS về một tài khoản duy nhất để xem.

E — cross-account role. X-Ray daemon ở mỗi tài khoản con assume một role ở tài khoản trung tâm rồi gửi trace vào đó:

Tài khoản A → daemon → AssumeRole → role ở tài khoản trung tâm → X-Ray
Tài khoản B → daemon → AssumeRole → ↑
Tài khoản C → daemon → AssumeRole → ↑

Cấu hình daemon:

--role-arn arn:aws:iam::<tai-khoan-trung-tam>:role/XRayCrossAccountRole

Và role đó cần trust policy cho phép các tài khoản con:

{"Effect": "Allow",
 "Principal": {"AWS": ["arn:aws:iam::<A>:root", "arn:aws:iam::<B>:root"]},
 "Action": "sts:AssumeRole"}

D — instance role. Để daemon assume được role kia, nó phải có một danh tính khởi đầu. Trên EC2, danh tính đó đến từ instance profile — cung cấp thông tin xác thực tạm thời, tự xoay vòng, không cần khoá tĩnh nào.

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

• A. Cấu hình daemon dùng access key và secret key — chống chỉ định: khoá tĩnh nằm trên hàng loạt instance, không tự hết hạn, phải xoay vòng thủ công. Trên EC2 luôn dùng instance profile.
• C. Tạo user ở tài khoản trung tâm rồi sinh access key — cùng vấn đề với A, và còn tệ hơn: một bộ khoá dùng chung cho mọi tài khoản, rò rỉ là mất tất cả.
• B. "Bật Cross Account collection trong X-Ray console" — không tồn tại. X-Ray không có công tắc nào như vậy; việc gom trace chéo tài khoản làm hoàn toàn bằng IAM role và cấu hình daemon.

Ghi nhớ

Kiến trúc X-Ray — cần nắm để chẩn đoán:

Ứng dụng (X-Ray SDK)
   ↓ UDP cổng 2000, gửi CỤC BỘ
X-Ray daemon
   ↓ HTTPS, dùng thông tin xác thực từ IAM role
Dịch vụ AWS X-Ray (có thể ở tài khoản khác)

Daemon cần ở đâu, theo nền tảng: | Nền tảng | Daemon | |---|---| | Lambda | có sẵn — chỉ bật Tracing: Active | | ECS Fargate | sidecar container + task role | | EC2 | tự cài + instance role | | On-premises | tự cài + thông tin xác thực riêng |

Và nguyên tắc chung: compute của AWS luôn dùng role, không bao giờ dùng access key.

Đáp án

A — Tối đa 10 EC2 instance.

Vì sao đúng

Đây là một ràng buộc cơ bản của Kinesis Client Library (KCL):

Mỗi shard được xử lý bởi ĐÚNG MỘT record processor tại một thời điểm.

Nghĩa là số worker hữu ích không bao giờ vượt quá số shard:

10 shard  →  tối đa 10 worker (mỗi worker giữ 1 shard)

Nếu triển khai 20 instance cho 10 shard: KCL phân bổ 10 shard cho 10 worker, và 10 worker còn lại nằm im, không xử lý gì — chỉ tốn tiền.

KCL tự lo phần phân bổ qua một bảng DynamoDB (mặc định cùng tên với ứng dụng), ghi lại worker nào đang giữ shard nào và checkpoint tới đâu. Khi thêm hoặc bớt worker, KCL tự cân bằng lại — gọi là lease rebalancing.

Điều này cũng giải thích cách mở rộng đúng: muốn xử lý nhanh hơn thì tăng số shard, rồi mới tăng số worker tương ứng. Đó chính là điều quản trị viên đã làm (6 → 10 shard).

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

• B. 20 — thừa 10 worker nằm im. Nhiều worker hơn số shard không tăng thông lượng.
• D. 6 — số shard cũ. Sau khi split, đã có 10 shard, nên dùng 10 worker mới tận dụng hết.
• C. 1 — chạy được (một worker giữ cả 10 shard), nhưng không tận dụng khả năng song song và là điểm hỏng đơn lẻ.

Ghi nhớ

Quan hệ giữa shard và consumer: | Số worker | Kết quả | |---|---| | Ít hơn số shard | mỗi worker giữ nhiều shard — chạy được nhưng chậm hơn | | Bằng số shard | tối ưu — mỗi worker một shard | | Nhiều hơn số shard | worker dư nằm im — lãng phí |

Và giới hạn của mỗi shard: | Chiều | Giới hạn | |---|---| | Ghi | 1 MB/giây hoặc 1.000 bản ghi/giây | | Đọc (shared) | 2 MB/giây, 5 lời gọi GetRecords/giây — CHIA CHUNG cho mọi consumer | | Đọc (enhanced fan-out) | 2 MB/giây RIÊNG cho mỗi consumer |

Điểm cuối đáng nhớ: với nhiều ứng dụng consumer cùng đọc một stream, enhanced fan-out cho mỗi consumer một đường 2 MB/giây riêng — nếu không, chúng tranh nhau cùng 2 MB.

Đáp án

A — Thiếu IAM permission cho CodeBuild service role.

Vì sao đúng

CodeBuild chạy dưới một service role, và mọi lời gọi AWS trong quá trình build — bao gồm kéo Docker image từ ECR — đều dùng quyền của role đó.

Kéo image từ ECR cần bộ quyền cụ thể:

{
  "Effect": "Allow",
  "Action": [
    "ecr:GetAuthorizationToken",        ← BẮT BUỘC, và phải có Resource: "*"
    "ecr:BatchCheckLayerAvailability",
    "ecr:GetDownloadUrlForLayer",
    "ecr:BatchGetImage"
  ],
  "Resource": "*"
}

ecr:GetAuthorizationToken là quyền hay bị bỏ sót nhất, và nó có một đặc điểm riêng: bắt buộc Resource: "*" vì nó không gắn với repository cụ thể nào.

Nếu image nằm ở tài khoản khác, còn cần thêm repository policy ở phía ECR cho phép service role của CodeBuild:

{"Effect": "Allow",
 "Principal": {"AWS": "arn:aws:iam::<tai-khoan-build>:role/codebuild-role"},
 "Action": ["ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer"]}

Nơi tìm bằng chứng: CloudWatch Logs của build sẽ có AccessDeniedException hoặc CannotPullContainerError kèm ARN của role.

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

• B. "Docker image quá lớn" — image lớn làm build chậm hơn, có thể timeout, nhưng thông báo sẽ nói về thời gian chờ, không phải lỗi kéo image. Và CodeBuild xử lý được image rất lớn.
• C. "Image thiếu một số tag" — thiếu tag thì lỗi là image not found (ImageNotFoundException), một thông báo rõ ràng và khác hẳn. Ngoài ra bạn luôn tham chiếu image bằng tag hoặc digest cụ thể.
• D. "CodeBuild không làm việc được với custom Docker image" — sai hoàn toàn. CodeBuild hỗ trợ đầy đủ custom image từ ECR, Docker Hub, hoặc bất kỳ registry nào — đó là tính năng được dùng rất phổ biến để có sẵn công cụ trong môi trường build.

Ghi nhớ

Quyền tối thiểu mà mọi CodeBuild project cần: | Nhóm | Action | |---|---| | CloudWatch Logs | CreateLogGroup, CreateLogStream, PutLogEvents | | S3 | đọc mã nguồn, ghi artifact | | ECR (nếu dùng custom image) | GetAuthorizationToken + ba action đọc layer | | Thêm | quyền cho mọi dịch vụ mà buildspec gọi tới |

Danh sách kiểm khi CodeBuild không kéo được image:

1. Service role có đủ bốn quyền ECR chưa? (đặc biệt GetAuthorizationToken với Resource: "*")
2. Image có ở đúng Region không?
3. Nếu chéo tài khoản: repository policy đã cho phép chưa?
4. Nếu build chạy trong VPC: có VPC endpoint cho ECR và S3 hoặc NAT gateway chưa?