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

Tìm thấy 2194 câu.

Câu 61 Design Secure Architectures

A company uses an Application Load Balancer (ALB) for its public-facing multi-tier web applications. The security team has recently reported that there has been a surge of SQL injection attacks lately, which causes critical data discrepancy issues. The same issue is also encountered by its other web applications in other AWS accounts that are behind an ALB. An immediate solution is required to prevent the remote injection of unauthorized SQL queries and protect their applications hosted across multiple accounts.

As a Solutions Architect, what solution would you recommend?

  1. A

    Use AWS Network Firewall to filter web vulnerabilities and brute force attacks using stateful rule groups across all Application Load Balancers on all AWS accounts. Refactor the web application to be less susceptible to SQL injection attacks based on the security assessment.
  2. B

    Use AWS WAF and set up a managed rule to block request patterns associated with the exploitation of SQL databases, like SQL injection attacks. Associate it with the Application Load Balancer. Integrate AWS WAF with AWS Firewall Manager to reuse the rules across all the AWS accounts.
  3. C

    Use Amazon Macie to scan for vulnerabilities and unintended network exposure. Refactor the web application to be less susceptible to SQL injection attacks based on the security assessment. Utilize the AWS Audit Manager to reuse the security assessment across all AWS accounts.
  4. D

    Use Amazon GuardDuty and set up a managed rule to block request patterns associated with the exploitation of SQL databases, like SQL injection attacks. Associate it with the Application Load Balancer and utilize the AWS Security Hub service to reuse the managed rules across all the AWS accounts
Xem giải thích

Đáp án

B — Dùng AWS WAF và thiết lập một managed rule chặn các mẫu request liên quan tới khai thác cơ sở dữ liệu SQL như SQL injection. Gắn nó vào Application Load Balancer. Tích hợp AWS WAF với AWS Firewall Manager để dùng lại các rule đó trên mọi tài khoản AWS.

Vì sao đúng

Đề nêu ba yêu cầu, và B đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Ngăn SQL injection | WAF managed rule cho SQLi | | Áp cho ALB | WAF gắn được vào ALB | | Dùng lại trên NHIỀU tài khoản AWS | AWS Firewall Manager |

WAF managed rule cho SQL injection có sẵn và được AWS cập nhật liên tục: | Rule group | Nội dung | |---|---| | AWSManagedRulesSQLiRuleSet | chuyên cho SQL injection | | AWSManagedRulesCommonRuleSet | OWASP phổ biến, gồm cả một số quy tắc SQLi | | AWSManagedRulesKnownBadInputsRuleSet | mẫu khai thác đã biết |

Vì sao dùng managed rule thay vì tự viết:

Tự viết rule chặn SQLi:
    → phải nghĩ ra mọi biến thể: ' OR 1=1, UNION SELECT, mã hoá hex,
      comment /**/, encode URL, encode Unicode...
    → kẻ tấn công tìm ra biến thể mới liên tục
    → bạn phải theo kịp mãi mãi

Managed rule:
    → AWS cập nhật khi có kỹ thuật tấn công mới
    → không cần bảo trì

Và Firewall Manager giải quyết vế "across multiple accounts":

Firewall Manager (tài khoản quản trị)
    ↓ định nghĩa MỘT WAF policy
Tự động áp cho MỌI ALB ở MỌI tài khoản trong tổ chức
    → kể cả ALB MỚI được tạo sau này

Dòng cuối là giá trị lớn nhất: đội nào đó dựng ALB mới cũng tự động được bảo vệ, không cần ai nhớ cấu hình.

Đề nói rõ vấn đề xảy ra ở "other AWS accounts" — nên quản lý tập trung là yêu cầu thật, không phải tính năng thừa.

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

  • A. Dùng AWS Network Firewall lọc lỗ hổng web và tấn công brute force bằng stateful rule group trên mọi ALB; tái cấu trúc ứng dụng cho ít bị SQL injection hơn — đây là phương án gần nhất về mặt cũng là một tường lửa, nhưng nó sai tầng: Network Firewall bảo vệ lưu lượng ở tầng mạng của VPC, nó không gắn được vào ALB và không được thiết kế để phân tích request HTTP. Và "refactor ứng dụng" không phải giải pháp TỨC THÌ mà đề yêu cầu.
  • D. Dùng Amazon GuardDuty và thiết lập managed rule chặn mẫu SQL injection; gắn vào ALB; dùng Security Hub để tái sử dụng rule — GuardDuty KHÔNG CHẶN gì cả: nó phát hiện mối đe doạ và sinh finding. Nó không có "managed rule", không gắn được vào ALB, và Security Hub tổng hợp finding chứ không phân phối rule.
  • C. Dùng Amazon Macie quét lỗ hổng và phơi nhiễm mạng; tái cấu trúc ứng dụng; dùng AWS Audit Manager để tái sử dụng đánh giá bảo mật — sai dịch vụ hoàn toàn: Macie phát hiện dữ liệu nhạy cảm trong S3. Nó không quét lỗ hổng ứng dụng web và không chặn tấn công.

Ghi nhớ

Ba dịch vụ tường lửa của AWS — phân biệt tầng hoạt động: | Dịch vụ | Tầng | Bảo vệ | |---|---|---| | AWS WAF | tầng 7 (HTTP) | CloudFront, ALB, API Gateway, AppSync | | AWS Network Firewall | tầng 3/4 (và một phần 7) | lưu lượng VPC — giữa subnet, ra Internet | | Security group / NACL | tầng 3/4 | ENI / subnet | | AWS Shield | tầng 3/4/7 | chống DDoS |

Câu hỏi phân biệt:

"SQL injection", "XSS", "HTTP request", "web application" → WAF "VPC traffic", "intrusion prevention", "domain filtering" → Network Firewall "DDoS" → Shield

Các bộ managed rule của WAF đáng biết: | Bộ | Bảo vệ | |---|---| | AWSManagedRulesSQLiRuleSet | SQL injection ← câu này | | AWSManagedRulesCommonRuleSet | OWASP Top 10 phổ biến | | AWSManagedRulesKnownBadInputsRuleSet | Log4j, mẫu khai thác đã biết | | AWSManagedRulesAmazonIpReputationList | IP có tiếng xấu | | AWSManagedRulesBotControlRuleSet | nhận diện và phân loại bot | | AWSManagedRulesLinuxRuleSet, ...PHPRuleSet | theo nền tảng |

Ba điều kiện tiên quyết để dùng Firewall Manager:

① AWS Organizations bật với "all features"
② Chỉ định một tài khoản làm Firewall Manager administrator
③ AWS Config bật ở MỌI tài khoản và Region cần quản lý

Điều kiện ③ hay bị bỏ sót — Firewall Manager dựa vào Config để biết tài nguyên nào tồn tại.

Các loại policy của Firewall Manager: | Loại | Quản lý | |---|---| | AWS WAF policy | web ACL cho CloudFront, ALB, API Gateway ← câu này | | Shield Advanced policy | bảo vệ DDoS | | Security group policy | common, content audit, usage audit | | Network Firewall policy | tường lửa mạng VPC | | DNS Firewall policy | chặn truy vấn DNS độc hại |

Nhớ bật RemediationEnabled — nếu không, policy chỉ báo cáo tài nguyên không tuân thủ mà không tự gắn web ACL (xem câu #7782).

Quy trình triển khai an toàn cho WAF managed rule:

① Đặt rule group ở action Count
② Bật log WAF, quan sát vài ngày
③ Kiểm tra request HỢP LỆ nào bị khớp nhầm
④ Thêm exception cho các rule gây báo động giả
⑤ Chuyển sang Block

Bước ③ quan trọng với ứng dụng có form nhập liệu phức tạp: managed rule SQLi đôi khi khớp nhầm nội dung hợp lệ chứa dấu nháy hoặc từ khoá SQL.

Và một điểm mà phương án A nói đúng dù bị loại: sửa chính ứng dụng vẫn là biện pháp gốc rễ. WAF là lớp phòng thủ bổ sung, không thay thế cho prepared statement và parameterized query — một ứng dụng dùng đúng cách truy vấn tham số hoá thì miễn nhiễm với SQL injection ngay cả khi không có WAF.

Câu 62 Design Secure Architectures

A payment processing company plans to migrate its on-premises application to an Amazon EC2 instance. An IPv6 CIDR block is attached to the company’s Amazon VPC. Strict security policy mandates that the production VPC must only allow outbound communication over IPv6 between the instance and the internet but should prevent the internet from initiating an inbound IPv6 connection. The new architecture should also allow traffic flow inspection and traffic filtering.

What should a solutions architect do to meet these requirements?

  1. A

    Launch the EC2 instance to a public subnet and attach an Internet Gateway to the VPC to allow outbound IPv6 communication to the internet. Use Traffic Mirroring to set up the required rules for traffic inspection and traffic filtering.
  2. B

    Launch the EC2 instance to a private subnet and attach AWS PrivateLink interface endpoint to the VPC to control outbound IPv6 communication to the internet. Use Amazon GuardDuty to set up the required rules for traffic inspection and traffic filtering.
  3. C

    Launch the EC2 instance to a private subnet and attach a NAT Gateway to the VPC to allow outbound IPv6 communication to the internet. Use AWS Firewall Manager to set up the required rules for traffic inspection and traffic filtering.
  4. D

    Launch the EC2 instance to a private subnet and attach an Egress-Only Internet Gateway to the VPC to allow outbound IPv6 communication to the internet. Use AWS Network Firewall to set up the required rules for traffic inspection and traffic filtering.
Xem giải thích

Đáp án

D — Khởi chạy EC2 instance trong private subnet và gắn một Egress-Only Internet Gateway vào VPC để cho phép giao tiếp IPv6 ra Internet. Dùng AWS Network Firewall để thiết lập các quy tắc kiểm tra và lọc lưu lượng.

Vì sao đúng

Đề nêu ba yêu cầu, và D đáp ứng cả ba: | Yêu cầu | Cơ chế | |---|---| | Chỉ cho phép giao tiếp IPv6 đi RA | Egress-Only Internet Gateway | | Ngăn Internet khởi tạo kết nối VÀO | EIGW có TRẠNG THÁI, chặn kết nối vào | | Kiểm tra và lọc lưu lượng | AWS Network Firewall |

Egress-Only Internet Gateway là dịch vụ được tạo ra chính xác cho bài toán này:

Vấn đề với IPv6:
    Địa chỉ IPv6 đều là ĐỊA CHỈ CÔNG KHAI, có thể định tuyến toàn cầu
    → không có khái niệm "IP riêng" như IPv4
    → gắn IGW thông thường = phơi instance ra Internet cả hai chiều

Egress-Only Internet Gateway:
    → CÓ TRẠNG THÁI (stateful)
    → cho phép lưu lượng đi RA và phản hồi tương ứng đi vào
    → CHẶN mọi kết nối do Internet KHỞI TẠO

Nó là bản tương đương IPv6 của NAT Gateway về mặt chức năng bảo mật — nhưng khác về cơ chế: | | NAT Gateway (IPv4) | Egress-Only IGW (IPv6) | |---|---|---| | Dịch địa chỉ | CÓ — nhiều IP riêng thành một IP công khai | KHÔNG — IPv6 giữ nguyên địa chỉ | | Chặn kết nối vào | ✅ | ✅ | | Chi phí | tính phí theo giờ + GB | MIỄN PHÍ |

Dòng cuối đáng chú ý: Egress-Only IGW không tốn phí — khác hẳn NAT Gateway.

Và AWS Network Firewall cho vế "traffic flow inspection and traffic filtering": | Khả năng | Chi tiết | |---|---| | Stateful inspection | theo dõi trạng thái kết nối | | Quy tắc Suricata | luật IPS tiêu chuẩn ngành | | Lọc theo tên miền | chặn truy cập tới domain độc hại | | Ghi log luồng và cảnh báo | phục vụ điều tra |

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

  • C. Khởi chạy EC2 trong private subnet và gắn NAT Gateway để cho phép giao tiếp IPv6 ra Internet; dùng AWS Firewall Manager thiết lập quy tắc kiểm tra — đây là phương án gần nhất và cấu trúc hoàn toàn hợp lý cho IPv4, nhưng nó sai với IPv6: NAT Gateway CHỈ hỗ trợ IPv4. Với IPv6 phải dùng Egress-Only IGW. (Và Firewall Manager là công cụ QUẢN LÝ tập trung, không tự kiểm tra lưu lượng.)
  • A. Khởi chạy EC2 trong public subnet và gắn Internet Gateway để cho phép giao tiếp IPv6 ra Internet; dùng Traffic Mirroring để thiết lập quy tắc — hai lỗi: IGW thông thường cho phép cả kết nối VÀO — trái thẳng chính sách bảo mật; và Traffic Mirroring chỉ SAO CHÉP lưu lượng để giám sát, nó không lọc hay chặn gì cả.
  • B. Khởi chạy EC2 trong private subnet và gắn AWS PrivateLink interface endpoint để kiểm soát giao tiếp IPv6 ra Internet; dùng GuardDuty thiết lập quy tắc lọc — hai lỗi: PrivateLink cho phép truy cập dịch vụ AWS hoặc dịch vụ đối tác cụ thể một cách riêng tư — nó không phải đường ra Internet; và GuardDuty phát hiện mối đe doạ, không lọc lưu lượng.

Ghi nhớ

Bốn loại gateway của VPC — bảng cần thuộc: | Gateway | Giao thức | Chiều | |---|---|---| | Internet Gateway (IGW) | IPv4 và IPv6 | CẢ HAI chiều | | NAT Gateway | CHỈ IPv4 | chỉ ra (stateful) | | Egress-Only IGW | CHỈ IPv6 | chỉ ra (stateful) ← câu này | | Virtual Private Gateway | — | kết nối VPN |

Bảng này là nội dung cốt lõi của câu hỏi — và cặp NAT Gateway / Egress-Only IGW là chỗ hay nhầm nhất.

Khác biệt căn bản giữa IPv4 và IPv6 trong VPC: | | IPv4 | IPv6 | |---|---|---| | Địa chỉ riêng | có (10.x, 172.16-31.x, 192.168.x) | KHÔNG — mọi địa chỉ đều công khai | | Cần NAT để ra Internet | ✅ | ❌ — nhưng cần EIGW để chặn chiều vào | | Bảo mật mặc định | private subnet là riêng tư tự nhiên | phải chủ động chặn bằng EIGW hoặc security group |

Dòng cuối là điểm quan trọng nhất về bảo mật IPv6: một instance có địa chỉ IPv6 và route tới IGW là truy cập được từ toàn thế giới — không có lớp bảo vệ tự nhiên nào như IPv4 private.

Ba lớp lọc lưu lượng trong VPC: | Lớp | Mức | Khả năng | |---|---|---| | Security group | ENI | stateful, CHỈ Allow | | Network ACL | subnet | stateless, Allow và Deny | | AWS Network Firewall | VPC — qua subnet riêng | stateful, IPS, lọc tên miền, luật Suricata |

Network Firewall vượt xa hai cái trên ở khả năng: nó kiểm tra nội dung gói tin, phát hiện mẫu tấn công, và chặn theo tên miền — thứ mà security group và NACL không làm được.

Kiến trúc triển khai Network Firewall:

Private subnet (EC2)
    ↓ route table trỏ tới VPC endpoint của firewall
Firewall subnet (endpoint của Network Firewall)
    ↓ sau khi kiểm tra
Egress-Only IGW → Internet (chỉ IPv6 đi ra)

Network Firewall cần subnet RIÊNG — đây là chi tiết cấu hình hay bị bỏ sót.

Ba loại rule group của Network Firewall: | Loại | Chi tiết | |---|---| | Stateless | lọc nhanh theo 5-tuple, không theo dõi kết nối | | Stateful (5-tuple) | theo dõi kết nối | | Stateful (Suricata) | luật IPS đầy đủ — nhận diện mẫu tấn công | | Domain list | chặn hoặc cho phép theo tên miền |

Dòng cuối rất hữu ích cho chính sách bảo mật nghiêm ngặt như đề mô tả: chỉ cho phép instance kết nối ra một danh sách tên miền được duyệt (kho phần mềm, API đối tác) và chặn mọi thứ khác.

Và một lưu ý về triển khai IPv6 song song: nhiều VPC chạy dual-stack (cả IPv4 lẫn IPv6). Khi đó bạn cần cả NAT Gateway cho IPv4 lẫn Egress-Only IGW cho IPv6 — và phải nhớ cấu hình security group cho cả hai họ địa chỉ, vì rule cho 0.0.0.0/0 không áp cho lưu lượng IPv6. Đây là chỗ hay để lọt lỗ hổng khi mới bật IPv6.

Câu 63 Chọn nhiều đáp án Design High-Performing Architectures

An online learning company hosts its Microsoft .NET e-Learning application on a Windows Server in its on-premises data center. The application uses an Oracle Database Standard Edition as its backend database.

The company wants a high-performing solution to migrate this workload to the AWS cloud to take advantage of the cloud’s high availability. The migration process should minimize development changes, and the environment should be easier to manage.

Which of the following options should be implemented to meet the company requirements? (Select TWO.)

  1. A

    Migrate the Oracle database to Amazon RDS for Oracle in a Multi-AZ deployment by using AWS Database Migration Service (AWS DMS).
  2. B

    Refactor the application to .NET Core and run it as a serverless container service using Amazon Elastic Kubernetes Service (Amazon EKS) with AWS Fargate.
  3. C

    Use AWS Application Migration Service (AWS MGN) to migrate the on-premises Oracle database server to a new Amazon EC2 instance.
  4. D

    Rehost the on-premises .NET application to an AWS Elastic Beanstalk Multi-AZ environment which runs in multiple Availability Zones.
  5. E

    Provision and replatform the application to Amazon Elastic Container Service (Amazon ECS) with Amazon EC2 worker nodes. Use the Windows Server Amazon Machine Image (AMI) and deploy the .NET application using to the ECS cluster via the Amazon ECS Anywhere service.
Xem giải thích

Đáp án

A và D.

  • A — Chuyển cơ sở dữ liệu Oracle sang Amazon RDS for Oracle ở cấu hình Multi-AZ bằng AWS Database Migration Service (DMS)
  • D — Rehost ứng dụng .NET tại chỗ lên một môi trường AWS Elastic Beanstalk Multi-AZ chạy trên nhiều Availability Zone

Vì sao đúng

Đề nêu ba yêu cầu, và cặp A+D đáp ứng cả ba cho hai thành phần của hệ thống: | Yêu cầu | Ứng dụng .NET | Cơ sở dữ liệu Oracle | |---|---|---| | Sẵn sàng cao | Beanstalk Multi-AZ | RDS Multi-AZ | | Ít thay đổi mã nhất | REHOST — chạy nguyên ứng dụng | DMS giữ nguyên lược đồ | | Dễ quản lý hơn | Beanstalk quản lý hạ tầng | RDS là dịch vụ được quản lý |

Cụm "minimize development changes" là điểm quyết định:

REHOST (lift-and-shift):
    → chạy nguyên ứng dụng .NET Framework trên Windows
    → KHÔNG sửa mã
    → Elastic Beanstalk hỗ trợ sẵn nền tảng .NET trên Windows Server

REFACTOR:
    → viết lại sang .NET Core, đóng gói container
    → NHIỀU thay đổi mã — trái yêu cầu

Và Elastic Beanstalk cho vế "easier to manage": | Beanstalk lo giúp | Chi tiết | |---|---| | Cấp phát EC2, ALB, Auto Scaling group | không phải dựng tay | | Vá lỗi nền tảng | managed platform updates | | Triển khai phiên bản mới | rolling, immutable, blue-green | | Giám sát và health check | tích hợp CloudWatch |

A — DMS giữ nguyên Oracle nên không phải sửa mã truy vấn:

Oracle tại chỗ → DMS → RDS for Oracle
    → cùng engine, cùng cú pháp SQL, cùng stored procedure
    → ứng dụng chỉ đổi chuỗi kết nối

Nếu chuyển sang engine khác (PostgreSQL chẳng hạn) thì phải dùng SCT và sửa rất nhiều — trái yêu cầu của đề.

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

  • B. Tái cấu trúc ứng dụng sang .NET Core và chạy như dịch vụ container không máy chủ trên EKS với Fargate — đây là phương án gần nhất về mặt kiến trúc hiện đại, nhưng nó trái thẳng yêu cầu "minimize development changes": chuyển từ .NET Framework sang .NET Core là việc viết lại đáng kể, đặc biệt với ứng dụng cũ dùng các thư viện chỉ có trên Windows.
  • **E. Replatform sang Amazon ECS với EC2 worker node, dùng Windows Server AMI và triển khai qua Amazon ECS Anywhere — hiểu sai ECS Anywhere: nó dùng để chạy ECS task trên hạ tầng TẠI CHỖ của bạn, không phải trên AWS. Đề nói công ty muốn chuyển lên AWS cloud.
  • C. Dùng AWS Application Migration Service (MGN) để chuyển máy chủ Oracle tại chỗ sang một EC2 instance mới — không đạt hai yêu cầu: Oracle trên EC2 nghĩa là bạn vẫn tự quản lý (vá, sao lưu, chuyển đổi dự phòng) — trái "easier to manage"; và một EC2 instance đơn lẻ không có tính sẵn sàng cao.

Ghi nhớ

Bảy chiến lược di chuyển lên cloud ("7 R") — nhóm này hay được hỏi: | Chiến lược | Nghĩa | Thay đổi mã | |---|---|---| | Rehost | "lift and shift" — chạy nguyên | không | | Replatform | "lift and reshape" — đổi vài thành phần | ít | | Refactor | viết lại kiến trúc | nhiều | | Repurchase | chuyển sang SaaS | — | | Retire | bỏ hẳn | — | | Retain | giữ tại chỗ | — | | Relocate | chuyển hạ tầng ảo hoá (VMware Cloud) | không |

Từ khoá trong đề thi:

"minimize development changes", "lift and shift" → Rehost "managed service", "reduce operational overhead" → Replatform "cloud-native", "microservices", "serverless" → Refactor

Đề này kết hợp cả hai: ứng dụng rehost lên Beanstalk (không sửa mã), cơ sở dữ liệu replatform sang RDS (từ tự quản sang dịch vụ được quản lý).

Ba công cụ di chuyển của AWS: | Công cụ | Di chuyển gì | |---|---| | AWS Application Migration Service (MGN) | máy chủ nguyên vẹn — rehost lên EC2 | | AWS Database Migration Service (DMS) | cơ sở dữ liệu, có CDC để đồng bộ liên tục | | AWS Schema Conversion Tool (SCT) | chuyển đổi lược đồ khi ĐỔI ENGINE |

SCT chỉ cần khi đổi engine (Oracle → PostgreSQL). Giữ nguyên Oracle thì DMS là đủ.

Bốn nền tảng mà Elastic Beanstalk hỗ trợ:

.NET trên Windows Server    ← đúng cho đề này
.NET Core trên Linux
Java, Node.js, Python, PHP, Ruby, Go
Docker (single và multi-container)

Ba chính sách triển khai của Beanstalk: | Chính sách | Đặc điểm | |---|---| | Rolling | thay theo lô — giảm dung lượng tạm thời | | Rolling with additional batch | thêm instance trước — giữ nguyên dung lượng | | Immutable | dựng đội máy MỚI hoàn toàn — an toàn nhất, quay lui nhanh | | Blue-green (swap URL) | hai môi trường, đổi CNAME |

Immutable đáng dùng cho môi trường sản xuất: nếu phiên bản mới lỗi, đội máy cũ vẫn còn nguyên và quay lui gần như tức thì.

Ba đặc điểm của DMS đáng biết: | Đặc điểm | Chi tiết | |---|---| | Full load + CDC | sao chép ban đầu rồi đồng bộ thay đổi liên tục | | Thời gian ngừng rất ngắn | chỉ vài phút để chuyển đổi cuối | | Không thay đổi nguồn | cơ sở dữ liệu cũ vẫn chạy trong suốt quá trình |

CDC là tính năng quan trọng nhất: nó cho phép chạy song song hai hệ thống cho tới khi bạn sẵn sàng chuyển — thay vì phải dừng dịch vụ suốt thời gian sao chép dữ liệu.

Ba lưu ý về RDS for Oracle: | Lưu ý | Chi tiết | |---|---| | Mô hình giấy phép | License Included hoặc Bring Your Own License (BYOL) | | Multi-AZ dùng sao chép đồng bộ | RPO = 0, chuyển đổi tự động | | Một số tính năng Oracle không hỗ trợ | kiểm tra danh sách trước khi cam kết |

Dòng cuối là bước thẩm định bắt buộc: RDS for Oracle không hỗ trợ mọi tính năng của Oracle tự quản (như một số cấu hình RAC, hoặc truy cập hệ thống tệp trực tiếp). Nếu ứng dụng phụ thuộc vào chúng, Oracle trên EC2 hoặc Amazon RDS Custom for Oracle — nơi bạn có quyền truy cập hệ điều hành — mới là lựa chọn khả thi.

Câu 64 Design Resilient Architectures

A company has recently migrated its microservices-based application to Amazon Elastic Kubernetes Service (Amazon EKS). As part of the migration, the company must ensure that all sensitive configuration data and credentials, such as database passwords and API keys, are stored securely and encrypted within the Amazon EKS cluster's etcd key-value store.

What is the most suitable solution to meet the company's requirements?

  1. A

    Enable secret encryption with a new AWS KMS key on an existing Amazon EKS cluster to encrypt sensitive data stored in the EKS cluster's etcd key-value store.
  2. B

    Use AWS Secrets Manager with a new AWS KMS key to securely manage and store sensitive data within the EKS cluster's etcd key-value store.
  3. C

    Enable default Amazon EBS volume encryption for the account with a new AWS KMS key to ensure encryption of sensitive data within the Amazon EKS cluster.
  4. D

    Use Amazon EKS default options and the Amazon Elastic Block Store (Amazon EBS) Container Storage Interface (CSI) driver as an add-on to securely store sensitive data within the Amazon EKS cluster.
Xem giải thích

Đáp án

A — Bật secret encryption với một AWS KMS key mới trên cụm Amazon EKS hiện có để mã hoá dữ liệu nhạy cảm lưu trong etcd key-value store của cụm.

Vì sao đúng

Đề nêu yêu cầu rất cụ thể: mã hoá dữ liệu nhạy cảm BÊN TRONG etcd của cụm EKS — không phải ở một kho bí mật bên ngoài.

Vấn đề mặc định của Kubernetes Secret:

Kubernetes Secret KHÔNG được mã hoá thật sự
    → chỉ mã hoá base64 (là ENCODE, không phải ENCRYPT)
    → ai đọc được etcd là đọc được mật khẩu

EKS secret encryption dùng mã hoá phong bì với KMS:

Bạn tạo một Secret trong Kubernetes
    ↓ EKS gọi KMS lấy data key
    ↓ mã hoá giá trị secret bằng data key
    ↓ lưu bản mã vào etcd
etcd chứa BẢN MÃ, không phải bản rõ

aws eks associate-encryption-config   --cluster-name cum-ung-dung   --encryption-config '[{
    "provider": {"keyArn": "arn:aws:kms:...:key/1234abcd"},
    "resources": ["secrets"]}]'

Đây là lớp bảo vệ "defense in depth": ngay cả khi ai đó lấy được bản sao lưu etcd, họ vẫn cần quyền trên KMS key mới đọc được nội dung.

Lưu ý quan trọng: bật rồi thì KHÔNG TẮT được, và không đổi được khoá. Đây là thao tác một chiều.

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

  • B. Dùng AWS Secrets Manager với một KMS key mới để quản lý và lưu dữ liệu nhạy cảm bên trong etcd của EKS — đây là phương án gần nhất và Secrets Manager là dịch vụ tốt, nhưng nó không lưu gì vào etcd cả: bí mật nằm trong Secrets Manager, ứng dụng lấy về qua API. Mệnh đề tự mâu thuẫn với yêu cầu của đề.
  • C. Bật mã hoá EBS mặc định cho tài khoản với một KMS key mới — sai lớp lưu trữ: EBS encryption bảo vệ volume của worker node, nó không liên quan tới etcd. Với EKS, control plane và etcd do AWS quản lý — bạn không chạm tới volume của chúng.
  • D. Dùng tuỳ chọn mặc định của EKS và EBS CSI driver làm add-on — CSI driver phục vụ lưu trữ persistent volume cho pod, không phải cơ chế bảo vệ secret.

Ghi nhớ

Ba cách quản lý bí mật cho ứng dụng trên EKS: | Cách | Bí mật nằm ở | Đặc điểm | |---|---|---| | Kubernetes Secret + EKS secret encryption | etcd (đã mã hoá) | native Kubernetes ← câu này | | AWS Secrets Manager + Secrets Store CSI Driver | Secrets Manager | xoay vòng tự động | | SSM Parameter Store + CSI Driver | Parameter Store | miễn phí (standard tier) |

Hai cách dưới thường được ưa chuộng hơn trong thực tế vì có xoay vòng tự động và quản lý tập trung — nhưng đề hỏi cụ thể về mã hoá trong etcd, nên chỉ A trả lời đúng câu hỏi.

Ba lớp bảo mật của EKS: | Lớp | Cơ chế | |---|---| | Xác thực | AWS IAM Authenticator, ánh xạ IAM → RBAC | | Phân quyền | Kubernetes RBAC | | Bảo vệ dữ liệu | secret encryption, EBS encryption cho node |

Ba lưu ý về EKS secret encryption: | Lưu ý | Chi tiết | |---|---| | Bật được cho cụm ĐANG CHẠY | không phải tạo cụm mới | | KHÔNG tắt được, KHÔNG đổi khoá được | thao tác một chiều | | Secret cũ chỉ được mã hoá khi ghi lại | phải kubectl replace để mã hoá bí mật đã có |

Dòng cuối hay bị bỏ sót: bật mã hoá không tự động mã hoá lại các secret đã tồn tại. Chạy lệnh này để buộc ghi lại:

kubectl get secrets --all-namespaces -o json | kubectl replace -f -

Và một thực hành nên theo cho IRSA (IAM Roles for Service Accounts): thay vì lưu access key làm secret, hãy dùng IRSA để pod nhận IAM role trực tiếp — loại bỏ hẳn nhu cầu lưu thông tin đăng nhập AWS trong cụm.

Câu 65 Chọn nhiều đáp án Design Resilient Architectures

A Forex trading platform, which frequently processes and stores global financial data every minute, is hosted in an on-premises data center and uses an Oracle database. Due to a recent cooling problem in its data center, the company urgently needs to migrate its infrastructure to AWS to improve the performance of its applications. As the Solutions Architect, the responsibility is to ensure that the database is properly migrated and remains available in case of database server failure in the future.

Which combination of actions would meet the requirement? (Select TWO.)

  1. A

    Launch an Oracle database instance in Amazon RDS with Recovery Manager (RMAN) enabled.
  2. B

    Convert the database schema using the AWS Schema Conversion Tool.
  3. C

    Create an Oracle database in Amazon RDS with Multi-AZ deployments.
  4. D

    Migrate the Oracle database to a non-cluster Amazon Aurora with a single instance.
  5. E

    Migrate the Oracle database to AWS using the AWS Database Migration Service
Xem giải thích

Đáp án

C và E.

  • E — Di chuyển cơ sở dữ liệu Oracle sang AWS bằng AWS Database Migration Service (DMS)
  • C — Tạo cơ sở dữ liệu Oracle trong Amazon RDS ở cấu hình Multi-AZ

Vì sao đúng

Đề nêu hai yêu cầu, và mỗi đáp án giải quyết một cái: | Yêu cầu | Cơ chế | |---|---| | Di chuyển cơ sở dữ liệu đúng cách | E — DMS | | Vẫn khả dụng khi máy chủ CSDL hỏng | C — RDS Multi-AZ |

E — DMS là công cụ di chuyển chuẩn, và nó giữ được dịch vụ chạy trong suốt quá trình:

Full load:  sao chép toàn bộ dữ liệu hiện có
    +
CDC:        đồng bộ liên tục mọi thay đổi phát sinh sau đó
    ↓
Chỉ cần vài phút ngừng dịch vụ lúc chuyển đổi cuối

Với tình huống khẩn cấp mà đề mô tả (sự cố làm mát ở trung tâm dữ liệu), việc không phải dừng dịch vụ lâu là rất quan trọng.

C — Multi-AZ trả lời trực tiếp "in case of database server failure":

Primary ở AZ-a  ──ĐỒNG BỘ──>  Standby ở AZ-b
    → máy chủ chính hỏng
    → RDS TỰ ĐỘNG chuyển đổi sang standby
    → CNAME trỏ sang bản mới, ứng dụng kết nối lại

Sao chép đồng bộ nghĩa là RPO = 0 — không mất giao dịch nào.

Và giữ nguyên engine Oracle là lựa chọn đúng cho tình huống khẩn cấp: không phải sửa câu truy vấn, không phải chuyển stored procedure, ứng dụng chỉ đổi chuỗi kết nối.

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

  • **B. Chuyển đổi lược đồ bằng AWS Schema Conversion Tool (SCT) — đây là phương án gần nhất và là công cụ có thật, nhưng nó chỉ cần khi ĐỔI ENGINE (Oracle → PostgreSQL chẳng hạn). Ở đây Oracle chuyển sang Oracle — cùng engine, cùng cú pháp, không cần chuyển đổi gì.
  • **D. Chuyển sang Aurora không cụm với một instance duy nhất — hai vấn đề: Aurora không tương thích Oracle (chỉ MySQL và PostgreSQL) nên phải viết lại nhiều; và một instance duy nhất không có tính sẵn sàng cao — trái yêu cầu chính.
  • A. Khởi chạy Oracle trong RDS với Recovery Manager (RMAN) bật — RMAN là công cụ sao lưu của Oracle, không phải cơ chế sẵn sàng cao. Và với RDS for Oracle, bạn không truy cập RMAN đầy đủ — AWS quản lý việc sao lưu.

Ghi nhớ

Ba công cụ di chuyển của AWS: | Công cụ | Di chuyển gì | |---|---| | AWS DMS | cơ sở dữ liệu, có CDC đồng bộ liên tục | | AWS SCT | chuyển đổi lược đồ khi ĐỔI ENGINE | | AWS MGN | máy chủ nguyên vẹn (rehost lên EC2) |

Quy tắc phân biệt:

Cùng engine (Oracle → Oracle) → chỉ cần DMS Khác engine (Oracle → PostgreSQL) → cần SCT + DMS

Multi-AZ và Read Replica — bảng phân biệt cần thuộc: | | Multi-AZ | Read Replica | |---|---|---| | Sao chép | ĐỒNG BỘ | BẤT ĐỒNG BỘ | | Mục đích | SẴN SÀNG CAO | mở rộng đọc | | Phục vụ đọc | ❌ | ✅ | | Chuyển đổi | tự động | thủ công (promote) | | Mất dữ liệu | không (RPO = 0) | có thể |

Ba đặc điểm của DMS đáng biết: | Đặc điểm | Chi tiết | |---|---| | Full load + CDC | sao chép ban đầu rồi đồng bộ liên tục | | Không đổi cơ sở dữ liệu nguồn | hệ thống cũ vẫn chạy suốt quá trình | | Hỗ trợ nhiều loại nguồn và đích | Oracle, SQL Server, MySQL, PostgreSQL, MongoDB, S3, Kinesis |

Ba lưu ý khi dùng RDS for Oracle: | Lưu ý | Chi tiết | |---|---| | Mô hình giấy phép | License Included hoặc Bring Your Own License | | Một số tính năng không hỗ trợ | kiểm tra danh sách trước khi cam kết | | Cần quyền truy cập hệ điều hành? | dùng RDS Custom for Oracle |

Dòng giữa là bước thẩm định bắt buộc: nếu ứng dụng phụ thuộc vào tính năng mà RDS không hỗ trợ, Oracle trên EC2 hoặc RDS Custom mới là lựa chọn khả thi — và khi đó tính sẵn sàng cao phải tự dựng.

Và một điểm về tình huống khẩn cấp trong đề: khi cần chuyển gấp vì sự cố hạ tầng, DMS với CDC cho phép chạy song song hai hệ thống — bạn chuyển đổi khi đã sẵn sàng thay vì phải hoàn tất mọi thứ trong một cửa sổ ngừng dịch vụ duy nhất.

Câu 66 Design High-Performing Architectures

A company has an on-premises MySQL database that needs to be replicated in Amazon S3 as CSV files. The database will eventually be launched to an Amazon Aurora Serverless cluster and be integrated with an RDS Proxy to allow the web applications to pool and share database connections. Once data has been fully copied, the ongoing changes to the on-premises database should be continually streamed into the S3 bucket. The company wants a solution that can be implemented with little management overhead yet still highly secure.

Which ingestion pattern should a solutions architect take?

  1. A

    Set up a full load replication task using AWS Database Migration Service (AWS DMS). Launch an AWS DMS endpoint with SSL using the AWS Network Firewall service.
  2. B

    Create a full load and change data capture (CDC) replication task using AWS Database Migration Service (AWS DMS). Add a new Certificate Authority (CA) certificate and create an AWS DMS endpoint with SSL.
  3. C

    Use an AWS Snowball Edge cluster to migrate data to Amazon S3 and AWS DataSync to capture ongoing changes. Create your own custom AWS KMS envelope encryption key for the associated AWS Snowball Edge job.
  4. D

    Use AWS Schema Conversion Tool (AWS SCT) to convert MySQL data to CSV files. Set up the AWS Application Migration Service (AWS MGN) to capture ongoing changes from the on-premises MySQL database and send them to Amazon S3.
Xem giải thích

Đáp án

B — Tạo một replication task kiểu full load + change data capture (CDC) bằng AWS DMS. Thêm một CA certificate mới và tạo DMS endpoint có SSL.

Vì sao đúng

Đề nêu bốn yêu cầu, và B đáp ứng cả bốn: | Yêu cầu | Cơ chế | |---|---| | Sao chép MySQL tại chỗ sang S3 dạng CSV | DMS hỗ trợ S3 làm target, xuất CSV | | Sau khi sao chép xong, tiếp tục stream thay đổi | CDC (change data capture) | | Ít công quản lý | DMS là dịch vụ được quản lý | | Bảo mật cao | endpoint có SSL với CA certificate |

Vì sao "full load + CDC" là loại task đúng:

Full load only:    sao chép ảnh chụp tại một thời điểm rồi DỪNG
                   → thay đổi sau đó KHÔNG được sao chép

Full load + CDC:   ① sao chép toàn bộ dữ liệu hiện có
                   ② đọc binlog của MySQL, stream thay đổi LIÊN TỤC
                   → đúng yêu cầu "ongoing changes should be continually streamed"

Và vế SSL là cách DMS đảm bảo bảo mật khi truyền:

Dữ liệu đi từ TRUNG TÂM DỮ LIỆU TẠI CHỖ sang AWS
    → phải mã hoá đường truyền
    → DMS endpoint dùng SSL/TLS
    → cần CA certificate để xác minh danh tính máy chủ

aws dms import-certificate --certificate-identifier ca-mysql   --certificate-pem file://ca-cert.pem

aws dms create-endpoint --endpoint-identifier nguon-mysql   --endpoint-type source --engine-name mysql   --ssl-mode verify-full --certificate-arn arn:aws:dms:...:cert/ca-mysql

verify-full là chế độ chặt nhất — nó xác minh cả chứng chỉ lẫn tên máy chủ.

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

  • A. Thiết lập full load replication task bằng DMS; khởi chạy DMS endpoint có SSL bằng AWS Network Firewall — đây là phương án gần nhất và có DMS đúng, nhưng nó sai ở hai điểm: full load một mình không stream thay đổi liên tục; và Network Firewall không liên quan gì tới SSL của DMS endpoint — nó là tường lửa cho lưu lượng VPC.
  • C. Dùng Snowball Edge di chuyển dữ liệu sang S3 và DataSync bắt thay đổi liên tục — hai vấn đề: Snowball là thiết bị vật lý vận chuyển bằng đường bưu điện — quá chậm và nhiều công cho một cơ sở dữ liệu MySQL; và DataSync đồng bộ TỆP, không đọc được thay đổi trong cơ sở dữ liệu.
  • D. Dùng SCT chuyển MySQL thành tệp CSV; dùng AWS MGN bắt thay đổi liên tục gửi sang S3 — nhầm chức năng cả hai công cụ: SCT chuyển đổi lược đồ giữa các engine, không xuất CSV; và MGN di chuyển MÁY CHỦ nguyên vẹn lên EC2, không bắt thay đổi cơ sở dữ liệu.

Ghi nhớ

Ba loại replication task của DMS: | Loại | Việc | |---|---| | Full load | sao chép dữ liệu hiện có một lần rồi dừng | | CDC only | chỉ đồng bộ thay đổi từ một điểm trở đi | | Full load + CDC | cả hai — dùng cho di chuyển không ngừng dịch vụ ← câu này |

Loại thứ ba là lựa chọn mặc định cho hầu hết dự án di chuyển — nó cho phép chạy song song hai hệ thống cho tới khi sẵn sàng chuyển đổi.

Các nguồn và đích mà DMS hỗ trợ: | Nguồn | Đích | |---|---| | Oracle, SQL Server, MySQL, PostgreSQL, MariaDB, MongoDB, DB2, SAP | các CSDL trên, cộng S3, Kinesis, Redshift, OpenSearch, DocumentDB |

S3 làm đích là tính năng quan trọng cho data lake: DMS xuất được CSV hoặc Parquet, và với CDC nó ghi thêm cột chỉ dấu thao tác (I, U, D).

Điều kiện để CDC hoạt động với MySQL:

① Bật binary logging: log_bin = ON
② binlog_format = ROW
③ binlog_row_image = FULL
④ Tài khoản DMS có quyền REPLICATION CLIENT và REPLICATION SLAVE
⑤ Giữ binlog đủ lâu (binlog_expire_logs_seconds)

Bước ⑤ hay bị bỏ sót: nếu binlog bị xoá trước khi DMS đọc kịp, task CDC thất bại và phải khởi động lại từ đầu.

Bốn chế độ SSL của DMS endpoint: | Chế độ | Đặc điểm | |---|---| | none | không mã hoá | | require | mã hoá, không xác minh chứng chỉ | | verify-ca | xác minh chứng chỉ do CA tin cậy ký | | verify-full | xác minh cả chứng chỉ lẫn TÊN MÁY CHỦ — chặt nhất |

Ba lưu ý về kiến trúc đích mà đề mô tả: | Thành phần | Vai trò | |---|---| | Aurora Serverless | tự co giãn dung lượng theo tải | | RDS Proxy | gộp kết nối — cần thiết khi ứng dụng web mở nhiều kết nối | | S3 CSV | kho dữ liệu trung gian cho phân tích |

RDS Proxy đáng nói riêng: nó giải quyết đúng vấn đề "pool and share database connections" mà đề nêu — đặc biệt quan trọng với Aurora Serverless, nơi việc mở kết nối mới tốn kém hơn.

Và một lưu ý về giám sát DMS: theo dõi metric CDCLatencySource và CDCLatencyTarget trong CloudWatch. Độ trễ tăng dần nghĩa là DMS không theo kịp khối lượng thay đổi — dấu hiệu cần tăng kích thước replication instance trước khi task thất bại.

Câu 67 Design High-Performing Architectures

A company has a serverless application made up of AWS Amplify, Amazon API Gateway and a Lambda function. The application is connected to an Amazon RDS MySQL database instance inside a private subnet. A Lambda Function URL is also implemented as the dedicated HTTPS endpoint for the function, which has the following value:

https://12june1898pil1pinas.lambda-url.us-west-2.on.aws/

There are times during peak loads when the database throws a “too many connections” error preventing the users from accessing the application.

Which solution could the company take to resolve the issue?

  1. A

    Increase the concurrency limit of the Lambda function
  2. B

    Provision an RDS Proxy between the Lambda function and RDS database instance
  3. C

    Increase the rate limit of API Gateway
  4. D

    Increase the memory allocation of the Lambda function
Xem giải thích

Đáp án

B — Cấp phát một RDS Proxy giữa Lambda function và RDS database instance.

Vì sao đúng

Đề mô tả triệu chứng rất đặc trưng: lỗi "too many connections" vào giờ cao điểm — và đó là hệ quả trực tiếp của cách Lambda mở rộng.

Nguyên nhân gốc:

Lambda mở rộng theo SỐ LỜI GỌI ĐỒNG THỜI
    → 1.000 lời gọi đồng thời = 1.000 execution environment
    → mỗi cái mở MỘT kết nối riêng tới RDS
    → RDS có GIỚI HẠN số kết nối theo loại instance
        db.t3.micro  ≈ 66 kết nối
        db.t3.medium ≈ 312 kết nối
        db.r5.large  ≈ 1.000 kết nối
    → vượt giới hạn → "too many connections"

RDS Proxy giải quyết bằng cách gộp và tái sử dụng kết nối:

1.000 Lambda
    ↓ mỗi cái kết nối tới RDS PROXY
RDS Proxy giữ một POOL kết nối nhỏ
    ↓ vài chục kết nối THẬT
RDS database

Ba lợi ích cùng lúc: | Lợi ích | Chi tiết | |---|---| | Gộp kết nối | hàng nghìn client thành vài chục kết nối thật | | Chuyển đổi dự phòng nhanh hơn | proxy giữ kết nối, giảm thời gian gián đoạn tới 66% | | Tích hợp IAM và Secrets Manager | không lưu mật khẩu trong mã Lambda |

Và điểm quan trọng: đây là vấn đề KIẾN TRÚC, không phải vấn đề dung lượng. Tăng bộ nhớ Lambda hay giới hạn tần suất API Gateway chỉ là chữa triệu chứng.

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

  • **A. Tăng giới hạn concurrency của Lambda function — đây là phương án gần nhất về mặt cũng chạm tới con số concurrency, nhưng nó làm vấn đề TỆ HƠN: nhiều lời gọi đồng thời hơn nghĩa là nhiều kết hơn tới cơ sở dữ liệu hơn. (Giảm concurrency bằng reserved concurrency thì mới hạn chế được — nhưng đó là hy sinh thông lượng.)
  • **C. Tăng rate limit của API Gateway — cùng lỗi hướng: cho nhiều request đi qua hơn nghĩa là nhiều Lambda chạy hơn và nhiều kết nối hơn.
  • **D. Tăng bộ nhớ cấp cho Lambda function — không liên quan: bộ nhớ ảnh hưởng tốc độ xử lý và CPU được cấp, nó không thay đổi số kết nối mà hàm mở.

Ghi nhớ

Vấn đề kinh điển của kiến trúc Lambda + cơ sở dữ liệu quan hệ:

Lambda thiết kế cho:  hàng nghìn thực thi NGẮN, ĐỘC LẬP
CSDL quan hệ thiết kế cho: ít kết nối, DÙNG LẠI LÂU DÀI
    → hai mô hình xung đột nhau
    → RDS Proxy là cầu nối

Ba khả năng của RDS Proxy: | Khả năng | Chi tiết | |---|---| | Connection pooling | tái sử dụng kết nối giữa các lời gọi | | Chuyển đổi dự phòng nhanh hơn | proxy phát hiện và định tuyến lại | | Xác thực qua IAM | không cần mật khẩu trong mã |

Ba cơ sở dữ liệu mà RDS Proxy hỗ trợ:

MySQL, PostgreSQL, MariaDB
(RDS và Aurora)

Ba thực hành khi viết Lambda kết nối cơ sở dữ liệu: | Thực hành | Lý do | |---|---| | Khởi tạo kết nối NGOÀI handler | tái sử dụng qua nhiều lời gọi trong cùng environment | | Đóng kết nối đúng cách | tránh rò rỉ | | Đặt timeout ngắn | không giữ kết nối chết |

import pymysql, os
# NGOÀI handler — chỉ chạy khi khởi tạo environment
conn = pymysql.connect(host=os.environ['PROXY_ENDPOINT'], ...)

def lambda_handler(event, context):
    with conn.cursor() as cur:   # tái sử dụng kết nối
        cur.execute("SELECT ...")

Ba lựa chọn thay thế cho kiến trúc này: | Lựa chọn | Đặc điểm | |---|---| | RDS Proxy | giữ nguyên CSDL quan hệ ← câu này | | Aurora Serverless Data API | gọi qua HTTP — không quản lý kết nối chút nào | | DynamoDB | không có khái niệm kết nối, mở rộng vô hạn |

Data API đáng biết: nó cho phép Lambda truy vấn Aurora bằng lời gọi HTTP thay vì mở kết nối TCP — loại bỏ hoàn toàn vấn đề này. Nhược điểm là độ trễ cao hơn và không hỗ trợ mọi tính năng.

Và một chi tiết trong đề đáng chú ý: hàm dùng Lambda Function URL làm endpoint HTTPS riêng. Đó là tính năng tiện lợi, nhưng nhớ rằng Function URL không có throttling hay caching như API Gateway — nên nếu cần bảo vệ backend khỏi tăng tải, API Gateway phía trước vẫn có giá trị riêng.

Câu 68 Design Resilient Architectures

A music publishing company is building a multitier web application that requires a key-value store which will save the document models. Each model is composed of band ID, album ID, song ID, composer ID, lyrics, and other data. The web tier will be hosted in an Amazon ECS cluster with AWS Fargate launch type.

Which of the following is the MOST suitable setup for the database-tier?

  1. A

    Launch an Amazon RDS database with Read Replicas.
  2. B

    Launch a DynamoDB table.
  3. C

    Use Amazon WorkDocs to store the document models.
  4. D

    Launch an Amazon Aurora Serverless database.
Xem giải thích

Đáp án

B — Khởi chạy một DynamoDB table.

Vì sao đúng

Đề dùng đúng thuật ngữ kỹ thuật: cần một key-value store lưu document model — và đó chính là định nghĩa của DynamoDB.

Cấu trúc dữ liệu mà đề mô tả khớp hoàn hảo:

Mỗi model gồm: band ID, album ID, song ID, composer ID, lyrics, và dữ liệu khác
    → item có nhiều thuộc tính, không cố định
    → truy cập theo khoá (song ID chẳng hạn)
    → KHÔNG cần JOIN phức tạp

DynamoDB phù hợp vì ba lý do: | Lý do | Chi tiết | |---|---| | Key-value và document store | đúng mô hình dữ liệu đề mô tả | | Lược đồ linh hoạt | bài hát có thêm trường mới không cần ALTER TABLE | | Không máy chủ, tự mở rộng | khớp với kiến trúc Fargate không máy chủ |

Và thiết kế khoá cho tình huống này:

Partition key = "BAND#<band_id>"
Sort key      = "SONG#<song_id>"
    → truy vấn mọi bài của một ban nhạc bằng MỘT lời gọi
    → thêm Global Secondary Index theo composer_id nếu cần tra theo nhạc sĩ

Kết hợp với Fargate là mẫu kiến trúc nhất quán: cả tầng web lẫn tầng dữ liệu đều không cần quản lý máy chủ, và cả hai đều mở rộng độc lập theo tải.

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

  • **D. Khởi chạy một Aurora Serverless database — đây là phương án gần nhất và cũng là dịch vụ tự mở rộng, nhưng nó là cơ sở dữ liệu QUAN HỆ: nó có lược đồ cố định, và đề nói rõ cần key-value store. Với dữ liệu tài liệu có cấu trúc thay đổi, mô hình quan hệ là gò bó không cần thiết.
  • **A. Khởi chạy RDS với Read Replica — cùng vấn đề về mô hình dữ liệu, cộng thêm việc phải quản lý instance và mở rộng thủ công.
  • **C. Dùng Amazon WorkDocs để lưu document model — nhầm nghĩa của từ "document": WorkDocs là dịch vụ lưu trữ và chia sẻ TÀI LIỆU VĂN PHÒNG (Word, PDF) cho nhân viên. "Document model" trong ngữ cảnh cơ sở dữ liệu nghĩa là bản ghi dạng JSON, hoàn toàn khác.

Ghi nhớ

Bốn nhóm cơ sở dữ liệu của AWS: | Nhóm | Dịch vụ | Phù hợp | |---|---|---| | Quan hệ (OLTP) | RDS, Aurora | giao dịch, JOIN phức tạp | | Khoá–giá trị / tài liệu | DynamoDB | quy mô lớn, độ trễ thấp, lược đồ linh hoạt ← câu này | | Kho dữ liệu (OLAP) | Redshift | phân tích khối lượng lớn | | Chuyên biệt | DocumentDB, Neptune, Timestream, ElastiCache | MongoDB, đồ thị, chuỗi thời gian, cache |

Từ khoá nhận diện trong đề thi:

"key-value store", "document model", "flexible schema", "single-digit millisecond" → DynamoDB "MongoDB compatible" → DocumentDB "complex joins", "transactions", "SQL" → RDS/Aurora

Hai chế độ dung lượng của DynamoDB: | Chế độ | Phù hợp | |---|---| | On-demand | tải không dự đoán được, hoặc mới bắt đầu | | Provisioned + Auto Scaling | tải ổn định — rẻ hơn đáng kể |

Ba tính năng của DynamoDB đáng biết: | Tính năng | Việc | |---|---| | Global Secondary Index (GSI) | truy vấn theo thuộc tính khác khoá chính | | DynamoDB Streams | bắt thay đổi để kích hoạt xử lý | | DAX | cache trong bộ nhớ — độ trễ MICROgiây | | Point-in-time recovery | khôi phục về bất kỳ giây nào trong 35 ngày |

GSI cần thiết cho đề này: truy vấn "mọi bài hát của một nhạc sĩ" đòi index theo composer_id, vì nó không phải partition key.

Nguyên tắc thiết kế quan trọng nhất của DynamoDB:

Thiết kế bảng theo MẪU TRUY CẬP, không theo cấu trúc dữ liệu.

Khác với cơ sở dữ liệu quan hệ (chuẩn hoá trước, truy vấn sau), với DynamoDB bạn phải liệt kê mọi cách sẽ truy vấn trước rồi mới thiết kế khoá — vì đổi khoá chính sau này đòi tạo bảng mới và di chuyển toàn bộ dữ liệu.

Và một lưu ý về partition key: chọn thuộc tính có độ phân biệt cao (song ID, band ID) chứ đừng chọn thuộc tính ít giá trị (thể loại nhạc) — nếu không sẽ tạo hot partition và bị throttling dù bảng còn thừa throughput.

Câu 69 Design High-Performing Architectures

A company plans to migrate its suite of containerized applications running on-premises to a container service in AWS. The solution must be cloud-agnostic and use an open-source platform that can automatically manage containerized workloads and services. It should also use the same configuration and tools across various production environments.

What should the Solution Architect do to properly migrate and satisfy the given requirement?

  1. A

    Migrate the application to Amazon Container Registry (ECR) with Amazon EC2 instance worker nodes.
  2. B

    Migrate the application to Amazon Elastic Kubernetes Service with EKS worker nodes.
  3. C

    Migrate the application to Amazon Elastic Container Service with ECS tasks that use the AWS Fargate launch type.
  4. D

    Migrate the application to Amazon Elastic Container Service with ECS tasks that use the Amazon EC2 launch type.
Xem giải thích

Đáp án

B — Chuyển ứng dụng sang Amazon Elastic Kubernetes Service (EKS) với EKS worker node.

Vì sao đúng

Đề nêu ba yêu cầu, và cụm từ khoá quyết định là "cloud-agnostic" và "open-source platform": | Yêu cầu | Cơ chế | |---|---| | Không phụ thuộc nhà cung cấp cloud | Kubernetes là chuẩn mở, chạy ở mọi nơi | | Nền tảng mã nguồn mở tự quản lý workload container | Kubernetes | | Dùng chung cấu hình và công cụ ở nhiều môi trường | manifest YAML, Helm chart giống hệt nhau |

Vì sao Kubernetes là "cloud-agnostic" còn ECS thì không:

Kubernetes:
    → dự án mã nguồn mở của CNCF
    → chạy trên AWS (EKS), Azure (AKS), Google (GKE), tại chỗ, máy cá nhân
    → CÙNG manifest YAML chạy ở mọi nơi
    → chuyển nhà cung cấp không phải viết lại

Amazon ECS:
    → dịch vụ ĐỘC QUYỀN của AWS
    → task definition CHỈ chạy trên AWS
    → chuyển sang cloud khác phải viết lại toàn bộ

Và vế "same configuration and tools across various production environments" là lợi ích thật của Kubernetes: | Công cụ | Dùng chung ở mọi nơi | |---|---| | kubectl | cùng lệnh cho mọi cụm | | Helm chart | cùng gói triển khai | | Manifest YAML | cùng định nghĩa Deployment, Service, Ingress | | Prometheus, Grafana, ArgoCD | hệ sinh thái công cụ chung |

Đây là lý do các tổ chức muốn tránh khoá chặt vào một nhà cung cấp thường chọn Kubernetes — dù nó phức tạp hơn ECS đáng kể.

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

  • **C. Chuyển sang ECS với Fargate launch type — đây là phương án gần nhất và là dịch vụ container tuyệt vời, nhưng nó KHÔNG cloud-agnostic: ECS là công nghệ độc quyền của AWS. Task definition và service definition không chạy ở đâu khác.
  • **D. Chuyển sang ECS với EC2 launch type — cùng vấn đề: vẫn là ECS, vẫn khoá vào AWS. (Chỉ khác Fargate ở chỗ bạn tự quản lý EC2 làm worker node.)
  • A. Chuyển ứng dụng sang Amazon Container Registry (ECR) với EC2 worker node — nhầm chức năng của ECR: nó là KHO LƯU TRỮ container image, không phải nền tảng điều phối. Bạn đẩy image lên ECR rồi mới triển khai bằng ECS hoặc EKS.

Ghi nhớ

Ba dịch vụ container của AWS — phân biệt vai trò: | Dịch vụ | Là gì | |---|---| | Amazon ECR | KHO LƯU TRỮ image (registry) | | Amazon ECS | ĐIỀU PHỐI container — độc quyền AWS | | Amazon EKS | ĐIỀU PHỐI container — Kubernetes chuẩn mở |

ECR dùng chung cho cả ECS lẫn EKS — nó không thay thế cái nào.

ECS và EKS — bảng so sánh cốt lõi: | | ECS | EKS | |---|---|---| | Nền tảng | độc quyền AWS | Kubernetes chuẩn mở | | Cloud-agnostic | ❌ | ✅ ← câu này | | Độ phức tạp | đơn giản hơn | cao hơn | | Chi phí control plane | MIỄN PHÍ | ~0,10 USD/giờ mỗi cụm | | Tích hợp AWS | sâu và mượt | tốt, qua add-on | | Hệ sinh thái | AWS | rất lớn — CNCF |

Câu hỏi phân biệt:

"cloud-agnostic", "open-source", "Kubernetes", "avoid vendor lock-in", "hybrid" → EKS "simplest", "deep AWS integration", "least operational overhead" → ECS

Hai kiểu compute cho cả ECS lẫn EKS: | Kiểu | Đặc điểm | |---|---| | EC2 (worker node) | bạn quản lý instance — kiểm soát nhiều hơn, rẻ hơn ở quy mô lớn | | Fargate | không máy chủ — AWS lo hạ tầng |

EKS hỗ trợ cả hai, nên phương án B (worker node) hợp lệ — và với workload đã chạy container tại chỗ, worker node thường cho lộ trình chuyển đổi mượt hơn.

Ba lựa chọn triển khai Kubernetes trên AWS: | Lựa chọn | Đặc điểm | |---|---| | EKS (managed control plane) | AWS quản lý control plane ← câu này | | EKS Anywhere | chạy EKS trên hạ tầng TẠI CHỖ của bạn | | Kubernetes tự dựng trên EC2 | toàn quyền, nhiều công nhất |

EKS Anywhere đáng biết cho chiến lược lai: cùng một bản phân phối Kubernetes chạy cả trên AWS lẫn tại trung tâm dữ liệu — tăng thêm tính nhất quán mà đề mong muốn.

Và một điểm cân bằng cần nói thẳng: "cloud-agnostic" hiếm khi tuyệt đối trong thực tế. Ứng dụng trên EKS vẫn thường dùng ALB Ingress Controller, EBS CSI driver, IRSA, Secrets Manager — những thứ chỉ có trên AWS. Kubernetes giảm đáng kể chi phí chuyển đổi, nhưng không loại bỏ nó hoàn toàn.

Câu 70 Chọn nhiều đáp án Design Secure Architectures

A media company has two VPCs: VPC-1 and VPC-2 with peering connection between each other. VPC-1 only contains private subnets while VPC-2 only contains public subnets. The company uses a single AWS Direct Connect connection and a virtual interface to connect their on-premises network with VPC-1.

Which of the following options increase the fault tolerance of the connection to VPC-1? (Select TWO.)

  1. A

    Use the AWS VPN CloudHub to create a new AWS Direct Connect connection and private virtual interface in the same region as VPC-2.
  2. B Establish a hardware VPN over the Internet between VPC-1 and the on-premises network.
  3. C Establish a hardware VPN over the Internet between VPC-2 and the on-premises network.
  4. D Establish a new AWS Direct Connect connection and private virtual interface in the same region as VPC-2.
  5. E Establish another AWS Direct Connect connection and private virtual interface in the same AWS region as VPC-1.
Xem giải thích

Đáp án

B và E.

  • E — Thiết lập một Direct Connect connection và private virtual interface KHÁC ở CÙNG AWS region với VPC-1
  • B — Thiết lập một hardware VPN qua Internet giữa VPC-1 và mạng tại chỗ

Vì sao đúng

Đề hỏi cách tăng fault tolerance cho kết nối tới VPC-1 — và mọi thứ phải hướng về VPC-1, không phải VPC-2.

Vấn đề hiện tại: một điểm hỏng đơn lẻ.

Mạng tại chỗ ── MỘT Direct Connect ── VPC-1
                 ↑
        DX đứt = MẤT kết nối hoàn toàn

Hai đáp án cho hai mức dự phòng khác nhau: | Đáp án | Loại dự phòng | Đặc điểm | |---|---|---| | E — DX thứ hai | cùng loại đường truyền | hiệu năng tương đương, độ trễ ổn định | | B — VPN qua Internet | loại đường truyền KHÁC | rẻ hơn nhiều, băng thông thấp hơn |

Vì sao dùng cả hai là thiết kế tốt: chúng dự phòng theo hai chiều khác nhau.

DX thứ hai   → chống hỏng một kết nối DX (cùng công nghệ)
VPN qua Net  → chống hỏng CẢ HỆ THỐNG DX (khác công nghệ, khác nhà cung cấp)

Và vế "cùng Region với VPC-1" trong đáp án E là chi tiết bắt buộc: private virtual interface chỉ kết nối tới VPC trong cùng Region (trừ khi qua Direct Connect Gateway). Đặt DX ở Region của VPC-2 không giúp gì cho VPC-1.

VPC peering KHÔNG bắc cầu — đây là lý do mọi phương án hướng về VPC-2 đều sai:

Mạng tại chỗ ──DX── VPC-1 ──peering── VPC-2

Lưu lượng từ tại chỗ KHÔNG đi qua VPC-2 để tới VPC-1
    → và ngược lại cũng không

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

  • D. Thiết lập một Direct Connect connection và private virtual interface mới ở cùng Region với VPC-2 — đây là phương án gần nhất và thoạt nhìn hợp lý, nhưng nó không giúp gì cho VPC-1: private VIF tới VPC-2 chỉ phục vụ VPC-2, và VPC peering không bắc cầu nên lưu lượng không đi vòng qua đó được.
  • C. Thiết lập hardware VPN qua Internet giữa VPC-2 và mạng tại chỗ — cùng lỗi: nó tạo đường dự phòng cho VPC-2, không phải VPC-1.
  • A. Dùng AWS VPN CloudHub để tạo Direct Connect connection và private VIF mới ở cùng Region với VPC-2 — nhầm chức năng của CloudHub: nó là mô hình kết nối NHIỀU CHI NHÁNH tại chỗ với nhau qua AWS theo kiểu trục bánh xe. Nó không tạo Direct Connect và không liên quan tới việc dự phòng cho một VPC.

Ghi nhớ

Ba cách kết nối mạng tại chỗ với AWS: | Cách | Mã hoá | Độ trễ | Chi phí | |---|---|---|---| | Site-to-Site VPN | ✅ IPsec | biến động (qua Internet) | thấp | | Direct Connect | ❌ KHÔNG mã hoá | thấp và ổn định | cao | | DX + VPN | ✅ | thấp và ổn định | cao nhất |

Dòng giữa đáng nhớ: Direct Connect không mã hoá dữ liệu — nó riêng tư về định tuyến nhưng dữ liệu đi ở dạng rõ. Cần mã hoá thì chạy IPsec VPN bên trong DX.

Bốn mức dự phòng cho Direct Connect — theo khuyến nghị của AWS: | Mức | Cấu hình | Phù hợp | |---|---|---| | Phát triển | một DX, một vị trí | không quan trọng | | Sản xuất cơ bản | hai DX ở CÙNG vị trí | chống hỏng thiết bị | | Sản xuất cao | hai DX ở HAI VỊ TRÍ khác nhau | chống hỏng cả một cơ sở | | Tối đa | DX kép + VPN dự phòng ← câu này | chống mọi kịch bản |

Ba loại virtual interface của Direct Connect: | Loại | Dùng để | |---|---| | Private VIF | truy cập VPC qua IP riêng ← câu này | | Public VIF | truy cập dịch vụ công khai của AWS | | Transit VIF | kết nối tới Transit Gateway — phục vụ NHIỀU VPC |

Transit VIF là giải pháp hiện đại cho tình huống nhiều VPC: thay vì một private VIF cho mỗi VPC, một Transit VIF nối tới Transit Gateway phục vụ được tất cả — và nó bắc cầu được, khác VPC peering.

Ba hạn chế của VPC peering cần nhớ: | Hạn chế | Chi tiết | |---|---| | KHÔNG bắc cầu | A↔B và B↔C không cho A↔C ← điểm mấu chốt câu này | | CIDR không được chồng lấn | | | Tham chiếu security group chỉ trong cùng Region | |

Dòng đầu cũng có nghĩa là: lưu lượng từ Direct Connect hay VPN KHÔNG đi qua peering để tới VPC thứ ba. Đây là hạn chế thường gây bất ngờ khi thiết kế mạng lai.

Và một cấu hình định tuyến cần lưu ý khi dùng cả DX lẫn VPN: AWS ưu tiên Direct Connect hơn VPN theo mặc định trong bảng định tuyến. Nên VPN nằm chờ và chỉ nhận lưu lượng khi DX ngừng quảng bá tuyến — đúng hành vi mong muốn cho một đường dự phòng.