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

Đáp án

A — Nếu hai lần ghi diễn ra đồng thời vào một object KHÔNG bật versioning, có thể chỉ một event notification được gửi.

Vì sao đúng

S3 event notification có một đảm bảo cụ thể và một giới hạn cụ thể — và giới hạn đó chính là nguyên nhân trong đề:

Với object không bật versioning, hai lệnh PUT đồng thời vào cùng một khoá có thể chỉ sinh ra MỘT event notification.

Lý do: khi không có versioning, hai lần ghi vào cùng một khoá tạo ra cùng một trạng thái cuối — S3 không phân biệt được chúng là hai sự kiện riêng biệt.

Cách chữa là bật versioning. Khi ấy mỗi lần ghi tạo ra một version ID riêng, nên S3 coi chúng là hai sự kiện khác nhau và gửi đủ hai notification:

aws s3api put-bucket-versioning --bucket kho-kiem-toan \
  --versioning-configuration Status=Enabled

Với dữ liệu kiểm toán như trong đề, bật versioning là điều nên làm dù sao đi nữa — nó còn cho khả năng khôi phục khi bị ghi đè hoặc xoá nhầm.

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

• B. "Ai đó tạo cấu hình notification mới ghi đè cấu hình cũ" — có thể xảy ra (S3 chỉ có một notification configuration mỗi bucket, nên PutBucketNotificationConfiguration ghi đè toàn bộ), nhưng khi đó bạn sẽ mất TẤT CẢ notification, không phải mất rải rác vài cái. Triệu chứng không khớp.
• C. "Notification action ghi vào chính bucket đang kích hoạt notification" — đây mô tả vòng lặp đệ quy, và hậu quả là quá nhiều notification (và chi phí tăng vọt), không phải thiếu notification.
• D. "Versioning đang bật và event chỉ bắn cho một version" — ngược với thực tế: versioning làm event notification đáng tin cậy hơn, không kém đi. Và đề nói đang thiếu event, tức là versioning nhiều khả năng chưa bật.

Ghi nhớ

Đảm bảo và giới hạn của S3 Event Notification: | Đặc điểm | Chi tiết | |---|---| | Đảm bảo giao | at-least-once (có thể trùng, hiếm) | | Độ trễ | thường dưới một giây, nhưng không đảm bảo | | Ghi đồng thời không versioning | có thể mất event | | Thứ tự | không đảm bảo | | Cấu hình | một notification configuration mỗi bucket |

Ba khuyến nghị cho hệ thống cần độ tin cậy cao:

1. Bật versioning — vừa chống mất event, vừa chống mất dữ liệu
2. Thiết kế consumer idempotent — vì giao là at-least-once
3. Cân nhắc EventBridge thay cho notification trực tiếp — nó có retry, DLQ, và lọc mạnh hơn

Đáp án

D — Tăng RAM cấp cho hàm Lambda.

Vì sao đúng

Đề nói rõ các hàm xử lý workload nặng (phân tích dữ liệu lớn, xử lý tệp lớn, tính toán thống kê) và cần cải thiện hiệu năng mà không đổi mã.

Với Lambda, đây là tình huống có đúng một câu trả lời — vì một đặc điểm nền tảng:

Lambda không cho cấu hình CPU. CPU được cấp TỶ LỆ THUẬN với bộ nhớ.

Nên tăng RAM là cách duy nhất để có thêm sức tính toán — và nó thường không làm tăng chi phí:

128 MB  × 10 giây = 1.280 MB-giây
1.024 MB × 1 giây = 1.024 MB-giây   ← nhanh gấp 10 lần VÀ rẻ hơn

Vì Lambda tính tiền theo GB-giây, hàm chạy nhanh gấp N lần với bộ nhớ gấp N lần có chi phí tương đương. Và trên mốc 1.769 MB, hàm còn dùng được đa luồng — rất đáng kể với workload song song hoá được như phân tích dữ liệu.

Công cụ nên dùng: AWS Lambda Power Tuning chạy thử ở nhiều mức bộ nhớ và vẽ biểu đồ chi phí – thời gian để tìm điểm tối ưu, thay vì đoán.

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

• A. "Đổi instance type cho Lambda" — Lambda không có instance type. Đó là khái niệm của EC2. Bạn không chọn phần cứng cho Lambda; bạn chỉ chọn bộ nhớ (và kiến trúc x86_64 hay arm64).
• C. Tăng timeout — chỉ cho phép hàm chạy lâu hơn trước khi bị cắt. Nó không tăng tốc gì cả; thực tế còn đi ngược mục tiêu cải thiện hiệu năng.
• B. Đổi runtime sang Golang — Go có nhanh hơn Python hay Node.js cho tính toán nặng, nhưng đây là viết lại toàn bộ mã — trái thẳng ràng buộc "without changing the code".

Ghi nhớ

Và một tối ưu miễn phí đáng thử với workload nặng: chuyển sang kiến trúc arm64 (Graviton2) — thường nhanh hơn ~20% và rẻ hơn ~20% cho cùng cấu hình, chỉ cần đổi một thiết lập nếu runtime hỗ trợ.

Đáp án

D — Dùng trường Export trong Outputs của network stack, rồi dùng Fn::ImportValue ở web application stack.

Vì sao đúng

Chia sẻ giá trị giữa hai stack CloudFormation đi theo một cặp cố định, và câu hỏi kiểm tra xem bạn nhớ đúng cả hai vế:

Network stack — công bố bằng Export:

Outputs:
  IdVPC:
    Description: VPC dùng cho tầng ứng dụng
    Value: !Ref VPCChinh
    Export:
      Name: !Sub "${AWS::StackName}-IdVPC"    # → mang-luoi-IdVPC

Web application stack — tiêu thụ bằng Fn::ImportValue:

Resources:
  NhomBaoMat:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !ImportValue mang-luoi-IdVPC

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

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

Ba phương án còn lại đều sai đúng một vế, và đó là cách câu hỏi được thiết kế:

• A. Outputs + Fn::ImportValue — sai vế đầu. Chỉ khai trong Outputs mà không có Export thì giá trị không nhìn thấy được từ stack khác; nó chỉ hiện trong DescribeStacks của chính stack đó.
• C. Export + Ref — sai vế sau. !Ref chỉ hoạt động trong CÙNG một stack — nó tham chiếu parameter hoặc tài nguyên nội bộ, không nhìn thấy export của stack khác.
• B. Outputs + Ref — sai cả hai vế.

Ghi nhớ

Phạm vi của các intrinsic function: | Hàm | Lấy gì | Phạm vi | |---|---|---| | !Ref | giá trị parameter / ID tài nguyên | cùng stack | | !GetAtt | thuộc tính của tài nguyên | cùng stack | | !ImportValue | giá trị đã export | stack khác (cùng tài khoản + Region) |

Ba ràng buộc của cross-stack reference: | Ràng buộc | Chi tiết | |---|---| | Tên export duy nhất | trong một tài khoản + Region | | Không xuyên Region hay tài khoản | — | | Không xoá export đang bị import | phải gỡ stack tiêu thụ trước |

Mẹo đặt tên: đưa ${AWS::StackName} vào tên export để tránh trùng. Và cần chia sẻ xuyên Region thì dùng SSM Parameter Store thay cho export.

Đáp án

B — Tạo saved configuration ở tài khoản A, tải về máy, sửa các tham số đặc thù theo tài khoản, rồi tải lên bucket S3 ở tài khoản B.

Vì sao đúng

Saved configuration là ảnh chụp toàn bộ cấu hình một môi trường Beanstalk: instance type, biến môi trường, thiết lập auto scaling, cấu hình load balancer, deployment policy.

Nó được lưu dưới dạng tệp YAML trong bucket S3 của Elastic Beanstalk trong chính tài khoản đó:

s3://elasticbeanstalk-<region>-<account-id>/resources/templates/<app>/<ten-cau-hinh>

Vì bucket đó thuộc về từng tài khoản, việc di chuyển sang tài khoản khác phải làm thủ công:

# 1. Ở tài khoản A — lưu và tải về
aws elasticbeanstalk create-configuration-template \
  --application-name ung-dung --template-name cau-hinh-prod \
  --environment-id e-xxxxx
aws s3 cp s3://elasticbeanstalk-.../templates/ung-dung/cau-hinh-prod ./cau-hinh.yml

# 2. Sửa các giá trị đặc thù theo tài khoản
#    - ARN của IAM role / instance profile
#    - ID của subnet, VPC, security group
#    - ARN chứng chỉ ACM
#    - ARN của SNS topic

# 3. Ở tài khoản B — tải lên đúng vị trí rồi tạo môi trường
aws s3 cp ./cau-hinh.yml s3://elasticbeanstalk-<region>-<account-B>/resources/templates/ung-dung/cau-hinh-prod

Bước sửa tham số là bắt buộc, và đó là lý do phương án này đúng: ARN và ID tài nguyên không dùng chung giữa các tài khoản.

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

• A. "Cấu hình Export ở tài khoản A rồi chọn Import ở tài khoản B" — Elastic Beanstalk không có chức năng Export/Import cho saved configuration. Không có nút nào như vậy trong Console hay lệnh nào trong CLI.
• D. "Tạo export configuration rồi chia sẻ với IAM Role của tài khoản B" — cùng vấn đề: không tồn tại cơ chế "export configuration" có thể chia sẻ qua IAM role.
• C. "Không thể migrate môi trường Beanstalk giữa các tài khoản" — sai. Làm được, chỉ là thủ công như phương án B mô tả.

Ghi nhớ

Saved configuration lưu cấu hình môi trường, không lưu: | Không đi kèm | Phải xử lý riêng | |---|---| | Mã ứng dụng | tải application version lên tài khoản mới | | Dữ liệu CSDL | snapshot RDS và chia sẻ, hoặc dump/restore | | ARN, ID tài nguyên | sửa tay trong tệp cấu hình | | Bí mật trong Parameter Store / Secrets Manager | tạo lại ở tài khoản mới |

Cách bền vững hơn cho việc này: dựng môi trường bằng CloudFormation hoặc CDK với parameter cho các giá trị đặc thù theo tài khoản. Khi ấy "di trú" chỉ là chạy cùng một template với bộ parameter khác — không có bước sửa tay nào.

Đáp án

A — AWS CloudTrail.

Vì sao đúng

Câu hỏi rất cụ thể: ai đã thay đổi cấu hình pipeline. Đó chính xác là điều CloudTrail được sinh ra để trả lời.

CloudTrail ghi lại mọi lời gọi API tới AWS, kèm đầy đủ ngữ cảnh:

{
  "eventTime": "2026-08-27T14:22:11Z",
  "eventSource": "codepipeline.amazonaws.com",
  "eventName": "UpdatePipeline",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "nguyen.van.a",
    "arn": "arn:aws:iam::123456789012:user/nguyen.van.a"
  },
  "sourceIPAddress": "203.0.113.45",
  "requestParameters": {"pipeline": {"name": "pipeline-chinh", "stages": [...]}}
}

Ba trường quan trọng nhất: userIdentity (ai), eventTime (khi nào), sourceIPAddress (từ đâu).

Cách tìm nhanh trong Event History:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=UpdatePipeline \
  --start-time 2026-08-20 --end-time 2026-08-28

Lưu ý về thời gian giữ: CloudTrail Event History chỉ lưu 90 ngày. Muốn giữ lâu hơn thì phải tạo trail ghi vào S3 — nên với yêu cầu kiểm toán, hãy bật trail ngay từ đầu.

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

• B. Amazon CloudWatch — thu thập metric và log. Nó cho biết pipeline thất bại lúc nào và ra sao, nhưng không cho biết ai đã sửa cấu hình.
• C. AWS X-Ray — công cụ theo dấu request phân tán, phân tích độ trễ trong ứng dụng. Hoàn toàn không liên quan tới việc kiểm toán thay đổi cấu hình.
• D. Amazon Inspector — quét lỗ hổng phần mềm và phơi nhiễm mạng trên EC2, container, Lambda. Không phải công cụ kiểm toán hành động người dùng.

Ghi nhớ

Bốn công cụ quan sát của AWS, mỗi cái trả lời một câu hỏi: | Công cụ | Trả lời | |---|---| | CloudTrail | AI đã gọi API nào, khi nào, từ đâu? | | CloudWatch Logs | Ứng dụng đã ghi gì? | | CloudWatch Metrics | Số liệu đang ở mức nào? | | X-Ray | Request chậm ở chặng nào? | | AWS Config | Cấu hình tài nguyên đã thay đổi thế nào theo thời gian? |

Nhận dạng nhanh: đề nói "who", "audit", "record of actions taken by a user" ⇒ CloudTrail.

(AWS Config bổ sung tốt cho CloudTrail: CloudTrail nói ai gọi API, Config nói cấu hình trước và sau khác nhau ra sao — dùng cả hai cho kiểm toán đầy đủ.)

Đáp án

A — ECS_ENABLE_TASK_IAM_ROLE.

Vì sao đúng

Vấn đề: task definition đã được gán role, nhưng container không dùng được quyền đó.

Với EC2 launch type, việc cho phép task dùng IAM role riêng là một tính năng phải bật tường minh trong cấu hình ECS agent:

# /etc/ecs/ecs.config
ECS_CLUSTER=cum-san-xuat
ECS_ENABLE_TASK_IAM_ROLE=true
ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true

Cơ chế bên dưới: ECS agent dựng một endpoint credential riêng cho mỗi task tại 169.254.170.2, và đặt biến môi trường AWS_CONTAINER_CREDENTIALS_RELATIVE_URI trong container. SDK tự tìm thấy và dùng thông tin xác thực đó.

Không bật cờ này thì container rơi về dùng instance profile của EC2 — tức là mọi task trên máy đều có cùng quyền, phá vỡ hoàn toàn nguyên tắc đặc quyền tối thiểu.

Cấu hình phải được ghi trước khi ECS agent khởi động, thường qua user data:

#!/bin/bash
echo "ECS_CLUSTER=${TenCluster}" >> /etc/ecs/ecs.config
echo "ECS_ENABLE_TASK_IAM_ROLE=true" >> /etc/ecs/ecs.config

(Với Fargate, task IAM role luôn bật và không có tệp cấu hình nào để chỉnh.)

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

• B. ECS_CLUSTER — khai instance đăng ký vào cluster nào. Quan trọng, nhưng không liên quan tới IAM role của task.
• C. ECS_AVAILABLE_LOGGING_DRIVERS — khai các log driver container dùng được (awslogs, json-file, fluentd, splunk). Về ghi log, không về phân quyền.
• D. ECS_ENGINE_AUTH_DATA — thông tin xác thực để kéo image từ registry riêng (Docker Hub private, registry bên thứ ba). Về kéo image, không về quyền lúc chạy.

Ghi nhớ

Các biến cấu hình quan trọng trong /etc/ecs/ecs.config: | Biến | Vai trò | |---|---| | ECS_CLUSTER | cluster để đăng ký vào | | ECS_ENABLE_TASK_IAM_ROLE | cho phép task dùng IAM role riêng | | ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST | cho phép cả với network mode host | | ECS_AVAILABLE_LOGGING_DRIVERS | log driver dùng được | | ECS_ENGINE_AUTH_DATA | xác thực với registry riêng |

Và phân biệt hai role của ECS — bị nhầm rất thường xuyên: | Role | Ai dùng | Để làm gì | |---|---|---| | Task execution role | ECS agent | kéo image từ ECR, ghi log lên CloudWatch | | Task role | mã trong container | gọi S3, DynamoDB, SQS… |

Nơi gỡ lỗi: /var/log/ecs/ecs-agent.log trên container instance.

Đáp án

D — Tạo Lambda@Edge function chuyển hướng theo header CloudFront-Viewer-Country, gắn vào sự kiện origin request của distribution.

Vì sao đúng

Câu hỏi có hai điểm phân biệt, và cả hai đều nằm trong chi tiết nhỏ.

Điểm 1 — origin request, không phải viewer request. Đề nói rõ chỉ chuyển hướng khi cache miss:

Gắn vào viewer request sẽ chạy hàm ở mọi request — tốn kém và thừa, vì cache hit không cần chọn origin. Origin request là đúng chỗ.

Điểm 2 — Lambda@Edge, không phải CloudFront Functions. Đây là ràng buộc cứng:

CloudFront Functions KHÔNG hỗ trợ origin request event — nên nó không dùng được cho bài toán này, dù rẻ hơn và nhanh hơn.

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const country = request.headers['cloudfront-viewer-country'][0].value;
  const bucket = {VN: 's3-ap-southeast-1', DE: 's3-eu-central-1'}[country] || 's3-us-east-1';
  request.origin.s3.domainName = `${bucket}.s3.amazonaws.com`;
  return request;
};

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

• A. Lambda@Edge nhưng gắn vào viewer request — đúng công nghệ, sai sự kiện: chạy ở mọi request thay vì chỉ cache miss.
• B và C. CloudFront Functions — không hỗ trợ origin request event (C), và với viewer request (B) thì cùng vấn đề với A. Ngoài ra CloudFront Functions không sửa được request.origin.

Ghi nhớ

Bốn sự kiện của CloudFront và cái nào dùng được gì:

Viewer  ──①viewer request──→ CloudFront ──②origin request──→ Origin
        ←─④viewer response──            ←─③origin response──

Quy tắc chọn: cần chạm vào origin (đổi origin, sửa header gửi tới origin, xử lý cache miss) ⇒ Lambda@Edge. Chỉ sửa request/response ở phía viewer (viết lại URL, thêm header bảo mật, kiểm token đơn giản) ⇒ CloudFront Functions — rẻ hơn khoảng 6 lần và nhanh hơn.

Đáp án

B — !GetAtt (Fn::GetAtt).

Vì sao đúng

Fn::GetAtt lấy một thuộc tính cụ thể của tài nguyên đã tạo — và endpoint của RDS chính là một thuộc tính như vậy:

Outputs:
  EndpointCSDL:
    Description: Địa chỉ kết nối tới RDS
    Value: !GetAtt CoSoDuLieu.Endpoint.Address
  CongCSDL:
    Value: !GetAtt CoSoDuLieu.Endpoint.Port

Cú pháp: !GetAtt <TenLogicTaiNguyen>.<TenThuocTinh>, và thuộc tính có thể lồng nhau (Endpoint.Address).

Vài thuộc tính hay dùng: | Tài nguyên | Thuộc tính | |---|---| | AWS::RDS::DBInstance | Endpoint.Address, Endpoint.Port | | AWS::S3::Bucket | Arn, DomainName, WebsiteURL | | AWS::EC2::Instance | PublicIp, PrivateIp, AvailabilityZone | | AWS::ElasticLoadBalancingV2::LoadBalancer | DNSName, CanonicalHostedZoneID | | AWS::Lambda::Function | Arn |

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

• C. !Ref — đây là bẫy chính, và khác biệt rất quan trọng: !Ref trả về "giá trị mặc định" của tài nguyên, mà mỗi loại tài nguyên định nghĩa khác nhau. Với AWS::RDS::DBInstance, !Ref trả về DB instance identifier (ví dụ csdl-prod), không phải endpoint. Muốn endpoint thì bắt buộc dùng !GetAtt.

  Tài nguyên	!Ref trả về
  AWS::RDS::DBInstance	DB instance identifier
  AWS::S3::Bucket	tên bucket
  AWS::EC2::Instance	instance ID
  Parameter	giá trị của parameter

• D. !Sub — thay thế chuỗi: chèn biến vào một chuỗi mẫu. Nó không tự lấy được thuộc tính, dù kết hợp được: !Sub "postgres://${CoSoDuLieu.Endpoint.Address}:5432/app".

• A. !FindInMap — tra cứu giá trị tĩnh trong section Mappings (ví dụ AMI ID theo Region). Nó không đọc được thuộc tính của tài nguyên đã tạo.

Ghi nhớ

Bốn intrinsic function hay dùng nhất: | Hàm | Lấy gì | |---|---| | !Ref | giá trị mặc định của tài nguyên hoặc parameter | | !GetAtt | một thuộc tính cụ thể của tài nguyên | | !Sub | thay thế biến trong chuỗi | | !FindInMap | tra cứu tĩnh trong Mappings |

Mẹo phân biệt: !Ref cho MỘT giá trị duy nhất mà tài nguyên tự định nghĩa; !GetAtt cho BẤT KỲ thuộc tính nào bạn chọn. Khi không chắc !Ref trả về gì, tra tài liệu của loại tài nguyên đó — mỗi loại khác nhau.

Đáp án

B — Đặt hai container vào MỘT task definition, dùng Fargate launch type.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi yêu cầu chọn một nửa của đáp án:

"Hai container CHIA SẺ TÀI NGUYÊN" ⇒ cùng một task definition. Đây là khái niệm cốt lõi của ECS: task là đơn vị lập lịch, và các container trong cùng một task:

Đặt vào hai task definition riêng thì chúng thành hai đơn vị độc lập — có thể chạy trên hai máy khác nhau, không chia sẻ gì cả, và phải gọi nhau qua service discovery.

"Serverless" ⇒ Fargate launch type. Fargate là chế độ không cần quản máy chủ: không cụm EC2, không vá hệ điều hành, trả tiền theo vCPU và bộ nhớ mà task thực sự dùng, tính theo giây.

{
  "family": "kho-du-lieu",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "1024", "memory": "2048",
  "containerDefinitions": [
    {"name": "db-engine", "image": "...ecr.../engine:v1",
     "mountPoints": [{"sourceVolume": "du-lieu", "containerPath": "/data"}]},
    {"name": "sidecar-backup", "image": "...ecr.../backup:v1",
     "mountPoints": [{"sourceVolume": "du-lieu", "containerPath": "/data"}]}
  ],
  "volumes": [{"name": "du-lieu"}]
}

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

• A. Một task definition với EC2 launch type — đúng vế chia sẻ tài nguyên, nhưng không serverless: phải quản cụm EC2, vá, tính dung lượng cluster, và trả tiền theo giờ instance kể cả lúc rảnh.
• C và D. Hai task definition riêng — dù dùng launch type nào cũng không chia sẻ tài nguyên: hai task là hai đơn vị độc lập, có thể nằm ở hai nơi, không dùng chung network namespace hay volume.

Ghi nhớ

Phân cấp của ECS: | Khái niệm | Là gì | |---|---| | Container | một image đang chạy | | Task definition | bản thiết kế: một hoặc nhiều container chia sẻ tài nguyên | | Task | một bản đang chạy của task definition | | Service | giữ N task luôn chạy |

Sidecar pattern — mẫu dùng nhiều container trong một task — rất phổ biến: | Sidecar | Việc | |---|---| | X-Ray daemon | thu thập trace | | Fluent Bit / FireLens | chuyển tiếp log | | Envoy | service mesh (App Mesh) | | Backup agent | sao lưu dữ liệu chung |

Và nhớ vài giới hạn của Fargate: không dùng GPU, không truy cập host, và network mode bắt buộc là awsvpc (mỗi task có ENI riêng).

Đáp án

A — Amazon S3.

Vì sao đúng

CloudFormation template là tệp văn bản (YAML hoặc JSON), và S3 là nơi lưu chuẩn cho chúng — không chỉ vì tiện, mà vì CloudFormation đọc trực tiếp từ S3:

aws cloudformation create-stack --stack-name ung-dung \
  --template-url https://s3.ap-southeast-1.amazonaws.com/kho-template/app.yaml \
  --parameters ParameterKey=TenKhachHang,ParameterValue=cong-ty-a

Và đây không phải tuỳ chọn mà là bắt buộc trong một số trường hợp:

Ba lợi ích khác của việc lưu template trên S3:

• Versioning — giữ lịch sử mọi phiên bản template, khôi phục được
• Phân quyền bằng IAM và bucket policy — chia sẻ chéo tài khoản dễ dàng
• Chi phí rất thấp cho tệp văn bản

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

• B. Amazon ECR — kho chứa Docker image, không phải tệp văn bản. Nó dùng định dạng image manifest, không lưu YAML/JSON tuỳ ý. (Về mặt kỹ thuật ECR có hỗ trợ OCI artifact, nhưng đó không phải cách CloudFormation đọc template.)
• C. Amazon EFS — hệ thống tệp NFS gắn vào EC2 hoặc container trong VPC. CloudFormation không đọc template từ EFS, và nó đắt hơn S3 nhiều lần cho việc lưu vài tệp văn bản.
• D. Amazon EBS — ổ đĩa khối gắn vào một EC2 instance trong một AZ. Không chia sẻ được, không truy cập qua API, và CloudFormation không đọc được từ đó.

Ghi nhớ

Chọn nơi lưu theo loại dữ liệu: | Loại dữ liệu | Dịch vụ | |---|---| | Tệp văn bản, artifact, template | S3 | | Docker image | ECR | | Hệ thống tệp POSIX chia sẻ | EFS | | Ổ đĩa cho một instance | EBS | | Gói phụ thuộc (npm, Maven, pip) | CodeArtifact | | Mã nguồn | CodeCommit, GitHub |

Khuyến nghị cho bucket chứa template: bật versioning, bật mã hoá mặc định, và giới hạn quyền ghi — template là mã hạ tầng, ai sửa được nó thì sửa được cả hệ thống.