Ngân hàng đề — AWS Certified Solutions Architect Professional

Tìm thấy 1221 câu.

Câu 261 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A startup is developing a health-related mobile app for both iOS and Android devices. The co-founder developed a sleep tracking app that collects the user's biometric data then stores them in an Amazon DynamoDB table, which is configured with an on-demand provisioned throughput capacity. Every nine in the morning, a scheduled task scans the DynamoDB table to extract and aggregate last night’s data for each user and stores the results in an Amazon S3 bucket. When the new data is available, the users are then notified via Amazon SNS mobile push notifications. Due to budget constraints, the management wants to optimize the current architecture of the backend system to lower costs and increase the overall revenue.

Which of the following options can the solutions architect implement to further lower the cost in AWS? (Select TWO.)

A Launch a Redshift cluster to replace Amazon DynamoDB. Switch from a Standard S3 bucket to One Zone-Infrequent Access storage class.
B Use ElastiCache to cache reads and writes from the DynamoDB table.
C Set up a scheduled job to drop the DynamoDB table for the previous day that contains the biometric data after it is successfully stored in the S3 bucket. Create another DynamoDB table for the day and perform the deletion and creation process everyday.
D Use a RDS instance configured with Multi-AZ deployments and Read Replicas as a replacement to your DynamoDB.
E Avail a reserved capacity for provisioned throughput for DynamoDB.

Xem giải thích

Đáp án

**C và E — Lập công việc theo lịch xoá bảng DynamoDB của ngày hôm trước sau khi dữ liệu đã được lưu an toàn vào S3, và tạo bảng mới cho ngày hôm nay, lặp lại quy trình mỗi ngày; đồng thời mua reserved capacity cho thông lượng đã cấp phát của DynamoDB.

Vì sao đúng

Đề nêu một mục tiêu duy nhất — giảm chi phí — và hai đáp án tấn công hai khoản chi khác nhau: | Khoản chi | Cách giảm | |---|---| | Lưu trữ dữ liệu cũ trong DynamoDB | xoá bảng hằng ngày sau khi lưu vào S3 | | Thông lượng đã cấp phát | reserved capacity |

⚠ Xoá cả BẢNG rẻ hơn nhiều so với xoá từng mục:

`DeleteItem` cho hàng triệu bản ghi
    → mỗi lần xoá tốn WCU
        ↓
    `DeleteTable`: MIỄN PHÍ
    → và tức thì
        ↓
    Đây là mẫu chuẩn cho dữ liệu
      theo ngày dùng một lần

Xoá bảng cũ và tạo bảng mới:

aws dynamodb delete-table --table-name du-lieu-2026-08-31

aws dynamodb create-table --table-name du-lieu-2026-09-01 \
  --attribute-definitions AttributeName=idNguoiDung,AttributeType=S \
  --key-schema AttributeName=idNguoiDung,KeyType=HASH \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=500

⚠ Và reserved capacity giảm tới 50-70% chi phí thông lượng:

aws dynamodb purchase-reserved-capacity-offerings \
  --reserved-capacity-offering-id <id> --quantity 1

Cam kết một mức thông lượng
  trong 1 hoặc 3 năm
        ↓
    Giảm giá đáng kể so với
      trả theo giờ
        ↓
    Hợp với tải ổn định, biết trước

⚠ Nhưng đề có một mâu thuẫn về chế độ thanh toán:

Đề nói bảng dùng "on-demand
  provisioned throughput capacity"
        ↓
    On-demand và provisioned là HAI
      chế độ LOẠI TRỪ nhau
        ↓
    Reserved capacity CHỈ áp cho
      chế độ PROVISIONED
    → phải chuyển sang provisioned
      trước khi mua

Chuyển sang provisioned:

aws dynamodb update-table --table-name du-lieu \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=100,WriteCapacityUnits=500

⚠ Và thao tác quét toàn bảng mỗi sáng là chỗ tốn WCU/RCU lớn nhất:

`Scan` đọc TOÀN BỘ bảng
    → tốn RCU theo tổng dung lượng
        ↓
    Với dữ liệu sinh trắc của hàng
      triệu người dùng
    → mỗi lần quét rất đắt

⚠ Và cách rẻ hơn nữa là dùng DynamoDB Export sang S3:

aws dynamodb export-table-to-point-in-time \
  --table-arn <arn-bang> \
  --s3-bucket ket-qua-tong-hop \
  --export-format DYNAMODB_JSON

Export KHÔNG tiêu RCU
    → xuất toàn bộ bảng sang S3
      mà không chạm thông lượng
        ↓
    Rồi dùng Athena hoặc Glue
      để tổng hợp
    → rẻ hơn nhiều so với Scan

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không trả tiền lưu trữ dữ liệu đã chuyển sang S3 | | | Xoá bảng miễn phí, xoá từng mục thì không | | | Reserved capacity giảm mạnh chi phí thông lượng | |

⚠ Và Redshift, RDS đều KHÔNG rẻ hơn DynamoDB ở đây:

Redshift (phương án A): cụm chạy
  24/7, đắt hơn nhiều
        ↓
    RDS Multi-AZ với read replica
      (phương án D): ba instance
      chạy liên tục
        ↓
    Cả hai đều TĂNG chi phí

⚠ Và ElastiCache (phương án B) cũng thêm chi phí:

Cache trước DynamoDB
    → thêm một cụm phải trả tiền
        ↓
    Và dữ liệu sinh trắc ghi một lần,
      đọc một lần mỗi sáng
    → không có mẫu đọc lặp lại
      để cache

Ghi nhớ về chất lượng câu hỏi

⚠ TTL của DynamoDB là cách hiện đại hơn để xoá dữ liệu cũ.

aws dynamodb update-time-to-live --table-name du-lieu \
  --time-to-live-specification "Enabled=true,AttributeName=hetHan"

Tiêu chí	Bảng theo ngày	TTL
Chi phí xoá	miễn phí (DeleteTable)	MIỄN PHÍ
Độ phức tạp ứng dụng	phải biết tên bảng theo ngày	không đổi gì
Thời điểm xoá	chính xác	trong vòng vài ngày

TTL: đặt một thuộc tính thời gian
  trên mỗi mục
        ↓
    DynamoDB tự xoá, KHÔNG tốn WCU
    → và không phải quản lý tên bảng

⚠ Nhưng TTL không xoá đúng giờ:

AWS xoá "trong vòng vài ngày sau
  thời điểm hết hạn"
        ↓
    Cần xoá chính xác theo ngày
    → bảng theo ngày vẫn đúng hơn
        ↓
    Cần đơn giản
    → TTL

Và một điểm nữa về S3 One Zone-IA trong phương án A:

One Zone-IA lưu ở MỘT AZ duy nhất
    → mất AZ đó là mất dữ liệu
        ↓
    Với kết quả tổng hợp có thể
      tính lại được
    → chấp nhận được
        ↓
    Nhưng dữ liệu gốc đã xoá khỏi
      DynamoDB
    → không tính lại được nữa

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

**A. Dùng Redshift thay DynamoDB và chuyển bucket S3 sang One Zone-IA — đây là phương án gần nhất và One Zone-IA thật sự rẻ hơn Standard, nhưng Redshift là cụm chạy 24/7, đắt hơn DynamoDB rất nhiều cho mẫu ghi theo khoá này; và One Zone-IA rủi ro khi dữ liệu gốc đã bị xoá.
**D. Dùng RDS Multi-AZ với Read Replica thay DynamoDB — ba instance chạy liên tục, tăng chi phí chứ không giảm.
**B. Dùng ElastiCache cache đọc ghi từ DynamoDB — thêm một cụm phải trả tiền, và mẫu truy cập không có lặp lại để cache.

Ghi nhớ

⚠ Bốn cách giảm chi phí DynamoDB — bảng phải thuộc: | Cách | Giảm gì | |---|---| | Reserved capacity | chi phí thông lượng provisioned | | TTL hoặc xoá bảng | chi phí lưu trữ | | Export sang S3 thay Scan | chi phí RCU | | Standard-IA table class | lưu trữ, cho dữ liệu ít đọc |

⚠ DynamoDB Standard-IA là lựa chọn ít người biết:

aws dynamodb update-table --table-name du-lieu \
  --table-class STANDARD_INFREQUENT_ACCESS

Rẻ hơn 60% chi phí LƯU TRỮ
    → nhưng đắt hơn về thông lượng
        ↓
    Hợp với bảng lưu nhiều, đọc ít

Từ khoá nhận diện:

"delete all data from a day" → DeleteTable hoặc TTL "steady predictable throughput" → reserved capacity "unpredictable traffic" → on-demand "export table for analysis" → Export to S3, không tốn RCU

⚠ On-demand và provisioned — bảng phải thuộc: | Tiêu chí | On-demand | Provisioned | |---|---|---| | Chuẩn bị trước | không cần | phải đoán công suất | | Đỉnh đột ngột | xử lý được | có thể bị chặn | | Reserved capacity | KHÔNG áp dụng | áp dụng | | Chi phí mỗi đơn vị | cao hơn | thấp hơn |

Ba lưu ý về reserved capacity: | Lưu ý | Chi tiết | |---|---| | Cam kết 1 hoặc 3 năm | | | Chỉ áp cho chế độ provisioned | | | Mua đúng mức tải NỀN, không mua thừa | |

Ba lưu ý về xoá dữ liệu: | Cách | Chi phí | |---|---| | DeleteTable | miễn phí | | TTL | miễn phí | | DeleteItem từng mục | tốn WCU | | BatchWriteItem xoá | tốn WCU |

⚠ Đây là khác biệt rất lớn về chi phí:

Xoá 10 triệu mục bằng DeleteItem
    → 10 triệu WCU
        ↓
    Xoá cả bảng
    → 0 WCU

Ba lưu ý về bảng theo ngày: | Lưu ý | Chi tiết | |---|---| | Ứng dụng phải biết tên bảng hôm nay | | | Tạo bảng mới trước khi cần dùng | | | Reserved capacity áp theo Region, không theo bảng | |

⚠ Điểm cuối là lý do mẫu này vẫn dùng được với reserved capacity:

Reserved capacity mua theo Region
    → không gắn với một bảng cụ thể
        ↓
    Xoá bảng cũ, tạo bảng mới
    → reserved capacity vẫn áp

Ba lưu ý về xuất dữ liệu: | Cách | Đặc điểm | |---|---| | Export to S3 | không tốn RCU, cần bật PITR | | Scan | tốn RCU theo dung lượng bảng | | DynamoDB Streams | theo dõi thay đổi, không xuất toàn bộ |

Ba lưu ý về lớp lưu trữ S3 cho kết quả: | Lớp | Hợp với | |---|---| | Standard | đọc thường xuyên trong tháng đầu | | Standard-IA | ít đọc, cần ngay khi cần | | One Zone-IA | dữ liệu tính lại được |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xác nhận dữ liệu đã vào S3 TRƯỚC khi xoá bảng | | | So hoá đơn DynamoDB trước và sau | | | Kiểm mức dùng reserved capacity trong Cost Explorer | |

Và một lời khuyên: hãy xác nhận dữ liệu đã ghi thành công vào S3 trước khi xoá bảng. Xoá bảng DynamoDB là thao tác không hoàn tác được — và một lỗi trong bước tổng hợp buổi sáng sẽ trở thành mất dữ liệu vĩnh viễn nếu công việc xoá vẫn chạy đúng lịch.

Câu 262 Domain - Design for New Solutions

A government technology agency has recently hired a team to build a mobile tax app that allows users to upload their tax deductions and income records using their devices. The app would also allow users to view or download their uploaded files later on. These files are confidential, tax-related documents that need to be stored in a single, secure S3 bucket. The mobile app's design is to allow the users to upload, view, and download their files directly from an Amazon S3 bucket via the mobile app. Since this app will be used by potentially hundreds of thousands of taxpayers in the country, the solutions architect must ensure that proper user authentication and security features are in place.

Which of the following options should the solutions architect implement in the infrastructure when a new user registers on the app?

A
Use Amazon DynamoDB to record the user's information and when the user uses the mobile app, create access credentials using STS with appropriate permissions. Store these credentials in the mobile app's memory and use them to access the S3 bucket every time the user runs the app.
B Record the user's information in Amazon RDS and create a role in IAM with appropriate permissions. When the user uses his/her mobile app, create temporary credentials using the 'AssumeRole' function in STS. Store these credentials in the mobile app's memory and use them to access the S3 bucket. Generate new credentials the next time the user runs the mobile app.
C Create a set of long-term credentials using AWS Security Token Service with appropriate permissions. Store these credentials in the mobile app and use them to access Amazon S3.
D
Create an IAM user then assign appropriate permissions to the IAM user. Generate an access key and secret key for the IAM user, store them in the mobile app and use these credentials to access Amazon S3.

Xem giải thích

Đáp án

**B — Ghi thông tin người dùng vào Amazon RDS và tạo một IAM role với quyền phù hợp; khi người dùng mở ứng dụng thì tạo credential tạm bằng AssumeRole của STS, lưu trong bộ nhớ ứng dụng và dùng để truy cập S3; lần sau mở ứng dụng thì sinh credential mới.

Vì sao đúng

Đề hỏi cách đăng ký người dùng an toàn, và nguyên tắc quyết định chỉ có một:

KHÔNG BAO GIỜ nhúng credential
  tồn tại lâu dài vào ứng dụng
  di động
        ↓
    Ứng dụng nằm trên máy người dùng
    → giải nén APK/IPA là đọc được
      mọi chuỗi
    → không có cách nào giấu

⚠ Đây là lý do hai phương án bị loại ngay: | Phương án | Vấn đề | |---|---| | C. "long-term credentials using STS" | STS chỉ cấp credential TẠM — mô tả sai | | D. IAM user + access key trong app | khoá tĩnh, ai cũng trích ra được |

⚠ Và phương án C sai ngay ở định nghĩa:

STS = Security Token Service
    → sinh ra token TẠM THỜI
        ↓
    "Long-term credentials using STS"
      là thứ không tồn tại
    → tối đa 12 giờ với AssumeRole

Luồng đúng:

Người dùng đăng nhập
    → máy chủ xác thực với RDS
        ↓
    Máy chủ gọi `AssumeRole` với
      chính sách thu hẹp theo người dùng
        ↓
    Trả credential tạm về ứng dụng
    → ứng dụng gọi thẳng S3
        ↓
    Hết hạn → xin lại

Thu hẹp phạm vi cho từng người dùng:

import boto3, json
sts = boto3.client('sts')

def cap_credential(ma_nguoi_dung):
    chinh_sach = {"Version": "2012-10-17", "Statement": [{
        "Effect": "Allow",
        "Action": ["s3:GetObject", "s3:PutObject"],
        "Resource":
          f"arn:aws:s3:::ho-so-thue/{ma_nguoi_dung}/*"}]}
    return sts.assume_role(
        RoleArn='arn:aws:iam::111122223333:role/NguoiNopThue',
        RoleSessionName=f'phien-{ma_nguoi_dung}',
        Policy=json.dumps(chinh_sach),
        DurationSeconds=3600)['Credentials']

⚠ Tham số Policy là phần quan trọng nhất:

Không có nó: mọi người dùng nhận
  cùng một quyền
    → người A đọc được hồ sơ thuế
      của người B
        ↓
    Có: quyền hiệu lực là GIAO của
      chính sách vai trò và chính
      sách phiên này
    → mỗi người chỉ chạm thư mục
      của chính mình

⚠ Và phương án A khác B ở chỗ nào:

A: ghi thông tin vào DynamoDB
    → và tạo credential bằng STS
        ↓
    Nghe rất giống B
    → nhưng A KHÔNG nhắc tới việc
      tạo IAM ROLE
    → và không nói sinh credential mới
      mỗi lần mở ứng dụng

⚠ Điểm "sinh credential mới mỗi lần mở ứng dụng" rất quan trọng:

Credential tạm có hạn tối đa 12 giờ
    → ứng dụng phải xin lại
        ↓
    Không xin lại: người dùng mở
      ứng dụng ngày hôm sau
    → mọi thao tác S3 thất bại

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có khoá tĩnh trong ứng dụng | | | Credential tự hết hạn | | | Mỗi người chỉ truy cập thư mục của mình | |

⚠ Và tải thẳng lên S3 là mẫu đúng cho ứng dụng di động:

Tệp đi qua máy chủ rồi mới vào S3
    → tốn băng thông gấp đôi
    → máy chủ thành nút thắt
        ↓
    Ứng dụng gọi thẳng S3 với
      credential tạm
    → máy chủ chỉ cấp quyền

Ghi nhớ về chất lượng câu hỏi

⚠ Amazon Cognito là câu trả lời chuẩn cho bài toán này, và nó không có trong danh sách.

Đề nói rõ: ứng dụng di động, luồng đăng ký người dùng, hàng trăm nghìn người dùng, xác thực và bảo mật. Đó là mô tả từng chữ của Cognito:

Việc	Phương án B tự làm	Cognito
Lưu người dùng và mật khẩu	tự viết trên RDS	user pool
Xác nhận email/SMS	tự viết	có sẵn
Quên mật khẩu	tự viết	có sẵn
MFA	tự viết	có sẵn
Đổi token lấy credential AWS	tự gọi STS	identity pool
Cô lập dữ liệu theo người dùng	tự dựng policy phiên	biến `${cognito-identity.amazonaws.com:sub}`

⚠ Cô lập dữ liệu bằng biến của Cognito:

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::ho-so-thue/${cognito-identity.amazonaws.com:sub}/*"}

MỘT chính sách cho mọi người dùng
    → AWS tự thay biến bằng danh tính
      của người đang gọi
        ↓
    Không cần máy chủ nào sinh
      policy động

Và câu này lặp lại gần như nguyên văn một câu khác trong bộ đề (mã #10435, cùng mẫu "RDS + AssumeRole cho ứng dụng di động"). Cùng một kiến thức được hỏi hai lần với bối cảnh khác nhau.

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

**A. Ghi thông tin vào DynamoDB và tạo credential bằng STS, lưu trong bộ nhớ ứng dụng — đây là phương án gần nhất và cũng dùng credential tạm, nhưng nó không nhắc tới việc tạo IAM role (thứ mà AssumeRole bắt buộc phải có) và không nói tới việc sinh credential mới khi hết hạn.
**C. Tạo credential dài hạn bằng STS và lưu trong ứng dụng — STS về bản chất chỉ cấp credential tạm; "long-term credentials using STS" là thứ không tồn tại.
**D. Tạo IAM user với access key và secret key rồi nhúng vào ứng dụng — khoá tĩnh trong ứng dụng phân phối công khai; và IAM có hạn ngạch số user, không dùng cho hàng trăm nghìn người.

Ghi nhớ

⚠ Bốn API cấp credential tạm — bảng phải thuộc: | API | Nguồn danh tính | |---|---| | AssumeRole | danh tính AWS khác, hoặc broker tự dựng | | AssumeRoleWithWebIdentity | OIDC: Google, Facebook, Apple | | AssumeRoleWithSAML | IdP doanh nghiệp SAML | | GetFederationToken | identity broker (chỉ IAM user gọi được) |

Từ khoá nhận diện:

"mobile app, hundreds of thousands of users" → Cognito "never embed credentials" → credential tạm từ STS "per-user folder isolation" → chính sách phiên hoặc biến Cognito "long-term credentials" → luôn là câu trả lời SAI

Ba lưu ý về bảo mật ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Coi mọi thứ trong ứng dụng là công khai | | | Lưu token trong keychain, không trong tệp | | | Xác thực logic quan trọng ở phía máy chủ | |

⚠ Điểm đầu là nguyên tắc phải nhớ:

Mã bị dịch ngược, chuỗi bị trích xuất,
  lưu lượng bị chặn bằng proxy
        ↓
    Không có bí mật nào an toàn
      trong ứng dụng di động
    → thiết kế như thể mọi client
      đều thù địch

Ba lưu ý về cô lập dữ liệu: | Cách | Chi tiết | |---|---| | S3: tiền tố theo id người dùng | | | Chính sách phiên thu hẹp khi giả nhận | | | Thẻ phiên + ABAC | |

Ba lưu ý về thời hạn phiên: | Lưu ý | Chi tiết | |---|---| | Mặc định 1 giờ, tối đa 12 giờ | | | Ứng dụng phải làm mới trước khi hết hạn | | | Bắt lỗi ExpiredToken và xin lại | |

Ba lưu ý về tải tệp lên S3: | Lưu ý | Chi tiết | |---|---| | Tải thẳng, không qua máy chủ trung gian | | | Multipart cho tệp lớn | | | Giới hạn kích thước trong chính sách | |

⚠ Pre-signed URL là lựa chọn khác:

url = s3.generate_presigned_post(
    Bucket='ho-so-thue', Key=f'{ma}/${{filename}}',
    Conditions=[['content-length-range', 0, 10485760],
                {'Content-Type': 'application/pdf'}],
    ExpiresIn=900)

Máy chủ cấp URL, client tải thẳng
    → không cần credential AWS
      trong ứng dụng chút nào

Ba lưu ý về dữ liệu thuế: | Lưu ý | Chi tiết | |---|---| | Mã hoá SSE-KMS với khoá riêng | | | Bật CloudTrail data event | | | Bật versioning chống xoá nhầm | |

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ghi mọi lần giả nhận vai trò | | | RoleSessionName truy về người dùng | | | GuardDuty phát hiện dùng credential bất thường | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử đọc thư mục người dùng khác — phải bị từ chối | | | Dùng token hết hạn — phải bị từ chối | | | Dịch ngược ứng dụng, tìm chuỗi giống access key | |

Và một lời khuyên: hãy dùng Cognito thay vì tự dựng luồng đăng ký trên RDS và STS. Phương án tự làm đúng về nguyên tắc bảo mật, nhưng nó bắt bạn viết và bảo trì toàn bộ tầng xác thực — phần mà mọi lỗ hổng đều đắt giá nhất, và cũng là phần AWS đã làm sẵn.

Câu 263 Domain - Design for New Solutions

A company manages more than 50 AWS accounts under its AWS Organization. All AWS accounts deploy resources on a single AWS region only. To enable routing across all accounts, each VPC has a Transit Gateway Attachment to a centralized AWS Transit Gateway. Each VPC also has an internet gateway and NAT gateway to provide outbound internet connectivity for its resources. As a security requirement, the company must have a centrally managed rule-based filtering solution for outbound internet traffic on all AWS accounts under its organization. It is expected that peak outbound traffic for each Availability Zone will not exceed 25 Gbps.

Which of the following options should the solutions architect implement to fulfill the company requirements?

A
Create a dedicated VPC for outbound internet traffic with a NAT gateway on it. Connect this VPC to the existing AWS Transit Gateway. Configure an AWS Network Firewall firewall for the rule-based filtering. Modify all the default routes in each account to point to the Network Firewall endpoint.
B
Create a dedicated VPC for outbound internet traffic with a NAT gateway on it. Connect this VPC to the existing AWS Transit Gateway. On this VPC, create an Auto Scaling group of Amazon EC2 instances running with an open-source internet proxy software for rule-based filtering across all AZ in the region. Configure the route tables on each VPC to point to this Auto Scaling group.
C
Provision an Auto Scaling group of Amazon EC2 instances with network-optimized instance type on each AWS account. Install an open-source internet proxy software for rule-based filtering. Configure the route tables on each VPC to point to the Auto Scaling group.
D
Use AWS Network Firewall service to create firewall rule groups and firewall policies for rule-based filtering. Attach the firewall policy to a new Network Firewall firewall on each account. Modify all the default routes in each account to point to their corresponding Network Firewall firewall.

Xem giải thích

Đáp án

**A — Tạo một VPC chuyên cho lưu lượng đi ra với NAT gateway, nối VPC đó vào Transit Gateway đã có; cấu hình một AWS Network Firewall để lọc theo luật; và sửa mọi tuyến mặc định ở từng tài khoản trỏ tới endpoint của Network Firewall.

Vì sao đúng

Đề nêu ba yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Lọc theo luật, quản lý TẬP TRUNG | một Network Firewall ở VPC kiểm tra | | Cho hơn 50 tài khoản | Transit Gateway đã có sẵn | | Đỉnh 25 Gbps mỗi AZ | Network Firewall hỗ trợ tới 100 Gbps |

⚠ Điểm mấu chốt: "quản lý tập trung" nghĩa là MỘT nơi cấu hình:

Network Firewall ở mỗi tài khoản
  (phương án D)
    → 50 firewall phải cấu hình
      và đồng bộ
        ↓
    Sửa một luật: phải sửa 50 chỗ
    → đây không phải "tập trung"

⚠ Và kiến trúc VPC kiểm tra là mẫu chuẩn của AWS:

Mọi VPC gắn vào Transit Gateway
        ↓
    Tuyến mặc định của chúng trỏ
      tới TGW
        ↓
    TGW gửi tới VPC kiểm tra
        ↓
    Network Firewall lọc
        ↓
    NAT gateway → Internet

Tạo firewall:

aws network-firewall create-firewall \
  --firewall-name tuong-lua-trung-tam \
  --firewall-policy-arn <arn-chinh-sach> \
  --vpc-id vpc-kiem-tra \
  --subnet-mappings SubnetId=subnet-fw-1a SubnetId=subnet-fw-1b

Luật lọc theo tên miền:

{"RulesSourceList": {
  "Targets": [".cap-nhat.nhacungcap.com",
              ".repo.amazonaws.com"],
  "TargetTypes": ["TLS_SNI", "HTTP_HOST"],
  "GeneratedRulesType": "ALLOWLIST"}}

⚠ Network Firewall lọc được theo TÊN MIỀN, khác hẳn NACL và security group: | Cơ chế | Lọc theo | |---|---| | Security group | IP, cổng | | NACL | IP, cổng, có deny | | Network Firewall | TÊN MIỀN, nội dung, luật Suricata |

URL của nhà cung cấp trỏ tới CDN
    → IP đổi liên tục
        ↓
    Lọc theo IP: danh sách không
      bao giờ đúng lâu
    → phải lọc ở tầng tên miền

⚠ Và bảng định tuyến phải đi qua đủ ba chặng:

Subnet TGW attachment:
    0.0.0.0/0 → endpoint Network Firewall
        ↓
Subnet firewall endpoint:
    0.0.0.0/0 → NAT gateway
        ↓
Subnet NAT:
    0.0.0.0/0 → Internet gateway

⚠ Đây là chỗ hay cấu hình sai nhất:

Thiếu một bảng định tuyến
    → gói tin đi thẳng ra Internet
      KHÔNG qua firewall
        ↓
    Không có lỗi nào, mọi thứ
      vẫn chạy
    → chỉ là việc kiểm soát không
      hề xảy ra

⚠ Và tự dựng proxy (phương án B, C) là nhiều việc hơn hẳn:

Đội EC2 chạy proxy mã nguồn mở
    → phải vá, phải giám sát,
      phải làm HA
        ↓
    Network Firewall: dịch vụ quản lý
    → AWS lo mọi thứ
        ↓
    Và 25 Gbps mỗi AZ đòi khá nhiều
      instance proxy

⚠ Và phương án C còn tệ hơn — proxy ở TỪNG tài khoản:

50 tài khoản × một đội proxy
    → 50 đội máy phải vận hành
        ↓
    Trái hẳn với "quản lý tập trung"

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nơi cấu hình luật cho toàn tổ chức | | | NAT gateway dùng chung, giảm chi phí | | | Dịch vụ quản lý, không tự vá gì | |

⚠ Và chi phí NAT gateway là lý do kinh tế mạnh:

Mỗi VPC một NAT gateway
    → 50 NAT chạy 24/7
        ↓
    Tập trung: vài NAT trong VPC
      kiểm tra
    → tiết kiệm rất lớn

⚠ Và Firewall Manager quản lý chính sách trên toàn tổ chức:

aws fms put-policy --policy '{
  "PolicyName": "tuong-lua-toan-to-chuc",
  "SecurityServicePolicyData": {
    "Type": "NETWORK_FIREWALL"},
  "ResourceType": "AWS::EC2::VPC",
  "ExcludeResourceTags": false,
  "RemediationEnabled": true}'

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

**D. Dùng Network Firewall tạo rule group và policy, nhưng gắn một firewall ở TỪNG tài khoản và sửa tuyến mặc định trỏ tới firewall tương ứng — đây là phương án gần nhất và dùng đúng dịch vụ, nhưng 50 firewall riêng lẻ không phải "quản lý tập trung"; và chi phí nhân lên 50 lần.
**B. Tạo VPC đi ra với NAT gateway, nối vào TGW, và dựng ASG EC2 chạy proxy mã nguồn mở cho việc lọc — phải tự vận hành đội proxy, tự làm HA, và 25 Gbps mỗi AZ đòi nhiều instance.
**C. Dựng ASG EC2 với proxy ở TỪNG tài khoản — vừa tự vận hành vừa phân tán, trái hẳn với yêu cầu tập trung.

Ghi nhớ

⚠ Bốn cơ chế lọc lưu lượng ra — bảng phải thuộc: | Cơ chế | Lọc theo | Vận hành | |---|---|---| | Security group | IP, cổng | AWS | | NACL | IP, cổng, có deny | AWS | | Network Firewall | tên miền, nội dung | AWS | | Proxy tự dựng | tên miền, đường dẫn | BẠN |

Từ khoá nhận diện:

"centrally managed rule-based filtering" → Network Firewall ở VPC kiểm tra "filter by domain name" → Network Firewall hoặc proxy "third-party firewall appliance" → Gateway Load Balancer "filter within a single VPC" → Network Firewall trong VPC đó

⚠ Network Firewall và GWLB — chọn theo nhà cung cấp: | Tiêu chí | Network Firewall | GWLB + thiết bị | |---|---|---| | Vận hành | AWS lo | bạn lo | | Luật | Suricata | của nhà cung cấp | | Dùng khi | không ràng buộc hãng | đã đầu tư vào một hãng |

Ba lưu ý về Network Firewall: | Lưu ý | Chi tiết | |---|---| | Endpoint đặt trong subnet riêng của nó | | | Tính phí theo giờ endpoint và GB xử lý | | | Hỗ trợ luật Suricata cho lọc nâng cao | |

⚠ Luật stateful theo Suricata:

pass tls $HOME_NET any -> $EXTERNAL_NET 443
  (tls.sni; content:"cap-nhat.nhacungcap.com";
   startswith; nocase; sid:1;)
drop tls $HOME_NET any -> $EXTERNAL_NET 443 (sid:2;)

Ba lưu ý về Transit Gateway: | Lưu ý | Chi tiết | |---|---| | Nhiều bảng định tuyến để phân đoạn | | | Chia sẻ qua RAM cho Organizations | | | Tính phí theo attachment và GB xử lý | |

⚠ Tắt liên kết và lan truyền mặc định:

aws ec2 create-transit-gateway \
  --options DefaultRouteTableAssociation=disable,\
DefaultRouteTablePropagation=disable

Bật mặc định: mọi VPC nói chuyện
  được với mọi VPC
        ↓
    Tắt: phải khai tường minh
    → phân đoạn mạng theo chủ đích

Ba lưu ý về kiến trúc VPC kiểm tra: | Lưu ý | Chi tiết | |---|---| | Subnet riêng cho TGW attachment | | | Subnet riêng cho firewall endpoint | | | Subnet riêng cho NAT gateway | |

⚠ Ba loại subnet là bắt buộc, không gộp được:

Firewall endpoint và NAT trong
  cùng subnet
        ↓
    Vòng lặp định tuyến
    → gói tin quay lại chính nó

Ba lưu ý về ghi log: | Loại log | Nội dung | |---|---| | Alert log | lưu lượng khớp luật drop hoặc alert | | Flow log | mọi luồng đi qua firewall | | TLS log | thông tin bắt tay TLS |

Ba lưu ý về giảm chi phí: | Lưu ý | Chi tiết | |---|---| | VPC endpoint cho S3 và DynamoDB miễn phí | | | Lưu lượng đó không qua firewall hay NAT | | | Thường là phần lớn nhất của lưu lượng ra | |

⚠ Đây là biện pháp giảm chi phí lớn nhất:

aws ec2 create-vpc-endpoint --vpc-id vpc-abc \
  --service-name com.amazonaws.ap-southeast-1.s3 \
  --route-table-ids rtb-rieng-1a

Gateway endpoint miễn phí
    → lưu lượng S3 không đi qua
      TGW, firewall hay NAT
    → giảm cả ba khoản phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gọi ra một URL bị cấm — phải bị chặn | | | Xem log firewall có ghi lưu lượng | | | Chạy Reachability Analyzer từ VPC ra Internet | |

Và một lời khuyên: hãy kiểm chứng rằng lưu lượng thật sự đi qua firewall chứ đừng tin vào sơ đồ. Một bảng định tuyến thiếu sẽ khiến gói tin đi thẳng ra Internet, mọi thứ vẫn chạy bình thường, và bạn chỉ phát hiện khi đọc log firewall và thấy nó trống rỗng một cách khó hiểu.

Câu 264 Chọn nhiều đáp án Domain - Design for New Solutions

A company has an on-premises data center that is hosting its gaming service. Its primary function is player-matching and is accessible from players around the world. The gaming service prioritizes network speed for the users so all traffic to the servers uses User Datagram Protocol (UDP). As more players join, the company is having difficulty scaling its infrastructure so it plans to migrate the service to the AWS cloud. The Solutions Architect has been tasked with the migration and AWS Shield Advanced has been enabled already to protect all public-facing resources.

Which of the following actions should the Solutions Architect implement to achieve the company requirements? (Select TWO.)

A
Create an Amazon CloudFront distribution and set the Load Balancer as the origin. Use only secure protocols on the distribution origin settings.
B
Set up network ACL rules on the VPC to deny all non-UDP traffic. Ensure that the NACL is associated with the load balancer subnets.
C
Place the Auto Scaling of Amazon EC2 instances behind an Internet-facing Application Load Balancer (ALB). For the domain name, create an Amazon Route 53 entry that is Aliased to the FQDN of the ALB.
D
Place the Auto Scaling of Amazon EC2 instances behind a Network Load Balancer (NLB). For the domain name, create an Amazon Route 53 entry that points to the Elastic IP address of the NLB.
E
Create an AWS WAF rule that will explicitly block all non-UDP traffic. Ensure that the AWS WAF rule is associated with the load balancer of the EC2 instances.

Xem giải thích

Đáp án

**B và D — Lập quy tắc network ACL từ chối mọi lưu lượng không phải UDP và gắn NACL đó vào subnet của load balancer; đồng thời đặt Auto Scaling group EC2 sau một Network Load Balancer (NLB), và tạo bản ghi Route 53 trỏ tới Elastic IP của NLB.

Vì sao đúng

Đề cho một dữ kiện quyết định mọi thứ:

"Toàn bộ lưu lượng tới máy chủ
  dùng UDP"
        ↓
    ALB làm việc ở TẦNG 7 (HTTP/HTTPS)
    → KHÔNG xử lý được UDP
        ↓
    Chỉ NLB (tầng 4) hỗ trợ UDP

Đây là lý do phương án C sai — nó dùng ALB.

⚠ Và CloudFront cũng không xử lý UDP:

CloudFront phân phối HTTP/HTTPS
    → và HTTP/3 (QUIC) chỉ giữa
      client và điểm biên
        ↓
    Không proxy được UDP tuỳ ý
      của game

Đây là lý do phương án A sai.

⚠ Và WAF cũng chỉ làm việc với HTTP:

AWS WAF gắn được vào CloudFront,
  ALB, API Gateway, AppSync
        ↓
    KHÔNG gắn được vào NLB
    → và không hiểu gói UDP

Đây là lý do phương án E sai.

Tạo NLB với Elastic IP:

aws elbv2 create-load-balancer \
  --name nlb-game --type network --scheme internet-facing \
  --subnet-mappings \
    SubnetId=subnet-1a,AllocationId=eipalloc-abc \
    SubnetId=subnet-1b,AllocationId=eipalloc-def

⚠ Elastic IP trên NLB là điều ALB không làm được: | Tiêu chí | ALB | NLB | |---|---|---| | IP tĩnh | KHÔNG | CÓ, gán Elastic IP | | Giao thức | HTTP/HTTPS | TCP, UDP, TLS | | Tầng | 7 | 4 |

Game client thường cài cứng
  địa chỉ máy chủ
        ↓
    IP tĩnh giúp không phải phụ
      thuộc DNS

Listener UDP:

aws elbv2 create-listener \
  --load-balancer-arn <arn-nlb> \
  --protocol UDP --port 7777 \
  --default-actions Type=forward,TargetGroupArn=<arn-tg>

⚠ Và NACL chặn mọi thứ không phải UDP là lớp giảm bề mặt tấn công:

aws ec2 create-network-acl-entry --network-acl-id acl-abc \
  --rule-number 100 --protocol 17 \
  --port-range From=7777,To=7777 \
  --cidr-block 0.0.0.0/0 --rule-action allow --ingress

aws ec2 create-network-acl-entry --network-acl-id acl-abc \
  --rule-number 32000 --protocol -1 \
  --cidr-block 0.0.0.0/0 --rule-action deny --ingress

⚠ Giao thức 17 là UDP — số hiệu phải nhớ: | Số | Giao thức | |---|---| | 6 | TCP | | 17 | UDP | | 1 | ICMP | | -1 | tất cả |

⚠ Và NACL là stateless — phải mở cả chiều ra:

aws ec2 create-network-acl-entry --network-acl-id acl-abc \
  --rule-number 100 --protocol 17 \
  --port-range From=1024,To=65535 \
  --cidr-block 0.0.0.0/0 --rule-action allow --egress

Cho phép UDP vào cổng 7777
    → phản hồi đi ra cổng tạm
        ↓
    Không mở dải cổng tạm chiều RA
    → game không hoạt động

⚠ Và security group KHÔNG chặn được — đây là lý do phải dùng NACL:

Security group chỉ có ALLOW
    → không viết được "deny mọi
      thứ không phải UDP"
        ↓
    NACL có deny
    → và áp ở tầng subnet, chặn
      trước khi tới instance

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | NLB xử lý được UDP với độ trễ rất thấp | | | Elastic IP cho địa chỉ cố định | | | NACL giảm bề mặt tấn công xuống chỉ UDP | |

⚠ Và Shield Advanced bảo vệ được NLB và Elastic IP:

Shield Advanced hỗ trợ:
    CloudFront, Route 53, ALB, NLB,
    Global Accelerator, Elastic IP
        ↓
    Đề nói đã bật Shield Advanced
    → NLB với EIP nằm trong phạm vi
      bảo vệ

⚠ Và Global Accelerator là lựa chọn đáng cân nhắc cho game toàn cầu:

Người chơi khắp thế giới
    → Global Accelerator: IP tĩnh
      anycast, hỗ trợ UDP
        ↓
    Lưu lượng vào mạng AWS ở điểm
      gần người chơi nhất
    → giảm độ trễ đáng kể

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

**C. Đặt ASG sau Application Load Balancer internet-facing và tạo bản ghi Route 53 Alias tới FQDN của ALB — đây là phương án gần nhất và Alias record là cách đúng để trỏ tới ELB, nhưng ALB làm việc ở tầng 7 và không hỗ trợ UDP.
**E. Tạo luật AWS WAF chặn mọi lưu lượng không phải UDP và gắn vào load balancer — WAF chỉ làm việc với HTTP và không gắn được vào NLB.
**A. Tạo CloudFront với load balancer làm origin và chỉ dùng giao thức bảo mật — CloudFront không proxy được lưu lượng UDP tuỳ ý.

Ghi nhớ

⚠ Bốn loại load balancer và giao thức — bảng phải thuộc: | Loại | Tầng | Giao thức | IP tĩnh | |---|---|---|---| | ALB | 7 | HTTP, HTTPS, gRPC | không | | NLB | 4 | TCP, UDP, TLS | CÓ | | GWLB | 3 | mọi gói IP | không áp dụng | | CLB | 4/7 | TCP, HTTP | không |

Từ khoá nhận diện:

"UDP traffic" → NLB "static IP address" → NLB với Elastic IP, hoặc Global Accelerator "HTTP routing by path" → ALB "deny non-UDP traffic" → NACL (SG không có deny)

⚠ Global Accelerator và NLB — bảng phải thuộc: | Tiêu chí | NLB | Global Accelerator | |---|---|---| | Phạm vi | một Region | toàn cầu | | IP tĩnh | theo AZ | anycast | | Chuyển đổi Region | không | vài giây | | Giao thức | TCP, UDP, TLS | TCP, UDP |

Ba lưu ý về NLB: | Lưu ý | Chi tiết | |---|---| | Cross-zone MẶC ĐỊNH TẮT | | | Bật cross-zone thì tính phí liên AZ | | | Giữ nguyên IP nguồn với target kiểu instance | |

⚠ Cross-zone tắt gây phân bố lệch:

AZ-a có 2 target, AZ-b có 8 target
    → node NLB ở AZ-a chỉ gửi
      tới target ở AZ-a
        ↓
    Mỗi target ở AZ-a nhận tải
      gấp 4 lần

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Stateless — mở cả hai chiều | | | Xử lý theo số thứ tự, dừng ở cái khớp đầu | | | Hạn ngạch 20 quy tắc (tăng lên 40) | |

Ba lưu ý về game dùng UDP: | Lưu ý | Chi tiết | |---|---| | UDP không có kết nối, dễ bị giả mạo nguồn | | | UDP reflection là kiểu DDoS phổ biến | | | Shield Advanced bảo vệ được NLB và EIP | |

⚠ Đây là lý do NACL chặn non-UDP có giá trị:

Chỉ mở đúng cổng UDP của game
    → mọi lưu lượng khác bị chặn
      ở tầng subnet
        ↓
    Giảm bề mặt tấn công
    → và giảm tải cho instance

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | Bảo vệ NLB, EIP, CloudFront, Route 53 | | | Có thông báo và đội ứng cứu (SRT) | | | Cấp vai trò SRT TRƯỚC khi cần | |

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Alias record cho NLB | | | Bản ghi A thường cho Elastic IP | | | Latency routing nếu có nhiều Region | |

Ba lưu ý về AWS GameLift: | Lưu ý | Chi tiết | |---|---| | Dịch vụ chuyên cho máy chủ game | | | Có FlexMatch cho ghép cặp người chơi | | | Tự quản đội máy chủ game theo phiên | |

⚠ GameLift là lựa chọn đáng cân nhắc cho bài toán này:

Đề nói chức năng chính là
  "ghép cặp người chơi"
        ↓
    GameLift FlexMatch làm sẵn
      việc đó
    → và tự co giãn đội máy chủ
      game theo số phiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi gói UDP tới NLB, xem có tới target | | | Thử kết nối TCP — NACL phải chặn | | | Đo độ trễ từ nhiều khu vực | |

Và một lời khuyên: hãy nhớ mở dải cổng tạm chiều ra khi viết quy tắc NACL. NACL là stateless, nên một cấu hình chỉ mở chiều vào sẽ khiến gói phản hồi bị chặn — và triệu chứng là kết nối treo mà không có lỗi nào nói cho bạn biết tại sao.

Câu 265 Chọn nhiều đáp án Domain - Design Solutions for Organizational Complexity

A company's cloud governance team is tightening its AWS policies for an upcoming audit. During an initial review, the team found IAM policies attached to Lambda function execution roles, granting full access to S3 buckets and DynamoDB tables. As a best practice, the team recommends implementing the principle of least privilege access for compliance with the security audit.

What steps should be taken to determine the minimum access needed by each function with the LEAST amount of effort? (Select TWO.)

A
Set up AWS Audit Manager to continuously audit AWS usage. Review the findings and create IAM access policies to provide more restrictive permissions for the Lambda functions.
B
Enable CloudTrail logging in the AWS account and export the logs to S3. Use Amazon GuardDuty to analyze the data and monitor unauthorized access to Amazon S3 and Amazon DynamoDB. Restrict access in IAM.
C
Build an inventory of AWS API Calls by applying the CodeGuru Profiler function decorator to Lambda’s handler functions. Export this data to a CSV file. Create a generic access policy for each Lambda function and apply the update to the functions using a Python script.
D
Use IAM Access Analyzer to review AWS CloudTrail logs and generate a policy template with permissions required by the Lambda functions.
E
Create a trail in AWS CloudTrail and turn on CloudTrail logging to capture Amazon S3 and Amazon DynamoDB events.

Xem giải thích

Đáp án

**D và E — Bật AWS Config trong mọi tài khoản và mọi Region, dùng aggregator gom kết quả về một tài khoản trung tâm; và tạo quy tắc AWS Config với hành động khắc phục tự động (remediation) để đưa tài nguyên vi phạm về đúng chuẩn.

Vì sao đúng

Đề hỏi cách kiểm tra sự tuân thủ liên tục trên nhiều tài khoản, và AWS Config sinh ra đúng cho việc này: | Việc | Dịch vụ | |---|---| | Ghi lại cấu hình tài nguyên theo thời gian | AWS Config | | Đánh giá cấu hình theo luật | Config rules | | Gom kết quả nhiều tài khoản | Config aggregator | | Tự sửa vi phạm | remediation với SSM Automation |

⚠ Điểm mấu chốt: Config đánh giá LIÊN TỤC, không phải theo lịch:

Tài nguyên thay đổi
    → Config ghi lại configuration item
        ↓
    Kích hoạt đánh giá lại các luật
      liên quan
        ↓
    Vi phạm → NON_COMPLIANT ngay
    → và remediation chạy

Bật aggregator:

aws configservice put-configuration-aggregator \
  --configuration-aggregator-name gom-toan-to-chuc \
  --organization-aggregation-source \
    RoleArn=arn:aws:iam::111122223333:role/ConfigAggregator,\
AllAwsRegions=true

⚠ Aggregator theo Organizations tự bao gồm tài khoản mới:

Aggregator kiểu ACCOUNT_AGGREGATION:
  phải liệt kê từng tài khoản
        ↓
    Kiểu ORGANIZATION: tự lấy toàn
      bộ tổ chức
    → tài khoản mới tự vào

Quy tắc có khắc phục tự động:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "s3-bucket-cam-truy-cap-cong-khai",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-ConfigureS3BucketPublicAccessBlock",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3,
    "RetryAttemptSeconds": 60}]'

⚠ Automatic: true là chỗ biến việc phát hiện thành việc sửa:

Automatic false: chỉ báo vi phạm
    → người phải bấm nút
        ↓
    Automatic true: SSM Automation
      chạy ngay
    → tài nguyên tự về chuẩn

Triển khai luật cho toàn tổ chức:

aws configservice put-organization-config-rule \
  --organization-config-rule-name cam-s3-cong-khai \
  --organization-managed-rule-metadata \
    RuleIdentifier=S3_BUCKET_PUBLIC_READ_PROHIBITED

⚠ Và conformance pack đóng gói nhiều luật thành một gói:

aws configservice put-organization-conformance-pack \
  --organization-conformance-pack-name pci-dss \
  --template-s3-uri s3://mau/Operational-Best-Practices-for-PCI-DSS.yaml

AWS có sẵn conformance pack cho
  PCI-DSS, HIPAA, NIST, CIS
        ↓
    Triển khai một lệnh cho cả
      tổ chức

⚠ Và Trusted Advisor (phương án A, C) không phải công cụ tuân thủ:

Trusted Advisor kiểm 5 nhóm:
  chi phí, hiệu năng, bảo mật,
  chịu lỗi, hạn ngạch
        ↓
    Danh sách kiểm CỐ ĐỊNH, không
      viết luật riêng được
        ↓
    Đầy đủ cần Business/Enterprise
      Support

⚠ Và Trusted Advisor không tự sửa gì:

Chỉ báo cáo
    → không có cơ chế remediation
        ↓
    Config có SSM Automation
    → sửa được

⚠ Và Systems Manager Inventory (phương án B) chỉ thấy trong instance:

SSM Inventory: gói phần mềm, bản vá,
  cấu hình mạng CỦA INSTANCE
        ↓
    Không thấy cấu hình bucket S3,
      security group, IAM policy
    → không phải công cụ tuân thủ
      hạ tầng

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Đánh giá liên tục, không theo lịch | | | Một bảng điều khiển cho toàn tổ chức | | | Tự sửa vi phạm, không cần người | |

⚠ Và lịch sử cấu hình là thứ chỉ Config có:

"Security group này mở cổng 22
  từ khi nào, ai sửa?"
        ↓
    Config timeline trả lời được
    → và so được hai phiên bản
      cấu hình

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

**A. Dùng AWS Trusted Advisor ở mọi tài khoản và tạo báo cáo định kỳ — đây là phương án gần nhất và Trusted Advisor có kiểm tra bảo mật, nhưng danh sách kiểm cố định, không định nghĩa được luật riêng, và không tự khắc phục.
**C. Dùng Trusted Advisor kèm việc bật Config chỉ ở tài khoản quản lý — Config ở một tài khoản không nhìn thấy tài nguyên của tài khoản khác.
**B. Dùng Systems Manager Inventory để thu thập trạng thái tuân thủ — Inventory chỉ thấy phần mềm và bản vá bên trong instance, không thấy cấu hình dịch vụ AWS.

Ghi nhớ

⚠ Bốn dịch vụ quản trị nhiều tài khoản — bảng phải thuộc: | Dịch vụ | Vai trò | |---|---| | AWS Config | ghi lại và đánh giá cấu hình | | AWS Organizations SCP | CHẶN hành động ở tầng quyền | | Security Hub | gom phát hiện bảo mật, chấm điểm chuẩn | | Control Tower | dựng sẵn landing zone có guardrail |

⚠ Config và SCP khác nhau ở thời điểm:

SCP: chặn TRƯỚC khi hành động
  xảy ra (phòng ngừa)
        ↓
    Config: phát hiện SAU khi
      cấu hình đã sai (phát hiện)
        ↓
    Dùng cả hai

Từ khoá nhận diện:

"continuously assess compliance" → AWS Config rules "across multiple accounts" → Config aggregator hoặc organization rules "automatically remediate" → Config remediation + SSM Automation "prevent the action entirely" → SCP "compliance standard like PCI-DSS" → conformance pack hoặc Security Hub

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Phải bật ở TỪNG Region, từng tài khoản | | | Tính phí theo configuration item ghi lại | | | Delivery channel ghi snapshot vào S3 | |

⚠ Chi phí Config dễ bị bất ngờ:

Ghi lại MỌI loại tài nguyên
    → tài nguyên thay đổi liên tục
      (như ENI của Lambda)
      sinh rất nhiều CI
        ↓
    Giới hạn danh sách loại tài
      nguyên cần ghi

Ba loại quy tắc Config: | Loại | Đặc điểm | |---|---| | Managed | AWS viết sẵn, hàng trăm luật | | Custom Lambda | tự viết bằng Lambda | | Custom Policy (Guard) | viết bằng CloudFormation Guard, không cần Lambda |

⚠ Custom Policy rule là lựa chọn mới, đáng biết:

rule cam_s3_cong_khai {
  configuration.publicAccessBlockConfiguration
    .blockPublicAcls == true
}

Không phải viết Lambda
    → không phải quản lý runtime
    → luật viết bằng DSL khai báo

Ba lưu ý về remediation: | Lưu ý | Chi tiết | |---|---| | Dùng tài liệu SSM Automation | | | Cần IAM role có quyền sửa tài nguyên | | | Giới hạn số lần thử để tránh vòng lặp | |

⚠ Vòng lặp remediation là bẫy thật:

Luật sửa tài nguyên
    → thay đổi kích hoạt đánh giá lại
        ↓
    Vẫn không tuân thủ vì lý do khác
    → sửa lại, lặp vô hạn
        ↓
    `MaximumAutomaticAttempts` chặn
      chuyện này

Ba lưu ý về aggregator: | Lưu ý | Chi tiết | |---|---| | Chỉ ĐỌC, không cấu hình từ đó được | | | Kiểu Organizations tự bao gồm tài khoản mới | | | Có API truy vấn nâng cao (SQL) | |

⚠ Truy vấn nâng cao rất mạnh:

SELECT accountId, resourceId, configuration.instanceType
WHERE resourceType = 'AWS::EC2::Instance'
  AND configuration.instanceType LIKE 'm4%'

Tìm mọi instance thế hệ cũ trên
  toàn tổ chức bằng một câu

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Dựa trên Config để chạy chuẩn | | | Gom phát hiện của GuardDuty, Inspector, Macie | | | Chấm điểm tuân thủ theo chuẩn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cố ý tạo tài nguyên vi phạm — xem có bị bắt | | | Xem remediation có chạy và sửa đúng | | | Kiểm aggregator có thấy đủ mọi tài khoản | |

Và một lời khuyên: hãy giới hạn danh sách loại tài nguyên mà Config ghi lại. Bật ghi tất cả trên hàng chục tài khoản sẽ tạo ra một hoá đơn lớn hơn nhiều người dự tính — và phần lớn chi phí đến từ những loại tài nguyên thay đổi liên tục mà chẳng ai kiểm tra tuân thủ trên chúng.

Câu 266 Domain - Continuous Improvement for Existing Solutions

A company manually runs its custom scripts when deploying a new version of its application that is hosted on a fleet of Amazon EC2 instances. This method is prone to human errors, such as accidentally running the wrong script or deploying the wrong artifact. The company wants to automate its deployment procedure.

If errors are encountered after the deployment, the company wants to be able to roll back to the older application version as fast as possible.

Which of the following options should the Solutions Architect implement to meet the requirements?

A
Utilize AWS CodeBuild and add a job with Chef recipes for the new application version. Use a “canary” deployment strategy to the new version on a new instance. Delete the canary instance if errors are found on the new version.
B
Create two identical environments of the application on AWS Elastic Beanstalk. Use a blue/green deployment strategy by swapping the environment’s URL. Deploy the custom scripts using Elastic Beanstalk platform hooks.
C
Create a new pipeline on AWS CodePipeline and add a stage that will deploy the application on the EC2 instances. Choose a “rolling update with an additional batch” deployment strategy, to allow a quick rollback to the older version in case of errors.
D
Create an AWS System Manager automation runbook to manage the deployment process. Set up the runbook to first deploy the new application version to a staging environment. Include automated tests and, upon successful completion, use the runbook to deploy the application to the production environment

Xem giải thích

Đáp án

**B — Dùng AWS Database Migration Service (DMS) với chế độ full load kèm change data capture (CDC), để đồng bộ liên tục cho tới thời điểm chuyển đổi.

Vì sao đúng

Đề nêu ràng buộc quyết định:

Cơ sở dữ liệu phải TIẾP TỤC PHỤC VỤ
  trong suốt quá trình di trú
        ↓
    Chỉ được ngừng rất ngắn khi
      chuyển đổi
        ↓
    Sao chép một lần không đủ
    → cần đồng bộ thay đổi liên tục

⚠ DMS có ba chế độ, và đề hỏi đúng chế độ thứ ba: | Chế độ | Làm gì | Ngừng dịch vụ | |---|---|---| | Full load | sao chép một lần | dài — dữ liệu đổi trong lúc chép bị mất | | CDC only | chỉ theo dõi thay đổi | cần đã có bản sao gốc | | Full load + CDC | chép rồi theo dõi tiếp | RẤT NGẮN |

Luồng full load + CDC:

DMS chép toàn bộ bảng
    → trong lúc đó, thay đổi mới
      được đệm lại
        ↓
    Chép xong → phát lại các thay đổi
      đã đệm
        ↓
    Bắt kịp → tiếp tục đồng bộ
      thời gian thực
        ↓
    Độ trễ gần 0 → chuyển ứng dụng
      sang đích

Tạo tác vụ:

aws dms create-replication-task \
  --replication-task-identifier di-tru-oracle \
  --source-endpoint-arn <arn-nguon> \
  --target-endpoint-arn <arn-dich> \
  --replication-instance-arn <arn-instance> \
  --migration-type full-load-and-cdc \
  --table-mappings file://anh-xa-bang.json

⚠ Nguồn phải bật ghi log thay đổi, nếu không CDC không chạy: | CSDL nguồn | Yêu cầu | |---|---| | Oracle | supplemental logging, ARCHIVELOG | | PostgreSQL | wal_level = logical | | MySQL | binlog định dạng ROW | | SQL Server | bật CDC hoặc MS-REPLICATION |

-- Oracle
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER TABLE hr.nhan_vien
  ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

⚠ Đây là bước hay bị quên nhất:

Quên bật supplemental logging
    → full load chạy bình thường
        ↓
    CDC không bắt được thay đổi
    → hoặc chỉ bắt được khoá chính
      mà không có giá trị cột

Theo dõi độ trễ:

aws cloudwatch get-metric-statistics \
  --namespace AWS/DMS --metric-name CDCLatencyTarget \
  --dimensions Name=ReplicationTaskIdentifier,Value=di-tru-oracle \
  --statistics Average --period 60 \
  --start-time 2026-08-05T00:00:00Z --end-time 2026-08-05T01:00:00Z

⚠ CDCLatencyTarget là số quyết định thời điểm chuyển đổi:

Độ trễ còn vài giây
    → dừng ghi vào nguồn
        ↓
    Chờ độ trễ về 0
        ↓
    Chuyển ứng dụng sang đích
    → tổng thời gian ngừng:
      vài phút

⚠ Và AWS SCT là công cụ bổ trợ khi đổi engine:

DMS chuyển DỮ LIỆU
    → không chuyển stored procedure,
      trigger, function
        ↓
    SCT chuyển SCHEMA và mã
    → cùng nhau mới đủ

⚠ Và đây là điểm phân biệt phương án C:

C nói "dùng SCT để di trú
  cơ sở dữ liệu"
        ↓
    SCT không di trú DỮ LIỆU
    → nó chuyển đổi schema và mã

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nguồn tiếp tục phục vụ trong lúc di trú | | | Thời gian ngừng chỉ vài phút | | | Quay lui được nếu đích có vấn đề | |

⚠ Và quay lui là lý do nên giữ CDC ngược:

Sau khi chuyển sang đích
    → dựng tác vụ CDC NGƯỢC
      (đích → nguồn)
        ↓
    Đích có sự cố
    → chuyển lại nguồn mà không
      mất dữ liệu

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

**C. Dùng AWS Schema Conversion Tool (SCT) để di trú cơ sở dữ liệu — đây là phương án gần nhất và SCT thật sự là công cụ trong bộ di trú CSDL, nhưng nó chuyển đổi schema và mã, không sao chép dữ liệu và không đồng bộ liên tục.
**A. Dùng DMS ở chế độ full load — dữ liệu thay đổi trong lúc sao chép sẽ bị mất; phải khoá CSDL suốt quá trình.
**D. Dùng AWS DataSync — DataSync đồng bộ TỆP giữa NFS/SMB/S3/EFS/FSx, không hiểu giao dịch của cơ sở dữ liệu.

Ghi nhớ

⚠ Bốn công cụ di trú và phạm vi — bảng phải thuộc: | Công cụ | Di trú gì | |---|---| | DMS | dữ liệu CSDL, có CDC | | SCT | schema và mã, đổi engine | | DataSync | tệp: NFS, SMB, S3, EFS, FSx | | MGN | toàn bộ máy chủ (block-level) |

Từ khoá nhận diện:

"minimal downtime database migration" → DMS full load + CDC "convert Oracle to PostgreSQL schema" → SCT "migrate file shares" → DataSync "lift and shift servers" → MGN "one-time copy, downtime acceptable" → DMS full load

⚠ DMS đồng nhất và không đồng nhất: | Kiểu | Cần SCT | |---|---| | Oracle → Oracle | KHÔNG | | Oracle → PostgreSQL | CÓ | | SQL Server → Aurora MySQL | CÓ |

Ba lưu ý về DMS: | Lưu ý | Chi tiết | |---|---| | Replication instance phải đủ lớn | | | Đặt trong VPC nhìn được cả nguồn và đích | | | DMS Serverless tự co giãn | |

⚠ Kích thước replication instance ảnh hưởng lớn:

Instance nhỏ
    → full load chậm
    → CDC không bắt kịp thay đổi
        ↓
    Độ trễ tăng dần, không bao giờ
      về 0
    → không chuyển đổi được

Ba lưu ý về CDC: | Lưu ý | Chi tiết | |---|---| | Nguồn phải bật ghi log thay đổi | | | Bảng không có khoá chính gây vấn đề | | | DDL trong lúc chạy có thể làm hỏng tác vụ | |

⚠ Bảng không có khoá chính là bẫy phổ biến:

CDC cần nhận diện dòng để cập nhật
    → không có khoá chính thì
      không biết cập nhật dòng nào
        ↓
    Thêm khoá chính trước khi di trú
    → hoặc dùng full LOB mode
      và chấp nhận chậm

Ba lưu ý về kiểm chứng dữ liệu: | Lưu ý | Chi tiết | |---|---| | DMS có tính năng data validation | | | So từng dòng giữa nguồn và đích | | | Bật bằng EnableValidation trong cài đặt tác vụ | |

Ba lưu ý về chuyển đổi: | Bước | Chi tiết | |---|---| | Dừng ghi vào nguồn | | | Chờ CDCLatencyTarget về 0 | | | Đổi chuỗi kết nối, khởi động lại ứng dụng | |

⚠ Dùng DNS cho chuỗi kết nối giúp chuyển đổi nhanh:

Ứng dụng trỏ tới csdl.noi-bo.vn
    → CNAME trỏ tới nguồn
        ↓
    Chuyển đổi: đổi CNAME sang đích
    → TTL ngắn (60s) đặt sẵn từ trước

Ba lưu ý về theo dõi: | Chỉ số | Ý nghĩa | |---|---| | CDCLatencySource | độ trễ đọc từ nguồn | | CDCLatencyTarget | độ trễ ghi vào đích | | FullLoadThroughputRowsTarget | tốc độ nạp |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đếm số dòng mỗi bảng ở hai bên | | | Bật DMS data validation | | | Chạy thử ứng dụng trên đích trước khi chuyển | |

Và một lời khuyên: hãy bật supplemental logging trên nguồn trước khi tạo tác vụ. Full load sẽ chạy trơn tru dù thiếu nó, nên bạn chỉ phát hiện vấn đề khi CDC đã chạy vài giờ và độ trễ vẫn không giảm — lúc đó phải làm lại từ đầu.

Câu 267 Domain - Design for New Solutions

A top Internet of Things (IoT) company has developed a wrist-worn activity tracker for soldiers deployed in the field. The device acts as a sensor to monitor the health and vital statistics of the wearer. It is expected that there would be thousands of devices that will send data to the server every minute and after 5 years, the number will increase to tens of thousands. One of the requirements is that the application should be able to accept the incoming data, run it through ETL to store in a data warehouse, and archive the old data. The officers in the military headquarters should have a real-time dashboard to view the sensor data.

Which of the following options is the most suitable architecture to implement in this scenario?

A
Store the raw data directly in an Amazon S3 bucket with a lifecycle policy to store in Glacier after a month. Register the S3 bucket as a source on AWS Lake Formation. Launch an EMR cluster access the data lake, runs it through ETL, and then output that data to Amazon Redshift.
B
Send the raw data directly to Amazon Data Firehose for processing and output the data to an S3 bucket. For archiving, create a lifecycle policy from S3 to Glacier. Use Amazon EMR to process the data stored in S3 and load the processed data into Amazon Redshift.
C Store the data directly to DynamoDB. Launch a data pipeline that starts an EMR cluster using data from DynamoDB and sends the data to S3 and Redshift.
D
Leverage Amazon Athena to accept the incoming data and store them using DynamoDB. Setup a cron job that takes data from the DynamoDB table and sends it to an Amazon EMR cluster for ETL, then outputs the result to Amazon Redshift.

Xem giải thích

Đáp án

**B — Thu thập dữ liệu bằng Amazon Kinesis Data Streams, đẩy sang Kinesis Data Firehose để ghi vào Amazon Redshift, và trực quan hoá bằng Amazon QuickSight.

Vì sao đúng

Đề nêu ba yêu cầu và phương án này khớp từng cái: | Yêu cầu | Thành phần | |---|---| | Nhận luồng dữ liệu liên tục | Kinesis Data Streams | | Nạp vào kho phân tích, ít vận hành | Firehose → Redshift | | Bảng điều khiển trực quan | QuickSight |

⚠ Điểm mấu chốt: Firehose là dịch vụ HOÀN TOÀN QUẢN LÝ:

Firehose tự đệm, tự nén, tự thử lại,
  tự nạp vào đích
        ↓
    Không có shard phải quản
    → không có consumer phải viết
        ↓
    Đây là lựa chọn ít vận hành nhất
      để nạp vào Redshift

Tạo luồng phân phối:

aws firehose create-delivery-stream \
  --delivery-stream-name nap-redshift \
  --delivery-stream-type KinesisStreamAsSource \
  --kinesis-stream-source-configuration \
    KinesisStreamARN=<arn-stream>,RoleARN=<arn-role> \
  --redshift-destination-configuration file://cau-hinh-redshift.json

⚠ Firehose nạp vào Redshift qua S3, không ghi thẳng:

Firehose ghi tệp vào S3 trung gian
        ↓
    Rồi phát lệnh `COPY` vào Redshift
        ↓
    Đây là cách nạp ĐÚNG cho Redshift
    → `INSERT` từng dòng vào Redshift
      cực chậm

⚠ Lý do: Redshift là CSDL cột, tối ưu cho ghi theo lô: | Cách ghi | Hiệu năng | |---|---| | INSERT từng dòng | rất chậm, tạo nhiều khối nhỏ | | COPY từ S3 | song song trên mọi slice, rất nhanh |

⚠ Và đây là lý do phương án A, C, D đều thua:

A: Kinesis → Lambda → Redshift
    → Lambda tự viết `INSERT`
    → chậm và phải tự xử lý lỗi
        ↓
C: dùng EMR để xử lý
    → thêm một cụm phải vận hành
        ↓
D: ghi vào DynamoDB rồi phân tích
    → DynamoDB không phải công cụ
      phân tích

Bảng đích trong Redshift:

CREATE TABLE su_kien_thiet_bi (
    ma_thiet_bi   VARCHAR(64) DISTKEY,
    thoi_diem     TIMESTAMP   SORTKEY,
    nhiet_do      DECIMAL(6,2),
    trang_thai    VARCHAR(32)
);

⚠ SORTKEY theo thời gian là bắt buộc cho dữ liệu chuỗi thời gian:

Truy vấn thường lọc theo khoảng
  thời gian
        ↓
    SORTKEY thời gian → Redshift bỏ
      qua toàn bộ khối ngoài khoảng
    → quét ít dữ liệu hơn nhiều lần

⚠ Và Firehose có phép đệm, đây là điểm phải hiểu:

"BufferingHints": {"SizeInMBs": 128, "IntervalInSeconds": 300}

Firehose gom dữ liệu tới khi
  đủ 128 MB HOẶC đủ 300 giây
        ↓
    Rồi mới nạp
    → đây là ĐỘ TRỄ cố hữu

⚠ Và đây là mâu thuẫn với chữ "thời gian thực" trong đề: | Cấu hình | Độ trễ tối thiểu | |---|---| | Firehose → Redshift | 60 giây | | Firehose → S3 | 0 giây (khả dụng zero buffering) | | Kinesis Data Streams trực tiếp | dưới 1 giây |

Bảng điều khiển "gần thời gian thực"
  chấp nhận được 60 giây
        ↓
    Cần dưới 1 giây
    → phải đọc thẳng từ Data Streams
    → và Firehose không phù hợp

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Firehose không có gì để vận hành | | | Redshift phân tích được khối lượng lớn | | | QuickSight tích hợp sẵn với Redshift | |

⚠ Và QuickSight SPICE giúp bảng điều khiển nhanh:

Truy vấn trực tiếp Redshift mỗi lần
  mở bảng
    → tải lên cụm, chậm khi nhiều
      người xem
        ↓
    SPICE: nạp dữ liệu vào bộ nhớ
      của QuickSight
    → làm mới theo lịch
    → bảng phản hồi tức thì

⚠ Và Redshift Streaming Ingestion là cách hiện đại hơn Firehose:

CREATE EXTERNAL SCHEMA kinesis_schema
FROM KINESIS IAM_ROLE '<arn-role>';

CREATE MATERIALIZED VIEW su_kien_moi AUTO REFRESH YES AS
SELECT approximate_arrival_timestamp,
       json_extract_path_text(from_varbyte(kinesis_data,'utf-8'),
                              'nhiet_do') AS nhiet_do
FROM kinesis_schema."luong-thiet-bi";

Redshift đọc THẲNG từ Kinesis
    → không qua S3, không qua Firehose
        ↓
    Độ trễ vài giây thay vì 60+
    → đây là cách AWS khuyến nghị
      hiện nay

Ghi nhớ về chất lượng câu hỏi

⚠ Đề nói "thời gian thực" nhưng đáp án có độ trễ tối thiểu 60 giây.

Firehose luôn đệm trước khi nạp; giá trị IntervalInSeconds nhỏ nhất cho đích Redshift là 60. Nếu "thời gian thực" hiểu theo nghĩa chặt (dưới một giây), không phương án nào trong đề đáp ứng được.

Câu này viết trước khi có Redshift Streaming Ingestion (ra mắt 2023). Với kiến thức hiện tại, kiến trúc đúng là:

Kinesis Data Streams
        ↓
    Redshift Streaming Ingestion
      (materialized view tự làm mới)
        ↓
    QuickSight

Bỏ được hẳn Firehose và bước trung gian S3, độ trễ xuống vài giây.

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

**A. Kinesis Data Streams → Lambda → Redshift → QuickSight — đây là phương án gần nhất và Lambda thật sự đọc được từ Kinesis, nhưng Lambda phải tự viết INSERT vào Redshift (rất chậm với CSDL cột), tự xử lý thử lại và lỗi.
**C. Dùng EMR để xử lý luồng rồi ghi vào Redshift — thêm một cụm phải vận hành, trái với yêu cầu ít vận hành.
**D. Ghi vào DynamoDB rồi trực quan hoá — DynamoDB không có khả năng truy vấn tổng hợp, và QuickSight không kết nối trực tiếp được.

Ghi nhớ

⚠ Kinesis Data Streams và Firehose — bảng phải thuộc: | Tiêu chí | Data Streams | Firehose | |---|---|---| | Quản lý shard | bạn (hoặc on-demand) | không có shard | | Độ trễ | dưới 1 giây | tối thiểu 60 giây | | Lưu giữ | 1-365 ngày | KHÔNG lưu | | Nhiều consumer | được | một đích | | Phát lại | được | KHÔNG |

⚠ Điểm "Firehose không lưu giữ" rất quan trọng:

Đích lỗi kéo dài
    → Firehose thử lại tối đa 24 giờ
        ↓
    Quá hạn: ghi vào S3 dự phòng
      hoặc MẤT
        ↓
    Data Streams giữ tới 365 ngày
    → đọc lại được bất cứ lúc nào

Từ khoá nhận diện:

"least operational overhead, load into Redshift/S3" → Firehose "sub-second latency" → Data Streams (đọc trực tiếp) "replay data" → Data Streams "multiple independent consumers" → Data Streams enhanced fan-out "stream into Redshift with low latency" → Redshift Streaming Ingestion

Ba lưu ý về Firehose: | Lưu ý | Chi tiết | |---|---| | Đích: S3, Redshift, OpenSearch, Splunk, HTTP | | | Chuyển đổi dữ liệu bằng Lambda | | | Chuyển sang Parquet/ORC được | |

⚠ Chuyển sang Parquet giảm chi phí truy vấn rất nhiều:

"DataFormatConversionConfiguration": {
  "Enabled": true,
  "OutputFormatConfiguration": {
    "Serializer": {"ParquetSerDe": {}}}}

JSON: Athena quét toàn bộ tệp
    → Parquet: chỉ đọc cột cần
    → giảm cả dung lượng lẫn chi phí

Ba lưu ý về Data Streams: | Lưu ý | Chi tiết | |---|---| | Mỗi shard: 1 MB/s vào, 2 MB/s ra | | | On-demand tự co giãn tới 200 MB/s | | | Khoá phân vùng quyết định shard | |

⚠ Khoá phân vùng lệch gây shard nóng:

Dùng một giá trị cố định làm khoá
    → mọi bản ghi vào một shard
        ↓
    Shard đó chạm trần 1 MB/s
    → dù có 100 shard khác rảnh

Ba lưu ý về Redshift: | Lưu ý | Chi tiết | |---|---| | COPY từ S3 là cách nạp đúng | | | DISTKEY quyết định phân bố dữ liệu | | | SORTKEY quyết định tốc độ lọc | |

Ba lưu ý về QuickSight: | Lưu ý | Chi tiết | |---|---| | SPICE: cache trong bộ nhớ, nhanh | | | Direct query: luôn mới, tải lên nguồn | | | Nhúng bảng điều khiển vào ứng dụng được | |

Ba lưu ý về kiến trúc chuỗi thời gian: | Lưu ý | Chi tiết | |---|---| | Timestream là CSDL chuyên cho chuỗi thời gian | | | OpenSearch hợp cho tìm kiếm và bảng điều khiển log | | | Redshift hợp cho phân tích tổng hợp lớn | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đo độ trễ từ lúc gửi tới lúc thấy trên bảng | | | Kiểm DeliveryToRedshift.Success của Firehose | | | Xem IteratorAgeMilliseconds của consumer | |

Và một lời khuyên: hãy hỏi rõ "thời gian thực" nghĩa là bao nhiêu giây trước khi chọn kiến trúc. Firehose là lựa chọn đúng cho độ trễ hàng phút và sai hoàn toàn cho độ trễ dưới giây — nhưng cả hai yêu cầu đều được gọi bằng cùng một từ trong tài liệu nghiệp vụ.

Câu 268 Chọn nhiều đáp án Domain - Continuous Improvement for Existing Solutions

A legal consulting firm is running a WordPress website on EC2 instances deployed across multiple Availability Zones with a Multi-AZ RDS MySQL database instance. Their website is designed to use an eventual consistency model and performs a high number of read and write operations. There is a growing number of people who are reporting that the website is slow and after checking, the root cause is due to the slow read processing in your database tier. The current DB instances are already optimized for the firm's operational budget, with considerations for cost-effectiveness and resource utilization.

Which of the following options could solve this issue? (Select THREE.)

A Add an RDS MySQL Read Replica in each Availability Zone.
B
Deploy an Amazon ElastiCache Cluster with nodes running in each Availability Zone.
C
Integrate Amazon CloudFront to the website to deliver the static media assets to the viewers faster. Consider using AWS Compute Optimizer to rightsize your fleet of Amazon EC2 instances.
D Upgrade the instance type of the RDS MySQL database instance to a larger type.
E Implement sharding to distribute the incoming load to multiple RDS MySQL instances.
F Upgrade the RDS MySQL instance to use provisioned IOPS.

Xem giải thích

Đáp án

**A, B và E — Cấu hình Multi-AZ cho cơ sở dữ liệu, đặt máy chủ ứng dụng trong một Auto Scaling group trải trên nhiều AZ, và dùng Elastic Load Balancer phân phối lưu lượng tới các máy chủ.

Vì sao đúng

Đề hỏi cách làm cho một ứng dụng ba tầng có tính sẵn sàng cao, và ba đáp án phủ đúng ba tầng: | Tầng | Biện pháp | |---|---| | Cân bằng tải | ELB (đã trải nhiều AZ sẵn) | | Ứng dụng | ASG trải nhiều AZ | | Cơ sở dữ liệu | Multi-AZ |

⚠ Nguyên tắc: sẵn sàng cao nghĩa là không có điểm hỏng đơn lẻ ở BẤT KỲ tầng nào:

Chỉ làm HA ở tầng ứng dụng
    → CSDL một instance hỏng
    → cả hệ thống chết
        ↓
    Chuỗi chỉ mạnh bằng mắt xích
      yếu nhất

RDS Multi-AZ:

aws rds modify-db-instance --db-instance-identifier csdl-chinh \
  --multi-az --apply-immediately

⚠ Multi-AZ hoạt động thế nào — phải hiểu đúng:

Instance chính ở AZ-a
        ↓
    Sao chép ĐỒNG BỘ sang standby
      ở AZ-b
        ↓
    AZ-a hỏng → RDS tự chuyển
      endpoint DNS sang standby
        ↓
    Ứng dụng không đổi chuỗi kết nối
    → chuyển đổi trong 60-120 giây

⚠ Và standby KHÔNG phục vụ đọc — đây là nhầm lẫn phổ biến: | Cơ chế | Mục đích | Đọc được | |---|---|---| | Multi-AZ (instance) | sẵn sàng cao | KHÔNG | | Read replica | mở rộng đọc | CÓ | | Multi-AZ DB cluster | cả hai | CÓ (2 standby đọc được) |

Auto Scaling group nhiều AZ:

aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name ung-dung \
  --min-size 4 --max-size 20 --desired-capacity 6 \
  --vpc-zone-identifier "subnet-1a,subnet-1b,subnet-1c" \
  --target-group-arns <arn-tg> \
  --health-check-type ELB --health-check-grace-period 300

⚠ --health-check-type ELB là chi tiết quan trọng:

Mặc định ASG chỉ kiểm tra EC2
  (máy có chạy không)
        ↓
    Ứng dụng treo nhưng máy vẫn chạy
    → ASG không thay thế
        ↓
    Kiểu ELB: dùng kết quả kiểm tra
      sức khoẻ của load balancer
    → ứng dụng hỏng thì thay máy

⚠ Và quy tắc N+1 quyết định số máy tối thiểu:

Cần 4 máy để chịu tải
    → trải 2 AZ, mỗi AZ 2 máy
        ↓
    Mất một AZ → còn 2 máy
    → KHÔNG đủ tải
        ↓
    Phải chạy 8 máy (4 mỗi AZ)
    → hoặc trải 3 AZ, 2 máy mỗi AZ
      → mất 1 AZ còn 4 máy

⚠ Đây là lý do ba AZ tiết kiệm hơn hai AZ: | Số AZ | Máy cần để chịu tải khi mất 1 AZ | |---|---| | 2 AZ | 8 máy (dư 100%) | | 3 AZ | 6 máy (dư 50%) | | 4 AZ | ~5,3 máy (dư 33%) |

⚠ Và snapshot theo lịch (phương án C) không phải sẵn sàng cao:

Snapshot là SAO LƯU
    → phục hồi mất hàng chục phút
      tới hàng giờ
        ↓
    Và mất toàn bộ dữ liệu từ lần
      snapshot cuối
        ↓
    Đây là chống mất dữ liệu, không
      phải chống gián đoạn

⚠ Và tăng cỡ instance (phương án D) là mở rộng ĐỨNG:

Máy to hơn vẫn là MỘT máy
    → nó hỏng, tất cả chết
        ↓
    Sẵn sàng cao cần NHIỀU máy
    → mở rộng NGANG

⚠ Và replica ở Region khác (phương án F) là khôi phục thảm hoạ:

Sẵn sàng cao: chịu mất một AZ,
  tự động, trong Region
        ↓
    Khôi phục thảm hoạ: chịu mất
      cả Region
    → thường cần thao tác thủ công
        ↓
    Đề chỉ hỏi sẵn sàng cao

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chịu được mất hoàn toàn một AZ | | | Tự phục hồi, không cần người can thiệp | | | Chuyển đổi CSDL không đổi chuỗi kết nối | |

⚠ Và trạng thái phiên là chỗ hay bị bỏ sót:

Phiên lưu trong bộ nhớ máy chủ
    → máy đó bị thay thế
    → người dùng bị đăng xuất
        ↓
    Lưu phiên ở ElastiCache hoặc
      DynamoDB
    → máy nào phục vụ cũng được

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

**F. Tạo read replica ở Region khác cho CSDL — đây là phương án gần nhất và thật sự tăng khả năng chống chịu, nhưng đó là khôi phục thảm hoạ liên Region, không phải sẵn sàng cao trong một Region; và chuyển đổi cần thao tác thủ công.
**C. Lập lịch snapshot cho CSDL — sao lưu chống mất dữ liệu, không chống gián đoạn dịch vụ.
**D. Tăng cỡ instance máy chủ ứng dụng — mở rộng đứng, vẫn là điểm hỏng đơn lẻ.

Ghi nhớ

⚠ Sẵn sàng cao và khôi phục thảm hoạ — bảng phải thuộc: | Tiêu chí | Sẵn sàng cao | Khôi phục thảm hoạ | |---|---|---| | Phạm vi hỏng | một AZ, một instance | cả Region | | Chuyển đổi | tự động, vài phút | thường thủ công | | Chi phí | gấp đôi tài nguyên | tuỳ chiến lược | | Ví dụ | Multi-AZ, ASG nhiều AZ | replica liên Region, pilot light |

Từ khoá nhận diện:

"highly available" → nhiều AZ trong một Region "disaster recovery" → nhiều Region "scale to handle load" → ASG, read replica "no data loss" → sao lưu, PITR

Bốn chiến lược khôi phục thảm hoạ: | Chiến lược | RTO | Chi phí | |---|---|---| | Backup & restore | giờ | thấp nhất | | Pilot light | chục phút | thấp | | Warm standby | phút | trung bình | | Multi-site active/active | gần 0 | cao nhất |

Ba lưu ý về Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Sao chép đồng bộ, không mất dữ liệu | | | Standby không phục vụ đọc (kiểu instance) | | | Chuyển đổi 60-120 giây | |

⚠ Và Multi-AZ DB cluster là kiểu mới, đáng biết:

Multi-AZ DB cluster: 1 writer +
  2 reader ở ba AZ
        ↓
    Reader phục vụ đọc được
    → chuyển đổi dưới 35 giây
        ↓
    Nhanh hơn Multi-AZ instance

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | min-size phải đủ chịu khi mất một AZ | | | Health check kiểu ELB, không phải EC2 | | | ASG tự cân bằng số máy giữa các AZ | |

Ba lưu ý về ELB: | Lưu ý | Chi tiết | |---|---| | Node ELB tự trải trên các AZ đã bật | | | Cross-zone: ALB bật sẵn, NLB thì không | | | Kiểm tra sức khoẻ phải chạm logic ứng dụng | |

⚠ Kiểm tra sức khoẻ hời hợt là bẫy:

`/health` trả về 200 cố định
    → CSDL chết, ứng dụng vẫn
      "khoẻ mạnh"
        ↓
    Nên kiểm tra kết nối tới
      phụ thuộc quan trọng

Ba lưu ý về trạng thái ứng dụng: | Lưu ý | Chi tiết | |---|---| | Máy chủ phải không giữ trạng thái | | | Phiên ở ElastiCache hoặc DynamoDB | | | Tệp tải lên ở S3 hoặc EFS | |

Ba lưu ý về kiểm thử: | Lưu ý | Chi tiết | |---|---| | Chủ động tắt một AZ để thử | | | AWS Fault Injection Service mô phỏng được | | | Thử chuyển đổi RDS ngoài giờ cao điểm | |

⚠ Chuyển đổi thủ công để thử:

aws rds reboot-db-instance \
  --db-instance-identifier csdl-chinh --force-failover

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt mọi máy ở một AZ — dịch vụ phải sống | | | Ép chuyển đổi RDS — đo thời gian gián đoạn | | | Kiểm phiên người dùng có sống sót không | |

Và một lời khuyên: hãy tính min-size của ASG theo tình huống mất một AZ, chứ đừng theo tải bình thường. Kiến trúc trải hai AZ với vừa đủ máy sẽ trông rất đẹp trên sơ đồ và sụp ngay khi mất một AZ — đúng lúc bạn cần nó nhất.

Câu 269 Chọn nhiều đáp án Domain - Design for New Solutions

A law firm has decided to use Amazon S3 buckets for storage after an extensive Total Cost of ownership (TCO) analysis comparing S3 versus acquiring more storage for its on-premises hardware. The attorneys, paralegals, clerks, and other employees of the law firm will be using Amazon S3 buckets to store their legal documents and other media files. For a better user experience, the management wants to implement a single-sign-on system in which the user can just use their existing Active Directory login to access the S3 storage to avoid having to remember yet another password.

Which of the following options should the solutions architect implement for the above requirement and also provide a mechanism that restricts access for each user to a designated user folder in a bucket? (Select TWO.)

A
Set up a federation proxy or a custom identity provider and use AWS Security Token Service to generate temporary tokens. Use an IAM Role to enable access to AWS services.
B
Use Amazon Connect to integrate the on-premises Active Directory with Amazon S3 and AWS IAM.
C
Configure an IAM user that provides access for the user and an IAM Policy that restricts access only to the user-specific folders in the S3 Bucket.
D
Configure an IAM Policy that restricts access only to the user-specific folders in the Amazon S3 Bucket.
E
Set up a matching IAM user and IAM Policy for every user in your corporate directory that needs access to a folder in the bucket.

Xem giải thích

Đáp án

**A và D — Bật AWS Config với các quy tắc phù hợp trên mọi tài khoản, và dùng service control policy (SCP) trong AWS Organizations để chặn hẳn những hành động không được phép.

Vì sao đúng

Đề hỏi cách vừa phát hiện vừa ngăn chặn vi phạm, và hai đáp án là hai vế của cùng một bài toán: | Vế | Công cụ | Thời điểm | |---|---|---| | Ngăn chặn | SCP | TRƯỚC khi hành động xảy ra | | Phát hiện | AWS Config | SAU khi cấu hình đã sai |

⚠ Cần cả hai — không cái nào thay được cái kia:

Chỉ SCP: chặn được hành động mới
    → nhưng tài nguyên đã sai từ
      TRƯỚC khi áp SCP vẫn sai
        ↓
    Chỉ Config: thấy được vi phạm
    → nhưng vi phạm đã xảy ra rồi

SCP chặn theo Region:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Deny",
  "NotAction": ["iam:*", "organizations:*",
                "cloudfront:*", "route53:*",
                "support:*", "sts:*"],
  "Resource": "*",
  "Condition": {"StringNotEquals": {
    "aws:RequestedRegion": ["ap-southeast-1", "us-east-1"]}}}]}

⚠ NotAction ở đây là bắt buộc, không phải tuỳ chọn:

IAM, Organizations, CloudFront,
  Route 53 là dịch vụ TOÀN CẦU
        ↓
    Endpoint của chúng nằm ở
      us-east-1
        ↓
    Không loại trừ: chặn luôn cả
      việc tạo IAM user
    → tài khoản gần như không
      dùng được

SCP chặn tắt CloudTrail:

{"Effect": "Deny",
 "Action": ["cloudtrail:StopLogging",
            "cloudtrail:DeleteTrail",
            "cloudtrail:UpdateTrail"],
 "Resource": "*"}

⚠ Và SCP KHÔNG áp cho tài khoản quản lý — điểm phải nhớ:

Tài khoản quản lý (management
  account) miễn nhiễm mọi SCP
        ↓
    Đừng chạy workload trong đó
    → chỉ dùng để quản trị tổ chức

⚠ Và SCP không CẤP quyền, chỉ giới hạn:

SCP = trần quyền tối đa
        ↓
    Quyền hiệu lực = GIAO của
      SCP và chính sách IAM
        ↓
    SCP cho phép s3:* nhưng IAM
      không cho
    → vẫn không truy cập được

Config rule kèm khắc phục:

aws configservice put-organization-config-rule \
  --organization-config-rule-name ma-hoa-ebs \
  --organization-managed-rule-metadata \
    RuleIdentifier=ENCRYPTED_VOLUMES

⚠ Và các phương án còn lại đều là công cụ sai việc: | Phương án | Công cụ | Vì sao không hợp | |---|---|---| | B | IAM policy ở từng tài khoản | quản trị viên tài khoản sửa được | | C | CloudTrail | ghi nhật ký, không đánh giá tuân thủ | | E | Trusted Advisor | danh sách kiểm cố định |

⚠ Điểm B đáng nói riêng:

IAM policy do quản trị viên tài
  khoản đó quản
    → họ sửa được, gỡ được
        ↓
    SCP do tài khoản quản lý áp
    → quản trị viên tài khoản con
      KHÔNG gỡ được
    → đây là khác biệt căn bản

⚠ Và CloudTrail chỉ ghi lại việc đã xảy ra:

CloudTrail: ai gọi API nào,
  lúc nào, từ đâu
        ↓
    Không đánh giá "cấu hình này
      có đúng chuẩn không"
        ↓
    Nhưng vẫn phải bật — nó là
      nguồn cho việc điều tra

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | SCP chặn được cả quản trị viên tài khoản con | | | Config thấy toàn cảnh tuân thủ | | | Cả hai áp tự động cho tài khoản mới | |

⚠ Và điểm cuối là lý do dùng Organizations:

Tài khoản mới gia nhập OU
    → tự thừa hưởng SCP của OU đó
    → và tự nằm trong organization
      config rule
        ↓
    Không phải cấu hình thủ công
      gì cả

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

**B. Tạo IAM policy ở từng tài khoản để hạn chế hành động — đây là phương án gần nhất và IAM policy thật sự kiểm soát được quyền, nhưng quản trị viên của chính tài khoản đó sửa hoặc gỡ được, nên không phải ràng buộc cấp tổ chức.
**C. Bật CloudTrail ở mọi tài khoản — cần thiết cho việc kiểm toán nhưng chỉ ghi nhật ký, không đánh giá và không ngăn chặn.
**E. Dùng Trusted Advisor — danh sách kiểm cố định, không viết được luật riêng theo chính sách công ty.

Ghi nhớ

⚠ Bốn tầng kiểm soát trong Organizations — bảng phải thuộc: | Tầng | Vai trò | |---|---| | SCP | trần quyền tối đa cho tài khoản | | RCP (resource control policy) | trần quyền cho TÀI NGUYÊN | | IAM policy | cấp quyền trong tài khoản | | Config rule | phát hiện cấu hình sai |

⚠ RCP là loại mới (2024), rất đáng biết:

SCP giới hạn danh tính TRONG
  tổ chức
        ↓
    RCP giới hạn ai truy cập được
      TÀI NGUYÊN của tổ chức
    → kể cả danh tính bên ngoài
        ↓
    Ví dụ: cấm mọi principal ngoài
      tổ chức đọc bucket S3

Từ khoá nhận diện:

"prevent, even for administrators" → SCP "detect non-compliant resources" → Config rules "who did what" → CloudTrail "restrict access to resources from outside" → RCP "deploy across all accounts" → StackSets hoặc organization rules

Ba lưu ý về SCP: | Lưu ý | Chi tiết | |---|---| | KHÔNG áp cho tài khoản quản lý | | | KHÔNG cấp quyền, chỉ giới hạn | | | Thừa hưởng theo cây OU, GIAO nhau | |

⚠ Thừa hưởng theo cây là chỗ hay nhầm:

Root có SCP cho phép A, B, C
    → OU con có SCP cho phép B, C, D
        ↓
    Quyền còn lại: B, C
    → GIAO chứ không phải HỢP

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Bật ở từng Region, từng tài khoản | | | Aggregator gom về một chỗ để xem | | | Remediation tự sửa qua SSM Automation | |

Ba lưu ý về CloudTrail tổ chức: | Lưu ý | Chi tiết | |---|---| | Organization trail gom mọi tài khoản | | | SCP cấm tắt trail | | | Bật log file validation chống sửa | |

⚠ Log file validation là thứ hay bị bỏ:

aws cloudtrail update-trail --name trail-to-chuc \
  --enable-log-file-validation

CloudTrail ký số mỗi tệp log
    → phát hiện được nếu ai sửa
      hoặc xoá
    → cần cho kiểm toán

Ba lưu ý về Control Tower: | Lưu ý | Chi tiết | |---|---| | Dựng sẵn landing zone nhiều tài khoản | | | Guardrail = SCP + Config rule đóng gói | | | Account Factory tạo tài khoản theo chuẩn | |

Ba lưu ý về Security Hub: | Lưu ý | Chi tiết | |---|---| | Chạy chuẩn CIS, PCI-DSS, AWS FSBP | | | Dựa trên Config để đánh giá | | | Gom phát hiện từ GuardDuty, Inspector, Macie | |

Ba lưu ý về triển khai: | Lưu ý | Chi tiết | |---|---| | Thử SCP trên OU thử nghiệm trước | | | Xem lại CloudTrail tìm lời gọi sẽ bị chặn | | | SCP quá chặt làm hỏng cả pipeline triển khai | |

⚠ Điểm cuối là sự cố thật hay gặp:

Áp SCP chặn một Region
    → CodeBuild của pipeline chạy
      ở Region đó
        ↓
    Toàn bộ việc triển khai dừng
    → và thông báo lỗi là
      AccessDenied chung chung

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử hành động bị cấm — phải AccessDenied | | | Xem Config aggregator có đủ tài khoản | | | Kiểm tài khoản mới có tự thừa hưởng SCP | |

Và một lời khuyên: hãy rà CloudTrail của vài tuần gần nhất trước khi áp một SCP mới. Một chính sách trông vô hại thường chặn luôn một lời gọi API nào đó mà pipeline triển khai đang dùng — và bạn chỉ biết khi mọi việc triển khai đồng loạt hỏng với lỗi AccessDenied không nói rõ nguyên nhân.

Câu 270 Domain - Design Solutions for Organizational Complexity

A large company has multiple AWS accounts with multiple IAM Users that launch different types of Amazon EC2 instances and EBS volumes every day. As a result, most accounts quickly hit the service limit and IAM users can no longer create any new instances. When cleaning up the AWS accounts, the solutions architect noticed that the majority of the instances and volumes are untagged. Therefore, it is difficult to pinpoint the owner of these resources and verify if they are safe to terminate. Because of this, the management had issued a new protocol that requires adding a predefined set of tags before anyone can launch their EC2 instances.

Which of the following options is the simplest way to enforce this new requirement?

A
Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a rule using AWS Systems Manager requiring users to tag specific resources and raise an alert whenever the rule is violated. This will allow a user to launch EC2 instances only if certain tags were defined. If the user applies any other tag then the action is denied.
B
Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a Service Control Policy that restricts launching any AWS resources without a tag by including the Condition element in the policy which uses the ForAllValues qualifier and the aws:TagKeys condition. This policy will require its principals to tag resources during creation. Apply the SCP to the OU which will automatically cascade the policy to individual member accounts.
C
Configure AWS Organizations to group different accounts into separate Organizational Units (OU) depending on the business function. Create a rule in AWS Config requiring users to tag specific resources and raise an alert whenever the rule is violated. The Config Rule should allow a user to launch EC2 instances only if the user adds all the tags defined in the rule. If the user applies any other tag then the action is denied.
D
Apply an IAM policy to the individual member accounts of the OU that includes a Condition element in the policy containing the ForAllValues qualifier and the aws:TagKeys condition. This policy will require its principals to attach specific tags to their resources during creation.

Xem giải thích

Đáp án

**B — Tạo một service control policy (SCP) từ chối việc tạo tài nguyên nếu không có thẻ (tag) bắt buộc, và gắn SCP đó vào các OU trong AWS Organizations.

Vì sao đúng

Đề hỏi cách bắt buộc mọi tài nguyên phải có thẻ, và chỉ SCP mới "bắt buộc" được:

Cách khác: phát hiện tài nguyên
  thiếu thẻ rồi báo
        ↓
    Tài nguyên đã được tạo rồi
    → và người tạo có thể lờ đi
        ↓
    SCP: KHÔNG tạo được ngay
      từ đầu

⚠ Và SCP là thứ quản trị viên tài khoản con không gỡ được: | Cơ chế | Ai gỡ được | |---|---| | IAM policy trong tài khoản | quản trị viên tài khoản đó | | Config rule | quản trị viên tài khoản đó (nếu không phải org rule) | | SCP | CHỈ tài khoản quản lý |

SCP theo cách AWS khuyến nghị:

{"Version": "2012-10-17", "Statement": [{
  "Sid": "BatBuocTheTrungTamChiPhi",
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance",
             "s3:CreateBucket"],
  "Resource": "*",
  "Condition": {"Null": {
    "aws:RequestTag/TrungTamChiPhi": "true"}}}]}

⚠ Điều kiện Null là cách đúng để kiểm tra "thẻ có tồn tại không":

`aws:RequestTag/Khoa` là giá trị
  của thẻ trong yêu cầu
        ↓
    `Null: true` nghĩa là "khoá này
      KHÔNG có mặt"
        ↓
    Deny khi không có mặt
    → bắt buộc phải có

⚠ Và điều kiện giá trị hợp lệ dùng StringNotEquals:

"Condition": {"StringNotEquals": {
  "aws:RequestTag/MoiTruong":
    ["san-xuat", "thu-nghiem", "phat-trien"]}}

Không chỉ bắt phải CÓ thẻ
    → mà giá trị phải nằm trong
      danh sách cho phép
        ↓
    Chống việc gõ "Prod", "PROD",
      "production" lung tung

⚠ Và cấm gỡ thẻ cũng cần một quy tắc riêng:

{"Effect": "Deny",
 "Action": ["ec2:DeleteTags"],
 "Resource": "*",
 "Condition": {"ForAnyValue:StringEquals": {
   "aws:TagKeys": ["TrungTamChiPhi"]}}}

Bắt buộc có thẻ lúc TẠO
    → nhưng gỡ sau đó thì sao?
        ↓
    Phải cấm luôn việc xoá thẻ đó

⚠ Và không phải mọi dịch vụ đều hỗ trợ aws:RequestTag:

Kiểm tra bảng "Actions, resources,
  and condition keys" trong tài
  liệu IAM của từng dịch vụ
        ↓
    Dịch vụ không hỗ trợ
    → SCP không có tác dụng
    → phải bù bằng Config rule

⚠ Và ec2:RunInstances có một cái bẫy riêng:

Gắn thẻ vào instance lúc tạo cần
  quyền `ec2:CreateTags` với điều
  kiện `ec2:CreateAction`
        ↓
    Thiếu quyền đó: người dùng
      không gắn thẻ được
    → và SCP chặn vì thiếu thẻ
        ↓
    Vòng luẩn quẩn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có tài nguyên nào lọt qua | | | Áp cho cả quản trị viên tài khoản con | | | Tài khoản mới tự thừa hưởng | |

⚠ Và thẻ đúng làm phân bổ chi phí hoạt động được:

aws ce get-cost-and-usage \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=TAG,Key=TrungTamChiPhi

Thiếu thẻ trên vài tài nguyên
    → chúng rơi vào nhóm
      "No TagKey"
    → báo cáo chi phí vô nghĩa

⚠ Và phải kích hoạt thẻ trong Billing thì mới dùng phân bổ được:

Gắn thẻ xong chưa đủ
    → vào Billing → Cost allocation tags
      → Activate
        ↓
    Chỉ có hiệu lực từ lúc kích hoạt
      trở đi, không hồi tố

⚠ Và Tag Policy là công cụ bổ trợ, không thay thế SCP:

Tag policy: định nghĩa khoá và
  giá trị chuẩn
        ↓
    Báo cáo tài nguyên không tuân thủ
    → và có tuỳ chọn chặn thao tác
      gắn thẻ sai
        ↓
    Nhưng KHÔNG chặn việc tạo tài
      nguyên không có thẻ

Ghi nhớ về chất lượng câu hỏi

⚠ Phương án B trong đề gốc mô tả điều kiện là ForAllValues:StringNotEquals với aws:TagKeys.

Đó không phải cách AWS khuyến nghị để bắt buộc một thẻ phải có mặt: | Điều kiện | Kiểm tra gì | |---|---| | Null trên aws:RequestTag/Khoa | thẻ này CÓ mặt không — đúng cho việc bắt buộc | | ForAllValues:StringEquals trên aws:TagKeys | MỌI khoá trong yêu cầu có nằm trong danh sách không |

`ForAllValues` với tập rỗng
  luôn trả về TRUE
        ↓
    Yêu cầu KHÔNG có thẻ nào
    → điều kiện thoả
    → không bị chặn
        ↓
    Đúng thứ ta muốn chặn thì lọt

Phương án vẫn là đáp án đúng vì SCP là hướng đúng, nhưng nếu triển khai đúng chữ trong đề thì chính sách sẽ không làm việc như mong đợi.

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

**A. Dùng AWS Config rule required-tags để phát hiện tài nguyên thiếu thẻ — đây là phương án gần nhất và thật sự có luật dựng sẵn cho việc này, nhưng nó phát hiện sau khi tài nguyên đã tồn tại, không ngăn được việc tạo.
**C. Dùng Tag Editor gắn thẻ hàng loạt định kỳ — sửa hậu quả chứ không chặn nguyên nhân, và người tạo tài nguyên vẫn không khai đúng trung tâm chi phí.
**D. Dùng AWS Budgets cảnh báo theo thẻ — Budgets chỉ theo dõi chi tiêu, không liên quan tới việc bắt buộc gắn thẻ.

Ghi nhớ

⚠ Bốn cách kiểm soát thẻ — bảng phải thuộc: | Cách | Thời điểm | Cưỡng chế | |---|---|---| | SCP với aws:RequestTag | lúc tạo | CHẶN | | IAM policy tương tự | lúc tạo | chặn, nhưng gỡ được | | Tag policy | lúc gắn thẻ | chuẩn hoá khoá/giá trị | | Config rule required-tags | sau khi tạo | phát hiện + sửa |

Từ khoá nhận diện:

"enforce, prevent creation" → SCP với aws:RequestTag và Null "detect resources missing tags" → Config rule required-tags "standardize tag keys and values" → Tag policy "cost allocation by department" → thẻ + kích hoạt trong Billing

⚠ Ba khoá điều kiện về thẻ — phân biệt rõ: | Khoá | Nghĩa | |---|---| | aws:RequestTag/Khoa | giá trị thẻ trong YÊU CẦU | | aws:ResourceTag/Khoa | giá trị thẻ trên TÀI NGUYÊN đã có | | aws:TagKeys | danh sách các khoá trong yêu cầu |

`RequestTag`: dùng khi tạo hoặc
  gắn thẻ
        ↓
    `ResourceTag`: dùng cho ABAC
    → "chỉ sửa được máy có thẻ
      Nhom = cua-toi"

Ba lưu ý về ABAC: | Lưu ý | Chi tiết | |---|---| | Quyền dựa trên thẻ, không phải ARN | | | Một chính sách phục vụ nhiều đội | | | Cần thẻ chính xác thì mới an toàn | |

⚠ ABAC dùng thẻ phiên:

{"Effect": "Allow", "Action": "ec2:StartInstances",
 "Resource": "*",
 "Condition": {"StringEquals": {
   "ec2:ResourceTag/Nhom": "${aws:PrincipalTag/Nhom}"}}}

Một chính sách cho mọi đội
    → mỗi người chỉ chạm tài nguyên
      của đội mình

Ba lưu ý về chiến lược đặt thẻ: | Lưu ý | Chi tiết | |---|---| | Ít khoá bắt buộc thôi (3-5) | | | Chuẩn hoá chữ hoa/thường | | | Ghi tài liệu ý nghĩa từng khoá | |

⚠ Thẻ phân biệt chữ hoa thường:

`Environment` và `environment`
  là HAI thẻ khác nhau
        ↓
    Báo cáo chi phí sẽ tách thành
      hai nhóm
    → Tag policy chuẩn hoá được
      chuyện này

Ba lưu ý về phân bổ chi phí: | Lưu ý | Chi tiết | |---|---| | Phải kích hoạt thẻ trong Billing | | | Không hồi tố cho dữ liệu cũ | | | Có thể mất 24 giờ để xuất hiện | |

Ba lưu ý về hạn ngạch thẻ: | Hạn ngạch | Giá trị | |---|---| | Số thẻ mỗi tài nguyên | 50 | | Độ dài khoá | 128 ký tự | | Độ dài giá trị | 256 ký tự |

Ba lưu ý về triển khai SCP: | Lưu ý | Chi tiết | |---|---| | Thử trên OU nhỏ trước | | | Nhớ thêm quyền ec2:CreateTags | | | Kiểm tra dịch vụ có hỗ trợ aws:RequestTag không | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo tài nguyên không thẻ — phải bị từ chối | | | Tạo với giá trị thẻ sai — phải bị từ chối | | | Xem báo cáo chi phí có nhóm "No TagKey" không | |

Và một lời khuyên: hãy dùng điều kiện Null trên aws:RequestTag/<khoá> chứ đừng dùng ForAllValues trên aws:TagKeys. Toán tử ForAllValues trả về true khi tập giá trị rỗng, nên một yêu cầu hoàn toàn không có thẻ sẽ lọt qua — đúng trường hợp bạn muốn chặn nhất.

Trang 27 / 123 — tổng 1221 câu hỏi