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

Đáp án

C — AWS CodePipeline.

Vì sao đúng

Đề yêu cầu tự động hoá cả ba giai đoạn — build, test, deploy — mỗi khi mã nguồn thay đổi. Đó là định nghĩa của một pipeline điều phối, và CodePipeline là dịch vụ làm việc đó.

CodePipeline không tự build hay tự deploy — nó điều phối các dịch vụ khác theo thứ tự và theo điều kiện:

Source          Build           Test            Deploy
(CodeCommit,  → (CodeBuild)  → (CodeBuild)  → (CodeDeploy, ECS,
 GitHub, S3)                                   Beanstalk, CloudFormation)
      ↑
  thay đổi mã → pipeline tự chạy

Các tính năng khiến nó phù hợp với quy trình Agile trong đề: | Tính năng | Chi tiết | |---|---| | Kích hoạt tự động | mọi commit đều chạy pipeline | | Nhiều stage, nhiều action | chạy song song hoặc tuần tự | | Manual approval | chèn bước duyệt trước khi lên production | | Tích hợp rộng | CodeBuild, CodeDeploy, ECS, Lambda, CloudFormation, cả công cụ bên thứ ba | | Dừng khi lỗi | stage hỏng thì các stage sau không chạy |

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

• B. AWS CodeBuild — đây là phương án gần nhất và cần phân biệt rõ: CodeBuild biên dịch mã và chạy test — nó phụ trách hai trong ba giai đoạn. Nhưng nó không triển khai và không điều phối gì cả. Nó là một action bên trong pipeline, không phải cái bao trùm.
• D. AWS Elastic Beanstalk — nền tảng chạy ứng dụng, lo hạ tầng và triển khai. Nó không build, không test, và không tự chạy khi mã thay đổi. Nó là đích đến của pipeline.
• A. AWS CloudFormation — công cụ hạ tầng dưới dạng mã: tạo và cập nhật tài nguyên AWS. Nó không build, không test, và cũng là một action trong pipeline chứ không phải bộ điều phối.

Ghi nhớ

Vai trò của từng dịch vụ trong bộ công cụ phát triển của AWS: | Dịch vụ | Vai trò | |---|---| | CodeCommit | kho mã Git | | CodeBuild | biên dịch, chạy test, đóng gói artifact | | CodeDeploy | triển khai lên EC2, ECS, Lambda, on-premises | | CodePipeline | ĐIỀU PHỐI toàn bộ — cái bao trùm | | CodeArtifact | kho package (npm, Maven, PyPI) | | CodeGuru | review mã và phân tích hiệu năng bằng ML |

Câu thần chú: CodePipeline là nhạc trưởng; CodeBuild và CodeDeploy là nhạc công. Đề hỏi về toàn bộ quy trình từ commit tới production ⇒ CodePipeline. Đề chỉ hỏi về biên dịch và test ⇒ CodeBuild. Đề chỉ hỏi về đưa mã lên máy chủ ⇒ CodeDeploy.

Một pipeline điển hình khai bằng CLI hoặc CloudFormation:

stages:
  - name: Source
    actions: [{provider: CodeStarSourceConnection, ...}]   # GitHub
  - name: Build
    actions: [{provider: CodeBuild, ...}]
  - name: Test
    actions: [{provider: CodeBuild, ...}]
  - name: DuyetThuCong
    actions: [{provider: Manual, ...}]                     # chờ người duyệt
  - name: Deploy
    actions: [{provider: CodeDeploy, ...}]

(Ghi chú thời sự: CodeCommit ngừng nhận khách hàng mới từ tháng 7/2024, nhưng CodePipeline vẫn phát triển bình thường và làm việc tốt với GitHub, GitLab, Bitbucket qua CodeStar Connections. Với dự án mới, đó là cách nối nguồn mã được khuyến nghị.)

Đáp án

C — Dùng Amazon CloudFront để cache nội dung website.

Vì sao đúng

Vấn đề: website nằm ở một Region duy nhất (us-east-1) nhưng người xem ở khắp thế giới. Người dùng ở châu Á phải chờ dữ liệu đi vòng qua nửa vòng trái đất cho mọi tệp ảnh.

CloudFront giải quyết bằng cách cache nội dung tại hơn 400 edge location trên toàn cầu:

Trước: Người dùng ở Singapore ──────── 200 ms ────────→ S3 us-east-1
Sau:   Người dùng ở Singapore → 10 ms → Edge Singapore → (chỉ lần đầu) → S3

Với website ảnh, hiệu quả đặc biệt rõ vì ảnh là nội dung tĩnh, cache rất tốt: lần đầu có người ở Singapore xem thì edge kéo về và giữ lại; mọi người xem sau đó đều được phục vụ ngay tại chỗ.

Lợi ích kèm theo, và chúng không nhỏ: | Lợi ích | Chi tiết | |---|---| | Giảm chi phí | truyền dữ liệu qua CloudFront rẻ hơn truyền trực tiếp từ S3 | | Giảm tải cho origin | phần lớn request không chạm tới S3 | | HTTPS với tên miền riêng | S3 static website endpoint không hỗ trợ HTTPS | | Bucket có thể để riêng tư | qua Origin Access Control | | Nén tự động | Gzip, Brotli |

Cấu hình tối thiểu:

{
  "Origins": [{"DomainName": "kho-anh.s3.us-east-1.amazonaws.com",
               "OriginAccessControlId": "E1ABCDEF"}],
  "DefaultCacheBehavior": {
    "ViewerProtocolPolicy": "redirect-to-https",
    "CachePolicyId": "658327ea-f89d-4fab-a63d-7e88639e58f6",
    "Compress": true
  }
}

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

• A. S3 Transfer Acceleration — đây là bẫy chính, và khác biệt rất đáng nhớ: Transfer Acceleration tối ưu cho việc TẢI LÊN (upload) từ xa, bằng cách đi qua edge của CloudFront rồi qua mạng backbone của AWS. Website ảnh là bài toán TẢI XUỐNG cho hàng nghìn người xem — Transfer Acceleration không cache gì cả, nên mỗi lượt xem vẫn phải lấy dữ liệu từ us-east-1, và còn tính phí thêm cho mỗi GB.
• B. Cross-region replication sang nhiều Region — chạy được nhưng là cách đắt và phức tạp nhất: bạn nhân đôi (hoặc nhân năm) chi phí lưu trữ, phải tự định tuyến người dùng tới bucket gần nhất bằng Route 53 latency routing, và phải quản lý việc đồng bộ. CloudFront làm tốt hơn với một phần chi phí.
• D. ElastiCache — cache trong bộ nhớ cho ứng dụng, nằm trong VPC của bạn ở một Region. Nó không phục vụ được nội dung web cho người dùng Internet, và không có mặt ở edge.

Ghi nhớ

Phân biệt hai dịch vụ dùng chung hạ tầng edge nhưng khác mục đích: | | CloudFront | S3 Transfer Acceleration | |---|---|---| | Tối ưu cho | TẢI XUỐNG, nhiều người xem | TẢI LÊN từ xa | | Cache | ✅ | ❌ | | Dùng khi | phân phối nội dung | upload tệp lớn xuyên lục địa |

Nhận dạng nhanh:

• "global users", "improve performance", "static content" ⇒ CloudFront
• "upload large files from distant locations" ⇒ Transfer Acceleration
• "disaster recovery", "data residency" ⇒ Cross-region replication

Kiến trúc chuẩn cho website tĩnh phục vụ toàn cầu:

Route 53 → CloudFront (ACM cert ở us-east-1, OAC) → S3 bucket riêng tư

Ba điểm cần nhớ trong kiến trúc này: chứng chỉ ACM cho CloudFront bắt buộc ở us-east-1, OAC thay thế OAI cũ để giữ bucket riêng tư, và đặt TTL phù hợp — ảnh ít đổi thì để TTL dài, và dùng URL có phiên bản (anh-v2.jpg) thay vì gọi invalidation mỗi lần cập nhật.

Đáp án

C và D.

• C — Tạo resource /products.
• D — Tạo method GET.

Vì sao đúng

API Gateway có cấu trúc hai tầng, và thứ tự này là bắt buộc:

API: dctlabs.com
└── Resource: /products        ← C: ĐƯỜNG DẪN
    ├── Method: GET            ← D: ĐỘNG TỪ HTTP
    ├── Method: POST
    └── Resource: /{id}
        └── Method: GET

Resource phải tạo trước — method luôn được gắn vào một resource đã tồn tại. Đây là quan hệ cha–con, không đảo ngược được.

# 1. Tạo resource
aws apigateway create-resource --rest-api-id abc123 \
  --parent-id <id-cua-root> --path-part products

# 2. Tạo method trên resource đó
aws apigateway put-method --rest-api-id abc123 \
  --resource-id <id-cua-products> \
  --http-method GET --authorization-type NONE

Sau hai bước này còn phải cấu hình integration (trỏ tới Lambda hoặc backend), rồi deploy sang một stage thì URL mới hoạt động — nhưng đề chỉ hỏi về việc cấu hình đường dẫn và động từ.

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

• A. Tạo "GET resource" — đảo ngược hai khái niệm: GET là method, không phải resource. Resource là đoạn đường dẫn.
• B. Tạo "/products method" — cũng đảo ngược: /products là resource, không phải method.
• E. Tạo "/GET method" — nhầm lẫn nặng nhất: gộp cả dấu gạch chéo của đường dẫn với tên động từ. Không có cấu trúc nào như vậy.

Ba phương án sai này đều là cùng một lỗi hiểu được diễn đạt theo ba cách — đó là dấu hiệu cho thấy câu hỏi đang kiểm tra đúng một điều: bạn có phân biệt được resource với method không.

Ghi nhớ

Cấu trúc phân cấp đầy đủ của một REST API:

REST API
└── Resource (/)                      ← root
    └── Resource (/products)
        └── Method (GET)
            ├── Method Request        ← xác thực, tham số, validation
            ├── Integration Request    ← MAPPING TEMPLATE, backend
            ├── Integration Response   ← biến đổi phản hồi
            └── Method Response        ← mã trạng thái, header

Bốn khối trong một method, và biết cái nào làm gì rất hữu ích khi gỡ lỗi: | Khối | Việc | |---|---| | Method Request | authorizer, API key, request validator, khai tham số | | Integration Request | chọn backend, mapping template | | Integration Response | biến đổi phản hồi từ backend | | Method Response | khai mã trạng thái và header trả về client |

Vài kiểu resource đặc biệt: | Cú pháp | Nghĩa | |---|---| | /products | đường dẫn cố định | | /{id} | path parameter — đọc bằng $input.params('id') | | /{proxy+} | greedy path — khớp mọi đường dẫn còn lại | | ANY | method khớp mọi động từ HTTP |

Kết hợp /{proxy+} với method ANY cho phép chuyển toàn bộ định tuyến xuống backend — rất tiện khi đưa một ứng dụng web có sẵn (Express, Flask, Spring) lên Lambda mà không muốn khai từng đường dẫn trong API Gateway.

Và đừng quên bước cuối: mọi thay đổi chỉ có hiệu lực sau khi deploy sang stage. Sửa xong mà không deploy là một trong những nhầm lẫn phổ biến nhất với API Gateway — cấu hình trông đúng trong Console nhưng URL vẫn hành xử theo bản cũ.

Đáp án

C — Dùng VPC Flow Logs để kiểm tra traffic vào và ra của Subnet-Y.

Vì sao đúng

Câu hỏi rất cụ thể: traffic có thật sự tới được Subnet-Y hay không. Đó là câu hỏi ở tầng mạng, và VPC Flow Logs là công cụ duy nhất trong bốn phương án nhìn được tầng đó.

Flow Logs ghi lại metadata của mọi luồng IP đi qua ENI, subnet, hoặc cả VPC:

2 123456789012 eni-abc123 10.1.0.5 10.2.0.10 43521 22 6 20 1580 1628... ACCEPT OK
                          └─ nguồn ─┘ └─ đích ─┘         └ giao thức    └─ kết quả

Từ trường cuối, bạn đọc được ngay chuyện gì đang xảy ra: | Kết quả | Nghĩa | |---|---| | ACCEPT | traffic tới nơi và được cho qua ⇒ vấn đề nằm ở tầng ứng dụng hoặc định tuyến ngược | | REJECT | traffic tới nơi nhưng bị chặn ⇒ security group hoặc NACL | | Không có bản ghi nào | traffic KHÔNG hề tới subnet ⇒ vấn đề ở route table hoặc cấu hình VPN/BGP |

Trường hợp thứ ba đặc biệt quan trọng với tình huống trong đề: nếu Subnet-X hoạt động mà Subnet-Y thì không, và Flow Logs của Subnet-Y trống trơn, thì nguyên nhân gần như chắc chắn là route table hoặc quảng bá BGP không bao gồm dải của Subnet-Y.

aws ec2 create-flow-logs \
  --resource-type Subnet --resource-ids subnet-Y \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name /vpc/flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::123456789012:role/FlowLogsRole

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

• A. CloudWatch Logs của EC2 trong Subnet-Y — chỉ chứa những gì ứng dụng và hệ điều hành tự ghi ra. Nếu gói tin không tới được máy, sẽ không có dòng log nào — và bạn không phân biệt được "không tới" với "tới nhưng ứng dụng im lặng".
• B. CloudTrail — ghi lời gọi API quản trị (ai tạo instance, ai sửa security group). Nó không ghi luồng traffic ở mức network interface.
• D. AWS Config — theo dõi thay đổi cấu hình tài nguyên theo thời gian. Hữu ích để biết "ai đã đổi route table lúc nào", nhưng không cho biết gói tin có đi qua hay không.

(Ghi chú nhỏ về đề: ba phương án sai ở đây đều tự kèm sẵn câu giải thích vì sao chúng sai — dấu hiệu phần giải thích của nguồn bị trộn vào nội dung phương án. Không ảnh hưởng tới đáp án, nhưng nó khiến câu hỏi dễ hơn nhiều so với thực tế.)

Ghi nhớ

Ba điều cần biết về Flow Logs:

1. Không ghi nội dung gói tin — chỉ metadata. Cần nội dung thì dùng Traffic Mirroring.
2. Không bắt được một số loại traffic: DNS tới Amazon DNS server, DHCP, metadata service (169.254.169.254), traffic tới địa chỉ dành riêng của VPC router.
3. Không phải thời gian thực — bản ghi được gom lô, độ trễ khoảng 1 hoặc 10 phút tuỳ cấu hình.

Và với chẩn đoán kết nối, có một công cụ nhanh hơn nữa: VPC Reachability Analyzer — nó phân tích tĩnh cấu hình mạng và chỉ thẳng ra thành phần nào đang chặn đường, mà không cần chờ traffic thật đi qua.

Đáp án

A — Tạo CloudWatch cross-account cross-region dashboard.

Vì sao đúng

Đề hỏi cách ĐƠN GIẢN NHẤT, và CloudWatch đã có tính năng dựng sẵn cho đúng nhu cầu này — không cần viết mã, không cần sao chép dữ liệu.

Cách bật gồm hai bước cấu hình:

1. Trong tài khoản GIÁM SÁT (nơi đặt dashboard):
   CloudWatch Console → Settings → bật "cross-account cross-region"

2. Trong mỗi tài khoản NGUỒN:
   Tạo IAM role tên CloudWatch-CrossAccountSharingRole,
   tin cậy tài khoản giám sát, gắn policy CloudWatchReadOnlyAccess

(Với AWS Organizations, việc này còn gọn hơn: bật monitoring account một lần ở cấp tổ chức là mọi tài khoản thành viên tự chia sẻ.)

Sau đó widget chỉ cần khai accountId và region:

{
  "type": "metric",
  "properties": {
    "metrics": [["AWS/EC2", "CPUUtilization", {"accountId": "111122223333", "region": "us-east-1"}],
                ["AWS/EC2", "CPUUtilization", {"accountId": "444455556666", "region": "ap-southeast-1"}]],
    "title": "CPU toàn hệ thống"
  }
}

Điểm quan trọng: dữ liệu không bị sao chép đi đâu cả — CloudWatch đọc trực tiếp từ tài khoản nguồn khi vẽ biểu đồ. Nên không có độ trễ đồng bộ, không có chi phí lưu trữ trùng lặp, và không có đường ống nào phải bảo trì.

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

• B. "Nhập dữ liệu từ các tài khoản khác vào một dashboard" — không có cơ chế "import" metric trong CloudWatch. Metric nằm ở tài khoản và Region nơi chúng được sinh ra; bạn tham chiếu tới chúng chứ không nhập chúng về.
• C. Viết Lambda thu thập metric rồi đẩy về một tài khoản — chạy được nhưng phức tạp nhất: phải viết hàm, lên lịch chạy, xử lý lỗi, quản lý quyền chéo tài khoản, và trả tiền cho custom metric ở tài khoản đích. Ngoài ra dữ liệu sẽ trễ theo chu kỳ chạy. Trái hẳn yêu cầu "SIMPLEST". (Đây từng là cách duy nhất trước khi có tính năng cross-account — nên nó là bẫy dành cho người học theo tài liệu cũ.)
• D. CloudTrail trail đa Region đổ về một bucket S3 — sai loại dữ liệu: CloudTrail ghi lời gọi API quản trị, không phải metric hiệu năng. Bạn không dựng được biểu đồ CPU hay độ trễ từ CloudTrail.

Ghi nhớ

Các tính năng chéo tài khoản của CloudWatch: | Tính năng | Việc | |---|---| | Cross-account dashboard | xem metric của nhiều tài khoản trên một dashboard | | Cross-account alarm | đặt cảnh báo trên metric của tài khoản khác | | Logs cross-account subscription | gom log về một nơi | | Metric Streams | đẩy metric gần thời gian thực sang Firehose/đích ngoài |

Nguyên tắc chọn khi đề hỏi "SIMPLEST": ưu tiên tính năng có sẵn hơn là tự viết mã. Nếu một phương án nói "tạo Lambda để…" trong khi có phương án nói "bật tính năng X", thì phương án tự viết mã gần như luôn sai — trừ khi tính năng đó không tồn tại.

Và với giám sát ở quy mô tổ chức, cân nhắc thêm Amazon Managed Grafana: nó đọc được CloudWatch của nhiều tài khoản, cộng thêm Prometheus, X-Ray và nguồn ngoài AWS — hợp khi dashboard cần trộn nhiều nguồn dữ liệu khác nhau.

Đáp án

C và D.

• C — Bật API Gateway access logs.
• D — Bật API Gateway execution logging.

Vì sao đúng

Đề nêu hai nhu cầu khác nhau, và mỗi loại log phục vụ đúng một nhu cầu:

C — Access log ghi một dòng cho mỗi request, với định dạng do bạn khai:

$context.identity.sourceIp $context.identity.caller $context.identity.user
[$context.requestTime] "$context.httpMethod $context.resourcePath $context.protocol"
$context.status $context.responseLength $context.requestId
$context.authorizer.principalId

Dòng cuối đặc biệt hữu ích với Lambda authorizer: $context.authorizer.principalId cho biết authorizer đã xác định người gọi là ai — đúng vế "who has accessed the API".

D — Execution log ghi chi tiết xử lý nội bộ: quá trình gọi authorizer, kết quả trả về, policy được sinh ra, và stack trace khi có lỗi. Đây là nơi duy nhất thấy được vì sao authorizer thất bại.

Bật cả hai ở mức stage:

aws apigateway update-stage --rest-api-id abc123 --stage-name prod \
  --patch-operations \
    op=replace,path=/accessLogSettings/destinationArn,value=arn:aws:logs:...:log-group:api-access \
    op=replace,path=/accessLogSettings/format,value='...' \
    op=replace,path=/*/*/logging/loglevel,value=INFO \
    op=replace,path=/*/*/logging/dataTrace,value=true

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

• A. "Bật detailed logging trong CloudWatch" — không có thiết lập nào tên như vậy. CloudWatch nhận log, nó không quyết định API Gateway ghi gì. ("Detailed monitoring" là khái niệm của EC2, đổi chu kỳ metric từ 5 phút xuống 1 phút — hoàn toàn khác.)
• B. Bật server access logging — đây là tính năng của Amazon S3 (ghi lại request tới bucket). API Gateway không có thiết lập tên này.
• E. Tạo usage plan — usage plan quản lý API key, hạn ngạch và giới hạn tần suất cho từng khách hàng. Nó giúp kiểm soát ai dùng bao nhiêu, nhưng không sinh ra log nào.

Ghi nhớ

Hai loại log của API Gateway — khác nhau hoàn toàn: | | Access log | Execution log | |---|---|---| | Nội dung | một dòng mỗi request, định dạng tuỳ chọn | chi tiết xử lý nội bộ | | Mức | — | ERROR hoặc INFO | | Biến dùng được | chỉ $context | — | | Hợp cho | kiểm toán, phân tích | gỡ lỗi | | Ai quản log group | bạn chỉ định | API Gateway tự tạo |

Ba lưu ý khi bật:

1. Phải cấu hình account-level CloudWatch role một lần cho mỗi Region — thiếu nó thì không có log nào xuất hiện và cũng không có thông báo lỗi rõ ràng.
2. Phải redeploy stage sau khi đổi cấu hình.
3. dataTrace: true ghi cả request và response body — rất hữu ích khi gỡ lỗi authorizer, nhưng có thể lộ dữ liệu nhạy cảm và token. Bật tạm rồi tắt ngay, đừng để thường trực ở production.

Và với việc theo dõi hiệu năng qua nhiều chặng, bổ sung X-Ray tracing — nó cho thấy thời gian ở authorizer tách biệt với thời gian ở backend.

Đáp án

C — Tạo Amazon EFS file system.

Vì sao đúng

Đề nêu ba yêu cầu, và EFS là lựa chọn duy nhất thoả cả ba:

Vế cuối là chỗ loại các phương án khác: EFS là dịch vụ lưu trữ tệp duy nhất mà cả EC2 lẫn Lambda đều gắn được.

Với EC2, mount như thư mục thường:

sudo mount -t efs -o tls fs-0abc123:/ /mnt/du-lieu-chung

Với Lambda, khai file system config trỏ tới access point:

{
  "FileSystemConfigs": [{
    "Arn": "arn:aws:elasticfilesystem:...:access-point/fsap-0abc123",
    "LocalMountPath": "/mnt/du-lieu-chung"
  }]
}

Rồi mã đọc ghi như tệp cục bộ:

with open('/mnt/du-lieu-chung/ket-qua.json', 'w') as f:
    json.dump(du_lieu, f)

Điều kiện: Lambda phải gắn vào VPC có mount target của EFS.

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

• B. EBS Multi-Attach volume — nghe hợp lý nhưng vướng nhiều hạn chế: chỉ với volume io1/io2, chỉ trong cùng MỘT AZ, tối đa 16 instance, Lambda không gắn được, và quan trọng nhất — nó không tự co giãn (phải tự tăng dung lượng). Ngoài ra Multi-Attach đòi hệ thống tệp hỗ trợ truy cập đồng thời (cluster filesystem), chứ không dùng được ext4 hay xfs thông thường.
• A. ElastiCache — cache trong bộ nhớ, không phải hệ thống tệp. Không mount được, không có đường dẫn tệp, và dữ liệu không bền.
• D. Storage Gateway volume gateway — dịch vụ kết nối hạ tầng tại chỗ với AWS (cung cấp iSCSI volume cho máy chủ on-premises). Nó không phải kho tệp chia sẻ cho tài nguyên trong AWS, và Lambda không dùng được.

Ghi nhớ

Chọn dịch vụ lưu trữ theo nhu cầu: | Nhu cầu | Dịch vụ | |---|---| | Hệ thống tệp POSIX, nhiều máy, đa AZ | EFS | | Ổ đĩa khối cho một instance | EBS | | Kho object qua API | S3 | | Chia sẻ SMB cho Windows | FSx for Windows | | HPC, tích hợp S3 | FSx for Lustre | | Cầu nối với hạ tầng tại chỗ | Storage Gateway |

Điểm quan trọng nhất của câu này: EFS là lựa chọn duy nhất mà Lambda mount được như hệ thống tệp. Hễ đề nhắc tới Lambda + shared file storage, đáp án là EFS.

Khi nào EFS đáng dùng với Lambda: | Tình huống | Vì sao | |---|---| | Dữ liệu vượt quá 10 GB của /tmp | EFS không giới hạn | | Chia sẻ trạng thái giữa các lần gọi | /tmp không chia sẻ giữa các môi trường thực thi | | Thư viện hoặc mô hình ML rất nặng | tránh giới hạn 250 MB của gói triển khai | | Lambda và EC2 cùng xử lý một tập tệp | đúng tình huống của đề |

Và nhớ dùng EFS Access Point thay vì mount thẳng gốc: nó ép sẵn UID/GID và thư mục gốc riêng cho mỗi ứng dụng, nên các hàm không giẫm chân nhau.

Đáp án

C — Tạo bốn IAM role riêng biệt, mỗi role chứa quyền của một service, rồi cấu hình mỗi TASK DEFINITION tham chiếu tới role tương ứng.

Vì sao đúng

Điểm mấu chốt nằm ở chỗ gắn role vào đâu, và bối cảnh bin packing làm cho lựa chọn này trở nên quan trọng về mặt bảo mật.

Vì bin packing dồn nhiều container của nhiều service khác nhau lên cùng một EC2 instance, nên nếu quyền được gắn ở mức instance, mọi container trên máy đó đều thừa hưởng toàn bộ quyền của cả bốn service:

Instance EC2 (instance profile có quyền của cả 4 service)
├── Container service A  → dùng được quyền của cả B, C, D  ✗
├── Container service B  → dùng được quyền của cả A, C, D  ✗
└── Container service C  → …

Task role giải quyết bằng cách gắn quyền vào task definition, tức là vào từng container:

{
  "family": "service-thanh-toan",
  "taskRoleArn": "arn:aws:iam::123456789012:role/TaskRole-ThanhToan",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [...]
}

ECS agent lấy credential tạm thời cho từng task và cung cấp qua endpoint riêng của task, nên container chỉ thấy đúng quyền của mình — kể cả khi bốn service đang chạy chung một máy. Đó chính là nghĩa của "MOST securely" trong đề.

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

• B. Một instance profile chứa quyền của tất cả các service, gắn vào EC2 — đây là bẫy chính, và nó vi phạm đặc quyền tối thiểu nghiêm trọng như sơ đồ trên. Nếu một container bị chiếm quyền, kẻ tấn công có ngay quyền của cả bốn service.
• A. Bốn role, nhưng cấu hình mỗi ECS SERVICE tham chiếu role — sai chỗ khai: service definition không có trường role cho ứng dụng. Role được khai trong task definition (taskRoleArn); service chỉ quyết định chạy bao nhiêu bản sao và ở đâu.
• D. Bốn role, tạo IAM group và cho ECS cluster tham chiếu group — IAM group chỉ chứa IAM user, không chứa role và không gắn được vào dịch vụ. Cluster cũng không có khái niệm tham chiếu group.

Ghi nhớ

Ba loại role trong ECS — nhầm lẫn giữa chúng là lỗi phổ biến nhất: | Role | Ai dùng | Cho việc gì | |---|---|---| | Task role | mã trong container | gọi S3, DynamoDB, SQS… | | Task execution role | ECS agent | kéo image từ ECR, ghi log CloudWatch, đọc secret | | Instance profile (EC2 launch type) | ECS agent trên host | đăng ký instance vào cluster |

Cách nhớ nhanh:

• "Ứng dụng của tôi cần gọi dịch vụ AWS" ⇒ task role
• "Không kéo được image / không thấy log" ⇒ execution role
• "Instance không tham gia được cluster" ⇒ instance profile

Với Fargate, câu hỏi này biến mất phần lớn: không có EC2 instance nào để gắn quyền, nên bắt buộc phải dùng task role. Đó là một lý do nữa để chọn Fargate khi ưu tiên bảo mật.

Và một biện pháp tăng cường cho EC2 launch type: đặt biến ECS_AWSVPC_BLOCK_IMDS=true (hoặc dùng network mode awsvpc) để chặn container truy cập instance metadata service — nếu không, container vẫn có thể tự lấy credential của instance profile bất chấp task role.

Đáp án

C — Dùng content-based routing của ALB: tạo target group riêng cho bản thử nghiệm và định tuyến các request mang cookie đặc thù sang đó.

Vì sao đúng

Yêu cầu: gửi một phần request thử nghiệm sang phiên bản test, hiệu quả nhất.

ALB có sẵn listener rule để định tuyến theo nội dung request — không cần thêm hạ tầng nào:

{
  "Conditions": [{
    "Field": "http-header",
    "HttpHeaderConfig": {
      "HttpHeaderName": "Cookie",
      "Values": ["*phien-ban=thu-nghiem*"]
    }
  }],
  "Actions": [{"Type": "forward", "TargetGroupArn": "arn:...:targetgroup/nhom-thu-nghiem"}],
  "Priority": 10
}

Kết quả:

Request có cookie phien-ban=thu-nghiem  → target group THỬ NGHIỆM
Mọi request khác                         → target group PRODUCTION

Vì sao dùng cookie thay vì header hay đường dẫn: cookie bám theo phiên của người dùng. Một khi người kiểm thử được gán cookie, mọi request sau đó của họ đều đi cùng một hướng — nên trải nghiệm nhất quán, không bị nhảy qua lại giữa hai phiên bản giữa chừng.

Toàn bộ là cấu hình trên ALB có sẵn: không thêm load balancer, không thêm tên miền, không sửa mã ứng dụng.

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

• A. Nhân bản ứng dụng lên một EC2 riêng và định tuyến thủ công — "manually route" là điểm loại: không tự động, không mở rộng được, và người kiểm thử phải tự nhớ địa chỉ IP hay tên miền khác. Cũng mất luôn khả năng kiểm thử trên đúng đường đi của production.
• B. Dùng Lambda để xử lý request thử nghiệm rồi chuyển sang target group mới — Lambda không định tuyến tới target group; đó là việc của ALB. Phương án này thêm một tầng vô ích cho việc mà listener rule làm sẵn.
• D. Tạo bucket S3 mới chứa bản thử nghiệm và chuyển hướng mọi request thử nghiệm sang đó — S3 chỉ phục vụ nội dung tĩnh. Đề mô tả một ứng dụng chạy trên EC2 sau ALB — nó có logic phía máy chủ mà bucket S3 không chạy được.

Ghi nhớ

Các điều kiện định tuyến của ALB listener rule: | Điều kiện | Ví dụ | |---|---| | host-header | api.example.com, *.example.com | | path-pattern | /api/*, /img/* | | http-header | Cookie, User-Agent, header tuỳ chỉnh | | http-request-method | GET, POST | | query-string | ?version=beta | | source-ip | 203.0.113.0/24 |

Một rule kết hợp tối đa 5 điều kiện, và mỗi ALB có tối đa 100 rule.

Ngoài routing theo nội dung, ALB còn có weighted target group cho canary release — chia traffic theo tỷ lệ phần trăm:

"ForwardConfig": {
  "TargetGroups": [
    {"TargetGroupArn": "...production", "Weight": 95},
    {"TargetGroupArn": "...thu-nghiem", "Weight": 5}
  ],
  "TargetGroupStickinessConfig": {"Enabled": true, "DurationSeconds": 3600}
}

Cách chọn giữa hai cơ chế: | Nhu cầu | Cách | |---|---| | Nhóm người kiểm thử xác định (đội QA, nhân viên nội bộ) | routing theo cookie hoặc header | | Một tỷ lệ % người dùng thật (canary) | weighted target group |

Đề này nói "system request testing" — tức nhóm xác định, nên routing theo cookie là đúng.

Đáp án

A — Tạo role với quyền cần thiết trong tài khoản Production và Testing, rồi cho lập trình viên assume role đó.

Vì sao đúng

Đây là mẫu cross-account access chuẩn của AWS, và là cách duy nhất trong bốn phương án thật sự hoạt động.

Cơ chế gồm hai phía:

Phía tài khoản đích (Production/Testing) — tạo role với trust policy chấp nhận tài khoản Development:

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::<ID-tai-khoan-Development>:user/lap-trinh-vien"},
  "Action": "sts:AssumeRole",
  "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
}

Phía tài khoản nguồn (Development) — cấp quyền được assume:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": ["arn:aws:iam::<Production>:role/RoleLapTrinhVien",
               "arn:aws:iam::<Testing>:role/RoleLapTrinhVien"]
}

Rồi chuyển đổi bằng một dòng trong ~/.aws/config:

[profile production]
role_arn = arn:aws:iam::<Production>:role/RoleLapTrinhVien
source_profile = development
mfa_serial = arn:aws:iam::<Development>:mfa/lap-trinh-vien

aws ec2 run-instances --profile production ...

Vì sao đây là cách hiệu quả nhất: | Lợi ích | Chi tiết | |---|---| | Một danh tính duy nhất | chỉ một bộ credential dài hạn phải bảo vệ | | Credential tạm thời | hết hạn sau 1–12 giờ, giảm hẳn thiệt hại nếu bị lộ | | Vết kiểm toán rõ | CloudTrail ghi cả người assume lẫn hành động sau đó | | Thu hồi tức thì | sửa trust policy là mất quyền ngay | | Ép được MFA | qua condition key |

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

• B. Tạo IAM group ở Production/Testing rồi thêm user từ tài khoản Development vào — không làm được: IAM group chỉ chứa user của CHÍNH tài khoản đó. Không có cơ chế thêm user chéo tài khoản vào group.
• C. Tạo IAM user riêng ở mỗi tài khoản và đăng nhập riêng — chạy được nhưng kém nhất: ba bộ credential dài hạn phải quản lý và xoay vòng, ba lần đăng nhập, và khi lập trình viên nghỉ việc thì phải nhớ xoá ở cả ba nơi. Đây chính là vấn đề mà assume role sinh ra để giải.
• D. Tạo IAM permissions policy ở Production/Testing tham chiếu tới user ở Development — nhầm hai loại policy: identity-based policy không nhận principal chéo tài khoản. Chỉ resource-based policy (bucket policy, KMS key policy, trust policy của role) mới khai được principal từ tài khoản khác — và với việc cấp quyền chung như "khởi chạy tài nguyên" thì cơ chế đúng vẫn là role + trust policy.

Ghi nhớ

Hai loại policy và khả năng chéo tài khoản: | Loại | Gắn vào | Khai principal? | |---|---|---| | Identity-based | user, group, role | ❌ | | Resource-based | S3 bucket, SQS, SNS, KMS, trust policy của role | ✅ |

Các API của STS: | API | Dùng khi | |---|---| | AssumeRole | danh tính IAM assume role, kể cả chéo tài khoản | | AssumeRoleWithSAML | liên kết SAML từ IdP doanh nghiệp | | AssumeRoleWithWebIdentity | liên kết OIDC (Cognito, Google) | | GetSessionToken | lấy credential tạm thời có MFA cho chính user đó |

Hai thực hành nên áp dụng:

1. Ép MFA trong trust policy — với tài khoản production thì gần như bắt buộc.
2. Dùng ExternalId khi cấp quyền cho bên thứ ba (đối tác, nhà cung cấp dịch vụ), để chống confused deputy problem.

Và với tổ chức nhiều tài khoản, AWS IAM Identity Center (SSO) là bước tiến tiếp theo: nó bỏ hẳn IAM user, cho phép đăng nhập một lần rồi chọn tài khoản và role — cùng nguyên lý assume role nhưng không còn credential dài hạn nào cả.