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

Đáp án

C — Policy gồm logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents, logs:DescribeLogStreams, với Resource: "arn:aws:logs:*:*:*".

Vì sao đúng

Đây là policy chính thức mà tài liệu ECS đưa ra cho container instance gửi log lên CloudWatch Logs. Bốn action, và mỗi cái có vai trò riêng:

logs:DescribeLogStreams là action hay bị bỏ sót nhất, và thiếu nó thì log driver không hoạt động ổn định: nó cần liệt kê stream để biết nên tạo mới hay ghi tiếp vào stream có sẵn.

Về Resource: "arn:aws:logs:*:*:*": cần phạm vi rộng vì log group được tạo động theo cấu hình task, và tên group chưa biết trước lúc viết policy.

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

• B. Thiếu logs:DescribeLogStreams — đây là phương án gây nhầm nhiều nhất vì nó trông rất giống C, chỉ thiếu đúng một dòng. Ba action còn lại đều đúng, nhưng thiếu DescribeLogStreams là policy không đầy đủ.
• D. Có logs:DescribeLogGroups thay vì DescribeLogStreams — sai đối tượng: log driver cần mô tả stream, không phải group. Hai tên rất giống nhau và đây là bẫy cố ý.
• A. Có ecs:DescribeServices và ARN log group cụ thể — sai hai chỗ. Thứ nhất, ecs:DescribeServices không liên quan gì tới việc ghi log. Thứ hai, JSON này có lỗi cú pháp: dòng "logs:PutLogEvents, thiếu dấu nháy đóng, nên policy không parse được.

Ghi nhớ

Bộ quyền tối thiểu để ghi CloudWatch Logs:

{"Effect": "Allow",
 "Action": ["logs:CreateLogGroup", "logs:CreateLogStream",
            "logs:PutLogEvents", "logs:DescribeLogStreams"],
 "Resource": "arn:aws:logs:*:*:*"}

Đính kèm vào đâu tuỳ kiểu chạy: | Kiểu | Đính vào | |---|---| | ECS trên EC2 | instance role (ecsInstanceRole) | | Fargate | task execution role |

Phân biệt hai role của ECS — nhầm lẫn kinh điển: | Role | Ai dùng | Cho việc gì | |---|---|---| | Task execution role | ECS agent | kéo image ECR, ghi log | | Task role | mã trong container | gọi S3, DynamoDB… |

Quyền ghi log thuộc execution role, không phải task role.

Đáp án

A và E.

• A — Tạo CloudFront distribution, đặt S3 bucket làm origin.
• E — Cấu hình CloudFront distribution với chứng chỉ SSL/TLS.

Vì sao đúng

Điểm mấu chốt nằm ở một hạn chế của S3 mà nhiều người không để ý:

S3 static website endpoint CHỈ hỗ trợ HTTP, không hỗ trợ HTTPS.

http://bucket.s3-website-ap-southeast-1.amazonaws.com   ✅ HTTP
https://bucket.s3-website-...                            ❌ KHÔNG hỗ trợ

(Endpoint REST của S3 — bucket.s3.region.amazonaws.com — thì có HTTPS, nhưng nó không hỗ trợ chức năng static website hosting như index document và redirect rule.)

Nên muốn có HTTPS cho website tĩnh, cách chuẩn là đặt CloudFront ở phía trước:

A — S3 làm origin:

Client ──HTTPS──→ CloudFront ──→ S3 (origin)

E — gắn chứng chỉ: CloudFront kết thúc TLS bằng chứng chỉ: | Lựa chọn | Đặc điểm | |---|---| | Chứng chỉ mặc định của CloudFront | dùng ngay cho tên miền *.cloudfront.net | | ACM certificate | cho tên miền riêng — phải cấp ở us-east-1 |

Và nên đặt luôn ViewerProtocolPolicy: redirect-to-https để mọi truy cập HTTP được chuyển sang HTTPS.

Lợi ích kèm theo: CDN toàn cầu, giảm chi phí truyền dữ liệu, và bucket có thể để riêng tư hoàn toàn nhờ Origin Access Control.

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

• B. Cấu hình S3 bucket với chứng chỉ SSL/TLS — không làm được. S3 không cho gắn chứng chỉ vào bucket; đây là bẫy trung tâm của câu hỏi.
• C. CloudFront với AWS WAF WebACL — WAF là tường lửa ứng dụng web (chặn SQL injection, XSS, giới hạn tần suất). Nó không cung cấp mã hoá khi truyền.
• D. Tạo WAF WebACL với "secure listener" — WAF không có khái niệm listener. "Listener" thuộc về load balancer. Phương án này ghép hai khái niệm không liên quan.

Ghi nhớ

Lưu ý quan trọng về ACM: chứng chỉ dùng cho CloudFront bắt buộc phải cấp ở Region us-east-1 — bất kể bucket và người dùng ở đâu. Cấp nhầm Region là lỗi phổ biến, và Console sẽ đơn giản là không hiện chứng chỉ đó trong danh sách.

Kiến trúc website tĩnh chuẩn: Route 53 → CloudFront (ACM cert, OAC) → S3 bucket riêng tư.

Đáp án

D — Tạo RESTful API bằng API Gateway, dùng mapping template để biến JSON đầu vào thành XML hợp lệ cho giao diện SOAP.

Vì sao đúng

Có hai quyết định trong câu này.

Quyết định 1 — REST, không phải "SOAP API". Vì API Gateway không có loại API nào tên là SOAP. Nó chỉ hỗ trợ: | Loại | Đặc điểm | |---|---| | REST API | đầy đủ tính năng, có mapping template | | HTTP API | rẻ và nhanh hơn, ít tính năng hơn | | WebSocket API | hai chiều |

Quyết định 2 — mapping template làm việc chuyển đổi. Đây là tính năng biến đổi payload bằng VTL (Velocity Template Language), chạy ngay trong API Gateway:

## Integration request: JSON của khách → XML cho SOAP
#set($inputRoot = $input.path('$'))
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <TraCuuDonHang xmlns="http://example.com/">
      <MaDon>$inputRoot.maDon</MaDon>
    </TraCuuDonHang>
  </soap:Body>
</soap:Envelope>

Và integration response làm chiều ngược lại: XML từ SOAP → JSON cho khách.

Kết quả: khách hàng bên ngoài chỉ thấy một REST API JSON hiện đại; hệ thống cũ không phải sửa một dòng nào. Đây gọi là mẫu façade hay anti-corruption layer.

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

• A. Tạo "SOAP API" bằng API Gateway, chuyển đổi bằng Lambda — vế đầu không tồn tại. Vế sau (dùng Lambda để chuyển đổi) thì chạy được, nhưng thêm một hàm Lambda, thêm độ trễ và thêm chi phí cho việc mà mapping template làm sẵn.
• C. "SOAP API" + Network Load Balancer — cùng lỗi về loại API. Ngoài ra NLB hoạt động ở tầng 4 — nó chỉ chuyển tiếp byte, không biến đổi được nội dung từ JSON sang XML.
• B. REST API + Application Load Balancer — loại API đúng, nhưng ALB không biến đổi payload. Nó định tuyến theo host/path và chuyển tiếp nguyên vẹn; SOAP endpoint sẽ nhận JSON và từ chối.

Ghi nhớ

Mapping template trong API Gateway: | Vị trí | Biến đổi | |---|---| | Integration Request | request của client → định dạng backend cần | | Integration Response | response của backend → định dạng client cần |

Các biến VTL hay dùng:

$input.path('$.field')      ## đọc một trường
$input.json('$')            ## toàn bộ body dạng JSON
$input.params('ten')        ## path/query/header
$context.requestId          ## thông tin request
$util.escapeJavaScript(...) ## thoát ký tự

Nhận dạng nhanh: đề nói "legacy XML/SOAP" và cần phơi ra dạng REST/JSON ⇒ REST API + mapping template. Đây là cách hiện đại hoá giao diện mà không đụng vào hệ thống cũ.

Đáp án

B — Dùng Cognito identity pool, liên kết với SAML provider, và dùng trust policy với IAM condition key để giới hạn quyền của mỗi nhân viên.

Vì sao đúng

Yêu cầu có hai vế, và vế thứ hai mới là điểm phân biệt:

1. Tích hợp với SAML directory tại chỗ
2. Mỗi nhân viên chỉ truy cập được dữ liệu của chính mình

Identity pool là thứ đổi danh tính đã xác thực lấy thông tin xác thực AWS tạm thời — và chính vì có credential AWS, ta mới đặt được điều kiện IAM cho từng người:

Nhân viên → SAML IdP tại chỗ → SAML assertion
   → Cognito identity pool → STS AssumeRoleWithWebIdentity
   → credential AWS tạm thời, GẮN VỚI DANH TÍNH CỦA NGƯỜI ĐÓ

Việc phân quyền theo từng người dùng cấu trúc này:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::du-lieu-nhan-vien/${aws:userid}/*"
}

hoặc với DynamoDB, dùng leading key condition:

"Condition": {
  "ForAllValues:StringEquals": {
    "dynamodb:LeadingKeys": ["${cognito-identity.amazonaws.com:sub}"]
  }
}

Biến ${cognito-identity.amazonaws.com:sub} được thay bằng ID thật của người đăng nhập ngay lúc đánh giá policy — nên một policy duy nhất phục vụ được mọi nhân viên, và không ai chạm được vào dữ liệu người khác.

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

• D. Cognito user pool + SAML + user pool group với IAM policy — đây là phương án gần đúng nhất và đáng phân tích kỹ. User pool có liên kết SAML được, và group có gắn IAM role được. Nhưng group cho quyền theo NHÓM, không cho quyền theo TỪNG NGƯỜI — mà đề đòi "access only their own data". Muốn tới mức từng người thì vẫn phải qua identity pool và condition key. (Trên thực tế, kiến trúc đầy đủ thường dùng cả hai: user pool để xác thực, identity pool để cấp credential AWS.)
• C. Tạo một IAM role riêng cho MỖI nhân viên — không mở rộng được: giới hạn 1.000 role mỗi tài khoản, và phải tạo/xoá role mỗi khi có người vào hoặc nghỉ việc. Chính vấn đề này là lý do condition key ra đời.
• A. VPC endpoint với trust policy — VPC endpoint kiểm soát truy cập ở tầng mạng (dịch vụ nào gọi được từ VPC nào). Nó không xác thực người dùng và không biết ai là ai.

Ghi nhớ

Các biến thay thế trong policy, dùng để phân quyền theo người:

${aws:userid}
${cognito-identity.amazonaws.com:sub}
${saml:sub}
${dynamodb:LeadingKeys}

Nhận dạng nhanh: đề nói "only their own data" ⇒ identity pool + IAM policy variable, không phải group.

Đáp án

D — Dùng Amazon DynamoDB để lưu session một cách co giãn.

Vì sao đúng

Nguyên tắc nền tảng của kiến trúc chịu lỗi: tầng web phải phi trạng thái (stateless).

Nếu session nằm trong bộ nhớ của EC2, thì instance hỏng = mọi người dùng đang được nó phục vụ bị đăng xuất. Cách chữa là đưa session ra kho lưu trữ bên ngoài:

Client → ELB → EC2 (BẤT KỲ máy nào, không giữ trạng thái)
                 ↓ đọc/ghi session
              DynamoDB (đa AZ, bền, tự co giãn)

DynamoDB phù hợp vì: | Đặc điểm | Chi tiết | |---|---| | Bền vững | nhân bản đồng bộ trên 3 AZ | | Co giãn | on-demand hoặc auto scaling | | Nhanh | độ trễ mili giây một chữ số | | TTL | tự xoá session hết hạn — không cần job dọn dẹp | | Quản lý | không có máy chủ nào để vá |

Tính năng TTL đặc biệt hợp với session:

table.put_item(Item={
    'session_id': sid,
    'du_lieu': data,
    'het_han': int(time.time()) + 3600   # DynamoDB tự xoá sau 1 giờ
})

AWS còn cung cấp sẵn DynamoDB Session Handler cho PHP và Tomcat SessionStore — dùng được với thay đổi cấu hình tối thiểu.

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

• C. Bật Sticky Sessions trên ELB — đây là bẫy chính, và nó làm ngược yêu cầu của đề: sticky session ghim người dùng vào đúng instance đang giữ session của họ. Khi instance đó chết, session mất hoàn toàn — đúng thứ cần tránh. Nó chỉ giấu vấn đề đi chứ không giải quyết.
• B. Dùng Auto Scaling group để tự tạo instance mới — giữ được năng lực phục vụ, nhưng không giữ được session: instance mới hoàn toàn trống, người dùng vẫn bị đăng xuất.
• A. Dùng SQS để lưu session — sai bản chất dịch vụ: SQS là hàng đợi tin nhắn, message bị xoá sau khi xử lý và không truy cập ngẫu nhiên theo khoá được. Không thể đọc "session của người dùng X".

Ghi nhớ

Các lựa chọn lưu session bên ngoài: | Kho | Độ trễ | Bền | Ghi chú | |---|---|---|---| | ElastiCache (Redis) | thấp nhất — dưới mili giây | có thể mất nếu không bật persistence | nhanh nhất | | DynamoDB | mili giây một chữ số | rất bền, đa AZ | có TTL, không cần quản lý | | RDS | cao hơn | bền | quá nặng cho session | | S3 | cao nhất | rất bền | không hợp cho session |

Cách chọn nhanh:

• "Độ trễ THẤP NHẤT" ⇒ ElastiCache Redis
• "Bền, co giãn, không quản lý" ⇒ DynamoDB
• Chỉ có sticky session ⇒ luôn là phương án sai cho câu hỏi về chịu lỗi

Đáp án

C — Dùng advanced container definition parameters, khai biến môi trường dưới tham số environment trong task definition.

Vì sao đúng

Có hai điểm phải đúng cùng lúc, và các phương án sai đều hỏng ở một trong hai:

1. Nơi khai: task definition, không phải service definition. | | Task definition | Service definition | |---|---|---| | Mô tả | container chạy thế nào: image, CPU, bộ nhớ, biến môi trường, log | bao nhiêu bản sao, ở đâu: desired count, load balancer, chiến lược triển khai |

Biến môi trường thuộc về cấu hình container, nên nó nằm trong task definition.

2. Tham số: environment.

{
  "name": "ung-dung",
  "image": "...ecr.../app:v1",
  "environment": [
    {"name": "DB_HOST", "value": "csdl.example.com"},
    {"name": "LOG_LEVEL", "value": "info"}
  ]
}

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

• A. environment trong service definition — đúng tham số, sai chỗ khai. Service definition không có trường nào tên environment.
• B. secrets trong task definition — đúng chỗ nhưng sai tham số, và khác biệt này rất đáng nhớ: secrets dùng cho dữ liệu NHẠY CẢM, và nó không nhận giá trị trực tiếp mà chỉ nhận ARN trỏ tới Secrets Manager hoặc SSM Parameter Store:

  "secrets": [
    {"name": "DB_PASSWORD",
     "valueFrom": "arn:aws:secretsmanager:...:secret:db-pass-AbCdEf"}
  ]
  

  Đề nói biến môi trường thông thường để khởi tạo ứng dụng, không nói gì về bí mật.
• D. WorkingDirectory trong service definition — sai cả hai vế. workingDirectory là tham số hợp lệ của container definition nhưng nó đặt thư mục làm việc (tương đương WORKDIR trong Dockerfile), không phải biến môi trường. Và nó cũng không nằm trong service definition.

Ghi nhớ

Ba cách truyền cấu hình vào container ECS: | Cách | Dùng cho | Giá trị | |---|---|---| | environment | cấu hình thường | giá trị trực tiếp | | secrets | mật khẩu, khoá API | ARN từ Secrets Manager / SSM | | environmentFiles | nhiều biến cùng lúc | tệp .env trên S3 |

Nguyên tắc bảo mật: đừng bao giờ đặt mật khẩu vào environment — task definition hiện nguyên văn trong Console và CloudTrail, và ai có quyền ecs:DescribeTaskDefinition đều đọc được. Dùng secrets để chỉ lưu con trỏ, còn giá trị thật chỉ được lấy lúc container khởi động.

Đáp án

C — Blue/green.

Vì sao đúng

Điểm mấu chốt là một sự thật đơn giản về CodeDeploy:

Với Amazon ECS, CodeDeploy CHỈ hỗ trợ blue/green. Không có lựa chọn nào khác.

Nên câu này có thể trả lời mà không cần cân nhắc gì thêm — nhưng lý do kỹ thuật cũng hợp lý: container bất biến; bạn không "cập nhật tại chỗ" một container mà thay nó bằng container mới.

Cách blue/green hoạt động với ECS:

1. Task set MỚI (green) khởi động cùng lúc với task set cũ (blue)
2. Test listener trỏ vào green để kiểm thử
3. Chuyển traffic của production listener sang green
4. Giữ blue lại một khoảng (có thể rollback tức thì)
5. Hết thời gian chờ → huỷ blue

Và đây là chỗ khớp với yêu cầu "complete the code update quickly": việc chuyển traffic chỉ là đổi target group ở listener — gần như tức thì, vì task mới đã sẵn sàng từ trước.

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

• A. In-place — không hỗ trợ cho ECS. Nó chỉ dùng cho EC2/on-premises, nơi CodeDeploy dừng ứng dụng, cài bản mới, rồi khởi động lại trên chính máy đó.

• B. Canary và D. Linear — đây là bẫy tinh vi nhất: chúng không phải KIỂU triển khai (deployment type), mà là CẤU HÌNH chuyển traffic (deployment configuration) BÊN TRONG blue/green: | Cấu hình | Cách chuyển traffic | |---|---| | AllAtOnce | 100% ngay — NHANH NHẤT | | Canary | ví dụ 10% → chờ → 90% | | Linear | ví dụ 10% mỗi 1 phút |

  Và nếu đề đã nhấn mạnh "quickly", thì trong blue/green nên chọn AllAtOnce — canary và linear cố tình chậm lại để giảm rủi ro.

Ghi nhớ

Đọc kỹ hai tầng khái niệm của CodeDeploy:

Deployment TYPE:   In-place | Blue/green
Deployment CONFIG: AllAtOnce | Canary | Linear (và các biến thể theo % và thời gian)

Ưu điểm của blue/green trên ECS: | Ưu điểm | Chi tiết | |---|---| | Rollback tức thì | chỉ cần trỏ listener về blue | | Không gián đoạn | green sẵn sàng trước khi chuyển | | Test trước | test listener riêng | | Đổi lại | tốn gấp đôi tài nguyên trong lúc triển khai |

Đáp án

B — max_connections.

Vì sao đúng

max_connections là tham số của MySQL quy định tổng số kết nối đồng thời mà máy chủ chấp nhận. Vượt quá, client nhận:

ERROR 1040 (HY000): Too many connections

Với Aurora MySQL, giá trị mặc định được tính theo bộ nhớ của instance class:

max_connections = GREATEST({log(DBInstanceClassMemory/805306368) * 45}, {log(DBInstanceClassMemory/8187281408) * 1000})

Muốn tăng, sửa trong DB parameter group (không sửa trực tiếp trên instance):

aws rds modify-db-parameter-group \
  --db-parameter-group-name aurora-mysql-cua-toi \
  --parameters "ParameterName=max_connections,ParameterValue=2000,ApplyMethod=pending-reboot"

Lưu ý ApplyMethod: max_connections là tham số động trong MySQL nhưng ở Aurora thường cần khởi động lại để áp dụng — nên phải lên kế hoạch cho khoảng gián đoạn đó.

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

• D. max_user_connections — đây là phương án gần nhất và cần phân biệt rõ: nó giới hạn số kết nối của MỘT tài khoản người dùng, không phải tổng của cả máy chủ. Nó là trần phụ nằm dưới max_connections — dùng để một ứng dụng không chiếm hết kết nối của các ứng dụng khác. Đề hỏi "allow more clients to connect" nói chung ⇒ tham số tổng.
• A. max_join_size — giới hạn kích thước phép JOIN (số dòng hoặc số byte máy chủ chấp nhận đọc cho một truy vấn). Đây là công cụ chống truy vấn chạy loạn, không liên quan tới kết nối.
• C. max_allowed_packet — kích thước tối đa của một gói giao tiếp (mặc định thường 64 MB ở Aurora). Nó quan trọng khi lưu BLOB lớn hoặc chạy câu lệnh rất dài, nhưng không quyết định số kết nối.

Ghi nhớ

Và một điểm quan trọng về thực hành: tăng max_connections không phải lúc nào cũng là câu trả lời đúng. Mỗi kết nối tốn bộ nhớ, nên tăng quá tay có thể làm instance hết RAM. Giải pháp bền hơn:

Đáp án

A — Dùng parallel scan kèm giới hạn tốc độ (rate limiting).

Vì sao đúng

Đề có hai ràng buộc kéo ngược nhau: giảm thời gian quét nhưng không ảnh hưởng production. Phương án đúng giải quyết cả hai bằng hai nửa của nó.

Nửa 1 — parallel scan để nhanh. Scan tuần tự chỉ dùng một luồng đọc lần lượt từng partition. Parallel scan chia bảng thành các segment và quét đồng thời:

import threading

TONG_SEGMENT = 8

def quet(segment):
    kwargs = {'TableName': 'bang-lon', 'Segment': segment,
              'TotalSegments': TONG_SEGMENT}
    while True:
        r = dynamodb.scan(**kwargs)
        xu_ly(r['Items'])
        if 'LastEvaluatedKey' not in r: break
        kwargs['ExclusiveStartKey'] = r['LastEvaluatedKey']
        time.sleep(0.1)          # ← giới hạn tốc độ

for i in range(TONG_SEGMENT):
    threading.Thread(target=quet, args=(i,)).start()

Với 8 segment, thời gian quét giảm khoảng 8 lần.

Nửa 2 — rate limiting để không đụng production. Đề nói rõ: khoảng một nửa RCU đang được dùng trong giờ thấp điểm. Nếu quét hết tốc lực, scan sẽ ngốn sạch RCU còn lại và cả phần production đang dùng, gây throttle cho ứng dụng thật.

Cách kiểm soát: dùng Limit để giới hạn số item mỗi lời gọi, đọc ConsumedCapacity trong phản hồi, và chèn độ trễ khi vượt ngân sách RCU tự đặt.

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

• B. Sequential scan — chính là thứ đang chậm. Nó không giảm thời gian quét chút nào, trái yêu cầu "minimize scan duration".
• C. Tăng RCU trong lúc scan — chạy được nhưng tốn tiền, và không phải điều đề hỏi: đề nói đã có sẵn ~50% RCU rảnh, tức là năng lực đã đủ — vấn đề là dùng nó cho hiệu quả, không phải mua thêm.
• D. Chuyển sang eventually consistent RCU — đây là phương án đáng cân nhắc nhất vì nó giảm một nửa chi phí đọc. Nhưng nó không tự làm scan nhanh hơn nếu vẫn quét tuần tự — nó chỉ giảm RCU tiêu thụ. (Trên thực tế, Scan mặc định đã là eventually consistent rồi; đề nói "strongly consistent RCUs" ám chỉ workload production, không phải bản thân lệnh scan.) Nó là tối ưu bổ sung tốt, nhưng không phải câu trả lời cho "minimize duration".

Ghi nhớ

Các tham số điều khiển scan: | Tham số | Tác dụng | |---|---| | TotalSegments | chia bảng thành N phần để quét song song | | Segment | phần nào (0 … N−1) | | Limit | số item tối đa mỗi lời gọi | | ProjectionExpression | chỉ lấy cột cần — giảm dữ liệu đọc | | ReturnConsumedCapacity | để tự giám sát và điều tiết |

Và nguyên tắc lớn hơn: Scan luôn là lựa chọn cuối cùng. Nó đọc toàn bộ bảng, nên với 50 GB thì cực đắt. Trước khi tối ưu scan, hãy hỏi:

1. Có thiết kế được partition key để dùng Query không?
2. Có thêm được GSI cho mẫu truy vấn này không?
3. Nếu cần quét toàn bảng định kỳ, cân nhắc Export to S3 rồi phân tích bằng Athena — không tốn RCU nào.

Phương án 3 thường là câu trả lời đúng trong thực tế cho việc quét toàn bảng lặp lại.

Đáp án

A — Thêm phase post_build vào buildspec, dùng khối commands để đẩy Docker image.

Vì sao đúng

Yêu cầu: đẩy image lên ECR chỉ khi build thành công.

Buildspec của CodeBuild có bốn phase, chạy theo thứ tự:

version: 0.2
phases:
  install:
    runtime-versions: {docker: 20}
  pre_build:
    commands:
      - aws ecr get-login-password --region $AWS_REGION | \
          docker login --username AWS --password-stdin $ECR_URI
  build:
    commands:
      - docker build -t $IMAGE_REPO:$IMAGE_TAG .
      - docker tag $IMAGE_REPO:$IMAGE_TAG $ECR_URI/$IMAGE_REPO:$IMAGE_TAG
  post_build:
    commands:
      - docker push $ECR_URI/$IMAGE_REPO:$IMAGE_TAG   # ← chỉ chạy nếu build thành công

post_build chỉ chạy khi build thành công — đó chính xác là điều kiện đề yêu cầu. Nếu build thất bại, post_build bị bỏ qua và không có image hỏng nào lọt lên ECR.

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

• C. Dùng khối finally trong post_build — đây là bẫy hay nhất trong câu này, vì nó đúng phase nhưng sai khối. finally chạy BẤT KỂ phase thành công hay thất bại — đó là toàn bộ mục đích của nó (dùng để in log chẩn đoán, dọn dẹp). Dùng finally để push nghĩa là đẩy image lên kể cả khi build hỏng, trái hẳn yêu cầu.

  post_build:
    commands: [docker push ...]      # chỉ khi thành công
    finally:  [docker logout, ls -la] # LUÔN chạy
  

• B. Dùng artifacts sequence để đẩy lên ECR — sai bản chất: artifacts chỉ đóng gói TỆP và tải lên S3. Nó không biết gì về Docker image và không nói chuyện được với ECR.
• D. Đặt lệnh push vào phase install — install chạy đầu tiên, trước cả khi image được dựng. Lúc đó chưa có gì để đẩy, và nó cũng không hề phụ thuộc vào việc build thành công.

Ghi nhớ

Thứ tự và điều kiện chạy của các phase: | Phase | Chạy khi | Dùng cho | |---|---|---| | install | luôn (đầu tiên) | cài runtime, công cụ | | pre_build | install xong | đăng nhập ECR, tải dependency | | build | pre_build xong | biên dịch, dựng image, chạy test | | post_build | build THÀNH CÔNG | đẩy image, đóng gói artifact |

Quy tắc quan trọng: nếu một phase thất bại, các phase sau bị bỏ qua — trừ khối finally của chính phase đó, vốn luôn chạy.

Và đừng quên quyền IAM cho service role của CodeBuild:

{"Effect": "Allow",
 "Action": ["ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability",
            "ecr:InitiateLayerUpload", "ecr:UploadLayerPart",
            "ecr:CompleteLayerUpload", "ecr:PutImage"],
 "Resource": "*"}

Cùng với privilegedMode: true cho project — thiếu nó thì Docker daemon không chạy được trong môi trường build.