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

Tìm thấy 1221 câu.

Câu 131 Domain - Design for New Solutions
An enterprise software company has just recently started using AWS as their cloud infrastructure. They are building an enterprise proprietary issue tracking system which would be accessed by their customers worldwide. Hence, the CTO carefully instructed you to ensure that the architecture of the issue tracking system is both scalable and highly available to avoid any complaints from the clients. It is expected that the application will have a steady-state usage and the database would be used for online transaction processing (OLTP). Which of the following would be the best architecture setup to satisfy the above requirement?
  1. A Launch an Auto Scaling group of Spot EC2 instances with an ELB in front to handle the load balancing. Leverage on CloudFront in distributing your static content and a RDS instance with Read Replicas.
  2. B Use multiple On-Demand EC2 instances to host the application and a highly scalable DynamoDB for the database. Use ElastiCache for in-memory data caching for your database to improve performance.
  3. C Use a Dedicated EC2 instance as the application server and Redshift as a petabyte-scale data warehouse service. Use ElastiCache for in-memory data caching for your database to improve performance.
  4. D Use a CloudFormation template to launch an Auto Scaling group of EC2 instances across multiple Availability Zones which are all connected via an ELB to handle the load balancing. Leverage on CloudFront in distributing your static content and a RDS instance with Multi-AZ deployments configuration.
Xem giải thích

Đáp án

**D — Dùng CloudFormation template dựng Auto Scaling group trải nhiều AZ sau một ELB, dùng CloudFront phân phối nội dung tĩnh, và RDS Multi-AZ cho CSDL.

Vì sao đúng

Đề cho hai dữ kiện quyết định, và phương án này khớp cả hai: | Dữ kiện | Suy ra | |---|---| | "steady-state usage" | KHÔNG dùng Spot; mua Reserved cho phần nền | | "OLTP" | CSDL quan hệ, KHÔNG phải Redshift |

Cộng hai yêu cầu chung: co giãn và sẵn sàng cao.

⚠ OLTP và OLAP là hai loại tải hoàn toàn khác nhau — bảng phải thuộc: | Tiêu chí | OLTP | OLAP | |---|---|---| | Thao tác | đọc/ghi nhiều bản ghi nhỏ | quét lớn, tổng hợp | | Dịch vụ | RDS, Aurora, DynamoDB | Redshift, Athena | | Ví dụ | tạo phiếu lỗi, cập nhật trạng thái | báo cáo xu hướng theo quý |

Hệ thống theo dõi phiếu lỗi
    → tạo, sửa, đóng phiếu liên tục
    → đây là OLTP
        ↓
    Redshift trong phương án C
      là sai loại tải hoàn toàn

⚠ Và "steady-state" là lý do loại Spot:

Spot rẻ nhưng bị thu hồi bất kỳ lúc nào
    → hợp với việc chịu được gián đoạn
        ↓
    Tải ổn định, khách hàng toàn cầu
      dùng liên tục
    → Reserved Instance hoặc Savings Plan
    → rẻ hơn On-Demand mà không mất
      máy giữa chừng

Template rút gọn:

Resources:
  CanBangTai:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Subnets: [!Ref SubnetA, !Ref SubnetB, !Ref SubnetC]

  NhomCoGian:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MinSize: 3
      MaxSize: 12
      VPCZoneIdentifier: [!Ref SubnetA, !Ref SubnetB, !Ref SubnetC]
      TargetGroupARNs: [!Ref NhomDich]
      HealthCheckType: ELB
      HealthCheckGracePeriod: 300

  CoSoDuLieu:
    Type: AWS::RDS::DBInstance
    DeletionPolicy: Snapshot
    UpdateReplacePolicy: Snapshot
    Properties:
      Engine: postgres
      MultiAZ: true
      DBInstanceClass: db.r6g.large
      StorageEncrypted: true

⚠ Multi-AZ và Read Replica giải quyết hai bài toán khác nhau:

Multi-AZ: SẴN SÀNG CAO
    → nhân bản đồng bộ, tự chuyển đổi
    → bản dự phòng KHÔNG phục vụ đọc
        ↓
    Read Replica: CO GIÃN ĐỌC
    → nhân bản bất đồng bộ
    → chuyển đổi phải làm thủ công
        ↓
    Đề đòi "sẵn sàng cao" → Multi-AZ

Đây là lý do phương án A yếu hơn — nó dùng Read Replica cho một yêu cầu về sẵn sàng.

Co giãn theo số yêu cầu:

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name asg-phieu-loi \
  --policy-name theo-request --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 1000.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ALBRequestCountPerTarget",
      "ResourceLabel": "<alb>/<target-group>"}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Toàn bộ hạ tầng dựng lại được từ template | | | Chịu được mất một AZ ở cả hai tầng | | | CloudFront giảm độ trễ cho khách toàn cầu | |

⚠ Và CloudFront giúp cả nội dung động:

Kết nối TLS chấm dứt ở biên
    → bắt tay nhanh hơn nhiều
        ↓
    Đi tiếp trên mạng xương sống AWS
    → nhanh hơn Internet công cộng
        ↓
    API không cache được vẫn hưởng lợi

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

  • **A. ASG Spot + ELB + CloudFront + RDS Read Replica — đây là phương án gần nhất và có đủ CloudFront, ELB, ASG, nhưng hai chi tiết sai: Spot không hợp với tải ổn định của hệ thống quan trọng, và Read Replica là cơ chế co giãn đọc chứ không phải sẵn sàng cao.
  • **B. Nhiều EC2 On-Demand với DynamoDB và ElastiCache — không có cơ chế co giãn tự động hay cân bằng tải nào; và chuyển sang DynamoDB đòi thiết kế lại mô hình dữ liệu.
  • **C. Một Dedicated EC2 với Redshift — một máy là một điểm hỏng, và Redshift là kho dữ liệu phân tích, sai hoàn toàn với tải OLTP.

Ghi nhớ

⚠ Bốn tầng của ứng dụng web toàn cầu — bảng phải thuộc: | Tầng | Lựa chọn | |---|---| | Biên | CloudFront | | Cân bằng tải | ALB | | Tính toán | ASG nhiều AZ | | CSDL | RDS Multi-AZ (+ replica nếu cần đọc) |

Từ khoá nhận diện:

"OLTP" → RDS hoặc Aurora "data warehouse, analytics" → Redshift "steady-state" → Reserved Instance / Savings Plan "fault-tolerant batch" → Spot "highly available database" → Multi-AZ

Ba lưu ý về chọn mô hình mua: | Mô hình | Dùng cho | |---|---| | Savings Plan / RI | phần công suất luôn chạy | | On-Demand | phần co giãn khó đoán | | Spot | việc chịu được gián đoạn |

⚠ Mẫu kết hợp trong một ASG:

MixedInstancesPolicy:
  InstancesDistribution:
    OnDemandBaseCapacity: 3
    OnDemandPercentageAboveBaseCapacity: 100

3 máy nền: phủ bằng Reserved
    → phần co giãn: On-Demand
        ↓
    Ổn định cho tải nền, linh hoạt
      cho đỉnh

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | HealthCheckType: ELB chứ không phải EC2 | | | ALB phải gắn đủ AZ mà ASG dùng | | | Warm pool rút ngắn thời gian sẵn sàng | |

Ba lưu ý về RDS Multi-AZ: | Lưu ý | Chi tiết | |---|---| | Nhân bản đồng bộ, RPO bằng 0 | | | Chuyển đổi 60-120 giây | | | Vá lỗi không gây gián đoạn dài | |

⚠ Ứng dụng phải chịu được lần chuyển đổi đó:

Endpoint DNS không đổi nhưng IP đổi
    → JVM cache DNS vĩnh viễn mặc định
        ↓
    Đặt `networkaddress.cache.ttl=60`
    → hoặc dùng RDS Proxy

Ba lưu ý về CloudFront: | Lưu ý | Chi tiết | |---|---| | Cache behavior riêng cho /api/* và nội dung tĩnh | | | Chứng chỉ ACM ở us-east-1 | | | Bật nén Gzip và Brotli | |

Ba lưu ý về CloudFormation: | Lưu ý | Chi tiết | |---|---| | Tách template theo tầng | | | Change set trước mọi cập nhật sản xuất | | | DeletionPolicy: Snapshot cho RDS | |

Ba lưu ý về giám sát: | Chỉ số | Cảnh báo khi | |---|---| | HealthyHostCount theo từng AZ | giảm bất thường | | TargetResponseTime | p99 tăng | | DatabaseConnections | gần chạm trần |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buộc chuyển đổi RDS và bấm giờ | | | Tắt một AZ, xem dịch vụ còn chạy | | | Đẩy tải xem ASG mở rộng kịp không | |

Và một lời khuyên: hãy đọc kỹ hai chữ "OLTP" và "steady-state" trong đề trước khi so sánh các phương án. Đề dạng này thường chỉ khác nhau ở một hoặc hai thành phần, và hai cụm từ đó loại được ngay hơn nửa số lựa chọn.

Câu 132 Domain - Design for New Solutions

A BPO company uses a multitiered, java-based content management system (CMS) hosted on an on-premises data center. The CMS has a JBoss Application server present in the application tier. The database tier consists of an Oracle database which is regularly backed up to S3 using the Oracle RMAN backup utility. The application's static files and content are kept on a 512 GB Storage Gateway volume which is attached to the application server via an iSCSI interface. The solutions architect was tasked to create a disaster recovery solution for the application and its data.

Which AWS-based disaster recovery strategy will give you the best RTO?

  1. A Provision EC2 servers for both your JBoss application and Oracle database, and then restore the database backups from an S3 bucket. Also provision an EBS volume containing static content obtained from Storage Gateway, and attach the volume to the JBoss EC2 server.
  2. B Provision EC2 servers for both your JBoss application and Oracle database, and then restore the database backups from an S3 bucket. Use an AWS Storage Gateway-VTL running on Amazon EC2 as your source for restoring static content.
  3. C Use RDS for your Oracle database and EC2 for the JBoss application server. Restore the RMAN Oracle backups from Amazon Glacier, and provision an EBS volume containing static content obtained from Storage Gateway. The volume will be attached to the JBoss EC2 server.
  4. D Provision EC2 servers for both your JBoss application and Oracle database, and then restore the database backups from an S3 bucket. Attach an AWS Storage Gateway running on Amazon EC2 as an iSCSI volume to the JBoss EC2 server to access the static content.
Xem giải thích

Đáp án

**A — Dựng EC2 cho cả JBoss lẫn Oracle, khôi phục bản sao lưu CSDL từ bucket S3, và tạo một volume EBS chứa nội dung tĩnh lấy từ Storage Gateway rồi gắn vào máy chủ JBoss.

Vì sao đúng

Đề hỏi chiến lược cho RTO tốt nhất, và điểm phân biệt nằm ở cách lấy nội dung tĩnh: | Cách | Thời gian tới khi phục vụ được | |---|---| | Tạo EBS từ ảnh chụp của gateway | volume dùng được gần như ngay | | Dựng gateway trên EC2 rồi gắn iSCSI | phải dựng gateway, nạp cache, kéo dữ liệu | | Khôi phục từ Tape Gateway (VTL) | hàng giờ |

⚠ Volume gateway chụp ảnh thành EBS snapshot — đây là mấu chốt:

Storage Gateway chế độ cached/stored
    → ảnh chụp lưu dưới dạng
      EBS SNAPSHOT thật
        ↓
    Khi có sự cố: tạo volume EBS
      từ ảnh chụp đó
    → gắn vào EC2, dùng ngay
        ↓
    Không cần dựng lại gateway nào

Tạo volume từ ảnh chụp:

aws ec2 create-volume --snapshot-id snap-abc \
  --availability-zone ap-southeast-1a --volume-type gp3

aws ec2 attach-volume --volume-id vol-moi \
  --instance-id i-jboss --device /dev/sdf

⚠ Và volume tạo từ snapshot có một đặc tính phải biết:

Volume dùng được NGAY
    → nhưng dữ liệu nạp lười (lazy load)
      từ S3 khi lần đầu đọc block
        ↓
    Vài lần đọc đầu chậm hơn
    → bật Fast Snapshot Restore để
      hết hiện tượng đó

aws ec2 enable-fast-snapshot-restores \
  --availability-zones ap-southeast-1a \
  --source-snapshot-ids snap-abc

⚠ Vì sao Oracle chạy trên EC2 chứ không phải RDS:

Khôi phục bằng RMAN từ bản sao lưu
  của CSDL tại chỗ
        ↓
    RDS KHÔNG cho khôi phục RMAN backup
      theo cách đó
    → và không có quyền truy cập
      hệ điều hành
        ↓
    EC2 là lựa chọn duy nhất khớp
      với quy trình sao lưu hiện có

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

⚠ Và Glacier trong phương án C giết chết RTO:

Glacier Flexible Retrieval:
    Expedited 1-5 phút
    Standard  3-5 giờ
    Bulk      5-12 giờ
        ↓
    Đề hỏi RTO TỐT NHẤT
    → S3 Standard, lấy ngay

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nội dung tĩnh sẵn sàng gần như tức thì | | | Không phải dựng lại gateway lúc khủng hoảng | | | Bản sao lưu nằm ở S3, lấy ngay được | |

⚠ Nhưng chiến lược này vẫn là Backup & Restore — RTO tính bằng giờ:

Dựng EC2 + cài JBoss + khôi phục Oracle
    → hàng chục phút tới vài giờ
        ↓
    Muốn nhanh hơn nữa:
    → Pilot Light: giữ sẵn AMI và
      CSDL nhân bản
    → Warm Standby: giữ đội máy nhỏ chạy

Rút ngắn bằng AMI dựng sẵn:

aws ec2 create-image --instance-id i-jboss-mau \
  --name "jboss-da-cai-dat-$(date +%F)" --no-reboot

AMI đã cài JBoss và cấu hình sẵn
    → khởi động là chạy
    → cắt bỏ toàn bộ thời gian cài đặt

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

  • **D. Dựng EC2 cho JBoss và Oracle, khôi phục CSDL từ S3, và gắn Storage Gateway chạy trên EC2 làm volume iSCSI — đây là phương án gần nhất và hoàn toàn khả thi, nhưng phải dựng gateway, kích hoạt, nạp cache và kéo dữ liệu từ S3 qua đường iSCSI; chậm hơn hẳn việc tạo thẳng volume EBS từ ảnh chụp.
  • **B. Dùng Storage Gateway VTL trên EC2 làm nguồn khôi phục nội dung tĩnh — Tape Gateway mô phỏng thư viện băng từ, khôi phục từ "băng" ảo là quy trình chậm nhất trong các lựa chọn.
  • **C. Dùng RDS cho Oracle và khôi phục RMAN từ Glacier — RDS không nhận RMAN backup theo cách này, và Glacier mất hàng giờ để lấy dữ liệu.

Ghi nhớ

⚠ Bốn chiến lược DR và RTO tương ứng — bảng phải thuộc: | Chiến lược | RTO | Chi phí thường trực | |---|---|---| | Backup & Restore | giờ | thấp nhất | | Pilot Light | chục phút | thấp | | Warm Standby | phút | trung bình | | Multi-Site | gần 0 | cao nhất |

Từ khoá nhận diện:

"best RTO from backups" → giảm số bước phải làm khi sự cố "snapshot to EBS volume" → volume gateway "replace tape library" → Tape Gateway "lowest RPO" → nhân bản liên tục

Ba lưu ý về volume gateway: | Lưu ý | Chi tiết | |---|---| | Chế độ cached: dữ liệu chính trên S3 | | | Chế độ stored: dữ liệu chính trên đĩa cục bộ | | | Ảnh chụp thành EBS snapshot dùng được trên EC2 | |

⚠ Điểm thứ ba chính là đường di chuyển lên cloud:

Dữ liệu tại chỗ qua volume gateway
    → ảnh chụp là EBS snapshot
        ↓
    Tạo volume, gắn vào EC2
    → dữ liệu tại chỗ dùng được
      trên cloud mà không chép lại

Ba lưu ý về rút ngắn RTO: | Lưu ý | Chi tiết | |---|---| | AMI dựng sẵn thay cho cài đặt lúc sự cố | | | CloudFormation dựng hạ tầng bằng một lệnh | | | Fast Snapshot Restore bỏ giai đoạn nạp lười | |

⚠ Hạ tầng dạng mã là yếu tố rút ngắn RTO lớn nhất:

Dựng tay lúc khủng hoảng
    → chậm, và dễ sai
        ↓
    Một lệnh `create-stack`
    → hạ tầng lên trong vài phút
    → và giống hệt môi trường cũ

Ba lưu ý về sao lưu Oracle: | Lưu ý | Chi tiết | |---|---| | RMAN ghi thẳng lên S3 được | | | Kiểm thử khôi phục định kỳ | | | Giữ archive log để phục hồi tới thời điểm | |

Ba lưu ý về lớp lưu trữ và RTO: | Lớp | Thời gian lấy | |---|---| | S3 Standard / IA | ngay | | Glacier Instant Retrieval | mili giây | | Glacier Flexible | 1 phút tới 12 giờ | | Deep Archive | 12-48 giờ |

⚠ Chọn lớp phải xuất phát từ RTO, không từ giá:

Deep Archive rẻ nhất
    → nhưng RTO tối thiểu 12 giờ
        ↓
    Bản sao lưu dùng cho DR
      phải nằm ở lớp lấy nhanh
    → Deep Archive chỉ cho lưu trữ
      tuân thủ dài hạn

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | Diễn tập khôi phục ít nhất mỗi quý | | | Bấm giờ thật, ghi lại | | | Kiểm hạn ngạch ở Region dự phòng | |

Ba lưu ý về AWS Elastic Disaster Recovery: | Lưu ý | Chi tiết | |---|---| | Nhân bản liên tục ở mức khối | | | RPO tính bằng giây, RTO tính bằng phút | | | Chi phí thường trực thấp — chỉ trả lưu trữ | |

⚠ Đây là lựa chọn hiện đại cho chính bài toán trong đề:

DRS nhân bản máy chủ tại chỗ liên tục
    → khi sự cố: khởi động instance
      từ bản sao
        ↓
    RTO vài phút thay vì vài giờ
    → và kiểm thử không ảnh hưởng
      hệ thống nguồn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khôi phục thử toàn bộ và bấm giờ | | | Kiểm dữ liệu tĩnh có đủ và đúng | | | Thử khôi phục CSDL tới một thời điểm | |

Và một lời khuyên: hãy diễn tập khôi phục đầy đủ ít nhất một lần và ghi lại con số thật. RTO trên tài liệu luôn là ước lượng lạc quan — và khoảng cách giữa nó với thực tế chỉ hiện ra khi bạn thật sự bấm giờ.

Câu 133 Domain - Design for New Solutions

An advertising company plans to release a new photo-sharing app that will be hosted on the AWS Cloud. The app will store all pictures directly uploaded by users in a single Amazon S3 bucket and users will also be able to view and download their own pictures directly from the Amazon S3 bucket. The solutions architect must ensure the security of the application and it should be able to handle potentially millions of users in the most secure manner.

How should the solutions architect set up the user registration flow in AWS for this mobile app?

  1. A

    Create an IAM user, assign appropriate permissions to it, and generate an access key and a secret key that will be stored in the mobile app and used to access Amazon S3.
  2. B Create an IAM user and generate an access key and a secret key to be stored in the mobile app for the IAM user. After applying the appropriate permissions to the S3 bucket policy, use the generated credentials to access S3.
  3. C

    Generate long-term credentials using AWS STS and apply the appropriate permissions. Store the credentials in the mobile app, and use them to access Amazon S3.
  4. D Store user information in Amazon RDS and create an IAM Role with appropriate permissions. Generate new temporary credentials using the AWS Security Token Service 'AssumeRole' function every time the user uses their mobile app and creates new temporary credentials. These credentials will be stored in the mobile app's memory and will be used to access Amazon S3.
Xem giải thích

Đáp án

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

Vì sao đúng

Đề hỏi cách đăng ký người dùng an toàn nhất cho ứng dụng di động, và nguyên tắc quyết định là:

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
    → không có cách nào giấu

⚠ Đây là lý do ba phương án còn lại đều sai: | Phương án | Vấn đề | |---|---| | A. IAM user + access key trong app | khoá tĩnh, ai cũng trích ra được | | B. IAM user + khoá + bucket policy | vẫn là khoá tĩnh | | C. "credential dài hạn từ STS" | STS chỉ cấp credential TẠM — mô tả sai |

⚠ 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
      policy 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

Giới hạn 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:::anh-nguoi-dung/{ma_nguoi_dung}/*"}]}
    return sts.assume_role(
        RoleArn='arn:aws:iam::111122223333:role/NguoiDungApp',
        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 ảnh 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

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 | | | Phạm vi thu hẹp theo từng người dùng | |

⚠ Và ứng dụng phải xử lý việc hết hạn:

Credential hết hạn giữa lúc tải ảnh lớn
    → thao tác thất bại
        ↓
    Xin credential mới khi còn 5 phút
    → hoặc bắt lỗi `ExpiredToken`
      và thử lại

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

⚠ Amazon Cognito là câu trả lời đúng 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 triệu người dùng, an toàn nhất. Đó là mô tả từng chữ của Cognito: | Việc | Phương án D 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} |

Cognito identity pool làm ĐÚNG
  việc mà phương án D mô tả
    → nhưng không phải viết
      tầng xác thực nào

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

{"Effect": "Allow",
 "Action": ["s3:GetObject", "s3:PutObject"],
 "Resource": "arn:aws:s3:::anh-nguoi-dung/${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

Phương án D vẫn là lựa chọn đúng nhất trong bốn phương án có sẵn — nó là phương án duy nhất không nhúng khoá tĩnh. Nhưng với hệ thống thật thì đây là việc dựng lại bằng tay thứ đã có sẵn.

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

  • **C. Sinh credential dài hạn bằng STS rồi lưu trong ứng dụng — đây là phương án gần nhất và có nhắc tới STS, nhưng STS về bản chất chỉ cấp credential tạm; "long-term credentials using STS" mô tả một thứ không tồn tại.
  • **A. Tạo IAM user và nhúng access key vào ứng dụng — khoá tĩnh nằm trong ứng dụng phân phối công khai.
  • **B. Tạo IAM user, nhúng khoá, dựa vào bucket policy để phân quyền — vẫn là khoá tĩnh; bucket policy không cứu được việc khoá bị trích xuất.

Ghi nhớ

⚠ Ba API cấp credential tạm của STS — bảng phải thuộc: | API | Dùng khi | |---|---| | AssumeRole | giả nhận vai trò, xuyên tài khoản | | AssumeRoleWithWebIdentity | đăng nhập Google/Facebook/OIDC | | AssumeRoleWithSAML | liên kết doanh nghiệp | | GetFederationToken | identity broker tự dựng |

Từ khoá nhận diện:

"mobile app, millions of users" → Cognito "never embed credentials" → credential tạm từ STS "per-user data isolation" → policy phiên hoặc biến Cognito "corporate employees" → IAM Identity Center

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ờ | | | Đặt ngắn nhất mà trải nghiệm chịu được | | | Chuỗi giả nhận vai trò tối đa 1 giờ | |

Ba lưu ý về thu hồi: | Lưu ý | Chi tiết | |---|---| | Không thu hồi được từng token | | | Deny theo aws:TokenIssueTime để cắt hàng loạt | | | Hoặc chờ hết hạn tự nhiên | |

{"Effect": "Deny", "Action": "*", "Resource": "*",
 "Condition": {"DateLessThan":
   {"aws:TokenIssueTime": "2026-08-31T10:00:00Z"}}}

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 | | | Xác thực logic quan trọng ở phía máy chủ | | | Lưu token trong keychain, không trong tệp | |

⚠ Điều đầu tiên 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ề S3 cho ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Tải thẳng lên S3, không qua máy chủ | | | Pre-signed URL là lựa chọn khác | | | Giới hạn kích thước tệp trong điều kiện | |

Ba lưu ý về Cognito: | Lưu ý | Chi tiết | |---|---| | User pool: "anh là ai" | | | Identity pool: "anh làm được gì trên AWS" | | | Hỗ trợ đăng nhập mạng xã hội và SAML | |

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 được 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 + 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ì 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 134 Domain - Design Solutions for Organizational Complexity

A multinational software provider in the US hosts both of its development and test environments in the AWS cloud. The CTO decided to use separate AWS accounts in hosting each environment. The solutions architect has enabled Consolidated Billing to link each of the accounts' bill to a Master AWS account. To make sure that each account is kept within the budget, the administrators in the master account must have the power to stop, delete, and/or terminate resources in both development and test environment AWS accounts.

Which of the following options is the recommended action to meet the requirements for this scenario?

  1. A First, create IAM users in the master account. Then in the Dev and Test accounts, generate cross-account roles that have full admin permissions while granting access for the master account.
  2. B In the master account, you are to create IAM users and a cross-account role that has full admin permissions to the Dev and Test accounts.
  3. C By linking all accounts under Consolidated Billing, you will be able to provide IAM users in the master account access to Dev and Test account resources.
  4. D IAM users with full admin permissions will be created in the master account. In both Dev and Test accounts, generate cross-account roles that would grant the master account access to Dev and Test account resources through permissions inherited from the master account.
Xem giải thích

Đáp án

**A — Tạo IAM user ở tài khoản chính, và trong tài khoản Dev và Test tạo vai trò xuyên tài khoản có quyền quản trị đầy đủ, cấp quyền giả nhận cho tài khoản chính.

Vì sao đúng

Đề nêu đúng một yêu cầu, và phương án này diễn tả đúng cơ chế: | Yêu cầu | Cách đáp ứng | |---|---| | Quản trị viên ở tài khoản chính dừng/xoá tài nguyên ở Dev và Test | vai trò nằm Ở TÀI KHOẢN ĐÍCH, tin cậy tài khoản chính |

⚠ Quy tắc nền tảng: vai trò phải nằm ở tài khoản CHỨA TÀI NGUYÊN:

Muốn thao tác tài nguyên trong
  tài khoản Dev
        ↓
    Vai trò phải được tạo TRONG
      tài khoản Dev
    → và trust policy của nó nói
      "tôi tin tài khoản chính"
        ↓
    Tạo vai trò ở tài khoản chính
      là vô nghĩa — nó không có
      quyền gì ở Dev

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

⚠ Và Consolidated Billing KHÔNG cấp quyền gì:

Thanh toán gộp: một hoá đơn,
  chiết khấu dùng chung
        ↓
    KHÔNG tạo ra bất kỳ quyền truy cập
      nào giữa các tài khoản
    → đây là hiểu nhầm rất phổ biến

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

Vai trò trong tài khoản Dev:

{"Version": "2012-10-17", "Statement": [{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
  "Action": "sts:AssumeRole",
  "Condition": {"Bool":
    {"aws:MultiFactorAuthPresent": "true"}}}]}

⚠ :root ở đây KHÔNG có nghĩa là tài khoản gốc:

`arn:aws:iam::111122223333:root`
    → nghĩa là "bất kỳ principal nào
      TRONG tài khoản 111122223333
      được chính tài khoản đó cho phép"
        ↓
    Vẫn phải cấp quyền `sts:AssumeRole`
      cho IAM user ở phía tài khoản chính
    → cần CẢ HAI phía đồng ý

Chính sách phía tài khoản chính:

{"Effect": "Allow",
 "Action": "sts:AssumeRole",
 "Resource": [
   "arn:aws:iam::444455556666:role/QuanTriDev",
   "arn:aws:iam::777788889999:role/QuanTriTest"]}

Giả nhận:

aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/QuanTriDev \
  --role-session-name phien-don-dep \
  --serial-number arn:aws:iam::111122223333:mfa/quantri \
  --token-code 123456

⚠ Điều kiện MFA nên có với vai trò quyền quản trị:

Không có MFA: access key rò rỉ là đủ
  để xoá sạch tài nguyên ở hai tài khoản
        ↓
    Có MFA: thêm một yếu tố mà kẻ tấn công
      không lấy được từ mã nguồn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không phải tạo tài khoản riêng ở mỗi nơi | | | Credential tạm, hết hạn tự động | | | CloudTrail ở tài khoản đích ghi rõ ai thao tác | |

⚠ Nhưng SCP là công cụ tốt hơn cho việc kiểm soát ngân sách:

Đề nói mục tiêu là giữ chi phí trong hạn mức
        ↓
    Vai trò quản trị cho phép DỌN DẸP
      sau khi đã tốn tiền
        ↓
    SCP NGĂN việc tạo tài nguyên đắt
      ngay từ đầu
    → phòng hơn chữa

SCP chặn loại máy đắt:

{"Effect": "Deny", "Action": "ec2:RunInstances",
 "Resource": "arn:aws:ec2:*:*:instance/*",
 "Condition": {"ForAnyValue:StringNotLike":
   {"ec2:InstanceType": ["t3.*", "t4g.*", "m6g.medium"]}}}

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

  • **D. Tạo IAM user có quyền quản trị đầy đủ ở tài khoản chính, rồi ở Dev và Test tạo vai trò cấp quyền cho tài khoản chính "thông qua quyền kế thừa từ tài khoản chính" — đây là phương án gần nhất và phần tạo vai trò ở tài khoản đích là đúng, nhưng không có cơ chế "kế thừa quyền" nào giữa các tài khoản AWS; quyền được xác định bởi chính sách gắn vào vai trò ở tài khoản đích, không phải bởi quyền của người giả nhận.
  • **B. Tạo IAM user và vai trò xuyên tài khoản đều ở tài khoản chính — vai trò ở tài khoản chính không có quyền gì trên tài nguyên của Dev và Test.
  • **C. Dựa vào Consolidated Billing để cấp quyền — thanh toán gộp không tạo ra quyền truy cập nào.

Ghi nhớ

⚠ Ba thứ Organizations cho và không cho — bảng phải thuộc: | Tính năng | Cho gì | |---|---| | Consolidated Billing | một hoá đơn, chiết khấu dùng chung | | SCP | đặt TRẦN quyền, không cấp quyền | | Vai trò xuyên tài khoản | CẤP quyền truy cập |

Không có cái nào trong ba cái này
  tự động cho quản trị viên tài khoản
  chính quyền vào tài khoản con
        ↓
    Trừ vai trò `OrganizationAccountAccessRole`
      mà Organizations tạo sẵn khi
      TẠO tài khoản qua nó

⚠ Vai trò tạo sẵn này rất đáng biết:

Tài khoản tạo BẰNG Organizations
    → tự có `OrganizationAccountAccessRole`
      với quyền quản trị
        ↓
    Tài khoản MỜI vào tổ chức
    → KHÔNG có, phải tạo tay

Từ khoá nhận diện:

"admin in master must manage member accounts" → vai trò xuyên tài khoản ở tài khoản đích "prevent expensive resources" → SCP "single bill, shared discounts" → Consolidated Billing "central login for all accounts" → IAM Identity Center

⚠ IAM Identity Center là cách hiện đại hơn hẳn:

Tự dựng: mỗi tài khoản một vai trò,
  mỗi vai trò một trust policy
        ↓
    Identity Center: permission set
      định nghĩa một lần
    → gán cho nhóm ở tài khoản nào cần
    → và có cổng đăng nhập chung

Ba lưu ý về trust policy: | Lưu ý | Chi tiết | |---|---| | Principal là ARN tài khoản hoặc vai trò cụ thể | | | Thêm điều kiện MFA cho quyền cao | | | aws:PrincipalOrgID giới hạn trong tổ chức | |

{"Condition": {"StringEquals":
  {"aws:PrincipalOrgID": "o-abc123"}}}

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Cân nhắc vai trò chỉ dừng/xoá thay vì quản trị đủ | | | Giới hạn theo tag môi trường | | | Permission boundary chặn leo thang quyền | |

⚠ Vai trò hẹp cho đúng mục đích:

{"Effect": "Allow",
 "Action": ["ec2:StopInstances", "ec2:TerminateInstances",
            "rds:StopDBInstance", "rds:DeleteDBInstance"],
 "Resource": "*"}

Mục tiêu là dọn dẹp để giữ ngân sách
    → không cần quyền quản trị đầy đủ
    → giảm thiệt hại nếu credential rò rỉ

Ba lưu ý về kiểm soát chi phí: | Công cụ | Việc | |---|---| | AWS Budgets | cảnh báo và hành động khi vượt | | SCP | chặn tạo tài nguyên đắt | | Instance Scheduler | tự tắt máy ngoài giờ |

⚠ Budgets Actions tự động hoá việc chặn:

Vượt ngân sách
    → tự gắn chính sách Deny
      vào vai trò của đội
        ↓
    Không cần ai bấm nút lúc nửa đêm

Ba lưu ý về giám sát: | Lưu ý | Chi tiết | |---|---| | CloudTrail ở tài khoản đích ghi thao tác | | | sessionContext truy về người gốc | | | Cảnh báo khi vai trò quản trị được giả nhận | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Giả nhận vai trò và thử dừng một instance | | | Thử không có MFA — phải bị từ chối | | | Kiểm CloudTrail ở tài khoản Dev ghi đúng người | |

Và một lời khuyên: hãy đặt SCP chặn loại máy đắt song song với việc lập vai trò dọn dẹp. Quyền xoá tài nguyên chỉ giúp bạn sau khi tiền đã tiêu — còn một dòng SCP thì ngăn khoản chi đó phát sinh ngay từ đầu.

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

A company is building a new cryptocurrency trading platform that will be hosted on the AWS cloud. The solutions architect needs to set up the designed architecture in a single VPC. The solution should mitigate distributed denial-of-service (DDoS) attacks to secure the company’s applications and systems. The solution should also include a notification for incoming Layer 3 or Layer 4 attacks such as SYN floods and UDP reflection attacks. The system should also be protected against SQL injection, cross-site scripting, and other Layer 7 attacks.

Which of the following solutions should the solutions architect implement together to meet the above requirement? (Select TWO.)

  1. A

    Send network logs to Amazon Fraud Detector to detect DDoS attacks and send notifications to security teams.
  2. B

    Place your servers behind a CloudFront web distribution and improve your cache hit ratio.
  3. C

    Use AWS Shield Advanced which provides enhanced DDoS attack detection and monitoring for application-layer traffic to your AWS resources.
  4. D

    Use AWS WAF to define customizable web security rules that control which traffic can access your web applications.
  5. E

    Set up rule-based filtering using the AWS Network Firewall service.
Xem giải thích

Đáp án

**C và D — Dùng AWS Shield Advanced để phát hiện và theo dõi tấn công DDoS nâng cao; và dùng AWS WAF để định nghĩa luật bảo mật web kiểm soát lưu lượng vào ứng dụng.

Vì sao đúng

Đề nêu hai loại tấn công ở hai tầng khác nhau, và mỗi dịch vụ lo một tầng: | Tấn công | Tầng | Dịch vụ | |---|---|---| | SYN flood, UDP reflection | 3 và 4 | Shield Advanced | | SQL injection, XSS | 7 | WAF |

⚠ Và yêu cầu "thông báo khi có tấn công tầng 3/4" chỉ Shield Advanced đáp ứng: | Tiêu chí | Shield Standard | Shield Advanced | |---|---|---| | Chi phí | miễn phí, tự động | 3.000 USD/tháng | | Chống DDoS tầng 3/4 cơ bản | có | có | | THÔNG BÁO khi bị tấn công | KHÔNG | CÓ | | Đội ứng cứu (SRT) | không | có | | Bảo vệ chi phí khi co giãn do DDoS | không | có | | WAF đi kèm | không | có, không tính phí riêng |

Shield Standard bảo vệ ngầm cho mọi
  khách hàng AWS
    → nhưng bạn không biết mình
      đang bị tấn công
        ↓
    Đề đòi "notification for incoming
      Layer 3 or Layer 4 attacks"
    → bắt buộc Advanced

Bật bảo vệ:

aws shield create-protection \
  --name bao-ve-alb \
  --resource-arn <arn-alb>

aws shield associate-drt-role \
  --role-arn arn:aws:iam::111122223333:role/DRTRole

⚠ associate-drt-role cho phép đội SRT hành động thay bạn:

Đang bị tấn công lúc 3 giờ sáng
    → SRT của AWS phân tích và
      áp luật WAF giúp
        ↓
    Không có vai trò này: họ chỉ
      tư vấn qua ticket
    → cấp trước, đừng chờ tới lúc cần

Cảnh báo qua CloudWatch:

aws cloudwatch put-metric-alarm \
  --alarm-name canh-bao-ddos \
  --namespace AWS/DDoSProtection \
  --metric-name DDoSDetected \
  --statistic Maximum --period 60 --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --alarm-actions <arn-sns>

Luật WAF cho tầng 7:

aws wafv2 create-web-acl --name acl-ung-dung \
  --scope REGIONAL --default-action Allow={} \
  --rules '[
    {"Name":"ChanSQLi","Priority":1,
     "Statement":{"ManagedRuleGroupStatement":{
       "VendorName":"AWS","Name":"AWSManagedRulesSQLiRuleSet"}},
     "OverrideAction":{"None":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"sqli"}},
    {"Name":"GioiHanTanSuat","Priority":2,
     "Statement":{"RateBasedStatement":{
       "Limit":2000,"AggregateKeyType":"IP"}},
     "Action":{"Block":{}},
     "VisibilityConfig":{"SampledRequestsEnabled":true,
       "CloudWatchMetricsEnabled":true,"MetricName":"ratelimit"}}]'

⚠ Luật rate-based chống được tấn công tầng 7 mà chữ ký không bắt được:

HTTP flood: yêu cầu hoàn toàn hợp lệ
    → không có mẫu tấn công nào để khớp
        ↓
    Chỉ có thể chặn theo TẦN SUẤT
    → 2.000 yêu cầu trong 5 phút
      từ một IP là bất thường

Ba nhóm luật quản lý nên bật: | Nhóm | Chặn gì | |---|---| | AWSManagedRulesCommonRuleSet | OWASP phổ biến | | AWSManagedRulesSQLiRuleSet | SQL injection | | AWSManagedRulesKnownBadInputsRuleSet | payload đã biết là độc |

⚠ Luôn chạy ở chế độ Count trước:

"OverrideAction": {"Count": {}}

Bật Block ngay
    → luật quản lý chặn nhầm
      lưu lượng hợp lệ
        ↓
    Chạy Count vài ngày, xem log
    → rồi mới chuyển sang Block

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phủ cả tầng 3/4 lẫn tầng 7 | | | Có thông báo và có đội ứng cứu | | | Bảo vệ chi phí khi co giãn vì bị tấn công | |

⚠ Điểm cuối là lợi ích tài chính đáng kể:

DDoS làm ASG mở rộng tối đa
  và truyền dữ liệu tăng vọt
        ↓
    Shield Advanced hoàn lại phần
      chi phí phát sinh do tấn công
    → giảm rủi ro "hoá đơn tấn công"

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

  • **B. Đặt máy chủ sau CloudFront và cải thiện tỷ lệ trúng cache — đây là phương án gần nhất và CloudFront thật sự hấp thụ được nhiều lưu lượng DDoS, nhưng nó không phát hiện, không thông báo, và không chặn SQL injection hay XSS; đó là biện pháp hỗ trợ chứ không đáp ứng yêu cầu nào của đề.
  • **E. Dùng AWS Network Firewall lọc theo luật — Network Firewall lọc lưu lượng trong VPC ở tầng mạng; nó không phải công cụ chống DDoS từ Internet và không xử lý tấn công tầng 7 vào ứng dụng web.
  • **A. Gửi log mạng sang Amazon Fraud Detector — Fraud Detector phát hiện gian lận trong giao dịch (tài khoản giả, thanh toán gian lận), không liên quan tới DDoS.

Ghi nhớ

⚠ Bốn dịch vụ bảo vệ và tầng tương ứng — bảng phải thuộc: | Dịch vụ | Tầng | Chặn gì | |---|---|---| | Shield | 3, 4 | DDoS thể tích và giao thức | | WAF | 7 | SQLi, XSS, bot, flood HTTP | | Network Firewall | 3-7 trong VPC | lưu lượng đông-tây và ra ngoài | | Security group / NACL | 3, 4 | theo IP và cổng |

Từ khoá nhận diện:

"SYN flood, UDP reflection, notification" → Shield Advanced "SQL injection, XSS" → WAF "filter traffic between VPCs" → Network Firewall "fraudulent transactions" → Fraud Detector

⚠ Kiến trúc phòng thủ nhiều lớp:

Route 53 (chống DDoS ở tầng DNS)
    ↓
CloudFront (hấp thụ và phân tán)
    ↓
Shield Advanced (phát hiện, thông báo)
    ↓
WAF (lọc tầng 7)
    ↓
ALB → ASG (co giãn hấp thụ phần còn lại)

Ba lưu ý về Shield Advanced: | Lưu ý | Chi tiết | |---|---| | Cam kết 1 năm, 3.000 USD/tháng | | | Áp cho cả tổ chức nếu dùng Organizations | | | WAF không tính phí thêm khi có Advanced | |

Ba lưu ý về WAF: | Lưu ý | Chi tiết | |---|---| | Gắn được vào CloudFront, ALB, API Gateway, AppSync | | | Scope CLOUDFRONT phải tạo ở us-east-1 | | | Bật logging vào Firehose để điều tra | |

⚠ Bot Control là nhóm luật riêng đáng cân nhắc:

Bot cào dữ liệu, bot dò mật khẩu
    → trông như người dùng thật
        ↓
    AWSManagedRulesBotControlRuleSet
    → phân loại bot theo mục đích
    → tính phí riêng theo lượt

Ba lưu ý về thiết kế chống DDoS: | Lưu ý | Chi tiết | |---|---| | Giảm bề mặt: chỉ mở cổng cần thiết | | | Đặt origin sau CloudFront, chặn truy cập thẳng | | | Co giãn để hấp thụ, không chỉ để chặn | |

⚠ Chặn truy cập thẳng vào origin:

CloudFront lọc mọi thứ
    → nhưng ALB vẫn có DNS công khai
        ↓
    Kẻ tấn công tìm IP của ALB
      và bỏ qua CloudFront
        ↓
    Dùng header bí mật + WAF ở ALB
      chỉ cho qua yêu cầu có header đó

Ba lưu ý về Route 53: | Lưu ý | Chi tiết | |---|---| | Bản thân đã chống DDoS ở tầng DNS | | | Shield Advanced bảo vệ hosted zone | | | TTL hợp lý để chuyển đổi nhanh | |

Ba lưu ý về diễn tập: | Lưu ý | Chi tiết | |---|---| | AWS cho phép kiểm thử tải có thông báo trước | | | Kiểm thử thâm nhập một số dịch vụ được phép sẵn | | | Diễn tập quy trình ứng cứu, không chỉ công cụ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Gửi payload SQLi thử — WAF phải chặn | | | Xem chỉ số DDoSDetected và cảnh báo | | | Kiểm log WAF xem có chặn nhầm không | |

Và một lời khuyên: hãy cấp vai trò cho đội ứng cứu của AWS ngay khi bật Shield Advanced. Việc đó mất năm phút lúc bình thường, nhưng lúc đang bị tấn công thì mọi phút đều đắt — và không ai muốn dừng lại để làm giấy tờ uỷ quyền giữa cơn khủng hoảng.

Câu 136 Domain - Design for New Solutions

A company runs its internal tool on AWS. It is used for logistics and shipment tracking for the company’s warehouse. With the current system process, the application receives an order and it sends an email to the employees with the information needed for the package shipment. After the employees prepare the order and ship the package, they reply to the email so that the application can mark the order as shipped. The company wants to migrate to a serverless application model to stop relying on emails and minimize the operational overhead for the application.

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

  1. A

    Use an Amazon EFS volume to store the new order information. Configure an instance to pull the order information from the EFS share and print the shipping label for the package. Once the package is scanned and leaves the warehouse, remove the order information on the EFS share by using an Amazon API Gateway call to the instances.
  2. B

    Create AWS Batch jobs corresponding to different tasks needed to ship a package. Write an AWS Lambda function with AWS Batch as the trigger to create and print the shipping label for the package. Once the package is scanned and leaves the warehouse, trigger another Lambda function to move the AWS Batch job to the next stage of the shipping process.
  3. C

    Store the order information on an Amazon DynamoDB table. Create an AWS Step Functions workflow that will be triggered for every new order. Have the workflow mark the order as “in progress” and print the shipping label for the package. Once the package is scanned and leaves the warehouse, trigger an AWS Lambda function to mark the order as “shipped” and complete the Step Functions workflow.
  4. D

    Store order information on an Amazon SQS queue when a new order is created. Schedule an AWS Lambda function to poll the queue every 5 minutes and start processing if any orders are found. Use another Lambda function to print the shipping labels for the package. Once the package is scanned and leaves the warehouse, use Amazon Pinpoint to send a notification to customers regarding the status of their order.
Xem giải thích

Đáp án

**C — Lưu thông tin đơn hàng trong DynamoDB, tạo luồng Step Functions kích hoạt cho mỗi đơn mới; luồng đánh dấu đơn "đang xử lý" và in nhãn vận chuyển; khi kiện hàng rời kho thì một Lambda đánh dấu "đã gửi" và kết thúc luồng.

Vì sao đúng

Đề mô tả một quy trình nhiều bước có trạng thái chờ, và đó chính là bài toán Step Functions sinh ra để giải: | Đặc điểm quy trình | Step Functions cho | |---|---| | Nhiều bước theo thứ tự | máy trạng thái | | Có bước chờ sự kiện bên ngoài | waitForTaskToken | | Cần biết đơn đang ở bước nào | lịch sử thực thi hiện rõ | | Không máy chủ | hoàn toàn quản lý |

⚠ Bước "chờ nhân viên quét mã" là điểm mấu chốt:

Email cũ: gửi đi rồi CHỜ người trả lời
    → không biết đơn đang ở đâu
    → không biết đơn nào bị bỏ quên
        ↓
    Step Functions: luồng DỪNG ở một
      trạng thái chờ
    → nhìn vào là biết ngay đơn nào
      đang chờ ai

Máy trạng thái:

{"StartAt": "DanhDauDangXuLy",
 "States": {
   "DanhDauDangXuLy": {
     "Type": "Task",
     "Resource": "arn:aws:states:::dynamodb:updateItem",
     "Parameters": {
       "TableName": "DonHang",
       "Key": {"idDonHang": {"S.$": "$.idDonHang"}},
       "UpdateExpression": "SET trangThai = :t",
       "ExpressionAttributeValues": {":t": {"S": "dang-xu-ly"}}},
     "Next": "InNhanVanChuyen"},
   "InNhanVanChuyen": {
     "Type": "Task",
     "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
     "Parameters": {
       "FunctionName": "in-nhan",
       "Payload": {"idDonHang.$": "$.idDonHang",
                   "taskToken.$": "$$.Task.Token"}},
     "TimeoutSeconds": 86400,
     "Next": "DanhDauDaGui"},
   "DanhDauDaGui": {
     "Type": "Task",
     "Resource": "arn:aws:states:::dynamodb:updateItem",
     "Parameters": {"...": "..."},
     "End": true}}}

⚠ waitForTaskToken là cơ chế chờ con người:

Luồng dừng lại và giữ token
    → có thể chờ tới MỘT NĂM
        ↓
    Nhân viên quét mã vạch
    → hệ thống gọi `SendTaskSuccess`
      kèm token
        ↓
    Luồng chạy tiếp

import boto3
sfn = boto3.client('stepfunctions')
sfn.send_task_success(
    taskToken=token,
    output='{"trangThai": "da-gui"}')

⚠ Và TimeoutSeconds là thứ giải quyết vấn đề gốc của email:

Đơn hàng bị bỏ quên
    → hết timeout
    → chuyển sang trạng thái cảnh báo
        ↓
    Với email thì đơn bị quên
      nằm im mãi mãi

Kích hoạt từ DynamoDB Streams:

aws lambda create-event-source-mapping \
  --function-name khoi-dong-luong \
  --event-source-arn <arn-stream-dynamodb> \
  --starting-position LATEST

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Nhìn được đơn nào đang ở bước nào | | | Tự phát hiện đơn bị bỏ quên | | | Không có máy chủ nào phải vận hành | |

⚠ Chọn đúng loại workflow: | Loại | Thời gian tối đa | Chọn khi | |---|---|---| | Standard | 1 năm | có bước chờ người, cần lịch sử đầy đủ | | Express | 5 phút | thông lượng rất cao, chạy nhanh |

Quy trình chờ nhân viên đóng gói
    → phải là Standard
    → Express hết hạn sau 5 phút

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

  • **B. Tạo AWS Batch job cho từng công việc, Lambda kích hoạt bởi Batch để in nhãn, rồi Lambda khác chuyển job sang giai đoạn tiếp theo — đây là phương án gần nhất và cũng là điều phối nhiều bước, nhưng AWS Batch dành cho tính toán theo lô (mô phỏng, xử lý dữ liệu), không phải quy trình nghiệp vụ có bước chờ người; và "chuyển job sang giai đoạn tiếp" không phải cách Batch hoạt động.
  • **D. Đưa đơn vào SQS và Lambda poll mỗi 5 phút, dùng Pinpoint thông báo cho khách — polling theo lịch là quay lại đúng vấn đề của email: không biết đơn đang ở đâu; và thông báo cho khách hàng không phải yêu cầu của đề.
  • **A. Dùng EFS lưu đơn hàng và instance kéo thông tin từ đó — quay lại mô hình có máy chủ, dùng hệ thống tệp làm hàng đợi, và trái với mục tiêu "không máy chủ, ít vận hành".

Ghi nhớ

⚠ Bốn công cụ điều phối — bảng phải thuộc: | Công cụ | Dùng khi | |---|---| | Step Functions | quy trình nhiều bước có trạng thái | | EventBridge | định tuyến sự kiện theo luật | | SQS | hàng đợi việc, xử lý bất đồng bộ | | AWS Batch | tính toán theo lô, hàng nghìn job |

Từ khoá nhận diện:

"multi-step workflow with human approval" → Step Functions + waitForTaskToken "replace email-based process" → máy trạng thái có theo dõi "high volume batch compute" → AWS Batch "route events by pattern" → EventBridge

Ba lưu ý về Step Functions: | Lưu ý | Chi tiết | |---|---| | Tích hợp trực tiếp hơn 200 dịch vụ AWS | | | Không cần Lambda cho thao tác đơn giản | | | Lịch sử thực thi là công cụ gỡ lỗi tốt nhất | |

⚠ Tích hợp trực tiếp bỏ được rất nhiều Lambda:

Trước: Lambda chỉ để gọi
  `dynamodb:UpdateItem`
        ↓
    Nay: `arn:aws:states:::dynamodb:updateItem`
    → không có hàm nào để viết,
      kiểm thử và bảo trì

Ba lưu ý về xử lý lỗi: | Cơ chế | Việc | |---|---| | Retry | thử lại với backoff | | Catch | chuyển sang nhánh xử lý lỗi | | TimeoutSeconds | không treo mãi |

{"Retry": [{"ErrorEquals": ["States.TaskFailed"],
            "IntervalSeconds": 2, "MaxAttempts": 3,
            "BackoffRate": 2.0}],
 "Catch": [{"ErrorEquals": ["States.ALL"],
            "Next": "XuLyLoi"}]}

Ba lưu ý về DynamoDB cho đơn hàng: | Lưu ý | Chi tiết | |---|---| | Khoá chính là id đơn hàng | | | GSI theo trạng thái để tìm đơn đang chờ | | | Streams kích hoạt luồng khi có đơn mới | |

⚠ GSI thưa cho việc tìm đơn đang chờ:

Chỉ ghi thuộc tính `dangCho` khi
  đơn ở trạng thái chờ
        ↓
    GSI trên thuộc tính đó chỉ chứa
      các đơn đang chờ
    → truy vấn rất nhỏ và rất nhanh

Ba lưu ý về giám sát: | Chỉ số | Ý nghĩa | |---|---| | ExecutionsFailed | luồng lỗi | | ExecutionsTimedOut | đơn bị bỏ quên | | ExecutionTime | quy trình chậm dần |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Standard tính theo bước chuyển trạng thái | | | Express tính theo thời gian chạy | | | Bước chờ không tính phí trong lúc chờ | |

⚠ Điểm cuối rất quan trọng với quy trình chờ người:

Luồng chờ 8 tiếng để nhân viên quét mã
    → KHÔNG tính tiền trong 8 tiếng đó
        ↓
    Chỉ tính các bước chuyển trạng thái
    → quy trình dài không đồng nghĩa
      với hoá đơn lớn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tạo đơn thử, xem luồng dừng đúng chỗ | | | Để một đơn quá hạn, xem có cảnh báo | | | Xem sơ đồ trực quan của một lần chạy | |

Và một lời khuyên: hãy đặt TimeoutSeconds cho mọi bước chờ con người. Không có nó, quy trình mới chỉ khác quy trình email ở chỗ nó đẹp hơn — đơn hàng bị bỏ quên vẫn nằm im, chỉ là nằm im trong một máy trạng thái thay vì trong hộp thư.

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

An online stock trading application is deployed to multiple Availability Zones in the us-east-1 region (N. Virginia) and uses RDS to host the database. Considering the massive financial transactions that the trading application handles, the company has hired you to be a consultant to make sure that the system is scalable, highly-available, and disaster resilient. In the event of failure, the Recovery Time Objective (RTO) must be less than 2 hours and the Recovery Point Objective (RPO) must be 10 minutes to meet the compliance requirements set by the regulators.

In this scenario, which Disaster Recovery strategy can be used to achieve the RTO and RPO requirements in the event of system failure? (Select TWO.)

  1. A

    Take 15-minute database backups stored in Glacier with transaction logs stored in S3 every 5 minutes.
  2. B

    Take hourly database backups and export to an S3 bucket with transaction logs stored in S3 every 5 minutes. Set up a Cross-Region Replication (CRR) to another AWS Region.
  3. C

    Set up an AWS Backup plan for the Amazon RDS database with the continuous backups for point-in-time recovery (PITR) option enabled
  4. D

    Configure your database to use synchronous “source-replica” replication between multiple Availability Zones.
  5. E

    Store hourly database backups to an EC2 instance store volume with transaction logs stored in an S3 bucket every 5 minutes.
Xem giải thích

Đáp án

**B và C — Sao lưu CSDL hằng giờ và xuất sang bucket S3 kèm transaction log mỗi 5 phút, bật Cross-Region Replication sang Region khác; và lập AWS Backup plan cho RDS với point-in-time recovery liên tục.

Vì sao đúng

Đề cho hai con số, và mọi phương án phải kiểm chứng theo chúng: | Chỉ tiêu | Yêu cầu | Cách đáp ứng | |---|---|---| | RPO | 10 phút | transaction log mỗi 5 phút, hoặc PITR liên tục | | RTO | dưới 2 giờ | khôi phục từ S3 hoặc AWS Backup |

⚠ Phương án B: RPO 5 phút, thấp hơn yêu cầu 10 phút:

Sự cố lúc 14:47
    → backup 14:00 + log tới 14:45
        ↓
    Mất nhiều nhất 5 phút dữ liệu
    → đạt RPO 10 phút với biên an toàn

⚠ Và Cross-Region Replication là phần khiến nó thành DR thật:

Sao lưu nằm cùng Region với CSDL
    → mất Region là mất cả bản sao lưu
        ↓
    CRR đẩy sang Region khác
    → đây mới là khôi phục sau thảm hoạ

Bật CRR:

aws s3api put-bucket-replication --bucket sao-luu-csdl \
  --replication-configuration '{"Role":"<arn>","Rules":[{
    "Status":"Enabled","Priority":1,"Filter":{},
    "DeleteMarkerReplication":{"Status":"Disabled"},
    "Destination":{"Bucket":"arn:aws:s3:::sao-luu-csdl-dr",
                   "StorageClass":"STANDARD_IA"}}]}'

⚠ Phương án C: PITR liên tục cho RPO còn tốt hơn:

AWS Backup với continuous backup
    → khôi phục tới bất kỳ GIÂY nào
      trong khoảng giữ
        ↓
    RPO gần bằng 0
    → vượt xa yêu cầu 10 phút

Lập backup plan:

aws backup create-backup-plan --backup-plan '{
  "BackupPlanName": "ke-hoach-giao-dich",
  "Rules": [{
    "RuleName": "hang-ngay-co-pitr",
    "TargetBackupVaultName": "kho-chinh",
    "ScheduleExpression": "cron(0 5 ? * * *)",
    "EnableContinuousBackup": true,
    "Lifecycle": {"DeleteAfterDays": 35},
    "CopyActions": [{
      "DestinationBackupVaultArn": "<arn-kho-region-khac>",
      "Lifecycle": {"DeleteAfterDays": 90}}]}]}'

⚠ CopyActions là phần bảo vệ khỏi mất Region:

Kho sao lưu nằm cùng Region
    → mất Region là mất luôn
        ↓
    Sao chép sang kho ở Region khác
    → và AWS Backup làm tự động

⚠ Và Vault Lock chống xoá — quan trọng với hệ thống tài chính:

aws backup put-backup-vault-lock-configuration \
  --backup-vault-name kho-chinh \
  --min-retention-days 30 --max-retention-days 365 \
  --changeable-for-days 3

Chế độ compliance: sau 3 ngày
  KHÔNG ai gỡ được, kể cả root
        ↓
    Ransomware xoá sạch tài nguyên
    → bản sao lưu vẫn còn

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO tốt hơn yêu cầu ở cả hai phương án | | | Bản sao nằm ở Region khác | | | Chi phí thấp hơn nhiều so với hạ tầng dự phòng | |

⚠ Vì sao Multi-AZ trong phương án D không đáp ứng đề:

Multi-AZ: nhân bản đồng bộ giữa hai AZ
    → chống hỏng instance và hỏng AZ
        ↓
    KHÔNG chống được mất cả Region
    → và đề nói "disaster resilient",
      tức là kịch bản thảm hoạ

⚠ Multi-AZ cũng KHÔNG chống được xoá nhầm:

`DROP TABLE` trên instance chính
    → nhân bản đồng bộ ngay sang
      bản dự phòng
        ↓
    Cả hai đều mất bảng
    → chỉ sao lưu và PITR cứu được

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

  • **D. Cấu hình CSDL dùng nhân bản đồng bộ giữa các AZ — đây là phương án gần nhất và Multi-AZ là thực hành đúng cho sẵn sàng cao, nhưng nó không phải chiến lược DR: không chống được mất Region và không chống được lỗi logic như xoá nhầm dữ liệu.
  • **A. Sao lưu mỗi 15 phút vào Glacier với transaction log vào S3 mỗi 5 phút — Glacier Flexible Retrieval mất 3-5 giờ với chế độ Standard, riêng thời gian lấy dữ liệu đã vượt RTO 2 giờ.
  • **E. Lưu bản sao lưu hằng giờ vào instance store volume — instance store là ổ đĩa tạm: dừng máy hoặc máy hỏng là mất sạch dữ liệu; đây là nơi tệ nhất có thể chọn để đặt bản sao lưu.

Ghi nhớ

⚠ Instance store là bẫy phải nhớ: | Loại lưu trữ | Sống sót khi | |---|---| | Instance store | reboot — MẤT khi stop hoặc hỏng máy | | EBS | stop, terminate (nếu không xoá) | | S3 | mọi thứ ở mức instance |

⚠ Bốn chiến lược DR và RPO/RTO — bảng phải thuộc: | Chiến lược | RTO | RPO | |---|---|---| | Backup & Restore | giờ | theo tần suất sao lưu | | Pilot Light | chục phút | phút | | Warm Standby | phút | giây | | Multi-Site | gần 0 | gần 0 |

RTO 2 giờ, RPO 10 phút
    → Backup & Restore là đủ
    → và rẻ nhất

Từ khoá nhận diện:

"RPO minutes, RTO hours" → sao lưu + transaction log "survive Region failure" → sao chép xuyên Region "recover from accidental deletion" → PITR "survive AZ failure" → Multi-AZ

Ba lưu ý về PITR của RDS: | Lưu ý | Chi tiết | |---|---| | Transaction log ghi mỗi 5 phút | | | Khôi phục tới bất kỳ giây nào trong khoảng giữ | | | Chỉ trong CÙNG Region | |

⚠ Sao lưu tự động xuyên Region:

aws rds start-db-instance-automated-backups-replication \
  --source-db-instance-arn <arn> \
  --backup-retention-period 14 --region us-west-2

PITR ở Region khác
    → đây là thứ biến sao lưu
      thành chiến lược DR thật

Ba lưu ý về AWS Backup: | Lưu ý | Chi tiết | |---|---| | Quản lý sao lưu tập trung nhiều dịch vụ | | | Backup plan gán theo tag | | | Vault Lock chống xoá | |

Ba lưu ý về Glacier: | Lớp | Thời gian lấy | |---|---| | Instant Retrieval | mili giây | | Flexible Retrieval | 1 phút tới 12 giờ | | Deep Archive | 12-48 giờ |

⚠ Chọn lớp phải xuất phát từ RTO:

RTO 2 giờ
    → Glacier Flexible Standard (3-5 giờ)
      đã vượt
        ↓
    Chỉ Instant Retrieval hoặc
      S3 Standard/IA dùng được

Ba lưu ý về kiểm thử: | Lưu ý | Chi tiết | |---|---| | Khôi phục thử định kỳ và bấm giờ | | | Kiểm tra dữ liệu sau khi khôi phục | | | Kiểm hạn ngạch ở Region dự phòng | |

⚠ Sao lưu chưa từng khôi phục là sao lưu chưa chắc dùng được:

Job báo thành công hai năm liền
    → chưa ai thử khôi phục
        ↓
    Ngày cần đến mới biết thiếu
      archive log hay sai định dạng

Ba lưu ý về tuân thủ: | Lưu ý | Chi tiết | |---|---| | Ghi lại thời gian khôi phục thực đo | | | Chứng minh bản sao lưu không sửa được | | | Mã hoá bản sao lưu bằng KMS | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khôi phục tới một mốc thời gian bất kỳ | | | Đo tổng thời gian khôi phục thật | | | Kiểm bản sao đã có ở Region kia | |

Và một lời khuyên: hãy kiểm chứng RTO bằng một lần khôi phục thật thay vì tin vào con số trong tài liệu. Với hệ thống chịu quy định, con số bạn báo cáo cho cơ quan quản lý nên là con số bạn đã bấm giờ — chứ không phải con số bạn hy vọng.

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

A leading call center company has its headquarters in Seattle. Its corporate web portal is deployed to AWS. The AWS cloud resources are linked to its corporate data center via a link aggregation group (LAG), which terminates at the same AWS Direct Connect endpoint and is connected on a private virtual interface (VIF) in your VPC. The portal must authenticate against their on-premises LDAP server. Each Amazon S3 bucket can only be accessed by a logged-in user if it belongs to that user.

Which of the following options should the solutions architect implement in AWS to meet the company requirements? (Select TWO.)

  1. A

    Use a Direct Connect Gateway instead of a single Direct Connect connection. Set up a Transit VPC which will authenticate against their on-premises LDAP server.
  2. B The application first authenticates against LDAP, and then uses the LDAP credentials to log in to IAM service. Finally, it can now use the IAM temporary credentials to access the appropriate S3 bucket.
  3. C

    Authenticate against LDAP using an identity broker you created, and have it call IAM Security Token Service (STS) to retrieve IAM federated user credentials. The application then gets the IAM federated user credentials from the identity broker to access the appropriate S3 bucket.
  4. D Create an identity broker that assumes an IAM role, and retrieve temporary AWS security credentials via IAM Security Token Service (STS). The application gets the AWS temporary security credentials from the identity broker to gain access to the appropriate S3 bucket.
  5. E

    The application first authenticates against LDAP to retrieve the name of an IAM role associated with the user. It then assumes that role via a call to IAM Security Token Service (STS). Afterward, the application can now use the temporary credentials from the role to access the appropriate S3 bucket.
Xem giải thích

Đáp án

**C và E — Xác thực với LDAP qua một identity broker tự dựng, broker gọi STS lấy credential liên kết rồi trả cho ứng dụng; hoặc ứng dụng xác thực với LDAP để lấy tên vai trò IAM, rồi gọi AssumeRole và dùng credential tạm đó truy cập bucket tương ứng.

Vì sao đúng

Đề nêu hai yêu cầu, và cả hai phương án đều thoả: | Yêu cầu | Cách đáp ứng | |---|---| | Xác thực với LDAP tại chỗ | broker hoặc ứng dụng hỏi LDAP | | Mỗi người chỉ vào bucket của mình | credential tạm có phạm vi hẹp |

⚠ Điểm chung: LDAP xác thực, STS cấp quyền:

LDAP: "anh là ai" — nguồn danh tính
    → nhưng LDAP không biết gì về AWS
        ↓
    STS: "đây là credential tạm"
    → cầu nối giữa hai thế giới

Cách của phương án E — dùng AssumeRole:

import boto3, ldap3

def dang_nhap(ten, mat_khau):
    ket_noi = ldap3.Connection('ldap://ldap.congty.com',
                               user=ten, password=mat_khau,
                               auto_bind=True)
    ket_noi.search('ou=NhanVien,dc=congty,dc=com',
                   f'(uid={ten})', attributes=['awsRole'])
    ten_vai_tro = ket_noi.entries[0].awsRole.value

    sts = boto3.client('sts')
    return sts.assume_role(
        RoleArn=f'arn:aws:iam::111122223333:role/{ten_vai_tro}',
        RoleSessionName=ten,
        DurationSeconds=3600)['Credentials']

⚠ Thuộc tính awsRole trong LDAP là nơi lưu ánh xạ:

Quản trị viên đặt vai trò AWS
  ngay trong bản ghi LDAP
        ↓
    Đổi vai trò của một người
    → sửa ở LDAP, không đụng vào AWS

Cách của phương án C — dùng GetFederationToken:

sts = boto3.client('sts')
chinh_sach = {"Version": "2012-10-17", "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
    "Resource": [f"arn:aws:s3:::bucket-{ten}",
                 f"arn:aws:s3:::bucket-{ten}/*"]}]}

ket_qua = sts.get_federation_token(
    Name=ten, Policy=json.dumps(chinh_sach),
    DurationSeconds=43200)

⚠ AssumeRole và GetFederationToken — bảng phải thuộc: | Tiêu chí | AssumeRole | GetFederationToken | |---|---|---| | Trả về | credential của một VAI TRÒ | credential của USER liên kết | | Thời hạn tối đa | 12 giờ | 36 giờ | | Người gọi phải là | bất kỳ principal nào được tin | IAM user (không phải vai trò) | | Quyền hiệu lực | chính sách vai trò ∩ chính sách phiên | chính sách user ∩ chính sách truyền vào |

Cả hai đều là mẫu identity broker hợp lệ
    → `AssumeRole` phổ biến hơn ngày nay
    → `GetFederationToken` là cách cũ
      nhưng vẫn đúng

Trust policy cho broker:

{"Effect": "Allow",
 "Principal": {"AWS":
   "arn:aws:iam::111122223333:role/IdentityBroker"},
 "Action": "sts:AssumeRole"}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không tạo IAM user cho từng nhân viên | | | Credential tạm, tự hết hạn | | | Nghỉ việc: khoá ở LDAP là mất quyền ngay | |

⚠ Nhưng phải bảo vệ chính broker:

Broker có quyền cấp credential
  cho mọi người dùng
        ↓
    Chiếm được broker = chiếm được
      quyền của tất cả
        ↓
    Đặt trong subnet riêng, ghi log
      mọi lời gọi, giới hạn tần suất

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

⚠ Phương án D mô tả gần như đúng cùng một cơ chế với C và E, nhưng bị chấm sai.

Đọc kỹ ba phương án: | Phương án | Nội dung | |---|---| | C | broker xác thực LDAP → gọi STS → trả credential liên kết | | D | broker giả nhận vai trò → lấy credential tạm qua STS → ứng dụng dùng | | E | ứng dụng hỏi LDAP lấy tên vai trò → tự AssumeRole |

D thiếu bước "xác thực với LDAP"
    → chỉ nói broker giả nhận vai trò
        ↓
    Đây có lẽ là lý do bị chấm sai
    → nhưng khác biệt rất mỏng

Khác biệt thật giữa D và C/E chỉ là D không nêu bước xác thực với LDAP — trong khi đề yêu cầu rõ "phải xác thực với máy chủ LDAP tại chỗ". Đó là lập luận chấp nhận được, nhưng ba phương án gần nhau đến mức này thì đề đang kiểm tra khả năng đọc hiểu chi tiết hơn là kiến thức kiến trúc.

Và về mặt thiết kế hiện nay, cả ba đều là cách cũ:

Dựng identity broker thủ công
    ↓
IAM Identity Center nối thẳng LDAP/AD
    → có cổng đăng nhập, permission set
    → không phải viết và vận hành
      broker nào

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

  • **D. Tạo identity broker giả nhận vai trò IAM và lấy credential tạm qua STS — xem phần chất lượng câu hỏi ở trên; nó thiếu bước xác thực với LDAP mà đề yêu cầu rõ.
  • **B. Ứng dụng xác thực với LDAP rồi dùng chính credential LDAP để đăng nhập dịch vụ IAM — IAM không nhận credential LDAP; không có luồng nào như vậy.
  • **A. Dùng Direct Connect Gateway và Transit VPC để "xác thực với LDAP" — đây là thành phần mạng, nó không liên quan gì tới xác thực hay phân quyền.

Ghi nhớ

⚠ Ba cách liên kết danh tính doanh nghiệp — bảng phải thuộc: | Cách | Ghi chú | |---|---| | IAM Identity Center | hiện đại nhất, ít việc nhất | | SAML federation | chuẩn, cần IdP hỗ trợ SAML | | Identity broker tự dựng | khi nguồn danh tính không nói SAML (LDAP thuần) |

⚠ LDAP thuần không phải SAML — đây là lý do broker tồn tại:

LDAP: giao thức thư mục, không có
  khái niệm assertion đã ký
        ↓
    Không dùng được `AssumeRoleWithSAML`
    → phải có broker đứng giữa

Từ khoá nhận diện:

"authenticate against LDAP" → identity broker + STS "SAML 2.0 IdP" → AssumeRoleWithSAML "Google/Facebook login" → AssumeRoleWithWebIdentity hoặc Cognito "manage many accounts" → IAM Identity Center

Ba lưu ý về identity broker: | Lưu ý | Chi tiết | |---|---| | Chạy ở nơi tới được LDAP | | | Vai trò của broker phải hẹp | | | Ghi log mọi lần cấp credential | |

Ba lưu ý về phạm vi theo người dùng: | Cách | Chi tiết | |---|---| | Một vai trò mỗi người | không co giãn | | Chính sách phiên truyền vào | linh hoạt | | Thẻ phiên + ABAC | một chính sách cho mọi người |

⚠ ABAC là cách gọn nhất:

sts.assume_role(
    RoleArn='...:role/NhanVien',
    RoleSessionName=ten,
    Tags=[{'Key': 'MaNhanVien', 'Value': ma}])

{"Effect": "Allow", "Action": "s3:*",
 "Resource": "arn:aws:s3:::bucket-${aws:PrincipalTag/MaNhanVien}/*"}

MỘT vai trò, MỘT chính sách
    → phục vụ hàng nghìn người dùng

Ba lưu ý về thời hạn: | Lưu ý | Chi tiết | |---|---| | AssumeRole tối đa 12 giờ | | | GetFederationToken tối đa 36 giờ | | | Đặt ngắn nhất mà quy trình chịu được | |

Ba lưu ý về kết nối tới LDAP: | Lưu ý | Chi tiết | |---|---| | Cần Direct Connect hoặc VPN | | | Dùng LDAPS, không dùng LDAP thuần | | | LDAP tại chỗ sập là không ai đăng nhập được | |

⚠ Điểm cuối là rủi ro phụ thuộc phải cân nhắc:

Mọi quyền truy cập AWS phụ thuộc
  vào LDAP tại chỗ
        ↓
    LDAP hoặc đường mạng sập
    → không ai vào AWS được
        ↓
    Giữ một đường vào khẩn cấp
      không phụ thuộc LDAP

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập và thử bucket của người khác — phải bị từ chối | | | Khoá tài khoản LDAP, thử lại — phải bị từ chối | | | Kiểm CloudTrail ghi đúng RoleSessionName | |

Và một lời khuyên: hãy luôn đặt RoleSessionName bằng định danh người dùng thật. Đó là thứ duy nhất trong CloudTrail cho phép truy một thao tác về đúng một con người — thiếu nó, mọi hoạt động của cả tổ chức đều trông giống nhau.

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

A global enterprise web application is using a private S3 bucket, named MANILATECH-CONFIG, which has Server-Side Encryption with Amazon S3-Managed Encryption Keys (SSE-S3) to store its configuration files for different regions in North America, Latin America, Europe, and Asia. There has been a lot of database changes and feature toggle switching for the past few weeks. Your CTO assigned you the task of enabling versioning on this bucket to track any changes made to the configuration files and have the ability to use the old settings if needed. In the coming days ahead, a new region in Oceania will be supported by the web application and thus, a new configuration file will be added soon. Currently, there are already four files in the bucket, namely: MNL-NA.config, MNL-LA.config, MNL-EUR.config, and MNL-ASIA.config which are updated regularly. As instructed, you enabled the versioning in the bucket and after a few days, the new MNL-O.config configuration file for the Oceania region has been uploaded. A week after, a configuration has been done on MNL-NA.config, MNL-LA.config, and MNL-O.config files.

In this scenario, which of the following is correct about files inside the MANILATECH-CONFIG S3 bucket? (Select TWO.)

  1. A

    The first Version ID of MNL-NA.config and MNL-LA.config has a value of 1.
  2. B The MNL-EUR.config and MNL-ASIA.config files will have a Version ID of null.
  3. C

    There would be two available versions for each of the MNL-NA.config, MNL-LA.config, and MNL-O.config files. The first Version ID of MNL-NA.config and MNL-LA.config has a value of null.
  4. D The MNL-EUR.config and MNL-ASIA.config files will have a Version ID of 1.
  5. E The latest Version ID of MNL-NA.config and MNL-LA.config has a value of null.
Xem giải thích

Đáp án

**B và C — Hai tệp MNL-EUR.config và MNL-ASIA.config sẽ có Version ID là null; và ba tệp MNL-NA.config, MNL-LA.config, MNL-O.config mỗi tệp có hai phiên bản, trong đó phiên bản đầu của MNL-NA và MNL-LA có Version ID là null.

Vì sao đúng

Quy tắc quyết định chỉ có một, nhưng phải áp đúng theo dòng thời gian:

Object có TRƯỚC khi bật versioning
    → giữ Version ID = "null"
        ↓
    Object ghi SAU khi bật versioning
    → nhận Version ID ngẫu nhiên
      (chuỗi dài, không phải số)

Dòng thời gian trong đề:

Ban đầu: 4 tệp (NA, LA, EUR, ASIA)
    → chưa bật versioning
        ↓
BẬT VERSIONING
    → 4 tệp cũ mang Version ID = null
        ↓
Tải lên MNL-O.config (mới)
    → nhận Version ID thật
        ↓
Cập nhật NA, LA, O
    → mỗi tệp thêm một phiên bản mới

Kết quả từng tệp: | Tệp | Số phiên bản | Version ID | |---|---|---| | MNL-NA.config | 2 | null + một ID thật | | MNL-LA.config | 2 | null + một ID thật | | MNL-EUR.config | 1 | chỉ null | | MNL-ASIA.config | 1 | chỉ null | | MNL-O.config | 2 | hai ID thật (chưa bao giờ có null) |

⚠ Chú ý sự khác biệt của MNL-O:

Tệp này tải lên SAU khi bật versioning
    → không có phiên bản `null` nào
        ↓
    Nó vẫn có hai phiên bản
    → nhưng cả hai đều có ID thật

Đây là lý do phương án C chỉ nói phiên bản đầu của NA và LA là null, không nói về O — và câu đó đúng.

⚠ Version ID KHÔNG BAO GIỜ là số đếm:

Không phải 1, 2, 3
    → là chuỗi kiểu
      `3sL4kqtJlcpXroDTDmJ.rmSpXd3dIbrHY`
        ↓
    Đây là lý do phương án A và D sai

Kiểm chứng bằng lệnh:

aws s3api list-object-versions --bucket MANILATECH-CONFIG \
  --query 'Versions[].[Key,VersionId,IsLatest,LastModified]' \
  --output table

⚠ Và phiên bản null chỉ có tối đa MỘT cho mỗi khoá:

Ghi đè object có phiên bản `null`
    → phiên bản `null` VẪN GIỮ NGUYÊN
      như một phiên bản cũ
    → bản ghi mới nhận ID thật
        ↓
    Nhưng nếu TẠM DỪNG versioning
      rồi ghi tiếp
    → phiên bản `null` cũ bị GHI ĐÈ

Ba trạng thái versioning — bảng phải thuộc: | Trạng thái | Hành vi | |---|---| | Unversioned | mặc định, ghi đè mất bản cũ | | Enabled | mọi bản ghi tạo phiên bản mới | | Suspended | bản ghi mới mang ID null và GHI ĐÈ bản null cũ |

⚠ Không bao giờ quay lại được trạng thái Unversioned:

Đã bật versioning
    → chỉ tạm dừng được, không tắt hẳn
        ↓
    Các phiên bản cũ vẫn nằm đó
      và vẫn tính tiền
    → phải dùng lifecycle rule để dọn

Ba lợi ích của versioning: | Lợi ích | Chi tiết | |---|---| | Khôi phục bản cũ khi cấu hình sai | | | Chống ghi đè và xoá nhầm | | | Là điều kiện cho CRR và Object Lock | |

Khôi phục một phiên bản cũ:

aws s3api copy-object --bucket MANILATECH-CONFIG \
  --key MNL-NA.config \
  --copy-source "MANILATECH-CONFIG/MNL-NA.config?versionId=<id-cu>"

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

  • **E. Phiên bản MỚI NHẤT của MNL-NA và MNL-LA có Version ID là null — đây là phương án gần nhất và đúng rằng hai tệp đó có phiên bản null, nhưng ngược thứ tự: null là phiên bản ĐẦU TIÊN (có trước khi bật versioning), còn phiên bản mới nhất mang ID thật.
  • **A. Version ID đầu tiên của MNL-NA và MNL-LA có giá trị 1 — Version ID không bao giờ là số đếm.
  • **D. MNL-EUR và MNL-ASIA có Version ID là 1 — cùng lỗi trên; chúng mang null.

Ghi nhớ

⚠ Bốn quy tắc versioning phải thuộc:

1. Object có TRƯỚC khi bật → ID = null
2. Object ghi SAU khi bật → ID ngẫu nhiên
3. Xoá không xoá thật → tạo delete marker
4. Tạm dừng: bản ghi mới mang null
   và ĐÈ bản null cũ

⚠ Delete marker là cơ chế phải hiểu:

`aws s3 rm s3://bucket/tep.txt`
    → KHÔNG xoá dữ liệu
    → tạo một "delete marker" làm
      phiên bản mới nhất
        ↓
    GET trả 404
    → nhưng dữ liệu vẫn còn
    → xoá delete marker là khôi phục

aws s3api delete-object --bucket MANILATECH-CONFIG \
  --key MNL-NA.config --version-id <id-cua-delete-marker>

Từ khoá nhận diện:

"objects before versioning was enabled" → Version ID null "deleted but recoverable" → delete marker "permanently delete" → xoá theo version-id cụ thể "prevent deletion entirely" → Object Lock

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | MỌI phiên bản đều tính tiền | | | Lifecycle rule dọn phiên bản cũ | | | Bucket không dọn phình rất nhanh | |

Lifecycle dọn phiên bản cũ:

{"Rules": [{
  "ID": "don-phien-ban-cu",
  "Status": "Enabled",
  "Filter": {},
  "NoncurrentVersionExpiration": {"NoncurrentDays": 90},
  "Expiration": {"ExpiredObjectDeleteMarker": true},
  "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}}]}

⚠ ExpiredObjectDeleteMarker dọn thứ vô hình:

Xoá hết phiên bản nhưng còn delete marker
    → marker không chứa dữ liệu
    → nhưng vẫn là một mục trong bucket
        ↓
    Bucket có hàng triệu marker mồ côi
    → làm chậm việc liệt kê

Ba lưu ý về MFA Delete: | Lưu ý | Chi tiết | |---|---| | Chỉ bật được bằng tài khoản gốc | | | Chỉ bật được qua CLI, không qua bảng điều khiển | | | Đòi mã MFA để xoá phiên bản | |

aws s3api put-bucket-versioning --bucket MANILATECH-CONFIG \
  --versioning-configuration Status=Enabled,MFADelete=Enabled \
  --mfa "arn:aws:iam::111122223333:mfa/root-account-mfa-device 123456"

Ba lưu ý về Object Lock: | Lưu ý | Chi tiết | |---|---| | Chỉ bật được khi TẠO bucket | | | Chế độ Governance gỡ được với quyền đặc biệt | | | Chế độ Compliance KHÔNG ai gỡ được | |

Ba lưu ý về CRR: | Lưu ý | Chi tiết | |---|---| | Bắt buộc bật versioning ở cả hai bucket | | | Chỉ nhân bản object ghi SAU khi bật quy tắc | | | Batch Replication cho object cũ | |

⚠ Điểm thứ hai hay gây bất ngờ:

Bật CRR hôm nay
    → object cũ KHÔNG tự sang bucket đích
        ↓
    Phải chạy S3 Batch Replication
      cho dữ liệu lịch sử

Ba lưu ý về SSE-S3 và versioning: | Lưu ý | Chi tiết | |---|---| | Mỗi phiên bản mã hoá độc lập | | | Đổi sang SSE-KMS chỉ áp cho bản ghi mới | | | Phiên bản cũ giữ nguyên cách mã hoá cũ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | list-object-versions xem Version ID thật | | | Xoá thử rồi khôi phục bằng cách xoá marker | | | Kiểm dung lượng bucket gồm cả phiên bản cũ | |

Và một lời khuyên: hãy đặt lifecycle rule dọn phiên bản cũ ngay khi bật versioning. Bucket cấu hình được cập nhật thường xuyên sẽ tích tụ phiên bản mãi mãi — và không có gì nhắc bạn về điều đó cho tới lúc đọc hoá đơn.

Câu 140 Domain - Continuous Improvement for Existing Solutions

A hospital chain in London uses an online central hub for its doctors and nurses. The application interacts with millions of requests per day to fetch various medical data of their patients. The system is composed of a web tier, an application tier, and a database tier that receives large and unpredictable traffic demands. The Solutions Architect must ensure that this infrastructure is highly-available and scalable enough to handle web traffic fluctuations automatically.

Which of the following options should the solutions architect implement to meet the above requirements?

  1. A

    Run the web and application tiers in stateful instances in an autoscaling group, using CloudWatch for monitoring. Run the database tier using RDS with read replicas.
  2. B

    Run the web and application tiers in stateless instances in an autoscaling group, using Amazon ElastiCache Serverless for tier synchronization and CloudWatch for monitoring. Run the database tier using RDS with Multi-AZ enabled.
  3. C

    Run the web and application tiers in stateful instances in an autoscaling group, using CloudWatch for monitoring. Run the database tier using RDS with Multi-AZ enabled.
  4. D

    Run the web and application tiers in stateless instances in an autoscaling group, using Amazon ElastiCache Serverless for tier synchronization and CloudWatch for monitoring. Run the database tier using RDS with read replicas, and Multi-AZ enabled.
Xem giải thích

Đáp án

**D — Chạy tầng web và tầng ứng dụng bằng instance stateless trong Auto Scaling group, dùng Amazon ElastiCache Serverless để đồng bộ trạng thái giữa các tầng và CloudWatch để giám sát; tầng CSDL dùng RDS có read replica và bật Multi-AZ.

Vì sao đúng

Đề nêu bốn yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Co giãn tự động theo tải khó đoán | ASG + ElastiCache Serverless | | Sẵn sàng cao | Multi-AZ ở tầng CSDL | | Hàng triệu yêu cầu đọc mỗi ngày | read replica | | Ứng dụng nhiều tầng | web, ứng dụng, CSDL tách bạch |

⚠ "Stateless" là điều kiện tiên quyết để co giãn được:

Instance stateful giữ phiên người dùng
  trong bộ nhớ của chính nó
        ↓
    ASG thu hồi máy → người dùng
      đăng xuất đột ngột
    → và phải dùng sticky session,
      làm tải phân bố lệch
        ↓
    Stateless: phiên nằm ngoài
    → thu hồi máy bất kỳ lúc nào
      cũng không ai nhận ra

Đây là lý do phương án A và C sai — cả hai dùng instance stateful.

⚠ Và cần CẢ read replica LẪN Multi-AZ vì chúng khác nhau: | Cơ chế | Giải bài toán | |---|---| | Multi-AZ | SẴN SÀNG CAO — tự chuyển đổi, RPO 0 | | Read replica | CO GIÃN ĐỌC — chia tải truy vấn |

Chỉ Multi-AZ (phương án B)
    → bản dự phòng KHÔNG phục vụ đọc
    → hàng triệu truy vấn vẫn đập vào
      một instance
        ↓
    Chỉ read replica
    → không có chuyển đổi tự động

Lưu phiên trong ElastiCache:

import redis
kho_phien = redis.Redis(
    host='cache-phien.serverless.apse1.cache.amazonaws.com',
    port=6379, ssl=True, decode_responses=True)

kho_phien.setex(f'phien:{ma_phien}', 1800,
                json.dumps(du_lieu_phien))

⚠ ElastiCache Serverless bỏ được bài toán chọn cỡ cụm: | Tiêu chí | Cụm tự quản | Serverless | |---|---|---| | Chọn loại node | phải chọn | không | | Co giãn | tự cấu hình | tự động trong vài giây | | Sẵn sàng cao | tự cấu hình Multi-AZ | có sẵn | | Chi phí | theo giờ node | theo dung lượng và lượt |

Đề nói "tải lớn và KHÓ ĐOÁN"
    → serverless hợp hơn hẳn
    → không phải đoán trước cỡ cụm

Tách đọc sang replica:

ket_noi_ghi = ket_noi(endpoint_chinh)
ket_noi_doc = ket_noi(endpoint_replica)

def lay_ho_so_benh_nhan(ma):
    return ket_noi_doc.query(...)   # doc tu replica

def cap_nhat_ho_so(ma, du_lieu):
    return ket_noi_ghi.execute(...)  # ghi vao chinh

⚠ Nhưng phải chú ý độ trễ nhân bản:

Bác sĩ cập nhật hồ sơ rồi xem lại ngay
    → đọc từ replica chưa kịp đồng bộ
    → thấy dữ liệu cũ
        ↓
    Với hệ thống y tế thì điều này
      nghiêm trọng
    → thao tác vừa ghi phải đọc từ
      instance CHÍNH

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Mỗi tầng co giãn độc lập | | | Chịu được mất một AZ ở cả ba tầng | | | Cache giảm mạnh tải cho CSDL | |

⚠ Và cache đúng chỗ còn hiệu quả hơn read replica:

Hàng triệu yêu cầu tra cứu cùng
  vài nghìn hồ sơ
        ↓
    Cache kết quả truy vấn
    → phần lớn không chạm CSDL nào
    → độ trễ micro giây thay vì mili giây

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

  • **B. Instance stateless trong ASG + ElastiCache Serverless + RDS chỉ bật Multi-AZ — đây là phương án gần nhất và kiến trúc tầng ứng dụng hoàn toàn đúng, nhưng thiếu read replica: bản dự phòng Multi-AZ không phục vụ đọc, nên hàng triệu truy vấn vẫn dồn vào một instance.
  • **C. Instance stateful trong ASG + RDS Multi-AZ — instance stateful không co giãn được đúng cách; thu hồi máy là mất phiên người dùng.
  • **A. Instance stateful + RDS chỉ có read replica — sai cả hai vế: stateful không co giãn, và read replica không cho sẵn sàng cao.

Ghi nhớ

⚠ Bốn nơi có thể lưu phiên — bảng phải thuộc: | Nơi | Đánh giá | |---|---| | Bộ nhớ instance | KHÔNG co giãn được | | Sticky session ở ALB | tải lệch, mất máy là mất phiên | | ElastiCache (Redis) | tiêu chuẩn công nghiệp | | DynamoDB | bền hơn, chậm hơn cache một chút |

Từ khoá nhận diện:

"scale automatically, unpredictable traffic" → stateless + ASG "session state across instances" → ElastiCache "high availability database" → Multi-AZ "offload read traffic" → read replica hoặc cache

Ba lưu ý về stateless: | Lưu ý | Chi tiết | |---|---| | Không lưu gì trên đĩa cục bộ | | | Không giữ phiên trong bộ nhớ | | | Tệp tải lên đi thẳng vào S3 | |

Ba lưu ý về ElastiCache: | Lưu ý | Chi tiết | |---|---| | Redis có bền vững và replica; Memcached thì không | | | Bật mã hoã khi truyền và khi lưu | | | Đặt TTL cho mọi khoá | |

⚠ Thiếu TTL là nguyên nhân cache đầy bộ nhớ:

Khoá phiên không có hạn
    → tích tụ mãi
        ↓
    Cache đầy, chính sách thu hồi
      xoá cả khoá đang dùng
    → người dùng bị đăng xuất ngẫu nhiên

Ba lưu ý về read replica: | Lưu ý | Chi tiết | |---|---| | Nhân bản bất đồng bộ, có độ trễ | | | Ứng dụng phải tự định tuyến | | | Theo dõi ReplicaLag | |

⚠ RDS Proxy tự tách đọc/ghi:

Không phải sửa ứng dụng để chọn endpoint
    → proxy định tuyến giúp
        ↓
    Và giữ pool kết nối
    → chuyển đổi Multi-AZ gần như
      không thấy gián đoạn

Ba lưu ý về Aurora so với RDS: | Tiêu chí | Aurora | |---|---| | Độ trễ replica | thường dưới 100ms | | Số replica | tới 15 | | Chuyển đổi | thường dưới 30 giây | | Reader endpoint | tự cân bằng qua các replica |

Ba lưu ý về ASG: | Lưu ý | Chi tiết | |---|---| | health-check-type ELB | | | Trải ít nhất ba AZ | | | Target tracking theo số yêu cầu mỗi target | |

Ba lưu ý về dữ liệu y tế: | Lưu ý | Chi tiết | |---|---| | Mã hoá khi lưu và khi truyền ở mọi tầng | | | Ghi nhật ký truy cập bằng CloudTrail data event | | | Ký thoả thuận BAA với AWS nếu chịu HIPAA | |

⚠ Dữ liệu bệnh nhân trong cache cũng phải mã hoá:

Cache thường bị bỏ quên khi rà soát
  tuân thủ
        ↓
    Redis lưu hồ sơ bệnh nhân
    → phải bật mã hoã và xác thực
    → và đặt trong subnet riêng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thu hồi một instance, xem người dùng có mất phiên | | | Buộc chuyển đổi Multi-AZ và bấm giờ | | | Theo dõi ReplicaLag khi tải cao | |

Và một lời khuyên: hãy thu hồi ngẫu nhiên một instance trong giờ làm việc và xem có ai nhận ra không. Đó là phép thử duy nhất chứng minh tầng ứng dụng thật sự stateless — và nếu có người bị đăng xuất, bạn vừa phát hiện ra điều đó trước khi ASG tự làm điều tương tự vào lúc bận nhất.