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

Đáp án

D — Gửi HTTP header Cache-Control: max-age=0.

Vì sao đúng

API Gateway hỗ trợ client-side cache invalidation: client gửi header chuẩn HTTP và API Gateway bỏ qua cache, gọi thẳng backend, rồi lưu lại kết quả mới.

curl -H "Cache-Control: max-age=0" https://abc123.execute-api.ap-southeast-1.amazonaws.com/prod/du-lieu

Điểm quan trọng: quyền này phải được cấp tường minh, nếu không ai cũng làm rỗng cache của bạn được.

{
  "Effect": "Allow",
  "Action": "execute-api:InvalidateCache",
  "Resource": "arn:aws:execute-api:ap-southeast-1:123456789012:abc123/prod/GET/du-lieu"
}

Trong stage settings có ba lựa chọn cho hành vi khi client chưa được cấp quyền mà vẫn gửi header: | Lựa chọn | Kết quả | |---|---| | Ignore | bỏ qua header, trả về từ cache (mặc định) | | Fail with 403 | từ chối request | | Ignore + thêm header cảnh báo | trả từ cache, kèm cảnh báo |

Đây đúng là thứ đề cần: một cơ chế các đối tác tự nhúng được vào ứng dụng của họ, chỉ bằng một header HTTP.

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

• A. "Gọi một AWS API endpoint để làm rỗng cache" — có API flushStageCache, nhưng nó làm rỗng TOÀN BỘ cache của cả stage và đòi quyền quản trị API Gateway. Không thể cấp quyền đó cho đối tác bên ngoài, và nó cũng không cho phép làm rỗng một mục cụ thể.
• B. "Phải chờ TTL hết hạn" — mô tả tình huống khi không có cơ chế nào, tức là phủ nhận chính tính năng mà câu hỏi đang hỏi tới.
• C. Query string parameter INVALIDATE_CACHE — không tồn tại. Ngược lại, query string là MỘT PHẦN của khoá cache: thêm bất kỳ tham số lạ nào sẽ tạo ra một mục cache mới, chứ không làm mất mục cũ. (Đó cũng là một mẹo "lách" thô sơ mà người ta hay dùng — nhưng nó làm phình cache chứ không phải invalidate.)

Ghi nhớ

Cache của API Gateway: | Thuộc tính | Giá trị | |---|---| | Bật ở mức | stage (ghi đè được ở mức method) | | Kích thước | 0,5 GB đến 237 GB | | TTL | 0 – 3600 giây, mặc định 300 | | TTL = 0 | tắt cache | | Chi phí | tính theo GIỜ, không theo request | | Mã hoá | bật được cho dữ liệu cache |

Khoá cache mặc định là toàn bộ URL request, nhưng bạn chọn được thành phần nào tham gia bằng cache key parameter (path param, query string, header) — quan trọng khi response khác nhau theo Accept-Language chẳng hạn.

Và lưu ý về chi phí: cache tính tiền theo giờ ngay cả khi không có request nào — nhớ tắt ở các stage dev và test.

Đáp án

A — Ghi dữ liệu vào cụm Amazon ElastiCache.

Vì sao đúng

Yêu cầu: session phải phục vụ được tin cậy qua nhiều request, trong khi request có thể rơi vào bất kỳ instance nào trong Auto Scaling group.

Nghĩa là session phải nằm ở kho chia sẻ bên ngoài — không nằm trên máy nào cả:

Client → ALB → EC2 #1, #2, #3… (phi trạng thái, thay thế được bất cứ lúc nào)
                  ↓ đọc/ghi
              ElastiCache (Redis) — kho session dùng chung

ElastiCache phù hợp vì: | Đặc điểm | Chi tiết | |---|---| | Độ trễ dưới mili giây | trong bộ nhớ — nhanh nhất trong các lựa chọn | | Mọi instance truy cập được | endpoint chung | | TTL sẵn có | session tự hết hạn | | Multi-AZ với tự động failover | Redis replication group | | Cấu trúc dữ liệu phong phú | hash, set — hợp với dữ liệu session |

Nhiều framework có sẵn adapter: spring-session-data-redis, connect-redis cho Node.js, django-redis — thường chỉ cần đổi cấu hình.

Nếu chọn Redis (thay vì Memcached), nên bật Multi-AZ với replica để một node hỏng không mất toàn bộ session.

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

• B. Ghi vào EBS volume chia sẻ — cụm từ "shared EBS volume" là một cái bẫy: EBS thông thường chỉ gắn vào MỘT instance, và không vượt qua ranh giới AZ. Multi-Attach có tồn tại nhưng chỉ với io1/io2, chỉ trong cùng một AZ, tối đa 16 instance, và đòi hệ thống tệp hỗ trợ truy cập đồng thời (như cluster filesystem) — không dùng được như một kho session thông thường. Với ASG trải nhiều AZ thì càng không.
• C. Ghi vào instance store — sai nghiêm trọng nhất: instance store là ổ đĩa tạm gắn vật lý vào máy chủ. Dữ liệu mất khi instance dừng, ngủ đông, hoặc bị huỷ, và không máy nào khác đọc được. ASG huỷ instance là mất session.
• D. Ghi vào thư mục gốc của hệ thống tệp — cùng vấn đề: dữ liệu cục bộ trên một máy, request rơi vào máy khác sẽ không thấy session. Đây chính là thứ đề đang muốn thoát ra.

Ghi nhớ

Nguyên tắc: tầng tính toán phải phi trạng thái. Mọi trạng thái đẩy ra ngoài.

Ba thứ không bao giờ dùng để lưu session:

• Instance store — mất khi instance dừng
• Ổ đĩa cục bộ / thư mục gốc — không chia sẻ được
• Sticky session làm giải pháp duy nhất — instance chết là mất session

(Sticky session vẫn hữu ích như một tối ưu bổ sung khi đã có kho ngoài — nó giúp tận dụng cache cục bộ — nhưng nó không thay thế được kho session chia sẻ.)

Đáp án

C — GraphQL API trên AWS AppSync.

Vì sao đúng

Đề nêu ba yêu cầu, và chúng cùng chỉ về GraphQL:

1. Response phải gộp dữ liệu từ nhiều nguồn (Lambda + DynamoDB)
2. Ít endpoint nhất
3. Ít lời gọi API nhất

GraphQL giải quyết cả ba bằng thiết kế: một endpoint duy nhất, và client mô tả chính xác dữ liệu mình cần trong một truy vấn — kể cả khi dữ liệu đó nằm ở nhiều nguồn.

type Query {
  thongTinNguoiDung(id: ID!): ThongTinNguoiDung
}

type ThongTinNguoiDung {
  hoSo: HoSo        # ← resolver trỏ tới DynamoDB
  goiY: [SanPham]   # ← resolver trỏ tới Lambda
}

Client gọi một lần:

query {
  thongTinNguoiDung(id: "123") {
    hoSo { ten, email }
    goiY { ten, gia }
  }
}

AppSync gọi song song cả hai nguồn và trả về một response gộp sẵn.

So sánh số lời gọi: | | REST | GraphQL | |---|---|---| | Endpoint | /ho-so, /goi-y | một /graphql | | Lời gọi | 2 | 1 | | Dữ liệu thừa | thường có (over-fetching) | không — client chọn trường |

AppSync là dịch vụ GraphQL được quản lý hoàn toàn của AWS: nối trực tiếp tới DynamoDB, Lambda, RDS, OpenSearch, HTTP endpoint; có subscription thời gian thực qua WebSocket; và caching, offline sync cho client di động — rất hợp với "mobile clients" trong đề.

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

• A. REST API trên API Gateway — chạy được, nhưng trái cả hai yêu cầu tối thiểu hoá: hoặc bạn tạo hai endpoint (client gọi 2 lần), hoặc tạo một endpoint gộp với Lambda tự đi lấy cả hai nguồn — lúc đó lại phải viết và bảo trì logic gộp bằng tay, và mỗi khi client cần trường khác là phải sửa backend.
• D. GraphQL trên EC2 — đúng công nghệ, sai cách triển khai: bạn phải tự cài Apollo Server, tự vá máy, tự lo co giãn và sẵn sàng cao. Đề mô tả nhu cầu serverless.
• B. REST API trên Elastic Beanstalk — sai cả hai: vẫn là REST (nhiều endpoint), và không serverless (Beanstalk chạy trên EC2 do bạn quản lý ở mức nào đó).

Ghi nhớ

Nhận dạng nhanh trong đề: "aggregate data from multiple sources", "minimize the number of API calls", "mobile clients" ⇒ AppSync + GraphQL. Đây gần như là chữ ký nhận dạng của loại câu hỏi này.

Đáp án

A — Tạo CloudWatch metric filter để trích metric từ log, với location làm dimension.

Vì sao đúng

Metric filter là cơ chế biến log dạng chữ thành metric dạng số — chạy liên tục và tự động trên mọi dòng log mới:

aws logs put-metric-filter \
  --log-group-name /ung-dung/ket-noi \
  --filter-name ket-noi-theo-vung \
  --filter-pattern '{ $.eventType = "connection" }' \
  --metric-transformations \
      metricName=SoKetNoi,metricNamespace=UngDung,metricValue=1,\
      dimensions={Location=\$.location}

Ba đặc điểm khiến nó là câu trả lời đúng: | Đặc điểm | Chi tiết | |---|---| | Tự động | áp cho mọi log mới, không cần ai chạy gì | | Tạo metric thật | đặt được alarm, vẽ được dashboard, lưu 15 tháng | | Hỗ trợ dimension | tách số liệu theo location — đúng yêu cầu |

Dimension là điểm mấu chốt của đề: nhờ nó, một metric SoKetNoi được tách thành nhiều chuỗi dữ liệu — mỗi location một chuỗi — và bạn so sánh được giữa các vùng, hoặc đặt cảnh báo riêng cho từng vùng.

(Lưu ý về chi phí: mỗi tổ hợp dimension là một custom metric riêng. Nếu location có hàng nghìn giá trị thì hoá đơn phình rất nhanh — nên chỉ dùng dimension cho trường có số giá trị hữu hạn và biết trước.)

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

• B. Dùng CloudWatch Logs Insights để tạo custom metric — đây là phương án gần nhất và cần phân biệt kỹ: Logs Insights là công cụ TRUY VẤN tương tác — bạn chạy một truy vấn, xem kết quả, rồi thôi. Nó không tạo ra metric liên tục, không đặt alarm được lên kết quả, và phải có người chạy mỗi lần muốn xem. Rất mạnh để khám phá dữ liệu, nhưng sai công cụ cho yêu cầu "publish a custom metric".
• C. Stream sang Elasticsearch rồi export metric — chạy được nhưng phức tạp và tốn kém hơn nhiều: thêm một cụm phải vận hành, thêm một đường ống phải bảo trì, cho một việc mà CloudWatch làm sẵn bằng một cấu hình.
• D. CloudWatch Events rule tạo metric từ log group — không tồn tại cơ chế này. EventBridge (CloudWatch Events) phản ứng với sự kiện của dịch vụ AWS; nó không đọc nội dung log group và không tạo metric từ đó.

Ghi nhớ

Ba cách xử lý log trong CloudWatch, cho ba mục đích khác nhau: | Công cụ | Mục đích | Liên tục? | |---|---|---| | Metric filter | log → metric, để cảnh báo và vẽ đồ thị | ✅ tự động | | Logs Insights | truy vấn khám phá, phân tích tại chỗ | ❌ chạy theo yêu cầu | | Subscription filter | đẩy log sang nơi khác (Lambda, Kinesis, OpenSearch) | ✅ |

Nhận dạng nhanh: đề nói "publish a custom metric", "alarm", "track continuously" ⇒ metric filter. Đề nói "analyze", "investigate", "ad-hoc query" ⇒ Logs Insights.

Mẫu filter pattern hay dùng:

ERROR                              # log dạng text
{ $.level = "ERROR" }              # log JSON
{ $.duration > 1000 }              # so sánh số
[ip, user, timestamp, request]     # log dạng cột

Đáp án

B — AWS Private Certificate Authority (AWS Private CA).

Vì sao đúng

Đề liệt kê bốn yêu cầu, và AWS Private CA đáp ứng đủ cả bốn — trong khi các phương án còn lại trượt ở yêu cầu quan trọng nhất:

AWS Private CA là dịch vụ PKI được quản lý cho hạ tầng nội bộ. Nó cho phép dựng cây phân cấp đúng chuẩn:

Root CA (riêng tư, giữ ngoại tuyến)
   ├── Subordinate CA — Sản xuất
   │      ├── chứng chỉ cho máy chủ nội bộ
   │      └── chứng chỉ cho thiết bị IoT
   └── Subordinate CA — Phát triển

Cây phân cấp quan trọng vì nó cho phép thu hồi cả một nhánh mà không ảnh hưởng phần còn lại, và giữ root CA an toàn bằng cách ít khi dùng đến.

Nó cấp chứng chỉ cho các đối tượng mà CA công cộng không cấp được: máy chủ nội bộ (app.noi-bo.local), thiết bị IoT, container, người dùng (mTLS), và ký mã.

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

• A. AWS Certificate Manager (ACM) — đây là phương án gây nhầm nhiều nhất, vì hai dịch vụ có quan hệ với nhau. ACM cấp chứng chỉ CÔNG CỘNG miễn phí cho tên miền bạn sở hữu, dùng với ELB, CloudFront, API Gateway. Nhưng nó không cấp chứng chỉ riêng tư và không có khái niệm subordinate CA. (ACM có thể cấp phát chứng chỉ từ một Private CA — nhưng bản thân Private CA vẫn phải do AWS Private CA cung cấp.)
• D. AWS KMS — quản lý khoá mã hoá (đối xứng và bất đối xứng), có ký số. Nhưng nó không phải PKI: không cấp chứng chỉ X.509, không có CA, không có chuỗi tin cậy, không có thu hồi chứng chỉ.
• C. AWS Secrets Manager — lưu trữ và xoay vòng bí mật (mật khẩu CSDL, khoá API). Nó lưu được một chứng chỉ như một chuỗi văn bản, nhưng không cấp phát chứng chỉ nào.

Ghi nhớ

Nhận dạng nhanh: đề nói "private certificates", "subordinate CA", "internal PKI" ⇒ AWS Private CA. Đề nói "HTTPS cho website", "gắn vào ELB/CloudFront" ⇒ ACM.

Lưu ý về chi phí: Private CA tính phí theo tháng cho mỗi CA (khá đáng kể) cộng phí mỗi chứng chỉ cấp ra — khác hẳn ACM công cộng vốn miễn phí. Đây là điểm cần cân nhắc thật khi thiết kế.

Đáp án

A và D.

• A — Tạo Aurora Replica trong CÙNG cluster với instance chính.
• D — Tạo cluster Aurora MySQL riêng và cấu hình binlog replication.

Vì sao đúng

A — Aurora Replica là cách chuẩn và nên dùng. Đây là cơ chế mở rộng đọc gốc của Aurora:

                  ┌──────────────────────────────┐
Writer endpoint → │  Instance chính (đọc + ghi)  │
                  ├──────────────────────────────┤
Reader endpoint → │  Replica 1  Replica 2  … 15  │
                  └──────────────────────────────┘
                     ↓ tất cả dùng CHUNG
              Volume lưu trữ chia sẻ (6 bản trên 3 AZ)

Vì mọi instance dùng chung một volume, không có việc sao chép dữ liệu — nên độ trễ nhân bản thường dưới 100 mili giây, và thêm replica không làm tăng tải ghi cho instance chính.

Ứng dụng chỉ cần trỏ truy vấn đọc vào reader endpoint, vốn tự cân bằng tải giữa các replica:

cluster-cua-toi.cluster-ro-xxx.ap-southeast-1.rds.amazonaws.com  ← reader
cluster-cua-toi.cluster-xxx.ap-southeast-1.rds.amazonaws.com     ← writer

Tối đa 15 Aurora Replica, và chúng còn là đích failover tự động.

D — binlog replication sang cluster riêng. Aurora MySQL hỗ trợ replication qua binary log sang một cluster Aurora khác hoặc sang MySQL bên ngoài. Cluster đích hoàn toàn tách biệt — có volume lưu trữ riêng — nên nó phục vụ được:

• Tải đọc rất nặng mà không đụng gì tới cluster gốc
• Vượt quá giới hạn 15 replica
• Nhân bản qua Region hoặc ra ngoài AWS

Đổi lại: độ trễ cao hơn hẳn (đây là replication logic, không dùng chung storage), tốn chi phí lưu trữ gấp đôi, và cần theo dõi Seconds_Behind_Master.

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

• E. Tạo một cluster Aurora nhân bản để xử lý request đọc — mô tả này thiếu cơ chế đồng bộ. Một cluster "duplicate" mà không nói nhân bản bằng gì thì chỉ là một bản sao tĩnh, lỗi thời ngay lập tức. Phương án D nói đúng điều còn thiếu đó (binlog replication) — đó là khác biệt giữa hai phương án nghe rất giống nhau này.
• C. Tạo một Aurora primary trùng lặp để xử lý đọc — cùng vấn đề, và tệ hơn: hai primary không có cơ chế đồng bộ sẽ phân kỳ dữ liệu ngay khi có ghi.
• B. "Tạo Aurora Replica trong một global S3 bucket" — vô nghĩa về mặt kỹ thuật: S3 là kho object, không chạy được instance CSDL và không phải nơi đặt replica. Và "global S3 bucket" cũng không phải khái niệm có thật.

Ghi nhớ

Các cách mở rộng đọc cho Aurora: | Cách | Độ trễ | Giới hạn | Dùng khi | |---|---|---|---| | Aurora Replica (cùng cluster) | < 100 ms | 15 | mặc định — luôn thử trước | | Aurora Auto Scaling cho replica | như trên | theo cấu hình | tải đọc biến động | | Global Database | ~1 giây, xuyên Region | 5 Region phụ | đọc ở khu vực khác, DR | | binlog replication | cao hơn | — | vượt 15 replica, đích ngoài AWS | | ElastiCache phía trước | — | — | đọc lặp lại nhiều |

Với đề bài chỉ nói "high number of reads", Aurora Replica là câu trả lời tự nhiên nhất; binlog replication là công cụ cho các tình huống mà replica thường không đủ.

Đáp án

A và B.

• A — Chia dữ liệu quá mịn (segmenting data too finely).
• B — Dữ liệu lệch nặng về một giá trị partition (data skew).

Vì sao đúng

Partition trong Athena có tác dụng nhờ partition pruning: khi truy vấn lọc theo cột partition, Athena chỉ đọc những thư mục liên quan trên S3.

-- Chỉ quét prefix của đúng một ngày, không quét cả bảng
SELECT * FROM don_hang WHERE nam='2026' AND thang='08' AND ngay='05';

Hai điều trong đề phá hỏng chính lợi ích đó:

A — chia quá mịn. Nếu partition theo tới từng phút, hoặc theo một cột có hàng triệu giá trị: | Hậu quả | Chi tiết | |---|---| | Quá nhiều tệp nhỏ | Athena tốn thời gian mở từng tệp hơn là đọc dữ liệu | | Overhead metadata lớn | phải liệt kê hàng chục nghìn partition trong Glue Data Catalog | | Chi phí S3 API tăng | mỗi tệp là một lời gọi GET |

Có một ngưỡng thực tế: tệp nhỏ hơn khoảng 128 MB thì overhead bắt đầu lấn át lợi ích. Đây là lý do các đường ống dữ liệu thường có bước compaction để gộp tệp nhỏ.

B — dữ liệu lệch. Nếu 90% dữ liệu rơi vào một partition:

country=VN  → 900 GB   ← truy vấn nào chạm vào đây cũng chậm như quét cả bảng
country=SG  →   5 GB
country=TH  →   3 GB

Partition pruning về lý thuyết vẫn hoạt động, nhưng thực tế vô nghĩa với partition khổng lồ kia — bạn không thu hẹp được gì.

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

• C. Lưu dữ liệu trên S3 — bắt buộc phải vậy: Athena chỉ truy vấn dữ liệu trên S3. Đây không phải sai lầm mà là điều kiện hoạt động.
• D. Dùng định dạng partition kiểu Hive — đây là cách làm ĐÚNG, không phải sai lầm. Định dạng key=value cho phép Athena tự nhận partition bằng MSCK REPAIR TABLE hoặc partition projection:

  s3://kho/don-hang/nam=2026/thang=08/ngay=05/du-lieu.parquet
  

• E. Tạo partition trực tiếp từ nguồn dữ liệu — cũng là thực hành tốt: để đường ống ghi thẳng vào cấu trúc partition, thay vì phải xử lý lại về sau.

Ghi nhớ

Thực hành tốt khi partition trong Athena: | Nên | Không nên | |---|---| | Partition theo cột hay dùng trong WHERE | partition theo cột có độ phân biệt cao (user_id, timestamp) | | Nhắm tệp 128 MB – 1 GB | để lại hàng nghìn tệp nhỏ | | Dùng định dạng cột (Parquet, ORC) | dùng CSV/JSON cho dữ liệu lớn | | Dùng partition projection cho bảng nhiều partition | dựa vào MSCK REPAIR với hàng vạn partition | | Nén (Snappy, Zstd) | để dữ liệu không nén |

Vì Athena tính tiền theo lượng dữ liệu QUÉT (khoảng 5 USD/TB), mọi tối ưu ở đây đều giảm tiền trực tiếp, không chỉ giảm thời gian. Chuyển từ CSV sang Parquet có nén thường giảm chi phí 80–90% ngay cả trước khi bàn tới partition.

Đáp án

D — BeforeAllowTraffic > AfterAllowTraffic.

Vì sao đúng

Mỗi nền tảng tính toán của CodeDeploy có bộ hook riêng, và Lambda chỉ có đúng hai hook:

version: 0.0
Resources:
  - hamCuaToi:
      Type: AWS::Lambda::Function
      Properties:
        Name: "ham-xu-ly"
        Alias: "prod"
        CurrentVersion: "3"
        TargetVersion: "4"
Hooks:
  - BeforeAllowTraffic: "ham-kiem-thu-truoc"
  - AfterAllowTraffic:  "ham-kiem-thu-sau"

Lý do chỉ có hai hook: với Lambda, không có gì để "cài đặt". Version đã tồn tại sẵn (bạn publish trước đó); CodeDeploy chỉ dịch alias từ version cũ sang version mới. Không có bước copy tệp, không có bước start/stop dịch vụ.

Hook được cài đặt bằng một hàm Lambda riêng, và nó phải báo kết quả về:

import boto3
cd = boto3.client('codedeploy')

def handler(event, context):
    ket_qua = 'Succeeded' if kiem_thu_thanh_cong() else 'Failed'
    cd.put_lifecycle_event_hook_execution_status(
        deploymentId=event['DeploymentId'],
        lifecycleEventHookExecutionId=event['LifecycleEventHookExecutionId'],
        status=ket_qua)

Quên gọi put_lifecycle_event_hook_execution_status là triển khai treo cho tới khi hết timeout — đây là lỗi rất hay gặp.

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

• B. BeforeInstall > AfterInstall > ApplicationStart > ValidateService — đây là bộ hook của EC2/On-premises kiểu in-place. Nó có ý nghĩa ở đó vì thật sự có bước cài đặt và khởi động ứng dụng trên máy.
• C. BeforeBlockTraffic > AfterBlockTraffic > BeforeAllowTraffic > AfterAllowTraffic — bộ hook của EC2/On-premises có load balancer: chặn traffic tới instance cũ, cập nhật, rồi mở lại. Lambda không có khái niệm "block traffic" vì không có instance nào để rút khỏi load balancer.
• A. Trộn BeforeInstall, AfterInstall, AfterAllowTestTraffic… — pha trộn hook của nhiều nền tảng. AfterAllowTestTraffic là hook của ECS, không phải Lambda.

Ghi nhớ

Bảng hook theo nền tảng — đáng thuộc vì đề hay hỏi: | Nền tảng | Hook | |---|---| | Lambda | BeforeAllowTraffic, AfterAllowTraffic | | ECS | BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic | | EC2 in-place | ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService | | EC2 blue/green | thêm BeforeBlockTraffic, AfterBlockTraffic |

Mẹo nhận dạng: hook có chữ "Install" ⇒ không phải Lambda. Lambda không cài gì cả — nó chỉ chuyển alias.

Và định dạng tệp: AppSpec cho Lambda và ECS phải là YAML hoặc JSON; chỉ EC2/on-premises mới bắt buộc YAML.

Đáp án

C — Dùng AWS SDK for Python (boto3) đã có sẵn trong môi trường thực thi Lambda.

Vì sao đúng

Yêu cầu: thay đổi mã ít nhất có thể.

Và có một sự thật khiến câu trả lời trở nên hiển nhiên: runtime Python của Lambda đã cài sẵn boto3. Bạn chỉ cần import và dùng:

import boto3
s3 = boto3.client('s3')

def lambda_handler(event, context):
    noi_dung = tao_bao_cao()
    s3.put_object(Bucket='kho-bao-cao', Key='bao-cao.csv', Body=noi_dung)
    return {'statusCode': 200}

Ba thứ được lo sẵn, và đó là lý do "ít thay đổi nhất": | Việc | boto3 tự làm | |---|---| | Xác thực | tự lấy credential từ execution role qua biến môi trường | | Ký request | SigV4, tự động | | Thử lại | có backoff sẵn |

Việc duy nhất phải làm ngoài mã: cấp quyền cho execution role:

{"Effect": "Allow", "Action": "s3:PutObject",
 "Resource": "arn:aws:s3:::kho-bao-cao/*"}

(Một lưu ý thực dụng: phiên bản boto3 dựng sẵn không phải bản mới nhất và AWS cập nhật nó theo lịch riêng. Nếu cần một API rất mới, bạn vẫn phải đóng gói boto3 riêng — nhưng đề này chỉ cần put_object, một API có từ lâu.)

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

• D. Đóng gói SDK for Python vào mã hàm — thừa: boto3 đã có sẵn. Làm vậy chỉ khiến gói triển khai to hơn (boto3 khoảng 50 MB), thời gian cold start lâu hơn, và thêm việc bảo trì. Nhiều thay đổi hơn, không ít hơn.
• A. Dùng AWS CLI có trong môi trường Lambda — AWS CLI KHÔNG được cài trong runtime Lambda. Đây là bẫy chính. Và kể cả nếu có, gọi CLI bằng subprocess từ Python là cách làm tệ: chậm, khó bắt lỗi, khó xử lý kết quả.
• B. Gọi thẳng HTTP tới S3 API — làm được về lý thuyết nhưng nhiều thay đổi nhất: bạn phải tự cài đặt SigV4 — băm payload, dựng canonical request, tính chuỗi ký, sinh chữ ký HMAC nhiều bước. Hàng chục dòng mã dễ sai, cho việc mà một dòng put_object làm xong.

Ghi nhớ

Các thư viện có sẵn trong runtime Lambda: | Runtime | Có sẵn | |---|---| | Python | boto3, botocore | | Node.js 18+ | AWS SDK v3 (@aws-sdk/client-*) | | Node.js 16 trở về trước | AWS SDK v2 | | Java, .NET, Go, Ruby | không có sẵn — phải đóng gói |

Khi nào nên tự đóng gói SDK:

• Cần API rất mới chưa có trong bản dựng sẵn
• Cần ghim phiên bản để đảm bảo hành vi không đổi
• Cần bản vá lỗi cụ thể

Cách tốt nhất để làm việc đó là Lambda Layer — tách thư viện khỏi mã hàm, dùng lại được cho nhiều hàm, và giữ gói triển khai nhỏ.

Đáp án

B — Cập nhật bucket policy thêm điều kiện yêu cầu aws:SecureTransport cho mọi action.

Vì sao đúng

Yêu cầu: bắt buộc mã hoá khi truyền cho mọi giao tiếp với S3.

aws:SecureTransport là khoá điều kiện toàn cục cho biết request có đi qua HTTPS hay không. Cách viết đúng là Deny khi giá trị là false:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "BatBuocHTTPS",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::kho-khach-hang",
      "arn:aws:s3:::kho-khach-hang/*"
    ],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}}
  }]
}

Hai chi tiết đáng nhớ trong policy này:

1. Dùng Deny, không dùng Allow. Vì Deny tường minh thắng mọi Allow, không IAM policy nào ở bất kỳ đâu có thể lách qua. Nếu viết dạng Allow khi SecureTransport = true, thì một Allow khác vẫn có thể cho phép HTTP đi qua.

2. Phải khai CẢ HAI ARN. arn:aws:s3:::bucket áp cho các thao tác mức bucket (như ListBucket), còn arn:aws:s3:::bucket/* áp cho các thao tác mức object (như GetObject). Thiếu một trong hai là có lỗ hổng.

Điểm hay: bucket policy áp cho mọi request tới bucket, bất kể người gọi là ai hay thuộc tài khoản nào — nên một policy phủ toàn bộ khách hàng, và không đụng gì tới IAM policy phân quyền theo từng người đã có sẵn.

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

• C. Bật server-side encryption để "bắt buộc mã hoá khi truyền" — nhầm hai loại mã hoá hoàn toàn khác nhau. SSE bảo vệ dữ liệu khi nằm yên trên đĩa (at rest); nó không ảnh hưởng gì tới cách dữ liệu di chuyển trên đường truyền. Bật SSE mà vẫn cho HTTP thì dữ liệu vẫn bị nghe lén được.
• A. Bật S3 Transfer Acceleration — tính năng tăng TỐC ĐỘ truyền bằng cách đi qua edge location của CloudFront. Nó không bắt buộc HTTPS (dù endpoint của nó hỗ trợ HTTPS), và có phí thêm.
• D. Gán IAM role "bắt buộc SSL/TLS" cho từng khách hàng — sai ở chỗ không mở rộng được (phải tạo và bảo trì role cho mỗi khách hàng), và không kín kẽ: chỉ cần một IAM policy thiếu điều kiện là lỗ hổng xuất hiện. Bucket policy là một điểm kiểm soát duy nhất, đó mới là cách làm đúng cho yêu cầu tuân thủ.

Ghi nhớ

Hai loại mã hoá — đừng bao giờ lẫn: | | Khi truyền (in transit) | Khi lưu (at rest) | |---|---|---| | Bảo vệ khỏi | nghe lén trên đường mạng | đọc trộm dữ liệu trên đĩa | | Cơ chế S3 | HTTPS/TLS | SSE-S3, SSE-KMS, SSE-C | | Bắt buộc bằng | aws:SecureTransport | s3:x-amz-server-side-encryption |

Bộ đôi policy thường dùng cùng nhau cho yêu cầu tuân thủ:

// Bắt buộc HTTPS
{"Effect":"Deny","Principal":"*","Action":"s3:*","Resource":[...],
 "Condition":{"Bool":{"aws:SecureTransport":"false"}}}

// Bắt buộc mã hoá khi tải lên
{"Effect":"Deny","Principal":"*","Action":"s3:PutObject","Resource":"...*",
 "Condition":{"StringNotEquals":{"s3:x-amz-server-side-encryption":"aws:kms"}}}