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

Đáp án

A — Dùng tham số DelaySeconds.

Vì sao đúng

Yêu cầu rất chính xác: hoãn việc giao MESSAGE MỚI vào hàng đợi ít nhất 10 giây.

DelaySeconds làm đúng nghĩa đen điều đó — message vừa được gửi vào sẽ vô hình với mọi consumer trong khoảng thời gian đó:

# Mức queue — áp cho mọi message mới
aws sqs set-queue-attributes --queue-url <url> --attributes DelaySeconds=10

# Hoặc mức từng message
aws sqs send-message --queue-url <url> --message-body "..." --delay-seconds 10

Giới hạn: 0 – 900 giây (15 phút). Riêng FIFO queue chỉ đặt được ở mức queue, không đặt riêng cho từng message.

Vì sao delay hữu ích trong tình huống này: ứng dụng ghi tệp lên S3 rồi gửi message chứa đường dẫn. Delay vài giây đảm bảo S3 đã hoàn tất việc ghi và object đã hiện diện trước khi consumer đọc — tránh lỗi NoSuchKey do đua tranh.

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

• B. Visibility timeout — đây là bẫy chính, và khác biệt rất quan trọng:

  	DelaySeconds	VisibilityTimeout
  Áp dụng cho	message MỚI, chưa ai nhận	message ĐÃ được nhận
  Tác dụng	hoãn lần xuất hiện đầu tiên	ẩn message trong lúc consumer xử lý
  Tối đa	15 phút	12 giờ

  Đề nói rõ "postpone the delivery of any new messages" ⇒ DelaySeconds.

• D. Bật Long Polling — giảm số lời gọi API rỗng và giảm chi phí. Nó không hoãn message.

• C. Tự hoãn ở phía ứng dụng — làm được (thêm sleep trước khi gửi), nhưng tự viết lại một tính năng có sẵn, và nó giữ luồng xử lý của ứng dụng một cách vô ích.

Ghi nhớ

Bốn tham số thời gian của SQS: | Tham số | Nghĩa | Phạm vi | |---|---|---| | DelaySeconds | hoãn message MỚI | 0 – 15 phút | | VisibilityTimeout | ẩn message đã nhận | 0 – 12 giờ | | MessageRetentionPeriod | giữ trong queue | 60 giây – 14 ngày | | ReceiveMessageWaitTimeSeconds | long polling | 0 – 20 giây |

Lỗi phổ biến nhất trong cặp SQS + Lambda: VisibilityTimeout nhỏ hơn timeout của hàm — message bị phát lại trong khi hàm vẫn đang chạy, gây xử lý trùng. Khuyến nghị đặt gấp 6 lần.

Đáp án

B — Hàm Lambda hết RAM.

Vì sao đúng

Đọc kỹ thông báo: Memory Size: 10,240 MB Max Memory Used.

Đây là hai trường trong dòng REPORT mà Lambda tự ghi ra CloudWatch Logs sau mỗi lần chạy:

REPORT RequestId: abc-123  Duration: 3521.42 ms  Billed Duration: 3522 ms
Memory Size: 10240 MB      Max Memory Used: 10240 MB

Max Memory Used bằng đúng Memory Size nghĩa là hàm đã dùng hết sạch bộ nhớ được cấp. Và 10.240 MB là mức tối đa mà Lambda cho phép — không thể tăng thêm.

Khi hàm chạm trần bộ nhớ, Lambda kết thúc môi trường thực thi, thường kèm lỗi:

Runtime exited with error: signal: killed

Với Node.js, còn có thể thấy JavaScript heap out of memory.

Vì đã ở mức tối đa nên không tăng bộ nhớ được nữa. Cách chữa phải nằm ở phía mã: | Cách | Chi tiết | |---|---| | Xử lý theo luồng (streaming) | đọc tệp lớn từng phần thay vì nạp hết vào bộ nhớ | | Chia nhỏ công việc | dùng Step Functions hoặc SQS để tách thành nhiều lần chạy | | Dùng /tmp | ghi dữ liệu tạm ra đĩa (tới 10.240 MB) thay vì giữ trong RAM | | Đổi sang ECS/Fargate | nếu công việc thực sự cần nhiều hơn 10 GB |

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

• C. "Zip lớn hơn 50 MB" — sai loại lỗi. Vượt giới hạn gói triển khai gây lỗi lúc tải lên hoặc lúc tạo hàm, không phải lúc chạy, và thông báo sẽ nói về RequestEntityTooLargeException.
• D. "Zip giải nén vượt giới hạn" (250 MB) — cũng là lỗi lúc triển khai, không phải lúc chạy.
• A. "Zip bị hỏng" — sẽ cho lỗi kiểu Unable to import module hoặc Runtime.InvalidEntrypoint, hoàn toàn khác thông báo trong đề.

Ghi nhớ

Các trường trong dòng REPORT và ý nghĩa: | Trường | Cho biết | |---|---| | Duration | thời gian chạy thật | | Billed Duration | thời gian tính tiền | | Memory Size | bộ nhớ đã cấp | | Max Memory Used | bộ nhớ thực sự dùng | | Init Duration | thời gian cold start |

Mẹo tối ưu: so Max Memory Used với Memory Size ở nhiều lần chạy. Dùng dưới 50% thì giảm bộ nhớ để tiết kiệm; chạm gần 100% thì tăng lên — và nhớ rằng tăng bộ nhớ cũng tăng CPU, nên hàm thường chạy nhanh hơn mà chi phí không đổi.

Đáp án

A — All at once.

Vì sao đúng

Đề nêu rõ hai điều kiện cho môi trường dev/test: deploy nhanh và không quan tâm tới thời gian chết.

All at once là chính sách nhanh nhất của Elastic Beanstalk — nó cập nhật toàn bộ instance cùng một lúc:

Không phải chờ lô nào, không phải dựng instance mới, không phải chờ health check tuần tự — nên với môi trường dev/test cần vòng lặp phát hành nhanh, đây là lựa chọn đúng.

Nó cũng không tốn thêm đồng nào về hạ tầng, phù hợp với môi trường không phải production.

Nhược điểm duy nhất — toàn bộ ứng dụng không phục vụ trong lúc deploy, và deploy hỏng thì cả môi trường hỏng — chính là điều đề nói rõ là chấp nhận được.

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

• B. Rolling — chậm hơn (đợi từng lô), và đề đã dùng nó cho production. Với dev/test thì tính năng "không thời gian chết" của nó là thừa.
• D. Rolling with additional batch — chậm hơn nữa và tốn thêm chi phí cho lô dư. Hoàn toàn không cần cho môi trường test.
• C. Immutable — chậm nhất và đắt nhất: dựng cả một fleet mới song song. An toàn nhất, nhưng an toàn không phải điều đề cần ở đây.

Ghi nhớ

Cách chọn chính sách deploy của Beanstalk theo tiêu chí: | Ưu tiên | Chọn | |---|---| | Nhanh nhất, chấp nhận downtime | All at once | | Không downtime, không tốn thêm | Rolling | | Không giảm năng lực, chi phí thêm tối thiểu | Rolling with additional batch | | An toàn nhất | Immutable | | Rollback tức thì | Blue/Green (swap CNAME) |

Nguyên tắc thực dụng: dev/test dùng All at once; production dùng Immutable hoặc Blue/Green. Chọn theo mức độ chịu đựng rủi ro của môi trường, không chọn một chính sách cho tất cả.

Đáp án

A — Bật SQS KMS encryption (SSE-SQS hoặc SSE-KMS).

Vì sao đúng

Yêu cầu: mã hoá message trong hàng đợi, không sửa mã hiện có.

Server-side encryption của SQS đáp ứng đúng điều đó — nó hoàn toàn trong suốt với ứng dụng:

aws sqs set-queue-attributes --queue-url <url> \
  --attributes '{
    "KmsMasterKeyId": "alias/khoa-cua-toi",
    "KmsDataKeyReusePeriodSeconds": "300"
  }'

Cách nó hoạt động: SQS tự mã hoá message khi nhận và tự giải mã khi trả về. Producer vẫn gọi SendMessage, consumer vẫn gọi ReceiveMessage — không một dòng mã nào thay đổi.

Điều duy nhất phải thêm là quyền KMS cho producer và consumer:

{"Effect": "Allow",
 "Action": ["kms:GenerateDataKey", "kms:Decrypt"],
 "Resource": "arn:aws:kms:...:key/xxxx"}

KmsDataKeyReusePeriodSeconds (60–86.400 giây) cho phép SQS tái sử dụng data key trong một khoảng, giảm số lời gọi KMS và giảm chi phí — đánh đổi nhỏ về mặt bảo mật.

(Ghi chú: SQS còn có SSE-SQS — mã hoá bằng khoá do SQS quản lý, miễn phí và bật mặc định cho queue tạo mới từ 2023. SSE-KMS đáng dùng khi cần kiểm soát khoá và có vết CloudTrail.)

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

• B. Client-side encryption — an toàn nhất về lý thuyết (SQS không bao giờ thấy bản rõ), nhưng nó đòi sửa mã ở cả producer lẫn consumer, cộng với việc tự quản lý khoá. Vi phạm thẳng ràng buộc "without making changes to the existing code".
• D. Dùng SSL endpoint — bảo vệ dữ liệu khi truyền, không phải khi lưu. Message vẫn nằm trong SQS ở dạng chưa mã hoá. (Và HTTPS vốn đã là mặc định của mọi endpoint AWS.)
• C. Dùng Secrets Manager — dịch vụ lưu bí mật ứng dụng (mật khẩu, API key). Nó không mã hoá message trong hàng đợi — sai công cụ hoàn toàn.

Ghi nhớ

Ba lựa chọn mã hoá cho SQS: | | SSE-SQS | SSE-KMS | Client-side | |---|---|---|---| | Ai quản lý khoá | SQS | bạn, qua KMS | bạn hoàn toàn | | Sửa mã | ❌ | ❌ | ✅ | | Chi phí | miễn phí | phí KMS API | không | | Vết CloudTrail cho khoá | ❌ | ✅ | ❌ |

Nhận dạng nhanh: "mã hoá mà không sửa mã" ⇒ server-side encryption, ở SQS cũng như ở S3, EBS, RDS.

Đáp án

A — Dùng cron job trên instance đẩy số liệu RAM lên CloudWatch dưới dạng custom metric.

Vì sao đúng

Điểm kiến thức cốt lõi: EC2 KHÔNG phát metric bộ nhớ.

Lý do nằm ở kiến trúc: hypervisor nhìn instance từ bên ngoài, nên nó thấy CPU, lưu lượng mạng và I/O đĩa. Nhưng mức dùng RAM là thứ chỉ hệ điều hành BÊN TRONG biết — hypervisor chỉ thấy bộ nhớ đã được cấp phát, không thấy bao nhiêu đang thực sự được dùng.

Nên phải để instance tự đo và tự báo cáo:

#!/bin/bash
# Chạy bằng cron mỗi phút
MEM=$(free | awk '/Mem:/ {printf "%.2f", $3/$2 * 100}')
IID=$(curl -s http://169.254.169.254/latest/meta-data/instance-id)
aws cloudwatch put-metric-data \
  --namespace "System/Linux" \
  --metric-name "MemoryUtilization" \
  --dimensions InstanceId=$IID \
  --value "$MEM" --unit Percent

Đề nói rõ "using a script", nên cron job là cách khớp đúng với yêu cầu.

(Trong thực tế với hàng trăm instance, cách nên dùng là CloudWatch Agent triển khai qua SSM State Manager — nó làm cùng việc đó nhưng có sẵn cấu hình, tự gộp lô để giảm chi phí API, và không phải bảo trì script trên từng máy.)

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

• C. "Lấy RAM từ metric CloudWatch chuẩn của EC2" — bẫy chính. Metric chuẩn không có bộ nhớ. Kể cả bật detailed monitoring cũng không thêm metric nào — nó chỉ đổi chu kỳ từ 5 phút xuống 1 phút.
• D. Lấy từ instance metadata — metadata service (169.254.169.254) trả về thông tin tĩnh về instance: ID, loại instance, IP, AMI, IAM role, user data. Nó không có số liệu vận hành theo thời gian thực như mức dùng RAM.
• B. Dùng X-Ray — công cụ theo dấu request phân tán để phân tích độ trễ trong ứng dụng. Nó không thu thập metric hệ điều hành.

Ghi nhớ

Ba metric không có sẵn trên EC2, luôn cần agent hoặc script: | Metric | Tên trong CloudWatch Agent | |---|---| | Bộ nhớ | mem_used_percent | | Dung lượng đĩa còn trống | disk_used_percent | | Swap | swap_used_percent |

Đây là câu hỏi kinh điển, và biến thể phổ biến nhất là đặt alarm cho một metric chưa từng tồn tại — alarm sẽ ở trạng thái INSUFFICIENT_DATA vĩnh viễn, không bao giờ kêu, và cũng không báo lỗi gì.

Đáp án

B và D.

• B — Giữ mã nguồn trong AWS CodeCommit và kích hoạt CodePipeline khi có push.
• D — Giữ mã nguồn trong Amazon S3 và kích hoạt CodePipeline khi tệp trong bucket được cập nhật.

Vì sao đúng

CodePipeline hỗ trợ đúng ba loại source action, và chỉ ba loại này mới kích hoạt được pipeline:

B — CodeCommit. Một EventBridge rule bắt sự kiện CodeCommit Repository State Change và gọi StartPipelineExecution. Đây là mẫu chuẩn nhất.

D — S3. Bucket phải bật versioning, và CodePipeline dùng EventBridge (qua CloudTrail data event) để phát hiện object mới:

{"source": ["aws.s3"],
 "detail-type": ["Object Created"],
 "detail": {"bucket": {"name": ["kho-ma-nguon"]}, "object": {"key": ["ung-dung.zip"]}}}

Cả hai đều dựa trên sự kiện, nên deploy bắt đầu ngay khi có thay đổi — đúng yêu cầu "as soon as there are any changes".

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

• A. Amazon EFS và C. Amazon EBS — không phải source hợp lệ của CodePipeline. Chúng là hệ thống tệp và ổ đĩa khối, không phát sự kiện khi tệp thay đổi và không có tích hợp nào với CodePipeline.
• E. S3 với polling mỗi 15 phút — hoạt động được (CodePipeline có chế độ polling cũ), nhưng nó có độ trễ tới 15 phút, trái yêu cầu "as soon as there are any changes". AWS cũng khuyến nghị bỏ polling và chuyển sang EventBridge — nhanh hơn và không tốn lời gọi API vô ích.

Ghi nhớ

Ba cách CodePipeline phát hiện thay đổi: | Cách | Độ trễ | Khuyến nghị | |---|---|---| | EventBridge | gần như tức thì | ✅ mặc định hiện nay | | Webhook (GitHub, Bitbucket) | tức thì | ✅ | | Polling | tới vài phút | ❌ đã lỗi thời |

Và với nguồn S3, hai điều kiện bắt buộc: bucket phải bật versioning, và CloudTrail phải ghi data event cho bucket đó (nếu dùng EventBridge kiểu cũ) — thiếu một trong hai thì pipeline im lặng không chạy.

Đáp án

A — Lưu dữ liệu truy cập thường xuyên trong ElastiCache for Redis với mã hoá bật cho cả lúc truyền lẫn lúc lưu.

Vì sao đúng

Đề nêu ba yêu cầu, và chúng cùng nhau chỉ về đúng một lựa chọn:

Vế "sort hoặc rank" là điểm quyết định. Redis có sorted set — cấu trúc dữ liệu lưu các phần tử kèm điểm số và giữ chúng luôn được sắp xếp:

ZADD bang_xep_hang 1500 "benh-nhan-A"  1200 "benh-nhan-B"
ZREVRANGE bang_xep_hang 0 9 WITHSCORES    # top 10, đã sắp sẵn

Đây là thứ Memcached hoàn toàn không có — nó chỉ lưu cặp khoá–giá trị đơn giản.

Vế mã hoá cũng loại Memcached. Với dữ liệu y tế (PHI), cả hai chiều đều bắt buộc: | | Redis | Memcached | |---|---|---| | Mã hoá at rest | ✅ | ❌ | | Mã hoá in transit | ✅ | ⚠️ chỉ với phiên bản rất mới | | Đủ điều kiện HIPAA | ✅ | ❌ |

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

• C. ElastiCache for Memcached — bẫy chính. Nó không có sorted set (không sort/rank được) và truyền thống không hỗ trợ mã hoá at rest — trượt cả hai yêu cầu quan trọng nhất.
• D. Migrate sang DynamoDB + DAX — đây là cuộc di trú CSDL toàn diện, không phải thêm một tầng cache. Đề nói rõ dữ liệu đang ở RDS for MySQL và chỉ cần cải thiện hiệu năng. DAX cũng chỉ hoạt động với DynamoDB, không cache được cho RDS.
• B. EC2 Instance Store — lưu trữ tạm thời gắn cứng với host: mất sạch khi instance dừng hoặc bị thay, không sao chép, không tự quản lý. Cực kỳ không phù hợp cho dữ liệu y tế.

Ghi nhớ

Nguyên tắc chọn: cần bất cứ thứ gì ngoài cache khoá–giá trị thuần ⇒ Redis. Memcached chỉ hợp khi cần cache rất đơn giản, đa luồng, và không có yêu cầu về bảo mật hay bền vững.

Đáp án

B — Một deployment mới của phiên bản hoạt động tốt gần nhất được triển khai, với deployment ID mới.

Vì sao đúng

Đây là chi tiết quan trọng nhất về automatic rollback của CodeDeploy, và nó thường gây bất ngờ:

CodeDeploy KHÔNG "hoàn tác" deployment thất bại. Nó thực hiện một deployment MỚI của bản revision cũ.

Nghĩa là rollback là một lần deploy đầy đủ, với:

• Deployment ID mới hoàn toàn
• Toàn bộ lifecycle event chạy lại: ApplicationStop → BeforeInstall → Install → ApplicationStart → ValidateService
• Xuất hiện như một mục riêng trong lịch sử deployment

Deployment d-ABC123 → version 2.0 → THẤT BẠI
Deployment d-XYZ789 → version 1.9 → tự động, là "rollback"

Hai hệ quả thực tế rất đáng nhớ:

1. Script hook chạy lại từ đầu. Nếu chúng không idempotent (chạy nhiều lần cho kết quả khác nhau), rollback có thể gây vấn đề mới.
2. Rollback tốn thời gian bằng một lần deploy. Nó không tức thì như blue/green.

Cấu hình:

aws deploy update-deployment-group --application-name ung-dung \
  --current-deployment-group-name prod \
  --auto-rollback-configuration enabled=true,events=DEPLOYMENT_FAILURE,DEPLOYMENT_STOP_ON_ALARM

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

• A. "Chuyển bản ghi alias Route 53 về bản xanh lá tốt và huỷ bản xanh lam hỏng" — mô tả blue/green, và còn nói nhầm chiều (xanh lam là bản cũ, xanh lá là bản mới). Đề nói về deploy lên EC2 với automatic rollback, không nói blue/green. Ngoài ra CodeDeploy blue/green chuyển traffic ở load balancer, không ở Route 53.
• C. "Khôi phục từ snapshot lưu trong S3" — CodeDeploy không chụp snapshot của instance. Nó chỉ quản lý các bản revision ứng dụng.
• D. "CodePipeline promote deployment gần nhất có trạng thái SUCCEEDED" — CodePipeline không có cơ chế nào như vậy. Rollback là việc của CodeDeploy, và pipeline chỉ ghi nhận stage thất bại.

Ghi nhớ

Ba sự kiện kích hoạt automatic rollback: | Sự kiện | Khi nào | |---|---| | DEPLOYMENT_FAILURE | deployment thất bại | | DEPLOYMENT_STOP_ON_ALARM | CloudWatch alarm chuyển sang ALARM | | DEPLOYMENT_STOP_ON_REQUEST | người dùng dừng thủ công |

Sự kiện thứ hai là thứ đáng cấu hình nhất: đặt alarm trên tỷ lệ lỗi 5xx hoặc độ trễ, và deployment tự lùi lại khi chỉ số xấu đi — không cần ai theo dõi.

Và nhớ: muốn rollback tức thì thì phải dùng blue/green (trỏ load balancer về fleet cũ trong vài giây), không phải in-place với auto rollback.

Đáp án

C — Dùng tính năng tích hợp CloudWatch với S3 (export log ra S3).

Vì sao đúng

Bối cảnh: Alexa skill viết bằng JavaScript chạy trên Lambda, và console.log(JSON.stringify(this.event)) tự động ghi vào CloudWatch Logs — đó là hành vi mặc định của Lambda, không cần cấu hình.

Yêu cầu còn lại là đưa những log đó sang S3, và CloudWatch Logs có sẵn hai cách:

Cách 1 — Export task (thủ công hoặc theo lịch):

aws logs create-export-task \
  --log-group-name /aws/lambda/alexa-skill \
  --from 1735689600000 --to 1735776000000 \
  --destination kho-log --destination-prefix alexa/

Cách 2 — Subscription filter + Firehose (liên tục):

CloudWatch Logs → subscription filter → Kinesis Data Firehose → S3

Cách 2 là cách nên dùng cho việc chuyển log liên tục; cách 1 hợp cho việc xuất một khoảng thời gian cụ thể để phân tích.

Với việc gỡ lỗi intent của Alexa như đề mô tả, thực tế thì CloudWatch Logs Insights thường đủ và nhanh hơn:

fields @timestamp, @message
| filter @message like /IntentRequest/
| sort @timestamp desc | limit 50

S3 đáng dùng khi cần giữ lâu dài hoặc phân tích bằng Athena.

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

• A. "Tích hợp CloudWatch với Lambda" — quan hệ này đã tồn tại sẵn theo chiều ngược lại: Lambda ghi vào CloudWatch Logs tự động. Nó không đưa log sang S3.
• D. "Tích hợp CloudWatch với Kinesis" — Kinesis có là đích hợp lệ của subscription filter, nhưng nó chỉ là đường vận chuyển: vẫn phải có một bước nữa để ghi vào S3 (thường là Firehose). Nói "tích hợp với Kinesis" không hoàn thành yêu cầu.
• B. "Tích hợp CloudWatch với Glue" — không tồn tại. Glue là dịch vụ ETL đọc dữ liệu từ S3, JDBC và các nguồn khác; nó không nhận log trực tiếp từ CloudWatch Logs.

Ghi nhớ

Ba đích hợp lệ của subscription filter: Kinesis Data Streams, Kinesis Data Firehose, và Lambda.

Và hai cách đưa log sang S3: | Cách | Đặc điểm | |---|---| | Export task | thủ công một lần, cho một khoảng thời gian | | Subscription filter → Firehose → S3 | liên tục, tự động |

Khuyến nghị vận hành quan trọng: luôn đặt retention cho log group của Lambda. Mặc định là giữ mãi mãi, và với hàm chạy nhiều thì đó là khoản chi phí âm thầm lớn dần.

Đáp án

D — Chủ bucket cũng phải là chủ sở hữu object thì mới nhận được log truy cập object.

Vì sao đúng

Đây là hệ quả của một đặc điểm lịch sử của S3: khi tài khoản khác tải object lên bucket của bạn, TÀI KHOẢN ĐÓ là chủ sở hữu object, không phải chủ bucket.

Và CloudTrail data event tuân theo quyền sở hữu đó:

Nên trong tình huống của đề: một tài khoản khác đọc object mà chủ bucket không sở hữu, và log đi về tài khoản sở hữu object — quản lý dự án không thấy gì.

Cách chữa là buộc chủ bucket sở hữu mọi object:

aws s3api put-bucket-ownership-controls --bucket kho-du-an \
  --ownership-controls 'Rules=[{ObjectOwnership=BucketOwnerEnforced}]'

Với Bucket owner enforced, ACL bị vô hiệu hoá hoàn toàn và chủ bucket luôn sở hữu mọi object, bất kể ai tải lên. Đây cũng là mặc định cho bucket tạo mới từ 2023.

(Cách cũ hơn: Bucket owner preferred, kèm yêu cầu người tải lên gửi x-amz-acl: bucket-owner-full-control.)

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

• B. "CloudTrail luôn giao log cho người yêu cầu, không cho chủ object" — đảo ngược quy tắc. Log data event đi theo quyền sở hữu object, không theo người gọi.
• C. "Phải cấu hình CloudTrail ở cả hai tài khoản" — không phải cách chữa. Cấu hình ở tài khoản kia thì họ nhận được log, còn quản lý dự án vẫn không thấy. Vấn đề là quyền sở hữu, không phải nơi bật CloudTrail.
• A. "Metadata của bucket ở trạng thái không hợp lệ, cần sửa từ Console" — bịa. Không có khái niệm "metadata bucket hỏng" nào như vậy.

Ghi nhớ

Ba thiết lập của S3 Object Ownership: | Thiết lập | Hành vi | |---|---| | Bucket owner enforced (khuyến nghị, mặc định mới) | ACL tắt, chủ bucket sở hữu mọi object | | Bucket owner preferred | chủ bucket sở hữu nếu người tải lên gửi ACL tương ứng | | Object writer | hành vi cũ — người tải lên sở hữu |

Và nhớ phân biệt hai loại sự kiện CloudTrail: | Loại | Ghi gì | Mặc định | |---|---|---| | Management event | CreateBucket, PutBucketPolicy | bật, miễn phí | | Data event | GetObject, PutObject, DeleteObject | tắt, có phí |