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

Đáp án

D — Bật storage auto-scaling cho RDS MySQL.

Vì sao đúng

Vấn đề: dung lượng lưu trữ có thể bị vượt, và cần giải pháp khẩn cấp với công sức phát triển tối thiểu.

RDS Storage Auto Scaling là tính năng dựng sẵn, bật bằng một thiết lập, và không cần thay đổi gì ở ứng dụng:

aws rds modify-db-instance \
  --db-instance-identifier csdl-game \
  --max-allocated-storage 1000 \
  --apply-immediately

Cách nó hoạt động: khi dung lượng trống xuống dưới ngưỡng, RDS tự tăng thêm mà không có thời gian chết:

Ba đặc điểm khiến nó là lựa chọn đúng: không downtime, không sửa mã, và chỉ trả tiền cho dung lượng thực dùng (bạn khai trần tối đa, không phải cấp trước).

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

• C. Migrate sang Aurora — Aurora có storage auto-scaling rất tốt (tự tăng tới 128 TB), nhưng đây là cuộc di trú CSDL — cần lên kế hoạch, kiểm thử, và có thời gian chết. Trái yêu cầu "urgent" và "minimum development effort".
• A. Migrate sang DynamoDB — di trú còn lớn hơn nữa: phải viết lại toàn bộ tầng truy cập dữ liệu từ SQL sang NoSQL, thiết kế lại khoá, bỏ join. Hoàn toàn không phù hợp với một vấn đề khẩn cấp về dung lượng.
• B. Tạo read replica — read replica mở rộng khả năng ĐỌC, không mở rộng dung lượng lưu trữ. Nó còn tệ hơn ở khía cạnh này: mỗi replica là một bản sao đầy đủ, nên tổng dung lượng tiêu thụ tăng lên, không giảm.

Ghi nhớ

Ba khái niệm mở rộng của RDS, đừng lẫn: | Nhu cầu | Giải pháp | |---|---| | Hết dung lượng lưu trữ | storage auto-scaling | | Quá tải đọc | read replica | | Quá tải ghi / CPU | instance type lớn hơn (vertical), hoặc sharding | | Tính sẵn sàng cao | Multi-AZ |

Vài lưu ý về storage auto-scaling: nó chỉ tăng, không bao giờ giảm; trần tối đa là 64 TiB (tuỳ engine); và luôn nên bật cho mọi CSDL production — nó là lưới an toàn miễn phí chống sự cố "hết đĩa lúc 3 giờ sáng".

Đáp án

C — Bucket policy của S3 đang cho phép đọc.

Vì sao đúng

Quan sát trong đề rất cụ thể: gỡ IAM role thì ghi ngừng hoạt động nhưng đọc vẫn chạy. Sự bất đối xứng đó chỉ có một lời giải thích hợp lý.

Quyền truy cập S3 được quyết định bởi hợp nhất nhiều nguồn:

Và nguyên tắc: trong cùng một tài khoản, chỉ cần MỘT nguồn cho phép là hành động được thực hiện.

Nên khi gỡ instance role:

Ghi : IAM role (đã gỡ) ❌  +  bucket policy: không cho ghi ❌  → TỪ CHỐI
Đọc : IAM role (đã gỡ) ❌  +  bucket policy: CHO ĐỌC ✅       → CHO PHÉP

Bucket policy nhiều khả năng trông như thế này:

{"Effect": "Allow",
 "Principal": "*",
 "Action": "s3:GetObject",
 "Resource": "arn:aws:s3:::my_bucket/*"}

Nói cách khác: quyền đọc chưa bao giờ đến từ IAM role — nó đến từ bucket policy suốt từ đầu, và việc gỡ role chỉ làm lộ ra điều đó.

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

• A. "Instance đang dùng thông tin xác thực tạm thời được cache" — nghe hợp lý, nhưng không giải thích được sự bất đối xứng. Nếu là cache thì cả đọc lẫn ghi đều còn hoạt động cho tới khi thông tin xác thực hết hạn. Đề nói ghi ngừng ngay.
• B. "Gỡ role mất vài phút mới có hiệu lực" — cùng vấn đề: nếu có độ trễ thì nó áp cho cả hai thao tác như nhau. (Thực tế, gỡ instance profile có hiệu lực gần như ngay lập tức.)
• D. "Có grace period 5 phút cho lần đọc lặp lại" — bịa hoàn toàn. S3 không có khái niệm nào như vậy; mỗi request được phân quyền độc lập.

Ghi nhớ

Nguyên tắc hợp nhất quyền: | Bối cảnh | Quy tắc | |---|---| | Cùng tài khoản | chỉ cần một bên cho phép | | Chéo tài khoản | bắt buộc cả hai bên cho phép | | Có Deny tường minh | luôn thắng, bất kể ở đâu |

Bài học thực tế từ câu này: khi gỡ quyền, hãy kiểm tra CẢ bucket policy lẫn IAM policy. Rất nhiều sự cố bảo mật đến từ việc tưởng đã thu hồi quyền qua IAM, trong khi bucket policy vẫn mở — và với Principal: "*" thì đó là quyền cho cả thế giới.

Công cụ phát hiện: IAM Access Analyzer báo ngay những bucket đang chia sẻ ra ngoài tài khoản.

Đáp án

D — Chỉ một quản trị viên truy cập được, sau khi đã bật MFA.

Vì sao đúng

Root user là danh tính mạnh nhất và nguy hiểm nhất trong một tài khoản AWS:

Vế thứ hai là điểm quan trọng nhất: không có IAM policy nào chặn được root user. Nên nếu thông tin đăng nhập root bị lộ, kẻ tấn công có toàn bộ tài khoản và không có cơ chế nào ngăn lại.

Vì vậy khuyến nghị của AWS là:

1. Bật MFA cho root — tốt nhất là thiết bị vật lý, cất trong két
2. Xoá mọi access key của root (nếu có) — root không bao giờ nên có access key
3. Giới hạn số người biết mật khẩu ở mức tối thiểu
4. Không dùng root cho công việc hằng ngày — tạo IAM user hoặc dùng IAM Identity Center
5. Đặt alarm khi có ConsoleLogin bằng root

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

• A. "Truy cập được bằng access key và secret key" — chống chỉ định rõ ràng nhất. AWS khuyến nghị xoá access key của root, vì khoá tĩnh với quyền tuyệt đối là rủi ro không thể chấp nhận. Trusted Advisor còn có check cảnh báo riêng cho điều này.
• C. "3 đến 6 thành viên đội IT truy cập được" — càng nhiều người biết thì bề mặt tấn công càng rộng, và không truy vết được ai đã làm gì (mọi hành động đều mang danh "root"). Vi phạm nguyên tắc đặc quyền tối thiểu.
• B. "Không ai truy cập được, vứt mật khẩu sau khi tạo tài khoản" — nghe cực đoan theo hướng an toàn nhưng thực tế là sai lầm nghiêm trọng: có những việc chỉ root làm được, và mất quyền root nghĩa là không bao giờ làm được chúng. (Khôi phục được qua AWS Support nhưng rất phiền phức.)

Ghi nhớ

Những việc chỉ root user làm được — lý do không thể vứt bỏ nó: | Thao tác | |---| | Đổi tên tài khoản, email, mật khẩu root | | Đóng tài khoản AWS | | Đổi gói hỗ trợ (Support plan) | | Bật quyền IAM truy cập Billing console | | Tạo CloudFront key pair | | Bật MFA Delete cho bucket S3 | | Khôi phục khi IAM policy bị khoá nhầm | | Rời khỏi một AWS Organization |

Quy trình an toàn chuẩn: bật MFA vật lý cho root, xoá access key, cất thông tin đăng nhập trong két, đặt alarm cho ConsoleLogin của root, và chỉ dùng khi thật sự cần một trong các việc trên.

Đáp án

A — --projection-expression

Vì sao đúng

ProjectionExpression khai những thuộc tính nào được trả về cho mỗi item:

aws dynamodb scan --table-name nguoi-dung \
  --projection-expression "user_id, ten, email"

Không có nó, Scan trả về toàn bộ thuộc tính của mỗi item. Với item có 30 thuộc tính mà bạn chỉ cần 3, đó là lãng phí băng thông đáng kể.

Nhưng có một điều rất quan trọng cần hiểu rõ, vì nó là nguồn hiểu nhầm phổ biến nhất về DynamoDB:

ProjectionExpression KHÔNG giảm RCU tiêu thụ.

DynamoDB đọc toàn bộ item trước, rồi mới lọc thuộc tính trước khi gửi về. Nên bạn vẫn trả tiền cho kích thước đầy đủ của item — thứ tiết kiệm được chỉ là băng thông mạng.

Với thuộc tính có tên trùng từ khoá của DynamoDB, phải dùng alias:

--projection-expression "#n, #s" \
--expression-attribute-names '{"#n":"name","#s":"status"}'

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

• C. --filter-expression — lọc theo giá trị, quyết định item nào được trả về (không phải thuộc tính nào). Nó cũng không giảm RCU — lọc diễn ra sau khi đọc.
• B. --max-items — giới hạn tổng số item trong kết quả trả về của CLI, và sinh NextToken để phân trang. Không liên quan tới thuộc tính.
• D. --page-size — điều khiển số item mỗi lời gọi API phía sau (CLI tự lặp). Dùng để tránh timeout hoặc giảm RCU tiêu thụ mỗi lần gọi, không liên quan tới thuộc tính.

Ghi nhớ

Bốn tuỳ chọn hay bị lẫn trong scan và query: | Tuỳ chọn | Điều khiển | |---|---| | --projection-expression | thuộc tính nào được trả về | | --filter-expression | item nào được trả về (lọc theo giá trị) | | --max-items | tổng số item trong kết quả CLI | | --page-size | số item mỗi lời gọi API |

Và ba sự thật về chi phí Scan cần thuộc:

1. FilterExpression không giảm RCU — lọc sau khi đọc
2. ProjectionExpression không giảm RCU — chỉ giảm băng thông
3. Chỉ thiết kế khoá tốt hoặc dùng Query/GSI mới thực sự giảm chi phí

Đáp án

D — Ứng dụng cần làm mới thông tin xác thực sau 1 giờ khi chúng hết hạn.

Vì sao đúng

Manh mối trong đề chính xác đến mức khó nhầm: ứng dụng dùng STS và ngừng hoạt động sau đúng một giờ.

Thông tin xác thực tạm thời do STS phát ra đều có thời hạn, và mặc định của AssumeRole là một giờ:

Khi hết hạn, mọi lời gọi API trả về:

ExpiredToken: The security token included in the request is expired

Cách chữa đúng: đừng tự quản lý — để SDK lo. Mọi AWS SDK đều tự làm mới thông tin xác thực khi dùng credential provider chuẩn:

import boto3
# SDK tự lấy và tự làm mới từ instance profile
s3 = boto3.client('s3')

Còn nếu tự gọi AssumeRole thì phải tự bắt lỗi hết hạn và lấy lại:

if het_han_sap_toi():
    cred = sts.assume_role(RoleArn=..., RoleSessionName=...)['Credentials']

Cách tốt nhất trong tình huống này: ứng dụng chạy trên EC2 trong Auto Scaling group, nên dùng instance profile — SDK sẽ tự lấy và tự làm mới từ metadata service, không cần một dòng mã nào.

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

• C. "IAM policy sai" — nếu policy sai thì ứng dụng hỏng ngay từ đầu, không phải sau đúng một giờ.
• A. "IAM ngừng hoạt động mỗi giờ một lần" — IAM là dịch vụ toàn cầu với độ sẵn sàng rất cao. Không có chuyện gián đoạn đều đặn theo giờ.
• B. "Một hàm Lambda thu hồi quyền mỗi giờ" — bịa, và đề không hề nhắc tới Lambda nào.

Ghi nhớ

Nhận dạng nhanh: "ngừng hoạt động sau đúng 1 giờ" ⇒ thông tin xác thực tạm thời hết hạn. Con số 1 giờ là mặc định của AssumeRole và xuất hiện rất nhiều trong đề.

Ba khuyến nghị:

1. Dùng credential provider chuẩn của SDK — nó tự làm mới
2. Đừng cache thông tin xác thực quá thời hạn, và làm mới trước khi hết hạn (thường trước 5 phút)
3. Ưu tiên instance profile / task role hơn là tự gọi AssumeRole

Đáp án

D — Tạo gateway endpoint riêng cho S3 và cho DynamoDB, thêm hai target mới vào route table của VPC.

Vì sao đúng

Yêu cầu: EC2 trong private subnet truy cập S3 và DynamoDB không qua Internet.

Điểm mấu chốt: S3 và DynamoDB là HAI dịch vụ duy nhất hỗ trợ gateway endpoint, và cả hai đều nên dùng loại đó:

aws ec2 create-vpc-endpoint --vpc-id vpc-xxx \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-private
aws ec2 create-vpc-endpoint --vpc-id vpc-xxx \
  --service-name com.amazonaws.ap-southeast-1.dynamodb \
  --route-table-ids rtb-private

Gateway endpoint hoạt động bằng cách thêm một route vào route table, trỏ dải IP của dịch vụ về endpoint thay vì ra Internet Gateway. Traffic không bao giờ rời khỏi mạng AWS.

Ba ưu điểm, và ưu điểm đầu là lý do chính: | Ưu điểm | Chi tiết | |---|---| | Miễn phí | không phí giờ chạy, không phí xử lý dữ liệu | | Bỏ được NAT gateway cho phần traffic này | tiết kiệm đáng kể | | Có endpoint policy | giới hạn được bucket/bảng nào truy cập được |

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

• A. Interface endpoint cho cả hai — về kỹ thuật có làm được (S3 và DynamoDB đều có interface endpoint), nhưng đắt hơn hẳn: interface endpoint tính phí theo giờ mỗi AZ cộng phí theo GB. Với truy cập từ trong VPC, gateway endpoint miễn phí là lựa chọn đúng.
• C. Gateway cho S3 + interface cho DynamoDB — nửa đúng, nhưng dùng interface cho DynamoDB là trả tiền không cần thiết.
• B. Gateway cho DynamoDB + "API endpoint" cho S3 — sai ở vế S3: "API endpoint" không phải một loại VPC endpoint. Hai loại duy nhất là gateway và interface.

Ghi nhớ

Hai loại VPC endpoint — bảng cần thuộc: | | Gateway endpoint | Interface endpoint (PrivateLink) | |---|---|---| | Dịch vụ | CHỈ S3 và DynamoDB | hầu hết dịch vụ AWS còn lại | | Cơ chế | route trong route table | ENI có IP riêng trong subnet | | Chi phí | miễn phí | theo giờ + theo GB | | Truy cập từ on-premises | ❌ | ✅ qua VPN/Direct Connect | | Security group | không áp dụng | áp dụng | | Endpoint policy | ✅ | ✅ |

Nhớ nhanh: S3 và DynamoDB có gateway endpoint miễn phí — hãy luôn bật chúng. Mọi dịch vụ khác dùng interface endpoint và có tính phí.

(Ngoại lệ: nếu cần truy cập S3 từ on-premises thì phải dùng interface endpoint cho S3, vì gateway endpoint chỉ hoạt động trong VPC.)

Đáp án

D — Canary deployment.

Vì sao đúng

Yêu cầu: kiểm thử phiên bản API mới trên một lượng traffic nhỏ.

Canary release của API Gateway làm đúng việc đó ở mức stage:

aws apigateway create-deployment --rest-api-id abc123 --stage-name prod \
  --canary-settings percentTraffic=10.0,useStageCache=false

Cách nó hoạt động: stage có hai bản triển khai cùng lúc — bản chính và bản canary — và traffic được chia theo phần trăm bạn khai:

90% → bản hiện tại
10% → bản canary (API mới)

Ba đặc điểm khiến nó là công cụ đúng cho việc kiểm thử: | Đặc điểm | Chi tiết | |---|---| | Metric riêng cho canary | CloudWatch tách riêng, so được tỷ lệ lỗi và độ trễ giữa hai bản | | Log riêng | dễ khoanh vùng lỗi của bản mới | | stageVariableOverrides | canary trỏ sang alias Lambda khác | | Rollback tức thì | xoá canary settings là xong | | Promote | chuyển canary thành bản chính khi hài lòng |

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

• C. Stage variables — cặp khoá–giá trị cấu hình theo từng stage, dùng để trỏ tới backend khác nhau giữa dev và prod. Nó không chia traffic theo phần trăm. (Stage variable hỗ trợ canary qua stageVariableOverrides, nhưng bản thân nó không phải cơ chế chia traffic.)
• B. Mapping templates — biến đổi định dạng request và response bằng VTL. Không liên quan tới việc định tuyến hay chia traffic.
• A. Custom authorizers — cơ chế uỷ quyền (Lambda authorizer), quyết định ai được gọi API. Không chia traffic.

Ghi nhớ

Các tầng chia traffic được, và nên chọn tầng nào: | Tầng | Cơ chế | Rollback | |---|---|---| | API Gateway | canary stage — có metric riêng | tức thì | | Lambda | weighted alias | tức thì | | ALB | weighted target group | tức thì | | Route 53 | weighted record | chậm — vướng TTL |

Với kiến trúc API Gateway + Lambda, canary ở API Gateway thường tốt nhất vì nó có sẵn bộ metric để so sánh hai nhánh — thứ mà weighted alias của Lambda không cho.

Và phân biệt với stage: canary chia traffic trong cùng một stage cho thay đổi tương thích ngược; stage riêng dùng cho môi trường tách biệt và thay đổi phá vỡ tương thích.

Đáp án

A và E.

• A — --max-items
• E — --starting-token

Vì sao đúng

Hai tuỳ chọn này là cặp phân trang chuẩn của AWS CLI:

--max-items — số item trả về trong một trang kết quả. Nếu còn dữ liệu, CLI trả thêm một NextToken:

aws s3api list-objects-v2 --bucket kho-du-lieu --max-items 100

{
  "Contents": [ ...100 object... ],
  "NextToken": "eyJTdGFydEFmdGVyIjogbnVsbCwgImJvdG9fdHJ1bmNhdGVfYW1vdW50IjogMTAwfQ=="
}

--starting-token — truyền NextToken đó vào để lấy trang tiếp theo:

aws s3api list-objects-v2 --bucket kho-du-lieu --max-items 100 \
  --starting-token eyJTdGFydEFmdGVyIjogbnVsbCwgImJvdG9fdHJ1bmNhdGVfYW1vdW50IjogMTAwfQ==

Về vế "minimize the number of API calls" — đây là chỗ cần hiểu đúng: --max-items chỉ giới hạn đầu ra, còn CLI vẫn tự gọi API bên dưới với kích thước trang mặc định (1.000 object cho list-objects-v2). Nên không đặt --page-size nhỏ chính là cách giữ số lời gọi ở mức thấp nhất.

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

• B. --page-size — đây là bẫy chính, và nó đi ngược mục tiêu. --page-size điều khiển số item mỗi LỜI GỌI API phía sau; đặt --page-size 100 sẽ khiến CLI gọi API nhiều hơn 10 lần so với mặc định 1.000. Nó chỉ hữu ích khi cần tránh timeout với dữ liệu rất lớn.
• C. --next-token — không phải tên tuỳ chọn của AWS CLI. NextToken là trường trong kết quả trả về; tuỳ chọn để truyền nó vào là --starting-token.
• D. --limit — không phải tuỳ chọn phân trang chung của AWS CLI. (Một vài API có tham số --limit riêng, nhưng nó không phải cơ chế phân trang chuẩn của CLI.)

Ghi nhớ

Ba tuỳ chọn phân trang của AWS CLI, phân biệt cho rõ: | Tuỳ chọn | Điều khiển | |---|---| | --max-items | số item trong KẾT QUẢ trả về | | --starting-token | vị trí bắt đầu (nhận NextToken từ lần trước) | | --page-size | số item mỗi LỜI GỌI API phía sau |

Quy tắc thực dụng:

• Muốn ít lời gọi API nhất ⇒ để --page-size mặc định (lớn nhất có thể)
• Muốn hiển thị theo trang cho người dùng ⇒ dùng --max-items + --starting-token
• Chỉ giảm --page-size khi gặp timeout hoặc muốn giảm tiêu thụ throughput mỗi lần gọi

Đáp án

B — Cập nhật resource-based policy của hàm Lambda để cấp quyền cần thiết cho API Gateway.

Vì sao đúng

Đây là một cái bẫy rất cụ thể của API Gateway, và nó liên quan tới cách stage variable hoạt động.

Khi bạn cấu hình integration trỏ thẳng vào một hàm Lambda qua Console, API Gateway tự động thêm quyền vào resource-based policy của hàm đó.

Nhưng khi integration dùng stage variable:

arn:aws:apigateway:ap-southeast-1:lambda:path/2015-03-31/functions/
  arn:aws:lambda:ap-southeast-1:123456789012:function:${stageVariables.tenHam}/invocations

API Gateway không biết trước hàm nào sẽ được gọi lúc chạy, nên không thể tự thêm quyền. Kết quả: khi gọi API, nó bị Lambda từ chối và trả về Internal server error với mã 500.

Cách chữa — thêm quyền thủ công cho từng hàm có thể được gọi:

aws lambda add-permission \
  --function-name xu-ly-don-hang \
  --statement-id apigateway-invoke \
  --action lambda:InvokeFunction \
  --principal apigateway.amazonaws.com \
  --source-arn "arn:aws:execute-api:ap-southeast-1:123456789012:abc123/*/*/*"

Điểm đáng chú ý về mặt gỡ lỗi: lỗi 500 không nói gì về nguyên nhân. Phải bật CloudWatch Logs cho stage mới thấy dòng Lambda invocation failed with status: 403.

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

• D. "Tạo IAM role mà Lambda function assume để gọi" — sai chiều. Chiều gọi là API Gateway → Lambda, nên quyền phải nằm ở resource-based policy của Lambda, không phải ở role mà Lambda assume. (Execution role của Lambda là thứ khác hẳn: nó nói hàm làm được gì, không nói ai được gọi hàm.)
• C. "Dùng ARN của hàm chứ không dùng alias khi đặt giá trị stage variable" — dùng alias là hợp lệ và còn được khuyến nghị. Vấn đề không nằm ở việc dùng ARN hay alias, mà ở việc thiếu quyền.
• A. "Vượt giới hạn tần suất API, cần retry với exponential backoff" — throttling trả về 429 Too Many Requests, không phải 500. Sai mã lỗi.

Ghi nhớ

Hai loại policy của Lambda — bị nhầm rất thường xuyên: | Loại | Trả lời câu hỏi | Triệu chứng khi thiếu | |---|---|---| | Resource-based policy | AI được phép GỌI hàm? | hàm không được gọi (403 → API trả 500) | | Execution role | Hàm được phép LÀM GÌ? | hàm chạy rồi lỗi bên trong |

Và nhớ quy tắc: integration dùng stage variable ⇒ phải tự thêm quyền cho MỌI hàm có thể được gọi. Đây là cái giá của tính linh hoạt mà stage variable mang lại.

Đáp án

C — Dùng Amazon Macie và tìm phát hiện loại SensitiveData:S3Object/Financial.

Vì sao đúng

Yêu cầu: phân tích dữ liệu trên S3 tìm thông tin tài chính nhạy cảm về khách hàng, một cách hiệu quả nhất.

Amazon Macie là dịch vụ chuyên trách: nó dùng máy học và so khớp mẫu để phát hiện dữ liệu nhạy cảm trong S3, hoàn toàn được quản lý, không phải viết mã.

Macie phân loại phát hiện thành các nhóm, và tên nhóm là điểm phân biệt của câu hỏi này:

Đề nói rõ "sensitive financial information" ⇒ Financial.

Macie chạy theo lịch hoặc theo yêu cầu, và phát hiện chảy vào EventBridge và Security Hub — nên nối cảnh báo được ngay.

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

• D. SensitiveData:S3Object/Personal — nhóm này dành cho thông tin định danh cá nhân (tên, địa chỉ, hộ chiếu), không phải dữ liệu tài chính. Sai nhóm.
• A. SensitiveData:S3Object/CustomIdentifier — dùng cho mẫu do bạn tự định nghĩa bằng regex (ví dụ mã nhân viên nội bộ theo định dạng riêng). Với dữ liệu tài chính chuẩn, Macie đã có sẵn managed data identifier — tự định nghĩa lại là thừa và kém chính xác hơn.
• B. S3 event notification + Lambda tự viết script Python — tự dựng lại Macie bằng tay: phải tự viết regex cho số thẻ, tự cài Luhn check, tự xử lý nhiều định dạng tệp (CSV, JSON, Parquet, tệp nén), tự bảo trì mãi. Trái thẳng "MOST efficiently".

Ghi nhớ

Bốn dịch vụ bảo mật hay bị lẫn, mỗi cái một đối tượng: | Dịch vụ | Phát hiện | |---|---| | Macie | dữ liệu nhạy cảm trong S3 | | GuardDuty | mối đe doạ, hành vi tấn công | | Inspector | lỗ hổng phần mềm, phơi nhiễm mạng | | Detective | điều tra sâu sau khi có phát hiện | | Security Hub | gom kết quả cả bốn, chấm theo khung chuẩn |

Nhận dạng nhanh: đề nói "sensitive data" + "S3" ⇒ Macie. Và nhớ ba nhóm finding chính: Financial, Personal, Credentials.