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

Tìm thấy 1221 câu.

Câu 71 Domain - Design for New Solutions

A company hosts its online delivery system on a fleet of EC2 instances deployed in multiple Availability Zones in the ap-southeast-1 region. The instances are behind an Application Load Balancer that evenly distributes the load. The system is using a MySQL RDS instance to store the deliveries and transactions of the system. To ensure business continuity, you are instructed to set up a disaster recovery system in which the RTO must be less than 3 hours and the RPO is 15 minutes when a system outage occurs. A system should also be implemented that can automatically discover, classify, and protect any personally identifiable information (PII) or intellectual property in your data store.

As the Solutions Architect, which disaster recovery strategy should you use to achieve the required RTO and RPO targets in the most cost-effective manner?

  1. A

    Set up asynchronous replication in the database using a Multi-AZ deployments configuration. Use AWS Shield to automatically discover, classify, and protect any personally identifiable information (PII) or intellectual property from your RDS database.
  2. B

    Schedule a database backup to an S3 bucket every hour and store transaction logs to a separate S3 bucket every 5 minutes. Use Amazon Macie to automatically discover, classify, and protect your sensitive data.
  3. C

    Schedule 15-minute DB backups to Amazon Glacier. Store the transaction logs to an S3 bucket every 5 minutes. Use Amazon Macie to automatically discover, classify, and protect your sensitive data.
  4. D

    Schedule a database backup to AWS Storage Gateway every hour and store transaction logs to a separate S3 bucket every 5 minutes. Use AWS Shield to automatically discover, classify, and protect any personally identifiable information (PII) or intellectual property on your Storage Gateway.
Xem giải thích

Đáp án

B — Lên lịch sao lưu CSDL vào S3 mỗi giờ và lưu transaction log vào bucket S3 riêng mỗi 5 phút; dùng Amazon Macie để tự động phát hiện, phân loại và bảo vệ dữ liệu nhạy cảm.

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 | |---|---| | RPO 15 phút | transaction log mỗi 5 phút — RPO tệ nhất 5 phút | | RTO dưới 3 giờ | khôi phục từ backup + phát lại log | | Tự phát hiện và bảo vệ PII | Macie |

⚠ Macie là dịch vụ DUY NHẤT quét nội dung tìm dữ liệu nhạy cảm:

Shield: chống DDoS ở tầng 3/4
GuardDuty: phát hiện hành vi đe doạ
Inspector: quét lỗ hổng phần mềm
        ↓
    Macie: MỞ object S3 ra và đọc bên trong
    → tìm số thẻ, hộ chiếu, thông tin cá nhân

Đây là lý do các phương án dùng Shield đều sai.

⚠ Và cách tính RPO của phương án này:

Sao lưu đầy đủ mỗi giờ
    + transaction log mỗi 5 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
        ↓
    Đáp ứng RPO 15 phút với biên an toàn

⚠ Còn RTO 3 giờ đủ để khôi phục và phát lại log:

Tải backup từ S3 → khôi phục CSDL
    → phát lại transaction log
        ↓
    Vài chục phút tới hơn một giờ
    → nằm trong 3 giờ

Bật Macie và tạo công việc quét:

aws macie2 enable-macie

aws macie2 create-classification-job \
  --job-type SCHEDULED \
  --schedule-frequency '{"dailySchedule":{}}' \
  --name quet-du-lieu-nhay-cam \
  --s3-job-definition '{"bucketDefinitions":[
    {"accountId":"123456789012",
     "buckets":["sao-luu-csdl","log-giao-dich"]}]}'

Cảnh báo khi phát hiện:

{"source": ["aws.macie"],
 "detail-type": ["Macie Finding"],
 "detail": {"severity": {"description": ["High"]}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | RPO 5 phút, tốt hơn yêu cầu | | | S3 rẻ hơn nhiều so với chạy hạ tầng dự phòng | | | Macie quét tự động, không cần viết bộ phân loại | |

⚠ Vì sao đây là "cost-effective" nhất:

Multi-AZ hay read replica: trả tiền hạ tầng 24/7
        ↓
    Sao lưu vào S3: chỉ trả tiền lưu trữ
    → RTO 3 giờ cho phép chiến lược
      Backup & Restore, rẻ nhất

⚠ Nhưng cần nói rõ: RDS đã có tính năng này sẵn:

aws rds modify-db-instance --db-instance-identifier csdl-giao-hang \
  --backup-retention-period 35 --apply-immediately

RDS tự động sao lưu và ghi transaction log mỗi 5 phút
    → point-in-time recovery tới bất kỳ giây nào
      trong khoảng giữ
        ↓
    Đây chính là cơ chế mà phương án B mô tả
    → RDS làm sẵn, không phải tự dựng

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

  • **C. Sao lưu mỗi 15 phút vào Amazon Glacier và log vào S3 — đây là phương án gần nhất và có Macie đúng, nhưng Glacier cần hàng giờ để lấy dữ liệu (Standard 3-5 giờ, Bulk 5-12 giờ); riêng thời gian khôi phục đã vượt RTO 3 giờ.
  • **A. Dùng Multi-AZ làm "nhân bản bất đồng bộ" và Shield để phát hiện PII — sai hai lần: Multi-AZ là nhân bản ĐỒNG BỘ (và là cơ chế sẵn sàng cao, không phải DR xuyên vùng); và Shield chống DDoS, không phát hiện dữ liệu nhạy cảm.
  • **D. Sao lưu vào Storage Gateway và dùng Shield — Storage Gateway là dịch vụ lưu trữ lai, không phải đích sao lưu cho RDS; và Shield lại sai vai trò.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật hay bị lẫn — bảng phải thuộc: | Dịch vụ | Trả lời câu hỏi | |---|---| | Macie | "có dữ liệu nhạy cảm nào trong S3 không?" | | GuardDuty | "có ai đang tấn công không?" | | Inspector | "có lỗ hổng phần mềm nào không?" | | Shield | "chống DDoS" |

⚠ Cách nhớ ngắn nhất:

Dữ liệu nhạy cảm trong S3 → Macie
Hành vi đe doạ            → GuardDuty
Lỗ hổng CVE              → Inspector
DDoS                     → Shield

⚠ Bốn chiến lược DR — chọn theo RTO: | Chiến lược | RTO | Chi phí | |---|---|---| | Backup & Restore | giờ - ngày | 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 |

RTO 3 giờ → Backup & Restore là đủ VÀ rẻ nhất
    → chọn thừa là trả tiền cho thứ không cần

Từ khoá nhận diện:

"RTO hours, RPO minutes, most cost-effective" → backup + transaction log "discover and classify PII" → Macie "RTO minutes" → Warm Standby "RTO near zero" → Multi-Site

Ba định nghĩa phải thuộc: | Chỉ số | Nghĩa | |---|---| | RTO | bao lâu để KHÔI PHỤC dịch vụ | | RPO | được phép MẤT bao nhiêu dữ liệu | | Tần suất sao lưu quyết định RPO | |

Ba lớp Glacier và thời gian lấy: | Lớp | Thời gian | |---|---| | Glacier Instant Retrieval | mili giây | | Glacier Flexible Retrieval | 1-5 phút (Expedited) tới 12 giờ | | Glacier Deep Archive | 12-48 giờ |

⚠ Chỉ Glacier Instant Retrieval hợp với RTO ngắn:

Đề nói RTO 3 giờ
    → Glacier Flexible với Standard retrieval
      (3-5 giờ) đã vượt
        ↓
    Nếu buộc dùng Glacier: chọn Instant Retrieval

Ba lưu ý về point-in-time recovery của RDS: | Lưu ý | Chi tiết | |---|---| | Tự động, transaction log mỗi 5 phút | | | Khôi phục tới bất kỳ giây nào trong khoảng giữ | | | Giữ tối đa 35 ngày | |

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier csdl-giao-hang \
  --target-db-instance-identifier csdl-khoi-phuc \
  --restore-time 2026-08-30T14:45:00Z

⚠ Nhưng PITR chỉ trong CÙNG Region:

Sự cố toàn Region
    → PITR không dùng được
        ↓
    Phải chép snapshot sang Region khác
    → hoặc dùng cross-region automated backup

aws rds start-db-instance-automated-backups-replication \
  --source-db-instance-arn <arn> \
  --backup-retention-period 14 \
  --region ap-northeast-1

Ba nhóm dữ liệu Macie nhận diện: | Nhóm | Ví dụ | |---|---| | Thông tin định danh cá nhân | tên, địa chỉ, ngày sinh | | Thông tin tài chính | số thẻ, tài khoản | | Thông tin xác thực | khoá riêng, token |

⚠ Giảm chi phí Macie bằng phạm vi quét:

{"scoping": {"includes": {"and": [{
  "simpleScopeTerm": {"comparator": "STARTS_WITH",
    "key": "OBJECT_KEY", "values": ["giao-dich/"]}}]}}}

Macie tính phí theo GB quét
    → giới hạn tiền tố giảm chi phí nhiều lần

Ba lưu ý về sao lưu: | Lưu ý | Chi tiết | |---|---| | Sao lưu chưa từng khôi phục = chưa chắc dùng được | | | Diễn tập khôi phục định kỳ | | | Đo RTO thật, đừng ước lượng | |

⚠ Đây là điều quan trọng nhất trong toàn bộ chủ đề DR:

Job sao lưu báo thành công mỗi giờ suốt hai năm
    → không ai từng thử khôi phục
        ↓
    Ngày cần đến mới phát hiện thiếu thứ gì đó

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ụ | | | Vault Lock chống xoá | | | Sao chép xuyên Region | |

Ba lưu ý về mã hoá bản sao lưu: | Lưu ý | Chi tiết | |---|---| | Snapshot của RDS mã hoá kế thừa từ instance | | | Bucket log mã hoá SSE-KMS | | | Kiểm soát ai giải mã bằng key policy | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Khôi phục thử và bấm giờ | | | Kiểm tra transaction log đầy đủ | | | Xem phát hiện của Macie | |

Và một lời khuyên: hãy diễn tập khôi phục và bấm giờ ít nhất mỗi quý. Con số RTO ba giờ chỉ là ước lượng cho tới khi bạn thực hiện nó một lần — và khoảng cách giữa ước lượng với thực tế luôn được phát hiện vào đúng lúc không ai muốn phát hiện.

Câu 72 Domain - Continuous Improvement for Existing Solutions

A company has several development teams using AWS CodeCommit to store their source code. With the number of code updates every day, the management is having difficulty tracking if the developers are adhering to company security policies. On a recent audit, the security team found several IAM access keys and secret keys in the CodeCommit repository. This is a big security risk so the company wants to have an automated solution that will scan the CodeCommit repositories for committed IAM credentials and delete/disable the IAM keys for those users.

Which of the following options will meet the company requirements?

  1. A

    Write a custom AWS Lambda function to search for credentials on new code submissions. Set the function trigger as AWS CodeCommit push events. If credentials are found, notify the user of the violation, and disable the IAM keys.
  2. B

    Using a development instance, use the AWS Systems Manager Run Command to scan the AWS CodeCommit repository for IAM credentials on a daily basis. If credentials are found, rotate them using AWS Secrets Manager. Notify the user of the violation.
  3. C

    Scan the CodeCommit repositories for IAM credentials using Amazon Macie. Using machine learning, Amazon Macie can scan your repository for security violations. If violations are found, invoke an AWS Lambda function to notify the user and delete the IAM keys.
  4. D

    Download and scan the source code from AWS CodeCommit using a custom AWS Lambda function. Schedule this Lambda function to run daily. If credentials are found, notify the user of the violation, generate new IAM credentials and store them in AWS KMS for encryption.
Xem giải thích

Đáp án

A — Viết một hàm Lambda tuỳ chỉnh tìm credential trong mã mới được đẩy lên; đặt trigger là sự kiện push của CodeCommit; nếu tìm thấy thì thông báo cho người vi phạm và vô hiệu hoá khoá IAM.

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 | |---|---| | Quét kho mã tìm credential IAM | Lambda đọc commit và tìm mẫu | | TỰ ĐỘNG | trigger theo sự kiện push | | Xoá hoặc vô hiệu hoá khoá | gọi API IAM |

⚠ Kích hoạt theo SỰ KIỆN chứ không quét theo lịch — đây là điều quan trọng nhất:

Quét mỗi ngày: credential nằm trong kho tới 24 giờ
    → đủ thời gian cho kẻ tấn công tìm thấy
        ↓
    Trigger theo push: phát hiện trong vài giây
    → và vô hiệu hoá ngay

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

Tạo trigger cho CodeCommit:

aws codecommit put-repository-triggers \
  --repository-name kho-ma-nguon \
  --triggers name=quet-credential,\
destinationArn=<arn-lambda>,\
events=updateReference,\
branches=main

⚠ Hoặc dùng EventBridge — linh hoạt hơn:

{"source": ["aws.codecommit"],
 "detail-type": ["CodeCommit Repository State Change"],
 "detail": {"event": ["referenceCreated", "referenceUpdated"]}}

Hàm quét và vô hiệu hoá:

import boto3, re
cc = boto3.client('codecommit')
iam = boto3.client('iam')

MAU_KHOA = re.compile(r'(AKIA|ASIA)[0-9A-Z]{16}')

def handler(su_kien, ngu_canh):
    for ban_ghi in su_kien['Records']:
        kho = ban_ghi['eventSourceARN'].split(':')[-1]
        commit = ban_ghi['codecommit']['references'][0]['commit']
        khac_biet = cc.get_differences(
            repositoryName=kho, afterCommitSpecifier=commit)
        for tep in khac_biet['differences']:
            noi_dung = cc.get_file(
                repositoryName=kho, commitSpecifier=commit,
                filePath=tep['afterBlob']['path'])['fileContent']
            for khoa in MAU_KHOA.findall(noi_dung.decode()):
                vo_hieu_hoa(khoa)

Vô hiệu hoá khoá:

def vo_hieu_hoa(ma_khoa):
    nguoi = iam.get_access_key_last_used(
        AccessKeyId=ma_khoa)['UserName']
    iam.update_access_key(
        UserName=nguoi, AccessKeyId=ma_khoa, Status='Inactive')

⚠ Inactive thay vì xoá là lựa chọn tốt hơn:

Xoá khoá: không khôi phục được
    → nếu nhận diện nhầm, người dùng mất quyền
        ↓
    Inactive: chặn ngay nhưng đảo ngược được
    → và vẫn dừng được rò rỉ

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Phản ứng trong vài giây | | | Không có máy chủ nào chạy nền | | | Chỉ trả tiền khi có commit | |

⚠ Nhưng khoá đã bị đẩy lên phải coi là ĐÃ RÒ RỈ vĩnh viễn:

Vô hiệu hoá khoá chặn được việc dùng nó
    → nhưng nó VẪN NẰM trong lịch sử Git
        ↓
    Phải viết lại lịch sử (git filter-repo)
    → hoặc chấp nhận rằng ai clone kho đều thấy

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

⚠ Ngày nay có công cụ làm sẵn việc này — không cần tự viết Lambda.

Amazon CodeGuru Security và Amazon Q Developer quét bí mật trong mã tự động. Và với kho mã trên GitHub thì secret scanning là tính năng có sẵn.

Còn trên AWS, giải pháp phòng ngừa tốt hơn nhiều:

Không có access key nào để rò rỉ
    → EC2 dùng instance profile
    → Lambda dùng execution role
    → CI/CD dùng OIDC federation
    → máy tại chỗ dùng IAM Roles Anywhere
        ↓
    Rất ít trường hợp thật sự cần access key tĩnh

Và chặn từ gốc bằng git hook phía client:

# .git/hooks/pre-commit
if git diff --cached | grep -E '(AKIA|ASIA)[0-9A-Z]{16}'; then
  echo "Phat hien access key — huy commit"
  exit 1
fi

Chặn TRƯỚC khi commit
    → khoá không bao giờ vào lịch sử Git
        ↓
    Tốt hơn nhiều so với phát hiện sau

⚠ Thêm nữa: CodeCommit không nhận khách hàng mới từ tháng 7/2024.

Dự án mới nên dùng GitHub, GitLab hoặc Bitbucket
    → CodePipeline kết nối được cả ba
        ↓
    Khách hàng đang dùng vẫn tiếp tục được

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

  • **D. Tải mã về và quét bằng Lambda chạy theo lịch hằng ngày, rồi sinh credential mới lưu vào KMS — đây là phương án gần nhất và cũng dùng Lambda, nhưng quét hằng ngày để credential nằm phơi tới 24 giờ; và KMS không lưu bí mật (đó là việc của Secrets Manager).
  • **C. Dùng Amazon Macie quét kho CodeCommit — Macie chỉ quét object trong S3, nó không đọc được kho Git.
  • **B. Dùng Systems Manager Run Command trên một máy phát triển để quét hằng ngày — thêm một máy phải vận hành, quét theo lịch chậm hơn, và Run Command không phải công cụ cho việc này.

Ghi nhớ

⚠ Bốn dịch vụ bảo mật và phạm vi — bảng phải thuộc: | Dịch vụ | Quét gì | |---|---| | Macie | object trong S3 | | GuardDuty | log hành vi (CloudTrail, VPC Flow, DNS) | | Inspector | lỗ hổng của EC2, ECR, Lambda | | CodeGuru Security | mã nguồn |

Từ khoá nhận diện:

"scan code repository for secrets" → CodeGuru Security hoặc Lambda tuỳ chỉnh "find PII in S3" → Macie "detect compromised credentials in use" → GuardDuty "prevent secrets from being committed" → git hook, pre-commit

⚠ GuardDuty phát hiện khoá bị dùng từ nơi lạ:

`UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration`
`UnauthorizedAccess:IAMUser/MaliciousIPCaller`
        ↓
    Bổ sung cho việc quét mã
    → bắt được cả khoá rò rỉ qua đường khác

Ba lớp phòng thủ cho bí mật: | Lớp | Chi tiết | |---|---| | Phòng ngừa | không tạo access key tĩnh | | Chặn | pre-commit hook | | Phát hiện | quét theo sự kiện + GuardDuty |

⚠ Lớp đầu tiên là quan trọng nhất:

Không có access key nào tồn tại
    → không có gì để rò rỉ
        ↓
    Mọi lớp sau chỉ là lưới an toàn

Ba cách thay thế access key tĩnh: | Trường hợp | Dùng gì | |---|---| | EC2, ECS, Lambda | IAM role | | CI/CD trên GitHub | OIDC federation | | Máy tại chỗ | IAM Roles Anywhere |

⚠ OIDC federation cho GitHub Actions:

permissions:
  id-token: write
steps:
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/VaiTroCI
      aws-region: ap-southeast-1

Không có secret nào trong GitHub
    → nhận credential tạm qua OIDC

Ba lưu ý về xử lý khi khoá rò rỉ: | Bước | Chi tiết | |---|---| | Vô hiệu hoá NGAY | | | Kiểm CloudTrail xem đã bị dùng chưa | | | Tạo khoá mới và cập nhật nơi dùng | |

⚠ Kiểm tra khoá đã bị dùng hay chưa:

aws iam get-access-key-last-used --access-key-id AKIA...

Nếu đã có lời gọi từ IP lạ
    → không chỉ vô hiệu hoá khoá
    → phải điều tra toàn bộ hoạt động của nó

Ba lưu ý về xoá khỏi lịch sử Git: | Lưu ý | Chi tiết | |---|---| | git filter-repo viết lại lịch sử | | | Mọi người phải clone lại | | | Vẫn phải coi khoá là đã rò rỉ | |

Ba lưu ý về Secrets Manager: | Lưu ý | Chi tiết | |---|---| | Nơi đúng để lưu bí mật | | | Có xoay tự động | | | Không bao giờ đặt bí mật trong mã | |

Ba lưu ý về SCP phòng ngừa: | Lưu ý | Chi tiết | |---|---| | Chặn tạo access key cho IAM user | | | Buộc dùng vai trò thay vì user | | | Ngăn từ gốc | |

{"Effect": "Deny", "Action": "iam:CreateAccessKey",
 "Resource": "*",
 "Condition": {"StringNotEquals":
   {"aws:PrincipalArn": "arn:aws:iam::*:role/QuanTriIAM"}}}

Ba lưu ý về thông báo: | Lưu ý | Chi tiết | |---|---| | Báo cho chính người vi phạm để họ học | | | Báo cho đội bảo mật để theo dõi | | | Ghi lại để thống kê xu hướng | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đẩy một khoá giả lên kho thử | | | Xem Lambda chạy và vô hiệu hoá | | | Đo thời gian từ push tới vô hiệu hoá | |

Và một lời khuyên: hãy đầu tư vào việc loại bỏ access key tĩnh thay vì hoàn thiện công cụ phát hiện chúng. Một khoá đã lọt vào kho mã phải được coi là rò rỉ vĩnh viễn dù bạn phản ứng nhanh đến đâu — còn khoá không tồn tại thì không có gì để rò rỉ.

Câu 73 Domain - Design for New Solutions

A startup in the fashion industry is building a mobile app that showcases its latest fashion accessories and gadgets. The marketing manager hired a famous model with millions of Instagram followers to promote their new products and hence, it is expected that the app will be a huge hit once it is launched in the market. It must have the ability to automatically scale to handle millions of views of its static contents and to allow users to store their own photos of themselves wearing fashionable accessories with a maximum of 100 characters for captions.

In this scenario, which of the following solutions would fulfill this requirement?

  1. A

    1. Use Cognito to handle user authentication and management.

    2. Launch a DynamoDB table to store user data.

    3. Create an S3 bucket to store all of the user photos and other static files.

    4. Distribute the static contents using CloudFront to improve scalability.
  2. B

    1. Set up a SAML 2.0-based Federation that lets the users sign into the app using a third-party identity provider such as Amazon, Google, or Facebook.

    2. Set up an RDS database and an S3 bucket to store the photos.

    3. Use the AssumeRoleWithWebIdentity API call to assume the IAM role containing the proper permissions to communicate with the RDS database.

    4. Distribute the static contents using S3 to improve scalability.
  3. C

    1. Use Cognito to handle user authentication and management.

    2. Use an RDS database to store user data.

    3. Create an S3 bucket to store all of the user photos and other static files.

    4. Distribute the static contents using CloudFront to improve scalability.
  4. D

    1. Configure an on-premises Active Directory (AD) server utilizing SAML 2.0 to manage the application users inside of the on-premises AD server.

    2. Develop a custom code that authenticates against the LDAP server.

    3. Use DynamoDB as the main database of the app and S3 as the scalable object storage.

    4. Grant an IAM role assigned to the STS token to allow the end-user to access the required data in the DynamoDB table.

    5. Distribute the static contents using CloudFront to improve scalability.
Xem giải thích

Đáp án

A — Dùng Amazon Cognito cho đăng nhập mạng xã hội, DynamoDB lưu điểm và trạng thái người chơi, S3 phục vụ nội dung tĩnh và CloudFront phân phối toàn cầu.

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 | |---|---| | Đăng nhập bằng Facebook/Google | Cognito identity pool + user pool | | Lưu trạng thái người chơi, độ trễ thấp | DynamoDB | | Phục vụ tài nguyên game | S3 | | Người chơi toàn cầu | CloudFront |

⚠ Cognito là dịch vụ DUY NHẤT của AWS làm liên kết danh tính mạng xã hội cho ứng dụng di động:

Người chơi bấm "Đăng nhập bằng Google"
    → nhận token của Google
        ↓
    Cognito đổi token đó lấy credential AWS tạm
    → ứng dụng gọi thẳng DynamoDB
        ↓
    Không cần tầng máy chủ trung gian

⚠ Và DynamoDB đúng cho dữ liệu người chơi vì mẫu truy cập:

Đọc/ghi theo ID người chơi
    → khoá chính đơn giản
        ↓
    Không có join, không có truy vấn phức tạp
    → độ trễ mili giây một chữ số
      ở bất kỳ quy mô nào

Bảng dữ liệu người chơi:

aws dynamodb create-table --table-name NguoiChoi \
  --attribute-definitions AttributeName=idNguoiChoi,AttributeType=S \
  --key-schema AttributeName=idNguoiChoi,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

⚠ Và giới hạn quyền theo chính người đăng nhập:

{"Effect": "Allow",
 "Action": ["dynamodb:GetItem", "dynamodb:PutItem"],
 "Resource": "arn:aws:dynamodb:*:*:table/NguoiChoi",
 "Condition": {"ForAllValues:StringEquals":
   {"dynamodb:LeadingKeys":
     ["${cognito-identity.amazonaws.com:sub}"]}}}

Người chơi chỉ đọc/ghi được DÒNG CỦA CHÍNH MÌNH
    → dù ứng dụng gọi thẳng DynamoDB
        ↓
    Đây là điều khiến kiến trúc không máy chủ
      này an toàn

Bảng xếp hạng bằng chỉ mục phụ:

aws dynamodb update-table --table-name NguoiChoi \
  --attribute-definitions \
    AttributeName=muaGiai,AttributeType=S \
    AttributeName=diem,AttributeType=N \
  --global-secondary-index-updates '[{"Create":{
    "IndexName":"XepHang",
    "KeySchema":[{"AttributeName":"muaGiai","KeyType":"HASH"},
                 {"AttributeName":"diem","KeyType":"RANGE"}],
    "Projection":{"ProjectionType":"INCLUDE",
                  "NonKeyAttributes":["tenHienThi"]}}}]'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Không có máy chủ nào phải vận hành | | | Tự co giãn theo lượng người chơi | | | Chi phí theo mức dùng thật | |

⚠ Vì sao không có tầng ứng dụng lại là điểm mạnh:

Game di động: lượng người chơi bùng nổ khó đoán
    → một video lan truyền là gấp trăm lần
        ↓
    Kiến trúc có EC2/ALB phải dự phòng công suất
    → kiến trúc này tự lo

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

  • **D. Dùng API Gateway + Lambda + DynamoDB với Cognito — đây là phương án gần nhất và hoàn toàn chạy được, nhưng thêm một tầng không cần thiết cho thao tác đọc/ghi đơn giản theo ID; đề không nêu logic nghiệp vụ phía máy chủ nào.
  • **B. Dùng EC2 + RDS cho trạng thái người chơi — RDS không co giãn tự động theo cách DynamoDB làm, và EC2 buộc phải quản lý máy chủ; sai với ứng dụng di động toàn cầu tải khó đoán.
  • **C. Dùng ElastiCache làm nơi lưu chính — cache là bộ nhớ tạm, dữ liệu người chơi phải bền vững; mất node là mất tiến trình chơi.

Ghi nhớ

⚠ Hai loại pool của Cognito — bảng phải thuộc: | Loại | Trả lời | |---|---| | User pool | "anh là ai?" — thư mục người dùng, đăng nhập | | Identity pool | "anh được làm gì trên AWS?" — cấp credential tạm |

⚠ Luồng đăng nhập mạng xã hội đầy đủ:

Google/Facebook → token
    → user pool (hoặc thẳng identity pool)
        ↓
    identity pool → credential AWS tạm
    → gọi DynamoDB/S3 với quyền giới hạn

Từ khoá nhận diện:

"social identity providers, mobile app" → Cognito "player state, low latency, massive scale" → DynamoDB "global users, static assets" → CloudFront + S3 "corporate SAML login" → IAM Identity Center

Ba lưu ý về dynamodb:LeadingKeys: | Lưu ý | Chi tiết | |---|---| | Giới hạn theo giá trị khoá phân vùng | | | Là cách cô lập dữ liệu giữa người dùng | | | Bắt buộc khi client gọi thẳng DynamoDB | |

⚠ Thiếu điều kiện này là mọi người chơi đọc được dữ liệu của nhau:

Credential tạm có quyền GetItem trên cả bảng
    → ai cũng đọc được điểm và trạng thái người khác
        ↓
    Và ghi đè được — sửa điểm của mình lên
      bảng xếp hạng

Ba lưu ý về bảng xếp hạng: | Lưu ý | Chi tiết | |---|---| | GSI với điểm làm khoá sắp xếp | | | Chú ý điểm nóng nếu chỉ một mùa giải | | | Cân nhắc chia nhỏ khoá phân vùng | |

⚠ Điểm nóng ở bảng xếp hạng là bẫy quen thuộc:

Mọi truy vấn xếp hạng cùng khoá "mua-2026"
    → một phân vùng chịu toàn bộ tải đọc
        ↓
    Chia thành "mua-2026#0" tới "mua-2026#9"
    → đọc cả 10 rồi gộp ở client

Ba lưu ý về DynamoDB Accelerator: | Lưu ý | Chi tiết | |---|---| | Cache trước DynamoDB, độ trễ micro giây | | | Hợp với dữ liệu đọc nhiều ghi ít | | | Không thay thế DynamoDB, chỉ đặt trước | |

Ba lưu ý về CloudFront cho game: | Lưu ý | Chi tiết | |---|---| | Tài nguyên game thường lớn, cache rất hiệu quả | | | Đặt TTL dài cho tệp có mã băm trong tên | | | Dùng OAC để bucket không cần công khai | |

⚠ Tệp có mã băm trong tên cho phép TTL vĩnh viễn:

texture-a3f9c2.png
    → nội dung đổi thì tên đổi
        ↓
    Cache-Control: max-age=31536000, immutable
    → không bao giờ phải xoá cache

Ba lưu ý về đồng bộ trạng thái nhiều thiết bị: | Lưu ý | Chi tiết | |---|---| | DynamoDB làm nguồn sự thật | | | AppSync nếu cần đồng bộ thời gian thực | | | Cân nhắc xung đột khi chơi ngoại tuyến | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | On-demand hợp với tải khó đoán | | | Chuyển sang provisioned khi tải ổn định | | | Bật auto scaling nếu dùng provisioned | |

Ba lưu ý về bảo mật ứng dụng di động: | Lưu ý | Chi tiết | |---|---| | Không nhúng access key vào ứng dụng | | | Credential tạm hết hạn sau một giờ | | | Xác thực logic quan trọng phía máy chủ | |

⚠ Điều cuối cùng đáng nói: điểm số không nên do client tự khai:

Client gọi thẳng DynamoDB ghi điểm
    → ai sửa ứng dụng cũng ghi được điểm bất kỳ
        ↓
    Điểm ảnh hưởng tới xếp hạng hay phần thưởng
    → phải qua Lambda kiểm tra tính hợp lệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử đăng nhập bằng cả hai nhà cung cấp | | | Thử đọc dữ liệu người chơi khác — phải bị từ chối | | | Đo độ trễ từ vài châu lục | |

Và một lời khuyên: hãy để client gọi thẳng DynamoDB cho dữ liệu riêng của người chơi, nhưng bắt mọi thứ ảnh hưởng tới người khác đi qua Lambda. Ranh giới đó chính là ranh giới giữa "kiến trúc gọn nhẹ" và "bảng xếp hạng toàn người chơi gian lận".

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

A clinic runs its medical record system using a fleet of Windows-based Amazon EC2 instances with several EBS volumes attached to it. Since the records that they are storing are confidential health files of their patients, it is a requirement that the latest security patches are installed on the EC2 instances. In addition, there should be a system in the cloud architecture that checks all of the EC2 instances if they are using an approved Amazon Machine Image (AMI). The system that will be implemented should not impede developers from launching instances using an unapproved AMI, but you still have to be notified if there are non-compliant EC2 instances in your VPC.

Which of the following should the solutions architect implement to protect and monitor all of your instances as required above? (Select TWO.)

  1. A

    Create an IAM policy that will restrict the developers from launching EC2 instances with an unapproved AMI.
  2. B

    Set up a patch baseline that defines which patches are approved for installation on your instances using AWS Systems Manager Patch Manager.
  3. C

    Set up Amazon GuardDuty that continuously monitors your instances if the latest security patches are installed and if there is an instance that is using an unapproved AMI. Use CloudWatch Alarms to notify you if there are any non-compliant instances running in your VPC.
  4. D

    Use the AWS Config Managed Rule which automatically checks whether your running EC2 instances are using approved AMIs. Set up CloudWatch Alarms to notify you if there are any non-compliant instances running in your VPC.
  5. E

    Use AWS Shield Advanced to automatically patch all of your EC2 instances and detect uncompliant EC2 instances which do not use approved AMIs.
Xem giải thích

Đáp án

B và D — Dùng Systems Manager Patch Manager với patch baseline để tự động vá; và dùng quy tắc quản lý của AWS Config approved-amis-by-id để kiểm tra instance chạy AMI đã duyệt.

Vì sao đúng

Đề nêu hai yêu cầu tách biệt, và mỗi phương án lo một cái: | Yêu cầu | Cách đáp ứng | |---|---| | Vá lỗi tự động theo lịch | Patch Manager + baseline | | Bảo đảm instance chạy AMI đã duyệt | Config rule approved-amis-by-id |

⚠ Đây là hai vấn đề khác nhau và cần hai công cụ khác nhau:

Patch Manager: sửa cái đang chạy
    → cài bản vá vào instance hiện có
        ↓
    Config rule: phát hiện cái sai
    → báo instance nào không dùng AMI duyệt

Tạo patch baseline:

aws ssm create-patch-baseline \
  --name baseline-san-xuat \
  --operating-system AMAZON_LINUX_2 \
  --approval-rules 'PatchRules=[{
    PatchFilterGroup={PatchFilters=[
      {Key=CLASSIFICATION,Values=[Security,Bugfix]},
      {Key=SEVERITY,Values=[Critical,Important]}]},
    ApproveAfterDays=7,
    ComplianceLevel=CRITICAL}]'

⚠ ApproveAfterDays=7 là chi tiết quan trọng:

Bản vá vừa phát hành có thể có lỗi
    → chờ 7 ngày để cộng đồng phát hiện
        ↓
    Cân bằng giữa an toàn bảo mật
      và rủi ro bản vá hỏng

Cửa sổ bảo trì:

aws ssm create-maintenance-window \
  --name cua-so-va-loi \
  --schedule "cron(0 2 ? * SUN *)" \
  --duration 4 --cutoff 1

⚠ cutoff ngăn công việc mới bắt đầu ở cuối cửa sổ:

Cửa sổ 4 giờ, cutoff 1 giờ
    → giờ cuối không nhận việc mới
        ↓
    Việc đang chạy có thời gian hoàn tất
    → không bị cắt giữa chừng

Bật quy tắc Config:

aws configservice put-config-rule --config-rule '{
  "ConfigRuleName": "instance-dung-ami-duyet",
  "Source": {"Owner": "AWS",
    "SourceIdentifier": "APPROVED_AMIS_BY_ID"},
  "InputParameters": "{\"amiIds\":\"ami-0abc,ami-0def\"}",
  "Scope": {"ComplianceResourceTypes":
    ["AWS::EC2::Instance"]}}'

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Cả hai đều là dịch vụ quản lý, không phải tự viết | | | Chạy trên toàn tổ chức qua Config aggregator | | | Có báo cáo tuân thủ sẵn | |

⚠ Và Config rule tự động sửa được:

aws configservice put-remediation-configurations \
  --remediation-configurations '[{
    "ConfigRuleName": "instance-dung-ami-duyet",
    "TargetType": "SSM_DOCUMENT",
    "TargetId": "AWS-StopEC2Instance",
    "Automatic": true,
    "MaximumAutomaticAttempts": 3}]'

Phát hiện instance dùng AMI lạ
    → tự dừng nó
        ↓
    Nhưng cân nhắc kỹ: dừng nhầm
      là gián đoạn dịch vụ

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

  • **A. Dùng Amazon Inspector để quét và tự vá — đây là phương án gần nhất và Inspector đúng cho việc phát hiện lỗ hổng, nhưng nó chỉ báo cáo chứ không vá; việc vá vẫn phải do Patch Manager làm.
  • **C. Viết quy tắc Config tuỳ chỉnh bằng Lambda để kiểm tra AMI — chạy được nhưng phải viết và bảo trì mã, trong khi AWS đã có quy tắc quản lý sẵn cho đúng việc này.
  • **E. Dùng CloudFormation drift detection để phát hiện AMI sai — drift chỉ so với stack template, không bao trùm instance tạo ngoài CloudFormation.

Ghi nhớ

⚠ Ba dịch vụ hay bị lẫn trong chủ đề vá lỗi — bảng phải thuộc: | Dịch vụ | Việc | |---|---| | Inspector | PHÁT HIỆN lỗ hổng (CVE) | | Patch Manager | CÀI bản vá | | Config | KIỂM TRA cấu hình có đúng chuẩn không |

⚠ Cách nhớ ngắn nhất:

Inspector: "máy này có lỗ hổng gì?"
Patch Manager: "cài bản vá đi"
Config: "máy này có đúng chuẩn không?"

Từ khoá nhận diện:

"automatically patch instances" → Patch Manager "ensure instances use approved AMIs" → Config approved-amis-by-id "scan for vulnerabilities" → Inspector "track configuration changes over time" → Config

Ba lưu ý về Patch Manager: | Lưu ý | Chi tiết | |---|---| | Cần SSM Agent và IAM role trên instance | | | Chọn instance bằng tag hoặc resource group | | | Báo cáo tuân thủ vá lỗi sẵn có | |

⚠ Điều kiện tiên quyết hay bị quên:

SSM Agent phải chạy
    + instance profile có AmazonSSMManagedInstanceCore
    + có đường ra tới endpoint SSM
      (Internet hoặc VPC endpoint)
        ↓
    Thiếu một trong ba: instance không hiện
      trong Fleet Manager, không vá được

Ba VPC endpoint cần cho subnet riêng tư: | Endpoint | Vai trò | |---|---| | com.amazonaws.<region>.ssm | kênh chính | | com.amazonaws.<region>.ssmmessages | Session Manager | | com.amazonaws.<region>.ec2messages | Run Command |

Ba lưu ý về AMI đã duyệt: | Lưu ý | Chi tiết | |---|---| | EC2 Image Builder tự dựng AMI theo lịch | | | Chia sẻ AMI qua Organizations | | | Cập nhật danh sách trong Config rule khi có AMI mới | |

⚠ Danh sách AMI trong quy tắc phải được cập nhật tự động:

Image Builder dựng AMI mới mỗi tháng
    → nếu không cập nhật quy tắc
        ↓
    Instance dùng AMI MỚI NHẤT bị báo vi phạm
    → và nếu có tự sửa: bị dừng

Ba lưu ý về EC2 Image Builder: | Lưu ý | Chi tiết | |---|---| | Pipeline dựng AMI có kiểm thử | | | Chạy theo lịch để AMI luôn mới | | | Phân phối sang nhiều Region và tài khoản | |

Ba lưu ý về cửa sổ bảo trì: | Lưu ý | Chi tiết | |---|---| | Chọn giờ ít người dùng | | | Vá theo đợt để không mất toàn bộ công suất | | | Kiểm thử ở môi trường thấp trước | |

⚠ Vá theo đợt bằng tỷ lệ lỗi và đồng thời:

aws ssm register-task-with-maintenance-window \
  --window-id mw-abc --task-type RUN_COMMAND \
  --max-concurrency "25%" --max-errors "5%"

Vá 25% một lúc
    → hơn 5% lỗi thì dừng
        ↓
    Bản vá hỏng không hạ toàn bộ đội máy

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Aggregator gộp tuân thủ nhiều tài khoản | | | Conformance pack đóng gói nhiều quy tắc | | | Ghi lịch sử cấu hình để điều tra | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Xem báo cáo tuân thủ vá lỗi | | | Tạo instance với AMI lạ — quy tắc phải báo | | | Kiểm tra bản vá thật sự được cài | |

Và một lời khuyên: hãy thay AMI thay vì vá máy đang chạy khi có thể. Vá tại chỗ để lại một đội máy mà mỗi cái có lịch sử riêng — còn dựng AMI mới rồi thay cả đội cho bạn thứ luôn giống nhau và luôn dựng lại được từ đầu.

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

An international foreign exchange company has a serverless forex trading application that was built using AWS SAM and is hosted on AWS Serverless Application Repository. They have millions of users worldwide who use their online portal 24/7 to trade currencies. However, they are receiving a lot of complaints that it takes a few minutes for their users to log in to their portal lately, including occasional HTTP 504 errors. As the Solutions Architect, you are tasked to optimize the system and to significantly reduce the time to log in to improve the customers' satisfaction.

Which of the following should you implement in order to improve the performance of the application with minimal cost? (Select TWO.)

  1. A

    Set up multiple and geographically disperse VPCs to various AWS regions then create a transit VPC to connect all of your resources. Deploy the Lambda function in each region using AWS SAM, in order to handle the requests faster.
  2. B

    Set up an origin failover by creating an origin group with two origins. Specify one as the primary origin and the other as the second origin which CloudFront automatically switches to when the primary origin returns specific HTTP status code failure responses.
  3. C

    Increase the cache hit ratio of your CloudFront distribution by configuring your origin to add a Cache-Control max-age directive to your objects, and specify the longest practical value for max-age.
  4. D

    Deploy your application to multiple AWS regions to accommodate your users around the world. Set up a Route 53 record with latency routing policy to route incoming traffic to the region that provides the best latency to the user.
  5. E

    Use Lambda@Edge to allow your Lambda functions to customize content that CloudFront delivers and to execute the authentication process in AWS locations closer to the users.
Xem giải thích

Đáp án

B và E — Cấu hình origin failover của CloudFront với origin group gồm hai Region; và dùng Lambda@Edge để xử lý xác thực ngay tại điểm biên.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi phương án lo một cái: | Yêu cầu | Cách đáp ứng | |---|---| | Chịu được mất một Region | origin group với origin dự phòng | | Xác thực gần người dùng, giảm độ trễ | Lambda@Edge tại điểm biên |

⚠ Origin failover chuyển origin ngay trong CloudFront, không cần DNS:

Origin chính trả 500/502/503/504 hoặc timeout
    → CloudFront thử origin dự phòng
        ↓
    Người dùng vẫn nhận được phản hồi
    → không phải chờ TTL của DNS hết hạn

Đây là điểm khác biệt so với Route 53 failover.

Tạo origin group:

{"OriginGroups": {"Quantity": 1, "Items": [{
  "Id": "nhom-goc",
  "FailoverCriteria": {"StatusCodes":
    {"Quantity": 4, "Items": [500, 502, 503, 504]}},
  "Members": {"Quantity": 2, "Items": [
    {"OriginId": "vung-chinh"},
    {"OriginId": "vung-du-phong"}]}}]}}

⚠ Nhưng phải biết giới hạn của nó:

Origin failover CHỈ áp cho GET, HEAD, OPTIONS
    → POST/PUT/DELETE không được thử lại
        ↓
    Ghi dữ liệu vẫn cần Route 53 failover
      hoặc logic ở tầng ứng dụng

⚠ Còn Lambda@Edge chạy ở điểm hiện diện gần người dùng:

Người dùng ở Singapore
    → xác thực ngay tại POP Singapore
        ↓
    Yêu cầu không hợp lệ bị chặn tại đó
    → không đi vòng qua Region gốc

Hàm kiểm tra token ở viewer request:

exports.handler = async (su_kien) => {
  const yeu_cau = su_kien.Records[0].cf.request;
  const token = yeu_cau.headers.authorization?.[0]?.value;
  if (!hop_le(token)) {
    return {status: '401',
            statusDescription: 'Unauthorized'};
  }
  return yeu_cau;
};

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Chuyển origin trong vài giây, không chờ DNS | | | Xác thực không tốn một vòng tới Region gốc | | | Cả hai đều là tính năng sẵn có của CloudFront | |

⚠ Chọn đúng loại trigger là điều quan trọng nhất với Lambda@Edge: | Trigger | Chạy khi | Dùng cho | |---|---|---| | Viewer request | mỗi yêu cầu, TRƯỚC cache | xác thực | | Origin request | chỉ khi cache trượt | sửa yêu cầu tới gốc | | Origin response | khi gốc trả về | sửa phản hồi | | Viewer response | trước khi trả người dùng | thêm header |

Xác thực đặt ở origin request
    → nội dung đã cache trả thẳng
      KHÔNG qua kiểm tra
        ↓
    Lỗ hổng: ai có URL đều xem được
    → phải đặt ở viewer request

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

  • **A. Dùng Route 53 failover routing với health check — đây là phương án gần nhất và thật sự là cơ chế DR xuyên vùng đúng đắn, nhưng nó phụ thuộc TTL của DNS và bộ nhớ đệm phía client; đề nhấn mạnh chuyển đổi nhanh mà origin failover làm tốt hơn.
  • **C. Dùng API Gateway ở mỗi Region với custom domain — chạy được nhưng vẫn cần cơ chế chuyển đổi bên trên, và không giải quyết yêu cầu xác thực tại biên.
  • **D. Dùng ALB xuyên Region — ALB không hoạt động xuyên Region; target của nó phải nằm trong cùng VPC hoặc qua peering trong cùng Region.

Ghi nhớ

⚠ Ba cách chuyển đổi khi mất Region — bảng phải thuộc: | Cách | Tốc độ | Áp cho | |---|---|---| | CloudFront origin failover | vài giây | GET/HEAD/OPTIONS | | Route 53 failover | theo TTL | mọi thứ | | Global Accelerator | vài giây | mọi thứ, TCP/UDP |

⚠ Global Accelerator là câu trả lời tốt nhất cho chuyển đổi nhanh mọi phương thức:

IP tĩnh anycast không đổi
    → chuyển đích ở tầng mạng
        ↓
    Không phụ thuộc DNS chút nào
    → và áp cho cả POST

Từ khoá nhận diện:

"failover between Regions, no DNS delay" → origin failover hoặc Global Accelerator "authenticate at the edge" → Lambda@Edge viewer request "lightweight header manipulation" → CloudFront Functions "static IP, non-HTTP" → Global Accelerator

⚠ CloudFront Functions và Lambda@Edge — bảng phải thuộc: | Tiêu chí | CloudFront Functions | Lambda@Edge | |---|---|---| | Thời gian chạy | dưới 1ms | tới 5 hoặc 30 giây | | Ngôn ngữ | JavaScript giới hạn | Node.js, Python | | Truy cập mạng | không | có | | Trigger | viewer request/response | cả bốn | | Chi phí | rẻ hơn nhiều | |

Kiểm token JWT bằng khoá cứng: Functions đủ
    → và rẻ hơn khoảng 6 lần
        ↓
    Cần gọi DynamoDB hay Secrets Manager:
      phải dùng Lambda@Edge

Ba lưu ý về Lambda@Edge: | Lưu ý | Chi tiết | |---|---| | Phải triển khai ở us-east-1 | | | Chỉ dùng phiên bản đánh số, không dùng $LATEST | | | Log nằm ở Region gần người dùng, không tập trung | |

⚠ Log phân tán là điểm gây bối rối nhất khi gỡ lỗi:

Lambda@Edge chạy ở POP Singapore
    → log vào CloudWatch ap-southeast-1
        ↓
    Tìm ở us-east-1 sẽ không thấy gì
    → phải biết người dùng ở đâu để tìm đúng Region

Ba lưu ý về origin failover: | Lưu ý | Chi tiết | |---|---| | Chỉ áp cho GET, HEAD, OPTIONS | | | Kích hoạt theo mã lỗi hoặc timeout | | | Origin dự phòng phải có cùng nội dung | |

Ba lưu ý về nhân bản dữ liệu giữa hai Region: | Lưu ý | Chi tiết | |---|---| | S3 CRR cho tệp tĩnh | | | DynamoDB global table cho dữ liệu | | | Aurora Global Database cho SQL | |

⚠ Failover ở tầng phân phối vô nghĩa nếu dữ liệu không sẵn ở Region kia:

CloudFront chuyển sang origin dự phòng
    → origin đó gọi CSDL... ở Region đã sập
        ↓
    Chuyển đổi thành công mà vẫn lỗi
    → phải nhân bản dữ liệu trước

Ba lưu ý về kiểm thử chuyển đổi: | Lưu ý | Chi tiết | |---|---| | Diễn tập định kỳ, đừng chờ sự cố thật | | | Dùng Fault Injection Service mô phỏng | | | Đo thời gian chuyển đổi thật | |

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Lambda@Edge tính theo lượt và thời gian | | | Chạy ở viewer request là MỌI yêu cầu | | | Cân nhắc CloudFront Functions cho việc nhẹ | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tắt origin chính, xem có chuyển không | | | Gửi token sai — phải bị chặn ở biên | | | Đo độ trễ trước và sau khi chuyển xác thực ra biên | |

Và một lời khuyên: hãy kiểm tra xem CloudFront Functions có đủ trước khi chọn Lambda@Edge. Xác thực ở viewer request chạy trên từng yêu cầu — chênh lệch chi phí giữa hai lựa chọn ở quy mô đó không hề nhỏ.

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

An online gambling site is hosted in two Elastic Compute Cloud (EC2) instances inside a Virtual Private Cloud (VPC) in the same Availability Zone (AZ) but in different subnets. The first EC2 instance is running a database and the other EC2 instance is a web application that fetches data from the database. You are required to ensure that the two EC2 instances can connect with each other in order for your application to work properly. You also need to track historical changes to the security configurations associated to your instances.

Which of the following options below can meet this requirement? (Select TWO.)

  1. A Ensure that the default route is set to a NAT instance or Internet Gateway (IGW).
  2. B

    Use AWS Systems Manager to track historical changes to the security configurations associated to your instances.
  3. C

    Use AWS Config to track historical changes to the security configurations associated to your instances.
  4. D

    Use Route 53 to ensure that there is proper routing between the two subnets.
  5. E

    Check and configure the network ACL to allow communication between the two subnets. Ensure that the security groups allow the application host to talk to the database on the right port and protocol.
Xem giải thích

Đáp án

C và E — Dùng AWS Config để xem lịch sử thay đổi cấu hình bảo mật; và dùng network ACL cùng security group để kiểm soát lưu lượng giữa các subnet.

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi phương án lo một cái: | Yêu cầu | Cách đáp ứng | |---|---| | Xem cấu hình bảo mật đã đổi thế nào theo thời gian | Config ghi lịch sử cấu hình | | Kiểm soát lưu lượng giữa các subnet | NACL ở tầng subnet + SG ở tầng instance |

⚠ Config là dịch vụ DUY NHẤT trả lời "cấu hình này trước đây thế nào":

CloudTrail: "AI đã gọi API nào lúc nào"
    → sự kiện, không phải trạng thái
        ↓
    Config: "tài nguyên này TRÔNG NHƯ THẾ NÀO
      vào ngày 15/8"
    → ảnh chụp trạng thái theo thời gian

Hai dịch vụ bổ sung cho nhau chứ không thay thế nhau.

Xem lịch sử một security group:

aws configservice get-resource-config-history \
  --resource-type AWS::EC2::SecurityGroup \
  --resource-id sg-0abc123 \
  --earlier-time 2026-08-01T00:00:00Z

⚠ Và Config trả về đúng cái mà điều tra sự cố cần:

Cổng 22 mở ra 0.0.0.0/0 từ bao giờ?
    → Config: trạng thái trước và sau mỗi lần đổi
        ↓
    Ghép với CloudTrail cùng khoảng thời gian
    → biết ai đã đổi

⚠ Còn NACL và security group là hai tầng khác nhau — bảng phải thuộc: | Tiêu chí | Security group | Network ACL | |---|---|---| | Áp ở | ENI (instance) | subnet | | Trạng thái | stateful | stateless | | Quy tắc | chỉ allow | allow và deny | | Xử lý | mọi quy tắc | theo số thứ tự |

⚠ "Stateless" là chỗ hay sai nhất:

NACL cho phép vào cổng 443
    → phản hồi đi ra cổng tạm 1024-65535
        ↓
    Không mở dải cổng tạm chiều RA
    → kết nối vẫn hỏng

Quy tắc NACL cho subnet ứng dụng:

aws ec2 create-network-acl-entry --network-acl-id acl-abc \
  --rule-number 100 --protocol tcp --port-range From=443,To=443 \
  --cidr-block 10.0.1.0/24 --rule-action allow --ingress

aws ec2 create-network-acl-entry --network-acl-id acl-abc \
  --rule-number 200 --protocol tcp \
  --port-range From=1024,To=65535 \
  --cidr-block 10.0.1.0/24 --rule-action allow --egress

Security group tham chiếu security group khác:

aws ec2 authorize-security-group-ingress \
  --group-id sg-csdl --protocol tcp --port 3306 \
  --source-group sg-ung-dung

⚠ Tham chiếu SG thay vì CIDR là cách viết đúng:

Cho phép từ sg-ung-dung
    → instance mới thêm vào nhóm đó
      tự động được phép
        ↓
    Không phải sửa quy tắc khi IP đổi

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Config cho lịch sử lẫn kiểm tra tuân thủ | | | Hai tầng lọc: subnet và instance | | | NACL chặn được cả những gì SG không chặn nổi | |

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

  • **A. Dùng CloudTrail để theo dõi thay đổi cấu hình bảo mật — đây là phương án gần nhất và thật sự ghi lại mọi lời gọi API, nhưng nó cho sự kiện chứ không cho trạng thái theo thời gian; muốn biết "hôm đó SG trông thế nào" phải dựng lại từ hàng loạt sự kiện.
  • **B. Dùng VPC Flow Logs để kiểm soát lưu lượng — flow log chỉ ghi lại, nó không chặn được gì.
  • **D. Dùng security group riêng cho mỗi subnet — security group gắn với ENI chứ không gắn với subnet; đây là mô tả sai về cách nó hoạt động.

Ghi nhớ

⚠ Ba dịch vụ ghi nhận hay bị lẫn — bảng phải thuộc: | Dịch vụ | Trả lời | |---|---| | CloudTrail | "ai gọi API gì, lúc nào" | | Config | "tài nguyên trông thế nào theo thời gian" | | VPC Flow Logs | "gói tin nào đi đâu" |

Từ khoá nhận diện:

"configuration history, point in time" → Config "who made the change" → CloudTrail "traffic between subnets" → NACL + SG "which traffic was accepted or rejected" → VPC Flow Logs

⚠ Điều tra sự cố cần cả ba:

Config: cổng 22 mở lúc 14:30 ngày 20/8
    ↓
CloudTrail: người dùng X gọi
  AuthorizeSecurityGroupIngress lúc đó
    ↓
Flow Logs: có ai kết nối vào cổng 22 sau đó không

Ba lưu ý về Config: | Lưu ý | Chi tiết | |---|---| | Phải bật recorder trước, không có dữ liệu quá khứ | | | Tính phí theo số bản ghi cấu hình | | | Aggregator gộp nhiều tài khoản và Region | |

⚠ "Không có dữ liệu quá khứ" là điều phải nhớ:

Sự cố xảy ra hôm nay
    → mới bật Config hôm nay
        ↓
    Không dựng lại được trạng thái tuần trước
    → bật Config là việc làm TRƯỚC, không phải
      khi cần

Ba lưu ý về NACL: | Lưu ý | Chi tiết | |---|---| | Stateless — phải mở cả hai chiều | | | Xử lý theo số thứ tự, dừng ở quy tắc khớp đầu tiên | | | Mặc định NACL của VPC cho phép tất cả | |

⚠ Đánh số cách quãng để chèn được về sau:

Đánh 100, 200, 300 thay vì 1, 2, 3
    → cần chèn quy tắc giữa: dùng 150
        ↓
    Đánh liền nhau: phải đánh số lại toàn bộ

Ba lưu ý về security group: | Lưu ý | Chi tiết | |---|---| | Stateful — phản hồi tự động được phép | | | Chỉ có allow, không có deny | | | Tham chiếu SG khác thay vì CIDR | |

⚠ Không có "deny" trong SG nghĩa là:

Muốn chặn một IP cụ thể
    → SG không làm được
        ↓
    Phải dùng NACL (có deny)
    → hoặc AWS Network Firewall

Ba lưu ý về thiết kế phân tầng: | Tầng | Quy tắc | |---|---| | Web | nhận 443 từ ALB | | Ứng dụng | nhận từ SG của web | | CSDL | nhận 3306 từ SG của ứng dụng |

Ba quy tắc Config đáng bật: | Quy tắc | Việc | |---|---| | restricted-ssh | cổng 22 không mở ra Internet | | vpc-default-security-group-closed | SG mặc định phải rỗng | | vpc-flow-logs-enabled | mọi VPC có flow log |

Ba lưu ý về AWS Network Firewall: | Lưu ý | Chi tiết | |---|---| | Lọc theo tên miền và nội dung, không chỉ IP/cổng | | | Đặt ở tầng VPC, mạnh hơn NACL | | | Tốn kém hơn, chọn khi thật sự cần | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thử kết nối từ subnet không được phép | | | Xem timeline cấu hình trong Config | | | Kiểm flow log xem có bị REJECT không | |

Và một lời khuyên: hãy dùng security group làm công cụ chính và để NACL cho những chặn thô ở tầng subnet. NACL stateless nên rất dễ tạo ra lỗi mạng khó lần — quy tắc chiều vào thì đúng, phản hồi chiều ra bị chặn, và triệu chứng chỉ là timeout không nói gì.

Câu 77 Domain - Design Solutions for Organizational Complexity

A company is using Microsoft Active Directory to manage all employee accounts and devices. The IT department instructed the solutions architect to implement a single sign-on feature to allow the employees to use their existing Windows account password to connect and use the various AWS resources.

Which of the following options is the recommended way to extend the current Active Directory domain to AWS?

  1. A

    Use IAM Roles to set up cross-account access and delegate access to resources that are in your AWS account.
  2. B

    Use AWS Directory Service to integrate your AWS resources with the existing Active Directory using trust relationship. Enable single sign-on using Managed Microsoft AD.
  3. C

    Create users and groups with AWS IAM Identity Center along with AWS Organizations to help you manage SSO access and user permissions across all the AWS accounts.
  4. D

    Use Amazon Cognito to authorize users to your applications using direct sign-in or through third-party apps, and access your apps' backend resources in AWS.
Xem giải thích

Đáp án

B — Dùng AWS Directory Service thiết lập quan hệ tin cậy với Active Directory tại chỗ, và dùng AWS Managed Microsoft AD để người dùng đăng nhập một lần vào tài nguyên AWS.

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 | |---|---| | Dùng lại danh tính AD tại chỗ | quan hệ tin cậy (forest trust) | | Đăng nhập một lần vào AWS | Managed Microsoft AD | | Không nhân bản người dùng | tin cậy thay vì sao chép |

⚠ Quan hệ tin cậy khác hẳn việc đồng bộ người dùng:

Đồng bộ: chép người dùng sang thư mục thứ hai
    → hai nơi lưu, phải giữ đồng bộ
    → mật khẩu ở đâu là nguồn sự thật?
        ↓
    Tin cậy: KHÔNG chép gì cả
    → AD tại chỗ vẫn là nơi duy nhất
    → AWS hỏi sang đó khi cần xác thực

⚠ Và chỉ Managed Microsoft AD lập được quan hệ tin cậy: | Loại thư mục | Tin cậy với AD tại chỗ | |---|---| | AWS Managed Microsoft AD | CÓ — forest trust hai chiều hoặc một chiều | | AD Connector | không — chỉ chuyển tiếp yêu cầu | | Simple AD | không |

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

Tạo thư mục:

aws ds create-microsoft-ad \
  --name congty.local --password '<mat-khau>' \
  --edition Standard \
  --vpc-settings VpcId=vpc-abc,SubnetIds=subnet-a,subnet-b

Tạo quan hệ tin cậy:

aws ds create-trust \
  --directory-id d-1234567890 \
  --remote-domain-name tai-cho.congty.com \
  --trust-password '<mat-khau-tin-cay>' \
  --trust-direction One-Way:Incoming \
  --trust-type Forest \
  --conditional-forwarder-ip-addrs 10.0.0.10 10.0.0.11

⚠ One-Way:Incoming nghĩa là:

AWS TIN CẬY miền tại chỗ
    → người dùng tại chỗ vào được tài nguyên AWS
        ↓
    Nhưng người dùng AWS KHÔNG vào được
      tài nguyên tại chỗ
    → nguyên tắc đặc quyền tối thiểu

Ánh xạ nhóm AD sang vai trò IAM:

{"Effect": "Allow", "Principal": {"Federated":
  "arn:aws:iam::123456789012:saml-provider/ThuMuc"},
 "Action": "sts:AssumeRoleWithSAML",
 "Condition": {"StringEquals":
   {"SAML:aud": "https://signin.aws.amazon.com/saml"}}}

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một nguồn danh tính duy nhất | | | Vô hiệu hoá tài khoản tại chỗ là mất quyền AWS ngay | | | Chính sách mật khẩu do AD tại chỗ quyết định | |

⚠ Lợi ích thứ hai là quan trọng nhất về mặt bảo mật:

Nhân viên nghỉ việc
    → khoá tài khoản AD
        ↓
    Mất quyền AWS NGAY LẬP TỨC
    → không phải nhớ xoá ở nơi thứ hai

⚠ Cần kết nối mạng tới AD tại chỗ:

Direct Connect hoặc Site-to-Site VPN
    → và mở các cổng AD:
      53, 88, 389, 445, 464, 636, 3268-3269,
      49152-65535
        ↓
    Thiếu kết nối: tin cậy không lập được

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

  • **A. Dùng AD Connector để chuyển tiếp yêu cầu xác thực — đây là phương án gần nhất và cũng dùng lại AD tại chỗ không sao chép gì, nhưng AD Connector là proxy thuần: nó không lập được quan hệ tin cậy và không hỗ trợ tài nguyên cần thư mục thật (như RDS SQL Server joined domain).
  • **C. Dùng Cognito user pool đồng bộ từ AD — Cognito dành cho người dùng ứng dụng bên ngoài, không phải nhân viên; và "đồng bộ" là chính điều đề muốn tránh.
  • **D. Tạo IAM user cho mỗi nhân viên — đây là nhân bản danh tính thủ công, không có đăng nhập một lần, và không co giãn.

Ghi nhớ

⚠ Ba lựa chọn Directory Service — bảng phải thuộc: | Lựa chọn | Bản chất | Chọn khi | |---|---|---| | Managed Microsoft AD | AD thật do AWS chạy | cần tin cậy, cần LDAP/GPO đầy đủ | | AD Connector | proxy tới AD tại chỗ | chỉ cần xác thực đơn giản | | Simple AD | Samba, tương thích một phần | nhu cầu nhỏ, không có AD sẵn |

Từ khoá nhận diện:

"trust relationship with on-premises AD" → Managed Microsoft AD "proxy authentication, no directory in cloud" → AD Connector "employees signing into AWS console" → IAM Identity Center "application end users" → Cognito

⚠ IAM Identity Center là câu trả lời hiện đại cho đăng nhập bảng điều khiển:

Trước đây: SAML federation tự dựng
    → mỗi tài khoản một IdP, mệt mỏi
        ↓
    Nay: IAM Identity Center
    → nối AD một lần
    → gán quyền cho mọi tài khoản trong Organizations

Ba nguồn danh tính của IAM Identity Center: | Nguồn | Trường hợp | |---|---| | Thư mục có sẵn | không có IdP | | Active Directory | có AD tại chỗ hoặc Managed AD | | IdP bên ngoài | Okta, Entra ID, Ping |

Ba lưu ý về quan hệ tin cậy: | Lưu ý | Chi tiết | |---|---| | Forest trust, không phải external trust | | | Cần conditional forwarder cho DNS | | | Một chiều là đủ và an toàn hơn | |

⚠ Conditional forwarder hay bị quên:

Managed AD phải phân giải được tên miền tại chỗ
    → và ngược lại
        ↓
    Thiếu forwarder: tin cậy lập xong
      mà không đăng nhập được
    → lỗi rất khó lần

Ba lưu ý về Managed Microsoft AD: | Lưu ý | Chi tiết | |---|---| | Chạy trên hai AZ, AWS lo vá lỗi và sao lưu | | | Standard tới 30.000 đối tượng, Enterprise 500.000 | | | Không có quyền Domain Admin, có OU riêng | |

⚠ "Không có Domain Admin" là điểm gây bất ngờ:

AWS giữ quyền quản trị gốc
    → bạn có quyền quản trị trên OU của mình
        ↓
    Đủ để tạo người dùng, nhóm, GPO
    → nhưng vài thao tác cấp forest thì không

Ba dịch vụ AWS tích hợp thư mục: | Dịch vụ | Dùng thư mục để | |---|---| | WorkSpaces | đăng nhập máy tính ảo | | RDS SQL Server | xác thực Windows | | FSx for Windows | quyền truy cập tệp |

Ba lưu ý về kết nối mạng: | Lưu ý | Chi tiết | |---|---| | Cần Direct Connect hoặc VPN | | | Mở đủ cổng AD giữa hai bên | | | Độ trễ cao làm chậm đăng nhập | |

Ba lưu ý về sẵn sàng cao: | Lưu ý | Chi tiết | |---|---| | Managed AD tự đặt hai domain controller | | | Thêm DC nếu cần chịu tải hơn | | | AD tại chỗ sập thì tin cậy không xác thực được | |

⚠ Điểm phụ thuộc cuối cùng đáng cân nhắc:

Tin cậy nghĩa là AWS hỏi sang AD tại chỗ
    → AD tại chỗ hoặc đường mạng sập
        ↓
    Đăng nhập AWS hỏng theo
    → nếu không chấp nhận được: cân nhắc
      người dùng dự phòng trong Managed AD

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập bằng tài khoản AD tại chỗ | | | Khoá tài khoản đó, thử lại — phải bị từ chối | | | Kiểm tra tin cậy bằng aws ds describe-trusts | |

Và một lời khuyên: hãy lập quan hệ tin cậy một chiều chứ đừng mặc định chọn hai chiều. Hai chiều nghĩa là AD tại chỗ cũng tin cậy môi trường AWS — và một tài khoản bị chiếm trong AWS khi đó trở thành đường vào mạng nội bộ.

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

A company is running thousands of virtualized Linux and Microsoft Windows servers on its on-premises data center. The virtual servers host a range of Java and PHP applications that are using MySQL and Oracle databases. There are also several department services hosted on an external data center. The company uses SAN storage to provide iSCSI disks to its physical servers. The company wants to migrate its data center into the AWS Cloud but the technical documentation of the systems is incomplete and outdated. The Solutions Architect was tasked to analyze the current environment and estimate the cost of migrating the resources to the cloud.

Which of the following should the Solutions Architect do to effectively plan the cloud migration? (Select THREE.)

  1. A

    Use Amazon Inspector to scan and assess the applications deployed on the on-premises virtual machines and save the generated report to an Amazon S3 bucket.
  2. B

    Use the AWS Cloud Adoption Readiness Tool (CART) to generate a migration assessment report to identify gaps in organizational skills and processes.
  3. C

    Use AWS Application Migration Service (MGN) to automate the migration of the on-premises virtual machines to the AWS Cloud.
  4. D

    Use AWS Migration Hub to discover and track the status of the application migration across AWS and partner solutions.
  5. E

    Use AWS Application Discovery Service to gather information about the running virtual machines and running applications inside the servers.
  6. F

    Use AWS X-Ray to analyze the applications running in the servers and identify possible errors that may be encountered during the migration.
Xem giải thích

Đáp án

B, D và E — Dùng Cloud Adoption Readiness Tool đánh giá mức sẵn sàng; dùng AWS Migration Hub theo dõi tiến độ di chuyển; và dùng AWS Application Discovery Service thu thập dữ liệu về máy chủ tại chỗ.

Vì sao đúng

Đề nêu ba giai đoạn của một dự án di chuyển, và mỗi công cụ lo một giai đoạn: | Giai đoạn | Công cụ | |---|---| | Trước: đánh giá mức sẵn sàng | Cloud Adoption Readiness Tool | | Trước: kiểm kê máy chủ và phụ thuộc | Application Discovery Service | | Trong: theo dõi tiến độ | Migration Hub |

⚠ Application Discovery Service là công cụ quan trọng nhất trong ba:

Không ai biết chính xác trung tâm dữ liệu
  có gì và cái nào gọi cái nào
        ↓
    Discovery Service thu thập:
    - cấu hình phần cứng
    - hiệu năng thực tế
    - kết nối mạng giữa các máy
        ↓
    Từ đó biết di chuyển cái gì trước

Hai chế độ thu thập: | Chế độ | Cách | Dùng khi | |---|---|---| | Agentless Collector | máy ảo trong VMware | môi trường VMware, không cài lên từng máy | | Discovery Agent | cài lên từng máy chủ | cần dữ liệu chi tiết, kể cả máy vật lý |

⚠ Và khác biệt về dữ liệu là điều quyết định:

Agentless: cấu hình + hiệu năng cơ bản
    → nhanh, không đụng vào máy chủ
        ↓
    Agent: thêm tiến trình đang chạy
      và KẾT NỐI MẠNG
    → đây mới là thứ vẽ được sơ đồ phụ thuộc

Xem dữ liệu đã thu thập:

aws discovery list-configurations \
  --configuration-type SERVER

aws discovery start-export-task \
  --export-data-format CSV \
  --filters name=agentIds,values=<id>,condition=EQUALS

⚠ Migration Hub gộp mọi công cụ vào một bảng:

MGN di chuyển máy chủ
    + DMS di chuyển CSDL
    + đối tác di chuyển phần khác
        ↓
    Mỗi cái báo trạng thái riêng
    → Migration Hub gộp thành một màn hình
      theo ứng dụng

Nhóm máy chủ thành ứng dụng:

aws discovery create-application \
  --name he-thong-don-hang \
  --description "Web, ung dung, CSDL"

aws discovery associate-configuration-items-to-application \
  --application-configuration-id d-application-abc \
  --configuration-ids d-server-1 d-server-2 d-server-3

⚠ Nhóm theo ứng dụng chứ không theo máy chủ là điều đúng:

Di chuyển từng máy lẻ
    → máy web sang cloud, CSDL còn tại chỗ
        ↓
    Độ trễ mỗi truy vấn tăng vọt
    → phải di chuyển cả cụm cùng lúc

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Quyết định dựa trên dữ liệu thật, không phải phỏng đoán | | | Một nơi theo dõi tiến độ toàn dự án | | | Sơ đồ phụ thuộc tránh chia nhầm đợt | |

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

⚠ Cloud Adoption Readiness Tool đã bị thay bằng công cụ khác.

CART là bảng câu hỏi tự đánh giá 16 câu, ra kết quả dạng báo cáo mức sẵn sàng. AWS nay hướng người dùng sang: | Công cụ mới | Việc | |---|---| | Migration Evaluator | đánh giá chi phí và xây dựng luận chứng kinh doanh | | AWS Cloud Adoption Framework | khung sáu trụ cột cho chuyển đổi | | Migration Readiness Assessment | đánh giá do đối tác thực hiện |

CART: bảng câu hỏi tự trả lời
    ↓
Migration Evaluator: đo tải thật
  → ước tính chi phí trên AWS
  → so với chi phí hiện tại

⚠ Application Discovery Service cũng đã được đóng gói lại:

Nay nằm trong AWS Migration Hub
    → có thêm Strategy Recommendations
      gợi ý 7R cho từng ứng dụng
        ↓
    Vẫn là cùng cơ chế thu thập
    → chỉ khác cách tiếp cận và giao diện

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

  • **A. Dùng AWS Server Migration Service (SMS) để đánh giá — đây là phương án gần nhất và SMS thật sự là công cụ di chuyển máy chủ, nhưng nó thực hiện việc di chuyển chứ không đánh giá hay theo dõi; ngoài ra SMS đã bị thay bằng Application Migration Service (MGN).
  • **C. Dùng AWS DataSync để thu thập dữ liệu máy chủ — DataSync chuyển tệp, nó không kiểm kê máy chủ.
  • **F. Dùng Trusted Advisor để đánh giá mức sẵn sàng — Trusted Advisor kiểm tra tài nguyên đã có trên AWS, nó không nhìn thấy trung tâm dữ liệu tại chỗ.

Ghi nhớ

⚠ Ba giai đoạn di chuyển và công cụ tương ứng — bảng phải thuộc: | Giai đoạn | Công cụ | |---|---| | Đánh giá | Migration Evaluator, Discovery Service | | Chuẩn bị | Migration Hub, Strategy Recommendations | | Di chuyển | MGN, DMS, DataSync, Transfer Family |

Từ khoá nhận diện:

"discover on-premises servers and dependencies" → Application Discovery Service "track migration progress across tools" → Migration Hub "build business case, estimate cost" → Migration Evaluator "lift and shift servers" → MGN "migrate database" → DMS + SCT

⚠ Bảy chiến lược 7R — phải thuộc: | Chiến lược | Nghĩa | |---|---| | Rehost | chuyển nguyên, không sửa | | Replatform | sửa nhẹ, ví dụ sang RDS | | Repurchase | đổi sang SaaS | | Refactor | viết lại theo kiến trúc cloud | | Relocate | chuyển VMware sang VMware Cloud | | Retain | giữ tại chỗ | | Retire | bỏ hẳn |

⚠ Retire thường là chiến lược sinh lời nhất:

Khảo sát điển hình: 10-20% máy chủ
  không còn ai dùng
        ↓
    Discovery Service cho thấy máy nào
      không có kết nối mạng nào
    → tắt luôn, tiết kiệm ngay

Ba lưu ý về Discovery Service: | Lưu ý | Chi tiết | |---|---| | Thu thập ít nhất 2 tuần để thấy chu kỳ tải | | | Agentless nhanh nhưng ít dữ liệu hơn | | | Xuất được CSV để phân tích ngoài | |

⚠ Hai tuần là con số tối thiểu có lý do:

Thu thập một ngày
    → không thấy tải cuối tuần
    → không thấy job chạy cuối tháng
        ↓
    Định cỡ theo dữ liệu thiếu
    → máy thiếu công suất đúng lúc bận nhất

Ba lưu ý về Migration Hub: | Lưu ý | Chi tiết | |---|---| | Chọn một Region làm nơi tập trung | | | Miễn phí, chỉ trả tiền công cụ bên dưới | | | Nhóm theo ứng dụng, không theo máy lẻ | |

Ba lưu ý về MGN: | Lưu ý | Chi tiết | |---|---| | Nhân bản liên tục ở mức khối | | | Kiểm thử nhiều lần không ảnh hưởng nguồn | | | Cutover thật khi đã kiểm thử xong | |

⚠ Kiểm thử không ảnh hưởng nguồn là điểm mạnh nhất của MGN:

Nhân bản vẫn chạy
    → khởi động instance kiểm thử từ bản sao
        ↓
    Kiểm thử bao nhiêu lần cũng được
    → hệ thống thật không hề biết

Ba lưu ý về định cỡ: | Lưu ý | Chi tiết | |---|---| | Máy tại chỗ thường thừa công suất rất nhiều | | | Định cỡ theo dữ liệu hiệu năng thật | | | Compute Optimizer tinh chỉnh tiếp sau khi lên | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đối chiếu kiểm kê với danh sách tài sản hiện có | | | Xem sơ đồ phụ thuộc có hợp lý không | | | Kiểm tra Migration Hub hiện đủ mọi luồng | |

Và một lời khuyên: hãy dành đủ thời gian cho giai đoạn khám phá trước khi di chuyển bất cứ thứ gì. Gần như mọi dự án di chuyển gặp trục trặc đều bắt đầu từ một phụ thuộc không ai biết — và nó luôn lộ ra vào đêm cutover chứ không phải trước đó.

Câu 79 Domain - Continuous Improvement for Existing Solutions

A financial startup offers flexible short-term loans of up to $5,000 to its users. Their online portal is hosted in AWS which uses S3 for scalable storage, DynamoDB as a NoSQL database, and a fleet of EC2 instances to host their web servers. To meet the financial regulation, the company is required to undergo a compliance audit.

In this scenario, how will you provide the auditor access to the logs of your AWS resources?

  1. A 1. Create an SNS Topic. 2. Configure the SNS to send out an email with the attached CloudTrail log files to the auditor's email every time the CloudTrail delivers the logs to S3.
  2. B 1. Contact AWS and inform them of the upcoming audit activities. 2. AWS will grant required access to the third-party auditor to see the logs.
  3. C 1. Create an IAM role that has the required permissions for the auditor. 2. Attach the roles to the EC2, S3, and DynamoDB.
  4. D 1. Enable CloudTrail logging to required AWS resources. 2. Create an IAM user with read-only permissions to the required AWS resources. 3. Provide the access credential to the auditor.
Xem giải thích

Đáp án

D — Bật AWS CloudTrail ghi lại mọi lời gọi API, và tạo IAM user với quyền chỉ đọc cho kiểm toán viên.

Vì sao đúng

Đề nêu hai yêu cầu, và phương án này khớp từng cái: | Yêu cầu | Cách đáp ứng | |---|---| | Kiểm toán viên xem được mọi hoạt động | CloudTrail ghi mọi lời gọi API | | Không được sửa gì | quyền chỉ đọc |

⚠ CloudTrail là nguồn ghi nhận hoạt động duy nhất trên AWS:

Mọi thao tác trên AWS đều là một lời gọi API
    → dù qua bảng điều khiển, CLI hay SDK
        ↓
    CloudTrail ghi lại tất cả
    → ai, làm gì, khi nào, từ IP nào

Chính sách chỉ đọc cho kiểm toán viên:

aws iam attach-user-policy --user-name kiem-toan-vien \
  --policy-arn arn:aws:iam::aws:policy/SecurityAudit

aws iam attach-user-policy --user-name kiem-toan-vien \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

⚠ Hai chính sách quản lý này khác nhau — bảng phải thuộc: | Chính sách | Phạm vi | |---|---| | ReadOnlyAccess | đọc được MỌI THỨ, kể cả nội dung dữ liệu | | SecurityAudit | chỉ đọc CẤU HÌNH bảo mật, không đọc dữ liệu | | ViewOnlyAccess | chỉ liệt kê tài nguyên, không xem chi tiết |

Kiểm toán viên cần xem cấu hình bảo mật
    → SecurityAudit là lựa chọn đúng
        ↓
    ReadOnlyAccess cho phép đọc luôn
      object trong S3 — thường là quá rộng

⚠ Nhưng chỉ gán quyền đọc chưa đủ — phải chặn cả sửa log:

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

Kiểm toán viên có ReadOnlyAccess
    → không sửa được gì
        ↓
    Nhưng thêm Deny tường minh là lớp bảo vệ
      không phụ thuộc việc gán chính sách đúng

Bật trail cho toàn tổ chức:

aws cloudtrail create-trail --name trail-to-chuc \
  --s3-bucket-name log-kiem-toan \
  --is-organization-trail \
  --is-multi-region-trail \
  --enable-log-file-validation

⚠ --enable-log-file-validation là yêu cầu bắt buộc với kiểm toán:

Sinh tệp digest ký số cho mỗi giờ log
    → chứng minh log không bị sửa
        ↓
    Không có nó: log chỉ là tệp text
      trong S3, ai có quyền ghi đều sửa được

Kiểm chứng tính toàn vẹn:

aws cloudtrail validate-logs \
  --trail-arn <arn> --start-time 2026-08-01T00:00:00Z

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Ghi nhận đầy đủ, không sót thao tác nào | | | Kiểm toán viên tự phục vụ, không cần xin dữ liệu | | | Không có rủi ro họ sửa nhầm gì | |

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

  • **C. Bật CloudTrail và cấp IAM role có quyền quản trị cho kiểm toán viên — đây là phương án gần nhất và có CloudTrail đúng, nhưng quyền quản trị vi phạm thẳng yêu cầu "không được sửa gì" và vi phạm đặc quyền tối thiểu.
  • **A. Dùng VPC Flow Logs cho hoạt động kiểm toán — flow log chỉ ghi lưu lượng mạng, không ghi lời gọi API.
  • **B. Dùng CloudWatch Logs làm nguồn kiểm toán — CloudWatch Logs là nơi chứa log, nhưng nó không tự sinh ra bản ghi hoạt động API; CloudTrail mới là dịch vụ đó.

Ghi nhớ

⚠ Ba nguồn ghi nhận hay bị lẫn — bảng phải thuộc: | Nguồn | Ghi gì | |---|---| | CloudTrail | lời gọi API — ai làm gì | | VPC Flow Logs | gói tin — luồng mạng | | CloudWatch Logs | log do ứng dụng và dịch vụ đẩy vào |

Từ khoá nhận diện:

"who did what, when" → CloudTrail "auditor, read-only" → SecurityAudit hoặc ReadOnlyAccess "prove logs were not tampered" → log file validation + Object Lock "configuration history" → Config

⚠ Hai loại sự kiện CloudTrail — bảng phải thuộc: | Loại | Ví dụ | Mặc định | |---|---|---| | Management event | CreateBucket, RunInstances | BẬT, miễn phí bản đầu | | Data event | GetObject, PutItem, Invoke | TẮT, tính phí |

Câu hỏi kiểu "ai đã ĐỌC tệp này"
    → cần DATA event
        ↓
    Chỉ bật management event
    → không có bản ghi nào về việc đọc

Bật data event cho bucket nhạy cảm:

aws cloudtrail put-event-selectors --trail-name trail-to-chuc \
  --advanced-event-selectors '[{
    "Name": "Doc ghi bucket nhay cam",
    "FieldSelectors": [
      {"Field": "eventCategory", "Equals": ["Data"]},
      {"Field": "resources.type", "Equals": ["AWS::S3::Object"]},
      {"Field": "resources.ARN", "StartsWith":
        ["arn:aws:s3:::du-lieu-nhay-cam/"]}]}]'

⚠ Chỉ bật cho bucket cần thiết vì chi phí:

Data event tính phí theo số sự kiện
    → bucket lưu lượng cao có thể tốn
      hơn cả chi phí lưu trữ
        ↓
    Dùng bộ chọn nâng cao giới hạn tiền tố

Ba lưu ý về bảo vệ log kiểm toán: | Lưu ý | Chi tiết | |---|---| | Bucket log ở tài khoản RIÊNG | | | Bật S3 Object Lock chế độ compliance | | | Bật MFA Delete | |

⚠ Tài khoản riêng là biện pháp quan trọng nhất:

Log nằm cùng tài khoản bị xâm nhập
    → kẻ tấn công xoá luôn dấu vết
        ↓
    Tài khoản log riêng, chỉ nhận ghi
    → dù mất tài khoản chính vẫn còn bằng chứng

Ba lưu ý về CloudTrail Lake: | Lưu ý | Chi tiết | |---|---| | Kho dữ liệu sự kiện có truy vấn SQL sẵn | | | Giữ tới 10 năm | | | Không cần dựng Athena và bảng phân vùng | |

SELECT userIdentity.arn, eventName, eventTime
FROM <ma-kho-du-lieu>
WHERE eventName = 'DeleteBucket'
  AND eventTime > '2026-08-01'

Ba lưu ý về Organizations trail: | Lưu ý | Chi tiết | |---|---| | Một trail cho mọi tài khoản thành viên | | | Tài khoản con không tắt được | | | Tự áp cho tài khoản mới tham gia | |

Ba lưu ý về cảnh báo: | Lưu ý | Chi tiết | |---|---| | Metric filter cho thao tác nhạy cảm | | | EventBridge cho phản ứng thời gian thực | | | GuardDuty phân tích CloudTrail tự động | |

⚠ Bốn thao tác nên cảnh báo ngay:

`StopLogging` — có người tắt ghi nhận
`DeleteTrail` — có người xoá trail
`ConsoleLogin` với root — dùng tài khoản gốc
`AuthorizeSecurityGroupIngress` mở 0.0.0.0/0

Ba lưu ý về đặc quyền tối thiểu: | Lưu ý | Chi tiết | |---|---| | Bắt đầu bằng chính sách quản lý sẵn | | | Thu hẹp bằng IAM Access Analyzer | | | Rà soát định kỳ quyền không dùng tới | |

⚠ Và nên dùng vai trò thay vì IAM user:

Kiểm toán viên là người bên ngoài
    → IAM user nghĩa là access key tồn tại lâu
        ↓
    Vai trò với tin cậy xuyên tài khoản
      + External ID
    → credential tạm, hết hạn tự động

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đăng nhập bằng tài khoản kiểm toán, thử sửa — phải bị từ chối | | | Chạy validate-logs xem log toàn vẹn | | | Kiểm tra trail bao phủ mọi Region | |

Và một lời khuyên: hãy đặt log kiểm toán ở một tài khoản mà không ai trong đội vận hành có quyền ghi. Ghi nhận nằm cùng chỗ với thứ nó ghi nhận thì chỉ có giá trị cho tới khi chỗ đó bị chiếm — đúng lúc bạn cần nó nhất.

Câu 80 Domain - Design for New Solutions

A leading online media company runs a popular sports news website. The solutions architect has been tasked to analyze each web visitor's clickstream data on the website to populate user analytics, which gives insights about the sequence of pages and advertisements the visitor has clicked. The data will be processed in real-time which will then transform the page layout as the visitors click through the web portal to increase user engagement and consequently, increase the revenue for the company.

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

  1. A Publish web clicks by session to an Amazon SQS queue and periodically drain these events to Amazon RDS then analyze with SQL.
  2. B

    Publish the web clicks to Amazon Timestream. Run custom analysis, SQL queries and apply machine learning to generate relevant reports regarding user behavior.
  3. C Push web clicks by session to Amazon Kinesis and analyze behavior using Amazon Kinesis workers.
  4. D Log clicks in weblogs by URL and store it in Amazon S3, and then analyze with Elastic MapReduce.
Xem giải thích

Đáp án

C — Dùng Amazon Kinesis để thu nhận dữ liệu clickstream và các worker đọc từ Kinesis để xử lý.

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 | |---|---| | Thu nhận luồng sự kiện tốc độ cao | Kinesis Data Streams | | Nhiều ứng dụng xử lý cùng dữ liệu | nhiều consumer đọc song song | | Giữ thứ tự và phát lại được | shard giữ thứ tự, dữ liệu lưu tới 365 ngày |

⚠ Ba đặc tính của Kinesis mà hàng đợi không có:

1. NHIỀU consumer đọc CÙNG dữ liệu độc lập
   → phân tích thời gian thực, lưu trữ,
     máy học — mỗi cái một luồng
        ↓
2. GIỮ THỨ TỰ trong mỗi shard
   → chuỗi click của một người dùng
     đúng trình tự
        ↓
3. PHÁT LẠI được
   → sửa lỗi thuật toán rồi chạy lại
     dữ liệu cũ

⚠ Điểm 1 là điều SQS không làm được:

SQS: một thông điệp, một người đọc lấy đi
    → đọc xong là biến mất
        ↓
    Kinesis: dữ liệu nằm lại đủ thời gian giữ
    → mỗi consumer có con trỏ riêng

Tạo luồng:

aws kinesis create-stream --stream-name luong-click \
  --stream-mode-details StreamMode=ON_DEMAND

⚠ Chọn khoá phân vùng quyết định hiệu năng:

partitionKey = idNguoiDung
    → mọi click của một người vào cùng shard
    → giữ đúng thứ tự
        ↓
    Nhưng người dùng cực kỳ hoạt động
      tạo shard nóng
    → cân nhắc idNguoiDung#soNgauNhien
      nếu không cần thứ tự tuyệt đối

Ghi vào luồng:

import boto3, json
kinesis = boto3.client('kinesis')
kinesis.put_record(
    StreamName='luong-click',
    Data=json.dumps({'idNguoiDung': 'u123',
                     'trang': '/san-pham/42',
                     'thoiGian': '2026-08-30T10:15:00Z'}),
    PartitionKey='u123')

⚠ Consumer nâng cao cho độ trễ thấp:

aws kinesis register-stream-consumer \
  --stream-arn <arn> --consumer-name phan-tich-thoi-gian-thuc

Consumer thường: chia sẻ 2 MB/giây mỗi shard
    → nhiều consumer thì tranh nhau
        ↓
    Enhanced fan-out: mỗi consumer
      2 MB/giây RIÊNG
    → độ trễ trung bình 70ms thay vì 200ms+

Ba lợi ích: | Lợi ích | Chi tiết | |---|---| | Một luồng phục vụ nhiều mục đích xử lý | | | Phát lại khi có lỗi hoặc thêm phân tích mới | | | On-demand tự co giãn theo lưu lượng | |

⚠ Và ON_DEMAND loại bỏ bài toán chia shard:

Provisioned: phải tự tính số shard
    → mỗi shard 1 MB/giây ghi, 1.000 bản ghi/giây
    → vượt là ProvisionedThroughputExceeded
        ↓
    On-demand: AWS tự lo, tới 200 MB/giây
    → đắt hơn nhưng không phải canh

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

  • **B. Dùng SQS với nhiều worker đọc — đây là phương án gần nhất và cũng tách được người gửi khỏi người xử lý, nhưng thông điệp SQS bị tiêu thụ mất: hai hệ thống phân tích khác nhau không đọc được cùng một sự kiện, và không phát lại được.
  • **A. Ghi thẳng vào RDS rồi truy vấn — CSDL quan hệ không chịu nổi tốc độ ghi của clickstream, và mỗi consumer phải tự quản lý con trỏ đọc.
  • **D. Ghi thẳng vào S3 rồi xử lý theo lô — mất tính thời gian thực; hợp cho phân tích nguội chứ không cho xử lý ngay.

Ghi nhớ

⚠ Bốn dịch vụ nhắn tin — bảng phải thuộc: | Dịch vụ | Mô hình | Chọn khi | |---|---|---| | SQS | hàng đợi, đọc là mất | một người xử lý mỗi việc | | SNS | phát tán, đẩy đi | thông báo nhiều đích | | Kinesis Data Streams | luồng, giữ lại | nhiều consumer, giữ thứ tự, phát lại | | EventBridge | định tuyến sự kiện | kết nối dịch vụ theo quy tắc |

Từ khoá nhận diện:

"clickstream, real-time analytics" → Kinesis Data Streams "multiple consumers, same data" → Kinesis "replay, ordered" → Kinesis "one worker per message" → SQS "deliver to S3/Redshift with no code" → Data Firehose

⚠ Kinesis Data Streams và Data Firehose — bảng phải thuộc: | Tiêu chí | Data Streams | Data Firehose | |---|---|---| | Xử lý | tự viết consumer | không cần mã | | Đích | bất kỳ | S3, Redshift, OpenSearch, Splunk | | Độ trễ | dưới 1 giây | tối thiểu 60 giây | | Giữ lại | 1-365 ngày | không giữ | | Phát lại | có | không |

Cần xử lý thời gian thực và phát lại
    → Data Streams
        ↓
    Chỉ cần đưa dữ liệu vào S3/Redshift
    → Firehose, đơn giản hơn nhiều

⚠ Và mẫu kiến trúc phổ biến dùng CẢ HAI:

Kinesis Data Streams (nguồn duy nhất)
    ├─ consumer 1: Lambda phân tích thời gian thực
    ├─ consumer 2: Firehose → S3 (lưu trữ nguội)
    └─ consumer 3: Managed Service for Apache Flink
                   (cửa sổ trượt, phát hiện bất thường)

Ba lưu ý về shard: | Lưu ý | Chi tiết | |---|---| | Mỗi shard: ghi 1 MB/giây, đọc 2 MB/giây | | | Khoá phân vùng quyết định shard | | | Khoá lệch tạo shard nóng | |

Ba lưu ý về thời gian giữ: | Lưu ý | Chi tiết | |---|---| | Mặc định 24 giờ | | | Tăng tới 7 ngày (thường) hoặc 365 ngày | | | Giữ lâu hơn thì tính thêm phí | |

⚠ Thời gian giữ là biên an toàn khi consumer hỏng:

Consumer chết lúc 2 giờ sáng
    → phát hiện lúc 9 giờ sáng
        ↓
    Giữ 24 giờ: còn kịp xử lý bù
    → giữ mặc định là đủ cho hầu hết trường hợp

Ba lưu ý về Kinesis Client Library: | Lưu ý | Chi tiết | |---|---| | Tự phân chia shard giữa các worker | | | Lưu con trỏ đọc trong DynamoDB | | | Tự xử lý khi worker chết | |

⚠ Bảng DynamoDB của KCL là chi phí ẩn hay bị quên:

KCL tạo bảng cùng tên ứng dụng
    → ghi checkpoint liên tục
        ↓
    Nhiều shard + checkpoint dày
    → chi phí DynamoDB đáng kể
    → dùng on-demand hoặc giãn checkpoint

Ba lưu ý về Lambda làm consumer: | Lưu ý | Chi tiết | |---|---| | Đơn giản nhất, không phải quản KCL | | | Một lô thất bại chặn cả shard | | | Cấu hình BisectBatchOnFunctionError và DLQ | |

⚠ "Chặn cả shard" là bẫy nghiêm trọng:

Một bản ghi hỏng làm Lambda ném lỗi
    → Lambda thử lại mãi
        ↓
    Shard đó dừng hoàn toàn
    → dữ liệu mới dồn lại
    → phải đặt `MaximumRetryAttempts`
      và DLQ để bỏ qua bản ghi độc

Ba lưu ý về chi phí: | Lưu ý | Chi tiết | |---|---| | Provisioned rẻ hơn khi tải ổn định | | | On-demand hợp với tải khó đoán | | | Enhanced fan-out tính phí riêng mỗi consumer | |

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Theo dõi IteratorAgeMilliseconds | | | Kiểm WriteProvisionedThroughputExceeded | | | Thử phát lại từ mốc thời gian cũ | |

⚠ IteratorAgeMilliseconds là chỉ số quan trọng nhất:

Nó cho biết consumer đang chậm hơn
  nguồn bao nhiêu
        ↓
    Tăng đều đặn → consumer không theo kịp
    → chạm thời gian giữ là MẤT DỮ LIỆU

Và một lời khuyên: hãy đặt cảnh báo trên IteratorAgeMilliseconds ngay từ ngày đầu. Đó là chỉ số duy nhất báo trước việc mất dữ liệu — và khi nó chạm ngưỡng thời gian giữ thì dữ liệu đã đi rồi, không có cách nào lấy lại.