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

Đáp án

B và D.

• B — Dùng Cognito User Pools để quản lý đăng ký và xác thực người dùng
• D — Dùng IAM role để cấp quyền khác nhau cho khách và người đã đăng ký

Vì sao đúng

Đề nêu hai nhu cầu, và mỗi đáp án giải quyết một nhu cầu:

1. Nhận diện người đã tạo tài khoản — cần một thư mục người dùng
2. Theo dõi số khách chuyển thành người dùng đăng ký — cần phân biệt hai nhóm

B — user pool là thư mục người dùng. Nó lo toàn bộ việc đăng ký, xác nhận email, đăng nhập, MFA và quên mật khẩu — và quan trọng với đề: nó biết ai đã có tài khoản.

aws cognito-idp sign-up --client-id abc123 \
  --username nguoidung@example.com --password 'MatKhau!2026'

D — hai IAM role phân biệt hai nhóm. Cognito identity pool có sẵn cấu trúc này:

Khách (chưa đăng nhập) → unauthenticated role → xem nội dung mẫu
Người đã đăng ký       → authenticated role   → xem toàn bộ nội dung

Và đây cũng là cách đo được tỷ lệ chuyển đổi: identity pool phát metric và CloudTrail ghi lại việc một identity chuyển từ trạng thái khách sang đã xác thực. Cognito user pool cũng có metric SignUpSuccesses để đối chiếu.

Hai đáp án bổ sung cho nhau: user pool xác thực, identity pool cấp quyền theo nhóm.

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

• E. Dùng Lambda để theo dõi việc chuyển từ khách sang tài khoản đầy đủ — tự viết lại thứ Cognito đã có. (Đáng nói: Cognito có Lambda trigger như PostConfirmation để chạy logic riêng khi ai đó đăng ký xong — nhưng đó là bổ sung cho user pool, không thay thế nó. Phương án E một mình không cung cấp cơ chế nhận diện người dùng nào.)
• A. Dùng S3 để quản lý dữ liệu người dùng và theo dõi chuyển đổi — S3 là kho object, không phải thư mục người dùng. Nó không xác thực, không có khái niệm đăng nhập, và bạn sẽ phải tự viết toàn bộ hệ thống tài khoản.
• C. Dùng AWS Glue để giám sát đăng ký và chuyển đổi tài khoản — sai công cụ hoàn toàn: Glue là dịch vụ ETL và data catalog, dùng để biến đổi dữ liệu cho phân tích. Nó không tham gia vào luồng xác thực.

Ghi nhớ

Kiến trúc đầy đủ cho ứng dụng có cả khách lẫn thành viên — chính là hai đáp án ghép lại:

Khách:      → Identity Pool (không có logins) → unauthenticated role
Thành viên: → User Pool (đăng nhập) → JWT → Identity Pool → authenticated role

Các Lambda trigger của user pool — hữu ích khi cần logic riêng: | Trigger | Chạy khi | |---|---| | PreSignUp | trước khi tạo tài khoản — tự động duyệt hoặc từ chối | | PostConfirmation | sau khi xác nhận email — nơi tốt để ghi nhận chuyển đổi | | PreTokenGeneration | thêm claim tuỳ chỉnh vào token | | PostAuthentication | sau mỗi lần đăng nhập thành công |

Với yêu cầu "theo dõi số khách chuyển thành đăng ký" trong đề, PostConfirmation là chỗ tự nhiên để ghi một bản ghi vào DynamoDB hoặc đẩy một sự kiện phân tích.

Cảnh báo về unauthenticated role: nó cấp credential cho bất kỳ ai trên Internet — chỉ cần biết identity pool ID (vốn nằm trong mã ứng dụng). Giữ quyền của nó ở mức tối thiểu tuyệt đối.

Đáp án

B — Gắn permissions policy vào một IAM group chứa tài khoản của các lập trình viên, cấp quyền truy cập bảng.

Vì sao đúng

Đây là mẫu chuẩn theo thực hành tốt của IAM: gán quyền qua group, không gán trực tiếp cho từng user.

aws iam create-group --group-name LapTrinhVienXacThuc

aws iam put-group-policy --group-name LapTrinhVienXacThuc \
  --policy-name TruyCapBangXacThuc \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:Query"],
      "Resource": "arn:aws:dynamodb:ap-southeast-1:123456789012:table/ThongTinXacThuc"
    }]}'

aws iam add-user-to-group --group-name LapTrinhVienXacThuc --user-name nguyen-van-a

Ba lợi ích của cách này: | Lợi ích | Chi tiết | |---|---| | Sửa một chỗ | đổi policy của group là mọi thành viên đổi theo | | Thêm/bớt người dễ | chỉ cần thêm hoặc gỡ khỏi group | | Dễ kiểm toán | nhìn group là biết ai có quyền gì |

Và vì bảng chứa thông tin xác thực của ứng dụng di động, nên kèm theo đặc quyền tối thiểu: chỉ đúng ARN của bảng đó, chỉ những action thực sự cần. Nên cân nhắc thêm điều kiện MFA:

"Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}

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

• C. Gắn resource-based policy vào bảng và khai IAM group làm Principal — sai vì hai lẽ. Thứ nhất, DynamoDB KHÔNG hỗ trợ resource-based policy theo kiểu S3 hay SQS. (DynamoDB có bổ sung resource-based policy gần đây cho một số kịch bản chia sẻ chéo tài khoản, nhưng đó không phải cách phân quyền thông thường.) Thứ hai và quan trọng hơn: IAM group KHÔNG dùng làm Principal được — group chỉ là công cụ tổ chức, nó không phải một danh tính. Principal phải là user, role, hoặc tài khoản.
• A. Tạo KMS resource-based policy cho CMK và cấp quyền giải mã — giải quyết sai lớp: quyền KMS kiểm soát việc giải mã dữ liệu đã mã hoá, nhưng truy cập vào bảng DynamoDB được kiểm soát bằng IAM policy trên DynamoDB. Ai không có quyền dynamodb:GetItem thì không đọc được bảng, bất kể quyền KMS ra sao.
• D. Tạo tài khoản dùng chung cho các lập trình viên — vi phạm nguyên tắc bảo mật cơ bản nhất: không biết ai đã làm gì (CloudTrail chỉ ghi tên tài khoản chung), không thu hồi quyền cho một người, và mật khẩu lan truyền không kiểm soát. Đặc biệt tệ với bảng chứa thông tin xác thực.

Ghi nhớ

Điểm quan trọng nhất của câu này: IAM group không phải một danh tính (principal). Nó chỉ là vùng chứa để gán policy cho nhiều user cùng lúc.

Hệ quả: trong resource-based policy (bucket policy, queue policy, trust policy), bạn khai được user và role, nhưng không khai được group.

Dịch vụ nào có resource-based policy: | Có | Không | |---|---| | S3, SQS, SNS, KMS, Lambda, Secrets Manager, ECR | DynamoDB (theo cách thông thường), EC2, RDS |

Với các dịch vụ ở cột phải, phân quyền hoàn toàn bằng identity-based policy — tức là gắn vào user, group hoặc role.

Và thực hành tốt cho tổ chức nhiều người: dùng IAM Identity Center (SSO) thay vì IAM user — nó bỏ hẳn credential dài hạn, cho phép đăng nhập một lần rồi chọn tài khoản và permission set phù hợp.

Đáp án

B — Đặt tệp trong thư mục .ebextensions.

Vì sao đúng

.ebextensions là thư mục quy ước của Elastic Beanstalk để tuỳ chỉnh môi trường. Beanstalk tự tìm và áp dụng mọi tệp .config trong đó khi triển khai.

goi-nguon.zip
├── index.js
├── package.json
└── .ebextensions/
    └── load-balancer.config       ← ĐÂY

Nội dung tệp là YAML hoặc JSON, khai các option setting:

option_settings:
  aws:elbv2:listener:443:
    Protocol: HTTPS
    SSLCertificateArns: arn:aws:acm:ap-southeast-1:123456789012:certificate/abc
  aws:elasticbeanstalk:environment:
    LoadBalancerType: application
  aws:elbv2:loadbalancer:
    IdleTimeout: 120
  aws:autoscaling:asg:
    HealthCheckType: ELB
    HealthCheckGracePeriod: 300

Vài đặc điểm cần biết: | Đặc điểm | Chi tiết | |---|---| | Phần mở rộng | phải là .config | | Thứ tự áp dụng | theo thứ tự bảng chữ cái của tên tệp | | Nhiều tệp | được — nên tách theo chủ đề (01-network.config, 02-packages.config) | | Vị trí | thư mục gốc của source bundle |

Ngoài option_settings, .ebextensions còn làm được nhiều việc khác — cài gói, tạo tệp, chạy lệnh:

packages:
  yum:
    git: []
files:
  "/etc/ung-dung/cau-hinh.conf":
    mode: "000644"
    content: |
      log_level = info
commands:
  01_tao_thu_muc:
    command: mkdir -p /var/ung-dung/du-lieu
container_commands:
  01_migrate:
    command: "python manage.py migrate"
    leader_only: true

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

• D. Đặt ở thư mục gốc của mã nguồn — Beanstalk chỉ quét thư mục .ebextensions để tìm tệp cấu hình. Tệp .config nằm ở gốc sẽ bị bỏ qua hoàn toàn — không có lỗi nào, cấu hình đơn giản là không được áp dụng.
• C. Đặt trong thư mục bin — không phải thư mục quy ước của Beanstalk. Cùng kết quả: bị bỏ qua.
• A. "Trong load-balancer.config.root" — không tồn tại khái niệm này.

Ghi nhớ

Các thư mục và tệp quy ước trong source bundle của Beanstalk: | Đường dẫn | Việc | |---|---| | .ebextensions/*.config | tuỳ chỉnh môi trường: option, gói, tệp, lệnh | | .platform/hooks/ | script hook trên nền tảng Amazon Linux 2 trở lên | | .platform/nginx/ | ghi đè cấu hình nginx | | Procfile | khai cách khởi động tiến trình | | Buildfile | lệnh chạy lúc build | | cron.yaml | chỉ cho worker environment — tác vụ định kỳ |

Hai loại lệnh trong .ebextensions — khác nhau ở thời điểm chạy: | Loại | Chạy khi | |---|---| | commands | TRƯỚC khi ứng dụng và web server được cài đặt | | container_commands | SAU khi ứng dụng đã giải nén, TRƯỚC khi triển khai xong |

container_commands là nơi đúng để chạy migration CSDL hoặc thu thập tệp tĩnh. Và leader_only: true rất quan trọng ở đó: nó đảm bảo lệnh chỉ chạy trên MỘT instance — thiếu nó, migration sẽ chạy đồng thời trên cả chục máy.

Vài lưu ý về source bundle: | Yêu cầu | Chi tiết | |---|---| | Một tệp duy nhất | ZIP hoặc WAR | | Không quá 512 MB | giới hạn cứng | | Không có thư mục cha | tệp phải nằm ở gốc của archive |

Điểm cuối là lỗi đóng gói phổ biến nhất — nén cả thư mục thay vì nén nội dung bên trong nó.

Đáp án

D — Dùng approval action trong một stage đặt trước stage triển khai.

Vì sao đúng

CodePipeline có sẵn loại action Manual approval cho đúng nhu cầu này — dừng pipeline lại chờ người duyệt:

{
  "name": "DuyetTruocProduction",
  "actions": [{
    "name": "PheDuyet",
    "actionTypeId": {
      "category": "Approval",
      "owner": "AWS",
      "provider": "Manual",
      "version": "1"
    },
    "configuration": {
      "NotificationArn": "arn:aws:sns:ap-southeast-1:123456789012:duyet-trien-khai",
      "CustomData": "Xem kết quả kiểm thử rồi duyệt để triển khai lên production",
      "ExternalEntityLink": "https://bao-cao-test.congty.com/build-42"
    }
  }]
}

Cấu trúc pipeline sẽ như sau:

Source → Build → Test → [DUYỆT THỦ CÔNG] → Deploy Production
                              ↑ pipeline dừng ở đây

Ba đặc điểm khiến nó là cách tốt nhất: | Đặc điểm | Chi tiết | |---|---| | Thông báo tự động | SNS gửi email cho người duyệt ngay khi tới bước | | Có vết kiểm toán | ai duyệt, lúc nào, kèm ghi chú | | Kiểm soát bằng IAM | chỉ người có quyền codepipeline:PutApprovalResult mới duyệt được | | Tự hết hạn | 7 ngày không ai duyệt thì pipeline thất bại |

Người duyệt bấm nút trong Console, hoặc dùng CLI:

aws codepipeline put-approval-result \
  --pipeline-name ung-dung --stage-name DuyetTruocProduction \
  --action-name PheDuyet --token <token> \
  --result summary="Đã kiểm thử xong",status=Approved

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

• B. Tắt chuyển tiếp stage (disable stage transition) để cho phép duyệt thủ công — đây là phương án gần nhất và cần phân biệt kỹ. Disable transition có thật và nó dừng pipeline lại, nhưng nó là thao tác vận hành thủ công, không phải một bước trong quy trình: không có thông báo tự động, không có vết kiểm toán ai bật lại, và phải nhớ tắt bằng tay mỗi lần. Nó dùng để tạm dừng pipeline khi có sự cố, không phải để dựng quy trình phê duyệt.
• C. Tắt một stage ngay trước stage triển khai — không có khái niệm "tắt một stage" trong CodePipeline. Bạn tắt được transition giữa các stage, không tắt được bản thân stage.
• A. Dùng thông báo SNS từ stage triển khai — sai thời điểm: thông báo phát ra khi triển khai đã bắt đầu hoặc đã xong. Nó không chặn gì cả — mã đã lên production rồi mới có người biết.

Ghi nhớ

Các loại action trong CodePipeline: | Category | Ví dụ provider | |---|---| | Source | CodeCommit, S3, CodeStar Connections (GitHub, GitLab) | | Build | CodeBuild, Jenkins | | Test | CodeBuild, thiết bị kiểm thử bên thứ ba | | Deploy | CodeDeploy, ECS, Elastic Beanstalk, CloudFormation, S3 | | Approval | Manual | | Invoke | Lambda, Step Functions |

Ba cách dừng pipeline — mỗi cách cho một mục đích: | Cách | Mục đích | |---|---| | Approval action | bước phê duyệt trong QUY TRÌNH | | Disable transition | tạm dừng vận hành khi có sự cố | | stop-pipeline-execution | huỷ một lần chạy cụ thể |

Ba việc nên làm với approval action:

1. Luôn khai NotificationArn — không có nó thì người duyệt phải tự vào Console kiểm tra, và pipeline sẽ nằm chờ nhiều ngày.
2. Dùng ExternalEntityLink trỏ tới báo cáo test hoặc URL môi trường staging — người duyệt có thứ để xem trước khi bấm.
3. Giới hạn quyền duyệt bằng IAM — chỉ trưởng nhóm hoặc người trực release mới có codepipeline:PutApprovalResult.

Và nhớ thời hạn 7 ngày: nếu không ai duyệt trong khoảng đó, stage thất bại và bạn phải chạy lại pipeline từ đầu.

Đáp án

C — Amazon S3 với Cross-Region Replication (CRR).

Vì sao đúng

Đề nêu ba yêu cầu, và S3 với CRR đáp ứng cả ba với chi phí thấp nhất:

1. Lưu tệp để dùng về sau, KHÔNG truy cập thường xuyên
2. Tuân thủ đòi lưu dư thừa GIỮA CÁC REGION
3. Tiết kiệm nhất

S3 là kho lưu trữ rẻ nhất cho tệp, và CRR tự động sao chép object sang bucket ở Region khác:

aws s3api put-bucket-replication --bucket kho-goc \
  --replication-configuration '{
    "Role": "arn:aws:iam::123456789012:role/RoleNhanBanS3",
    "Rules": [{
      "ID": "NhanBanSangRegionKhac",
      "Status": "Enabled",
      "Priority": 1,
      "Filter": {},
      "DeleteMarkerReplication": {"Status": "Disabled"},
      "Destination": {
        "Bucket": "arn:aws:s3:::kho-du-phong-us-east-1",
        "StorageClass": "STANDARD_IA"
      }
    }]}'

Chú ý StorageClass: STANDARD_IA ở đích — đây là chỗ tiết kiệm quan trọng: dữ liệu ít được truy cập nên không cần lớp Standard đắt tiền ở cả hai nơi.

Và nên đặt thêm lifecycle rule để tự chuyển lớp lưu trữ theo thời gian:

0–30 ngày   → Standard
30–90 ngày  → Standard-IA
90+ ngày    → Glacier Instant Retrieval hoặc Glacier Flexible Retrieval

Điều kiện bắt buộc để CRR hoạt động: cả hai bucket phải bật versioning.

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

• D. S3 với Same-Region Replication — sai ở yêu cầu quan trọng nhất: SRR nhân bản trong CÙNG một Region, nên không đáp ứng được yêu cầu dư thừa GIỮA CÁC REGION. (Ghi chú: phương án này còn viết nhầm chữ viết tắt — Same-Region Replication là SRR, không phải CRR.)
• B. DynamoDB với Global Tables — sai loại lưu trữ: DynamoDB là CSDL NoSQL với giới hạn 400 KB mỗi item — không phải nơi lưu tệp. Và nó đắt hơn S3 rất nhiều cho cùng dung lượng.
• A. Storage Gateway với replicated file gateway — sai mục đích: Storage Gateway là cầu nối giữa hạ tầng TẠI CHỖ và AWS, cho phép máy chủ on-premises dùng lưu trữ đám mây. Đề không nhắc gì tới hạ tầng tại chỗ, và giải pháp này phức tạp cùng tốn kém hơn hẳn.

Ghi nhớ

Hai loại nhân bản của S3: | | CRR (Cross-Region) | SRR (Same-Region) | |---|---|---| | Đích | Region khác | cùng Region | | Dùng cho | tuân thủ đa Region, khôi phục sau thảm hoạ, giảm độ trễ cho người dùng ở xa | gộp log, tách môi trường, tuân thủ chủ quyền dữ liệu |

Yêu cầu chung cho cả hai: | Yêu cầu | Chi tiết | |---|---| | Versioning | bật ở CẢ HAI bucket | | IAM role | cho S3 quyền đọc nguồn và ghi đích | | Phạm vi | chỉ object MỚI — object cũ cần S3 Batch Replication |

Dòng cuối rất hay bị bỏ sót: bật CRR không tự sao chép dữ liệu đã có.

Các lớp lưu trữ của S3, theo chi phí tăng dần về phía truy cập: | Lớp | Dùng cho | Phí truy xuất | |---|---|---| | Standard | truy cập thường xuyên | không | | Standard-IA | ít truy cập, cần ngay khi cần | có | | One Zone-IA | ít truy cập, chấp nhận rủi ro một AZ | có | | Glacier Instant Retrieval | lưu trữ dài hạn, truy xuất tức thì | có | | Glacier Flexible Retrieval | lưu trữ, chờ phút tới giờ | có | | Glacier Deep Archive | rẻ nhất, chờ tới 12 giờ | có | | Intelligent-Tiering | mẫu truy cập không đoán được — tự chuyển lớp | không (có phí giám sát) |

Với đề bài này, Standard-IA là lớp hợp lý; nếu tệp gần như không bao giờ đọc lại, Glacier Instant Retrieval còn rẻ hơn nữa.

Đáp án

D — AWS CloudTrail.

Vì sao đúng

Yêu cầu rất trực tiếp: ghi lại nhật ký MỌI lời gọi API tới tài nguyên AWS. Đó chính xác là định nghĩa của CloudTrail.

CloudTrail ghi lại ai làm gì, khi nào, từ đâu:

{
  "eventTime": "2026-08-05T10:30:00Z",
  "eventName": "TerminateInstances",
  "eventSource": "ec2.amazonaws.com",
  "awsRegion": "ap-southeast-1",
  "sourceIPAddress": "203.0.113.45",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "nguyen-van-a",
    "arn": "arn:aws:iam::123456789012:user/nguyen-van-a"
  },
  "requestParameters": {"instancesSet": {"items": [{"instanceId": "i-0abc123"}]}},
  "responseElements": {...}
}

Với yêu cầu bảo mật nghiêm ngặt như đề mô tả, nên tạo multi-region trail kèm các biện pháp bảo vệ:

aws cloudtrail create-trail \
  --name trail-tuan-thu \
  --s3-bucket-name kho-cloudtrail-cong-ty \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id alias/khoa-cloudtrail

aws cloudtrail start-logging --name trail-tuan-thu

Ba tuỳ chọn đáng chú ý: | Tuỳ chọn | Việc | |---|---| | --is-multi-region-trail | phủ mọi Region, kể cả Region AWS mở sau này | | --enable-log-file-validation | sinh tệp digest có chữ ký — chứng minh log không bị sửa | | --kms-key-id | mã hoá log bằng CMK riêng |

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

• B. Amazon CloudWatch Logs — lưu trữ và tìm kiếm log, nhưng nó không tự sinh ra bản ghi API. Nó là nơi chứa log do ứng dụng hoặc dịch vụ khác gửi tới. (CloudTrail có thể gửi log sang CloudWatch Logs để tìm kiếm và đặt alarm — nhưng nguồn dữ liệu vẫn là CloudTrail.)
• C. Amazon CloudWatch — dịch vụ giám sát bằng metric và alarm. Nó theo dõi số liệu hiệu năng (CPU, độ trễ, số lỗi), không ghi lại từng lời gọi API và không cho biết ai gọi.
• A. AWS X-Ray — theo dấu request qua các dịch vụ để phân tích hiệu năng và tìm chặng lỗi. Nó nhìn vào traffic của ứng dụng, không phải lời gọi API quản trị.

Ghi nhớ

Bốn công cụ quan sát, mỗi cái trả lời một câu hỏi khác nhau: | Công cụ | Trả lời | |---|---| | CloudTrail | AI đã gọi API nào, khi nào, từ đâu? | | CloudWatch Metrics | Có bao nhiêu, nhanh chậm thế nào? | | CloudWatch Logs | Ứng dụng đã ghi ra gì? | | X-Ray | Request đi qua đâu, chậm ở chặng nào? |

Nhận dạng nhanh: đề nói "log of all API calls", "audit", "who did what", "compliance" ⇒ CloudTrail.

Hai loại sự kiện của CloudTrail: | Loại | Nội dung | Chi phí | |---|---|---| | Management event | thao tác quản trị (tạo instance, sửa policy, xoá bucket) | trail đầu tiên miễn phí | | Data event | thao tác dữ liệu (s3:GetObject, lambda:Invoke, dynamodb:PutItem) | có phí, khối lượng rất lớn |

Data event tắt theo mặc định — bật cho một bucket bận rộn có thể sinh hàng triệu bản ghi mỗi ngày, nên chọn lọc đúng tài nguyên cần kiểm toán.

Ba tính năng khác đáng biết: | Tính năng | Việc | |---|---| | Event history | 90 ngày, miễn phí, bật sẵn — nhưng chỉ management event | | Organization trail | một trail cho TOÀN BỘ tổ chức, tài khoản thành viên không tắt được | | CloudTrail Lake | kho dữ liệu để truy vấn bằng SQL trực tiếp, không cần Athena |

Và điểm quan trọng cần nhớ: CloudTrail ghi lời gọi API, không ghi traffic của người dùng cuối. Muốn biết ai truy cập ứng dụng thì dùng ALB access log, CloudFront log, hoặc VPC Flow Logs.

Đáp án

A — CloudWatch Logs chỉ phát dữ liệu metric cho các sự kiện xảy ra SAU KHI filter được tạo.

Vì sao đúng

Đây là hành vi rất hay gây bối rối: metric filter không quét lại log cũ.

Nó hoạt động như một bộ lọc đặt trên dòng chảy: khi một dòng log mới tới, filter kiểm tra và phát ra điểm dữ liệu metric nếu khớp. Với những dòng đã nằm sẵn trong log group từ trước, filter hoàn toàn không đụng tới.

Timeline:
  10:00  ─ log ghi 50 exception  ──→ (chưa có filter) → không có metric nào
  11:00  ─ TẠO metric filter
  11:05  ─ log ghi 3 exception   ──→ khớp filter → metric = 3  ✓

Nên nếu vừa tạo filter mà chưa có exception mới nào, biểu đồ hoàn toàn trống — đúng triệu chứng trong đề.

Cách kiểm tra filter có đúng cú pháp không mà không phải chờ:

aws logs test-metric-filter \
  --filter-pattern '{ $.level = "ERROR" }' \
  --log-event-messages '{"level":"ERROR","msg":"loi ket noi"}'

Và để phân tích log CŨ, dùng CloudWatch Logs Insights — nó truy vấn được toàn bộ dữ liệu đã lưu:

fields @timestamp, @message
| filter @message like /Exception/
| stats count() by bin(1h)

Đây là phân công đúng giữa hai công cụ: Insights nhìn về quá khứ, metric filter nhìn về tương lai.

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

• B. Khoảng thời gian của filter chưa được cấu hình đúng — metric filter không có tham số khoảng thời gian. Nó chạy liên tục trên mọi dòng log mới. (Khoảng thời gian là thứ bạn chọn khi xem biểu đồ, không phải thuộc tính của filter.)
• C. Log ứng dụng đã được lưu trữ sang S3 nên không lọc được — export sang S3 không xoá log khỏi CloudWatch. Log vẫn nằm trong log group cho tới khi hết hạn retention, và filter vẫn áp cho dòng mới bình thường.
• D. Chưa cài CloudWatch Logs agent trên EC2 instance — mâu thuẫn với đề: đề nói lập trình viên đang sàng lọc dữ liệu log trong CloudWatch Logs, tức là log đã có ở đó. Nếu chưa cài agent thì sẽ không có log nào để mà xem.

Ghi nhớ

Phân công giữa hai công cụ — điểm quan trọng nhất của câu này: | | Metric filter | Logs Insights | |---|---|---| | Áp cho dữ liệu | CHỈ log MỚI, từ lúc tạo | TOÀN BỘ log đã lưu | | Chạy | liên tục, tự động | theo yêu cầu | | Kết quả | metric — đặt alarm được | bảng kết quả để xem | | Chi phí | phí custom metric | tính theo lượng dữ liệu quét |

Nhận dạng nhanh: cần cảnh báo liên tục ⇒ metric filter. Cần điều tra sự cố đã xảy ra ⇒ Logs Insights.

Vài mẫu filter pattern hay dùng:

ERROR                          # log dạng text thuần
"Exception" -"NullPointer"     # có Exception nhưng loại trừ NullPointer
{ $.level = "ERROR" }          # log JSON
{ $.duration > 1000 }          # so sánh số trong JSON
[ip, user, ts, req, status=5*] # log dạng cột, mã 5xx

Một chi tiết đáng biết khi tạo filter: đặt defaultValue: 0 cho metric transformation. Nếu không, những khoảng thời gian không có dòng nào khớp sẽ không có điểm dữ liệu (thay vì có điểm bằng 0) — khiến alarm rơi vào INSUFFICIENT_DATA và biểu đồ bị đứt quãng.

Ba công cụ xử lý log của CloudWatch, cho ba mục đích: | Công cụ | Mục đích | |---|---| | Metric filter | log → metric, để cảnh báo | | Logs Insights | truy vấn khám phá | | Subscription filter | đẩy log sang nơi khác (Lambda, Kinesis, OpenSearch) |

Đáp án

A và C.

• C — Đặt Viewer Protocol Policy thành "HTTPS Only" hoặc "Redirect HTTP to HTTPS"
• A — Đặt Origin Protocol Policy thành "HTTPS Only"

Vì sao đúng

Yêu cầu là mã hoá cả hai chặng của đường đi:

Người dùng ──chặng 1──→ CloudFront ──chặng 2──→ Ứng dụng web (origin)
             ↑                        ↑
      Viewer Protocol Policy   Origin Protocol Policy

Hai chính sách này điều khiển hai chặng độc lập với nhau, nên phải đặt cả hai.

C — Viewer Protocol Policy (người dùng ↔ CloudFront): | Giá trị | Hành vi | |---|---| | allow-all | cho phép cả HTTP lẫn HTTPS | | redirect-to-https | chuyển hướng HTTP sang HTTPS — thường dùng nhất | | https-only | từ chối hẳn HTTP |

A — Origin Protocol Policy (CloudFront ↔ origin): | Giá trị | Hành vi | |---|---| | http-only | luôn dùng HTTP — phá vỡ mã hoá đầu-cuối | | https-only | luôn dùng HTTPS | | match-viewer | dùng đúng giao thức mà người dùng đã dùng |

{
  "DefaultCacheBehavior": {"ViewerProtocolPolicy": "redirect-to-https"},
  "Origins": [{
    "DomainName": "alb-ung-dung.ap-southeast-1.elb.amazonaws.com",
    "CustomOriginConfig": {
      "OriginProtocolPolicy": "https-only",
      "OriginSSLProtocols": {"Items": ["TLSv1.2"]}
    }
  }]
}

Điểm hay bị bỏ sót: chỉ đặt Viewer Protocol Policy là chưa đủ. Nhiều người thấy trình duyệt hiện ổ khoá rồi yên tâm, trong khi chặng từ CloudFront tới origin vẫn đang chạy HTTP — dữ liệu vẫn đi qua Internet công khai ở dạng không mã hoá.

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

• B. Bật "Restrict Viewer Access" — tính năng này bắt buộc dùng signed URL hoặc signed cookie để truy cập nội dung. Nó là cơ chế kiểm soát truy cập, không phải mã hoá.
• D. Dùng AWS KMS để mã hoá traffic giữa CloudFront và ứng dụng web — KMS mã hoá DỮ LIỆU, không mã hoá KẾT NỐI. Mã hoá đường truyền là việc của TLS.
• E. Đặt HTTP Port của origin thành 443 — đổi số cổng không đổi giao thức: CloudFront vẫn nói HTTP thuần, chỉ là qua cổng 443. Cổng và giao thức là hai thứ khác nhau. (Cấu hình đúng là đặt OriginProtocolPolicy: https-only, khi đó CloudFront dùng HTTPSPort — mặc định đã là 443.)

Ghi nhớ

Ba chặng có thể mã hoá trong kiến trúc CloudFront:

Người dùng → CloudFront → ALB → EC2
            ①            ②      ③

Hai lưu ý quan trọng về chứng chỉ:

1. Chứng chỉ ACM cho CloudFront bắt buộc nằm ở Region us-east-1 — cấp nhầm Region thì Console đơn giản là không hiện nó trong danh sách, không có thông báo giải thích.
2. CloudFront CÓ kiểm tra chứng chỉ của origin — nó phải hợp lệ, do CA công cộng cấp, và tên miền phải khớp với DomainName khai trong origin. Đây là khác biệt với ALB, vốn không kiểm tra chứng chỉ backend.

Và nên đặt OriginSSLProtocols chỉ gồm TLS 1.2 trở lên — mặc định vẫn cho phép các phiên bản cũ hơn.

Ba tính năng bảo mật khác của CloudFront, đừng lẫn với mã hoá: | Tính năng | Việc | |---|---| | Origin Access Control (OAC) | chỉ CloudFront đọc được S3 bucket | | Restrict Viewer Access | yêu cầu signed URL/cookie | | Geo restriction | chặn theo quốc gia | | AWS WAF | lọc request độc hại |

Đáp án

B — AWS credential provider tìm instance profile credentials SAU CÙNG.

Vì sao đúng

Đây là hệ quả của chuỗi thứ tự tìm credential (credential provider chain) trong AWS SDK. SDK không tìm ngẫu nhiên — nó duyệt theo thứ tự ưu tiên cố định và dùng cái đầu tiên tìm thấy.

Với AWS SDK for Java, thứ tự là:

1. Thuộc tính hệ thống của Java (-Daws.accessKeyId)
2. BIẾN MÔI TRƯỜNG (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)   ← ĐỀ BÀI Ở ĐÂY
3. Web identity token
4. Tệp ~/.aws/credentials
5. Credential của container (ECS)
6. INSTANCE PROFILE (IAM role của EC2)                          ← BỊ BỎ QUA

Đề nói rõ ứng dụng lưu access key trong biến môi trường — tức là bước 2. Nên SDK tìm thấy credential ngay ở đó và không bao giờ đi tới bước 6 để dùng IAM role mới.

Kết quả: gắn role hạn chế vào instance không có tác dụng gì, vì access key cũ vẫn được ưu tiên.

Cách sửa là gỡ credential ở các bước có ưu tiên cao hơn:

# Xoá biến môi trường
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

# Kiểm tra tệp credentials có tồn tại không
rm -f ~/.aws/credentials

# Xác nhận danh tính đang dùng
aws sts get-caller-identity

Lệnh cuối là công cụ chẩn đoán hữu ích nhất — nó cho biết SDK đang thực sự dùng danh tính nào:

{"Arn": "arn:aws:iam::123456789012:user/cu"}          ← vẫn dùng access key
{"Arn": "arn:aws:sts::123456789012:assumed-role/..."} ← đã dùng instance role

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

• A. Đang dùng IAM managed policy trên role và D. Đang dùng IAM inline policy trên role — loại policy không ảnh hưởng tới nội dung quyền. Cả managed lẫn inline đều thực thi đúng những gì viết trong đó. Vấn đề không nằm ở role, mà ở chỗ role không hề được dùng tới.
• C. AWS CLI bị hỏng, cần cài lại — không liên quan: ứng dụng dùng AWS SDK for Java, không dùng CLI. Và hành vi quan sát được (vẫn ghi được vào mọi bucket) là đúng logic, không phải dấu hiệu phần mềm hỏng.

Ghi nhớ

Chuỗi tìm credential — đáng thuộc vì nó giải thích rất nhiều lỗi khó hiểu: | Thứ tự | Nguồn | |---|---| | 1 | Thuộc tính hệ thống / tham số truyền thẳng vào mã | | 2 | Biến môi trường | | 3 | Web identity token | | 4 | Tệp ~/.aws/credentials | | 5 | Credential của container (ECS task role) | | 6 | Instance profile (EC2 IAM role) — cuối cùng |

(Thứ tự chi tiết khác nhau đôi chút giữa các SDK, nhưng nguyên tắc chung không đổi: credential khai tường minh luôn thắng credential lấy tự động từ môi trường.)

Bài học quan trọng nhất: gắn IAM role vào instance KHÔNG tự động vô hiệu hoá credential cũ. Bạn phải chủ động gỡ chúng đi.

Danh sách kiểm khi "đã gắn role mà quyền vẫn như cũ":

1. aws sts get-caller-identity — đang là ai?
2. Kiểm tra biến môi trường: env | grep AWS
3. Kiểm tra tệp: cat ~/.aws/credentials
4. Kiểm tra mã có hardcode credential không
5. Khởi động lại ứng dụng — SDK cache credential trong bộ nhớ

Và nguyên tắc bao trùm: ứng dụng chạy trên AWS thì không bao giờ dùng access key dài hạn. Luôn dùng cơ chế phù hợp với nơi mã chạy — instance profile cho EC2, task role cho ECS, execution role cho Lambda.

Đáp án

A — CORS chưa được bật trên bucket dctlabsimages.

Vì sao đúng

Tình huống trong đề là cross-origin request kinh điển:

Trang web ở origin: http://dctlabs.com.s3-website-...amazonaws.com
JavaScript tải ảnh từ: https://dctlabsimages.s3.amazonaws.com/
                        ↑ ORIGIN KHÁC

Trình duyệt áp dụng same-origin policy: JavaScript ở origin này không được đọc tài nguyên từ origin khác trừ khi phía trả lời cho phép tường minh.

Và điểm mấu chốt: CORS luôn được bật ở phía MÁY CHỦ TRẢ LỜI request — ở đây là bucket chứa ảnh, tức dctlabsimages.

aws s3api put-bucket-cors --bucket dctlabsimages --cors-configuration '{
  "CORSRules": [{
    "AllowedOrigins": ["http://dctlabs.com.s3-website-ap-southeast-1.amazonaws.com"],
    "AllowedMethods": ["GET", "HEAD"],
    "AllowedHeaders": ["*"],
    "MaxAgeSeconds": 3000
  }]
}'

Sau đó S3 sẽ thêm header cho phép vào response:

Access-Control-Allow-Origin: http://dctlabs.com.s3-website-...

— và trình duyệt mới cho JavaScript đọc dữ liệu.

(Ghi chú kỹ thuật: thẻ <img> thông thường không bị CORS chặn — trình duyệt vẫn hiển thị ảnh. Nhưng đề nói rõ trang dùng JavaScript để tải ảnh, và khi JavaScript đọc dữ liệu ảnh — qua fetch, XMLHttpRequest, hoặc <img crossorigin> để vẽ lên canvas — thì CORS mới áp dụng.)

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

• C. CORS chưa được bật trên bucket dctlabs.com — đây là bẫy chính, và nó sai ở chỗ đặt cấu hình. Bucket dctlabs.com là nơi PHÁT ĐI request, không phải nơi TRẢ LỜI. Bật CORS ở đó hoàn toàn không chạm tới vấn đề.
• B. Cần bật S3 Transfer Acceleration — tính năng tối ưu tốc độ TẢI LÊN từ xa bằng cách đi qua edge location. Nó không liên quan gì tới CORS và không ảnh hưởng tới việc trình duyệt cho phép hay chặn.
• D. Hai bucket không nằm cùng Region — Region không ảnh hưởng tới CORS. Bucket ở đâu cũng truy cập được qua Internet; điều quyết định là header cho phép trong response.

Ghi nhớ

Nguyên tắc cốt lõi: CORS được cấu hình ở PHÍA TRẢ LỜI request, không phải ở phía gọi đi.

Phân biệt hai nhóm header CORS: | Nhóm | Ai gửi | Ví dụ | |---|---|---| | Request (Access-Control-Request-*) | trình duyệt, tự động | -Method, -Headers | | Response (Access-Control-Allow-*) | máy chủ, bạn phải cấu hình | -Origin, -Methods, -Headers |

Các trường trong CORS rule của S3: | Trường | Việc | |---|---| | AllowedOrigins | origin nào được phép — dùng * thì mở cho tất cả | | AllowedMethods | GET, PUT, POST, DELETE, HEAD | | AllowedHeaders | header nào được gửi trong request | | ExposeHeaders | header nào JavaScript ĐỌC ĐƯỢC từ response (ví dụ ETag) | | MaxAgeSeconds | trình duyệt cache kết quả preflight bao lâu |

Trường ExposeHeaders hay bị bỏ sót: mặc định JavaScript chỉ đọc được vài header cơ bản. Muốn đọc ETag (để kiểm tra phiên bản tệp) hay x-amz-meta-* thì phải khai tường minh.

Ba tình huống thường cần CORS trên S3: | Tình huống | Method cần | |---|---| | Trang web tải ảnh, font, dữ liệu JSON | GET, HEAD | | Tải tệp trực tiếp lên S3 bằng presigned URL | PUT, POST | | Xoá object từ trình duyệt | DELETE |

Và lời khuyên bảo mật: đừng để AllowedOrigins: ["*"] cho bucket chứa dữ liệu riêng — hãy khai đúng những origin của bạn.