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

Đáp án

A — Desired capacity của Auto Scaling group bị giảm, nhưng ASG sẽ không huỷ được instance nào.

Vì sao đúng

Đề mô tả một tình huống rất cụ thể: mọi instance đều được bật termination protection khi scale-in, rồi một sự kiện scale-in xảy ra.

⚠ Điểm mấu chốt: bảo vệ scale-in KHÔNG ngăn ASG ra quyết định — nó chỉ ngăn việc thực thi:

Chính sách co giãn kích hoạt scale-in
        ↓
    ASG giảm desired capacity — bước này LUÔN xảy ra
        ↓
    ASG chọn instance để huỷ
        ↓
    Mọi ứng viên đều bật scale-in protection
        ↓
    → không huỷ được cái nào
    → desired capacity đã giảm, số instance thực tế không đổi

Kết quả là một trạng thái lệch: ASG "muốn" ít máy hơn nhưng không thực hiện được.

# xem trạng thái lệch
aws autoscaling describe-auto-scaling-groups \
  --query 'AutoScalingGroups[0].{Desired:DesiredCapacity,ThucTe:length(Instances)}'

⚠ Scale-in protection khác với termination protection của EC2: | Cơ chế | Ngăn cái gì | |---|---| | Scale-in protection (ASG) | ASG huỷ máy khi co giãn vào | | Termination protection (EC2) | lời gọi TerminateInstances thủ công | | Không cái nào ngăn | huỷ do health check thất bại, hoặc thu hồi Spot |

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

• B (desired capacity giảm và các instance bị huỷ theo cấu hình) — đây là phương án gần nhất và nó mô tả đúng hành vi bình thường của ASG. Nhưng nó bỏ qua chính điều kiện mà đề đặt ra: các instance được bảo vệ, nên bước huỷ không thực hiện được. Đây là bẫy chọn hành vi mặc định mà quên dữ kiện đặc biệt trong đề.

• C (khi mọi instance đều được bảo vệ thì sự kiện scale-in không được sinh ra) — sai về cơ chế. ASG không kiểm tra trạng thái bảo vệ trước khi quyết định co giãn: chính sách co giãn dựa trên chỉ số CloudWatch, và nó kích hoạt bất kể instance có được bảo vệ hay không. Việc bảo vệ chỉ ảnh hưởng ở bước thực thi.

• D (minimum capacity bị giảm) — sai thuộc tính. Co giãn thay đổi desired capacity; MinSize và MaxSize là các biên do bạn đặt và ASG không tự sửa chúng.

Ghi nhớ

⚠ Ba thuộc tính dung lượng của ASG — bảng phải thuộc: | Thuộc tính | Ai đổi | |---|---| | DesiredCapacity | chính sách co giãn tự đổi | | MinSize | bạn đặt — ASG không xuống dưới | | MaxSize | bạn đặt — ASG không vượt lên |

Từ khoá nhận diện:

"scale-in protection" + scale-in xảy ra → desired giảm, không huỷ được máy "termination protection" cho EC2 → chỉ ngăn TerminateInstances thủ công "sự kiện scale-in không được sinh ra" → SAI, quyết định vẫn xảy ra "minimum capacity bị giảm" → SAI, co giãn đổi desired máy hỏng health check → vẫn bị thay, bảo vệ không ngăn được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có lệch giữa desired và thực tế không | describe-auto-scaling-groups | | Instance nào đang được bảo vệ | xem ProtectedFromScaleIn của từng instance | | Vì sao không co giãn được | lịch sử hoạt động của ASG ghi rõ |

Và một lời khuyên: hãy dùng lifecycle hook thay cho scale-in protection khi lý do là "máy đang bận". Bảo vệ scale-in là một công tắc nhị phân: máy đó không bao giờ bị co giãn huỷ cho tới khi ai đó tắt cờ đi — và nếu quên tắt, bạn có một đội máy không bao giờ co lại được, trả tiền mãi cho dung lượng không dùng. Lifecycle hook giải quyết cùng vấn đề theo hướng tự phục hồi: máy được cho thêm thời gian để hoàn tất việc đang làm, rồi tự báo là đã xong và chấp nhận bị huỷ.

Đáp án

C — Duy trì hệ điều hành và nền tảng của Amazon S3.

Vì sao đúng

Mô hình trách nhiệm chung của AWS chia theo một đường ranh giới rõ ràng: AWS chịu trách nhiệm bảo mật CỦA đám mây, khách hàng chịu trách nhiệm bảo mật TRONG đám mây.

⚠ Điểm mấu chốt: với dịch vụ TRỪU TƯỢNG như S3, AWS lo gần như toàn bộ hạ tầng — bạn chỉ lo dữ liệu và cấu hình:

Dịch vụ hạ tầng (EC2)
        ↓
    Bạn lo: hệ điều hành khách, vá lỗi, ứng dụng, firewall, dữ liệu
        ↓
Dịch vụ trừu tượng (S3, DynamoDB, SQS)
        ↓
    AWS lo: hạ tầng, hệ điều hành, nền tảng, vá lỗi
    Bạn lo: dữ liệu, phân loại, mã hoá, quyền truy cập
        ↓
    → bạn KHÔNG có hệ điều hành nào để mà vá

Ba phương án còn lại đều là những việc bạn làm, và đó chính là ranh giới mà câu hỏi kiểm tra.

⚠ Đường ranh giới dịch chuyển theo loại dịch vụ: | Loại | Ví dụ | Bạn lo gì | |---|---|---| | Hạ tầng (IaaS) | EC2, VPC, EBS | hệ điều hành, vá lỗi, ứng dụng, mạng, dữ liệu | | Container | ECS, EKS, Fargate | ứng dụng, cấu hình, dữ liệu (Fargate lo giúp cả OS) | | Trừu tượng (PaaS/SaaS) | S3, DynamoDB, Lambda | chỉ dữ liệu, cấu hình, quyền |

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

• B (chọn tuỳ chọn mã hoá cho dữ liệu trong bucket) — đây là phương án gần nhất và nó liên quan trực tiếp tới bảo mật S3. Nhưng đó là trách nhiệm của khách hàng: AWS cung cấp các cơ chế mã hoá (SSE-S3, SSE-KMS, SSE-C), còn việc quyết định dùng cái nào và có bật hay không là của bạn. Đây là bẫy hay vì mã hoá nghe như thứ nhà cung cấp phải lo, trong khi thực tế AWS chỉ cung cấp công cụ.

• A (định nghĩa quy tắc chuyển dữ liệu giữa các lớp lưu trữ S3) — lifecycle policy là cấu hình do bạn đặt, phản ánh nhu cầu nghiệp vụ và chi phí của chính bạn. AWS không biết dữ liệu nào của bạn nên chuyển sang Glacier khi nào.

• D (quản lý dữ liệu nằm trong bucket) — rõ ràng nhất: dữ liệu luôn thuộc trách nhiệm của khách hàng, ở mọi loại dịch vụ, không có ngoại lệ.

Ghi nhớ

⚠ Mô hình trách nhiệm chung — bảng phải thuộc: | AWS lo | Khách hàng lo | |---|---| | Cơ sở vật chất, phần cứng | Dữ liệu và phân loại dữ liệu | | Ảo hoá, mạng nền | Kiểm soát truy cập (IAM) | | Hệ điều hành của dịch vụ có quản lý | Mã hoá — bật và chọn cách | | Vá lỗi nền tảng dịch vụ trừu tượng | Cấu hình dịch vụ | | Bảo mật vật lý | Firewall, security group |

Câu tóm gọn: AWS bảo mật "OF the cloud", khách hàng bảo mật "IN the cloud".

Từ khoá nhận diện:

"abstracted service" như S3, DynamoDB → AWS lo hệ điều hành và nền tảng "dữ liệu" → LUÔN là trách nhiệm khách hàng "chọn tuỳ chọn mã hoá" → khách hàng — AWS chỉ cung cấp công cụ "lifecycle policy" → khách hàng cấu hình EC2 → khách hàng vá hệ điều hành khách; AWS lo hypervisor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cấu hình bảo mật của bạn có đúng không | AWS Config rule, Security Hub | | AWS đang lo phần nào | trang mô hình trách nhiệm chung của AWS cho từng dịch vụ | | Có bằng chứng tuân thủ không | AWS Artifact — báo cáo kiểm toán của AWS |

Và một lời khuyên: hãy tải báo cáo tuân thủ từ AWS Artifact khi cần chứng minh phần trách nhiệm của AWS trong một cuộc kiểm toán. Kiểm toán viên thường hỏi những câu mà bạn không tự trả lời được — trung tâm dữ liệu có kiểm soát ra vào không, đĩa hỏng được huỷ thế nào, nhân viên AWS truy cập hạ tầng ra sao. Bạn không có quyền vào kiểm tra những thứ đó, và cũng không cần: AWS Artifact cung cấp sẵn các báo cáo SOC, ISO, PCI DSS đã được kiểm toán độc lập, tải về ngay trong console. Đó là bằng chứng cho nửa của AWS, và nửa còn lại là việc bạn chứng minh cấu hình của chính mình.

Đáp án

C, E — hai điều cần kiểm khi read replica của RDS for MySQL liên tục gặp lỗi:

• C — Nếu giá trị max_allowed_packet của read replica NHỎ HƠN của instance nguồn thì lỗi sao chép sẽ xảy ra.
• E — Ghi vào bảng trên read replica có thể làm hỏng quá trình sao chép.

Vì sao đúng

Sao chép MySQL là quá trình phát lại các câu lệnh (hoặc sự kiện hàng) từ nguồn sang bản sao. Bất cứ điều gì khiến bản sao không phát lại được đều làm đứt sao chép.

⚠ Điểm mấu chốt: max_allowed_packet ở replica phải LỚN HƠN HOẶC BẰNG ở nguồn:

Nguồn cho phép gói tin lớn (ví dụ 64 MB)
        ↓
    Một câu INSERT với BLOB lớn được ghi vào binlog
        ↓
    Replica có max_allowed_packet nhỏ hơn (ví dụ 16 MB)
        ↓
    → không đọc nổi sự kiện đó → sao chép dừng với lỗi

Vì sao ghi vào replica làm hỏng sao chép (E). Read replica được thiết kế chỉ đọc. Nếu bạn ghi vào:

Ghi trực tiếp một dòng vào replica
        ↓
    Sau đó nguồn gửi một sự kiện đụng tới cùng dòng đó
        ↓
    Replica phát lại → xung đột khoá chính, hoặc không tìm thấy dòng
        ↓
    → sao chép dừng, và phải can thiệp thủ công để tiếp tục

-- kiểm tra
SHOW VARIABLES LIKE 'max_allowed_packet';
SHOW REPLICA STATUS\G   -- xem Last_Error

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

• A (read replica chạy được trên cả storage engine giao dịch lẫn phi giao dịch, nhưng engine phi giao dịch dễ lỗi vì cách quản lý bộ nhớ) — đây là phương án gần nhất và nó chạm đúng một sự thật: engine phi giao dịch như MyISAM thật sự gây vấn đề với sao chép. Nhưng lý do nó nêu là sai: vấn đề không phải cách quản lý bộ nhớ mà là thiếu tính giao dịch — MyISAM không hỗ trợ rollback, nên một thao tác dở dang không thể được phát lại nhất quán. Ngoài ra RDS khuyến nghị InnoDB, và với MyISAM thì read replica còn không được hỗ trợ đầy đủ.

• B (câu lệnh chứa hàm không tất định như SYSDATE() phải được khai trước trong cấu hình để tạo được replica) — hàm không tất định thật sự gây vấn đề với statement-based replication, nhưng không có cơ chế "khai trước trong cấu hình" nào cả. Cách xử lý là chuyển sang row-based replication (binlog_format = ROW), vốn ghi lại kết quả thay vì câu lệnh.

• D (để ghi an toàn vào bảng trên replica, hãy tạo index sau khi đặt read_only thành 0) — mâu thuẫn trực tiếp với phương án E, vốn là đáp án đúng. Không có cách nào ghi "an toàn" vào read replica; tắt read_only để ghi là chính hành động phá vỡ sao chép.

Ghi nhớ

⚠ Bốn nguyên nhân lỗi sao chép RDS MySQL — bảng phải thuộc: | Nguyên nhân | Cách chữa | |---|---| | max_allowed_packet ở replica nhỏ hơn | đặt bằng hoặc lớn hơn nguồn | | Ghi trực tiếp vào replica | giữ read_only = 1 | | Storage engine phi giao dịch (MyISAM) | chuyển sang InnoDB | | Hàm không tất định với statement-based | dùng binlog_format = ROW |

Từ khoá nhận diện:

"replica errors" + tham số cấu hình → kiểm max_allowed_packet trước tiên "ghi vào read replica" → phá vỡ sao chép "đặt read_only = 0 để ghi an toàn" → LUÔN SAI, không có cách an toàn hàm không tất định → chuyển sang row-based replication MyISAM → không hợp với read replica, dùng InnoDB

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sao chép có đang chạy không | SHOW REPLICA STATUS, xem Replica_IO_Running và Replica_SQL_Running | | Độ trễ bao nhiêu | chỉ số ReplicaLag | | Tham số hai bên có khớp không | so parameter group của nguồn và replica |

Và một lời khuyên: hãy đặt cảnh báo trên ReplicaLag chứ đừng chỉ kiểm tra khi có sự cố. Sao chép MySQL hỏng theo cách rất im lặng: khi luồng SQL dừng vì một lỗi, replica vẫn chấp nhận kết nối và vẫn trả lời truy vấn — chỉ là với dữ liệu ngày càng cũ. Ứng dụng đọc từ nó không nhận được lỗi nào, người dùng chỉ thấy dữ liệu lạ, và không có gì trong bảng điều khiển RDS đập vào mắt bạn. ReplicaLag tăng vô hạn là tín hiệu duy nhất, và nó chỉ hữu ích nếu có ai đó — hoặc một alarm — đang nhìn vào nó.

Đáp án

B — Dùng CloudWatch Synthetics để tạo canary, và các canary này sinh ra CloudWatch metric để theo dõi dịch vụ.

Vì sao đúng

Đề mô tả chính xác thứ CloudWatch Synthetics làm: script cấu hình được, chạy theo lịch, giám sát endpoint và API.

⚠ Điểm mấu chốt: canary là giám sát CHỦ ĐỘNG — nó phát hiện sự cố trước cả người dùng:

Giám sát bị động (log, metric từ lưu lượng thật)
        ↓
    Chỉ biết có vấn đề khi đã có người dùng gặp phải
        ↓
Canary
        ↓
    Chạy theo lịch, tự gọi endpoint như một người dùng thật
        ↓
    → phát hiện endpoint chết ngay cả lúc không ai truy cập
    → biết trước người dùng thật, kể cả ban đêm

const synthetics = require('Synthetics');
const apiCanary = async function () {
  const response = await synthetics.executeHttpStep('kiem-tra-api',
    { hostname: 'api.congty.vn', path: '/health', method: 'GET' });
  return response;
};
exports.handler = async () => await apiCanary();

Chỉ số canary tự sinh ra:

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

• A (dùng CloudWatch ServiceLens để tích hợp script tuỳ chỉnh vào CloudWatch nhằm sinh metric và log) — đây là phương án gần nhất và ServiceLens là tính năng có thật của CloudWatch. Nhưng vai trò của nó khác: ServiceLens gộp metric, log và trace của X-Ray lại thành một bức tranh về sức khoẻ ứng dụng — nó là công cụ hiển thị và tương quan, không phải nơi để chạy script tuỳ chỉnh. Nó tiêu thụ dữ liệu chứ không tạo ra dữ liệu.

• C (cấu hình CloudWatch Composite Alarm và tích hợp script với CloudWatch Logs) — sai vai trò. Composite alarm gộp nhiều alarm khác lại theo biểu thức logic — ví dụ "báo động khi cả A và B cùng kêu" — để giảm nhiễu. Nó không chạy script và không sinh dữ liệu giám sát.

• D (dùng cài đặt CloudWatch Dashboard để tích hợp script vào alarm) — Dashboard chỉ để hiển thị. Nó vẽ biểu đồ từ metric đã có; nó không chạy gì và không tạo metric.

Ghi nhớ

⚠ Bốn thành phần giám sát của CloudWatch — bảng phải thuộc: | Thành phần | Việc | |---|---| | Synthetics (canary) | chạy script theo lịch để giám sát chủ động | | RUM | thu thập trải nghiệm người dùng thật từ trình duyệt | | ServiceLens | gộp metric, log, trace thành một bức tranh | | Composite alarm | gộp nhiều alarm theo biểu thức logic |

Từ khoá nhận diện:

"script chạy hằng ngày để giám sát endpoint và API" → CloudWatch Synthetics "giám sát chủ động" → canary "trải nghiệm người dùng thật" → CloudWatch RUM "ServiceLens để chạy script" → SAI, nó gộp và hiển thị "Dashboard để tích hợp script" → SAI, Dashboard chỉ hiển thị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Canary có chạy đúng lịch không | lịch sử chạy trong console Synthetics | | Thất bại vì lý do gì | ảnh chụp màn hình và log trong S3 | | Alarm có kêu đúng lúc không | tạm dừng endpoint và quan sát |

Và một lời khuyên: hãy cho canary chạy từ trong VPC nếu bạn cần giám sát endpoint nội bộ, và từ ngoài nếu cần giám sát trải nghiệm người dùng thật. Đây là hai phép đo trả lời hai câu hỏi khác nhau, và chọn nhầm chỗ đặt canary sẽ cho bạn cảm giác an toàn sai lệch: một canary chạy trong VPC gọi thẳng vào ALB sẽ báo mọi thứ đều tốt trong khi người dùng bên ngoài không vào được vì DNS sai, chứng chỉ hết hạn, hay WAF chặn nhầm. Nếu chỉ dựng được một cái, hãy dựng cái đi theo đúng đường mà người dùng thật đi.

Đáp án

B — Nếu AMI có sẵn CloudWatch agent thì agent tự động được cài khi tạo Auto Scaling group. Lập trình viên cần chọn AMI đã cấu hình sẵn agent.

Vì sao đúng

Đề nói rõ quản trị viên không cài agent thủ công trên nhóm nào, nhưng một nhóm lại có agent. Chỉ một nguồn giải thích được điều đó: AMI.

⚠ Điểm mấu chốt: mọi thứ có sẵn trong AMI đều xuất hiện trên mọi instance khởi động từ nó:

AMI đã cài sẵn CloudWatch agent
        ↓
    Mọi instance khởi động từ AMI đó đều có agent
        ↓
    → không cần thao tác gì thêm
        ↓
AMI chuẩn của Amazon Linux
        ↓
    Không có agent → phải cài bằng user data hoặc Systems Manager

⚠ Có agent chưa đủ — instance còn cần IAM role để gửi dữ liệu:

Agent chạy nhưng thiếu quyền
        ↓
    Không đẩy được metric lên CloudWatch
        ↓
    → cần policy CloudWatchAgentServerPolicy trong instance profile

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

• A (có một cờ khi cấu hình ASG để nạp CloudWatch agent, lập trình viên đã vô tình tích vào một ASG) — đây là phương án gần nhất và nghe rất hợp lý. Nhưng không có tuỳ chọn nào như vậy trong cấu hình Auto Scaling group: ASG chỉ khai launch template và chính sách co giãn, nó không cài phần mềm.

• C (kiến trúc instance không tương thích với AMI, dẫn tới bỏ qua một số dịch vụ AWS) — không tương thích kiến trúc thì instance không khởi động được, chứ không phải khởi động rồi thiếu vài dịch vụ.

• D (kiến trúc InstanceType không khớp image nên ASG tạo ra với lỗi và bỏ qua CloudWatch agent) — cùng lỗi logic với C: lệch kiến trúc gây thất bại khởi động, không gây thiếu phần mềm một cách chọn lọc.

Ghi nhớ

⚠ Ba cách đưa CloudWatch agent lên EC2 — bảng phải thuộc: | Cách | Đặc điểm | |---|---| | Có sẵn trong AMI | mọi instance từ AMI đó đều có | | User data script | cài lúc khởi động, chậm hơn | | Systems Manager Distributor | cài và cập nhật tập trung cho cả đội máy |

Từ khoá nhận diện:

"không ai cài thủ công nhưng một nhóm có" → khác AMI "cờ bật CloudWatch agent trong ASG" → LUÔN SAI, không tồn tại lệch kiến trúc → không khởi động được, không phải thiếu phần mềm agent chạy mà không có dữ liệu → kiểm IAM role

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Agent có chạy không | amazon-cloudwatch-agent-ctl -a status | | Instance có role không | describe-instances, xem IamInstanceProfile | | Metric có tới không | tìm namespace CWAgent trong CloudWatch |

Và một lời khuyên: hãy dùng Systems Manager Distributor để cài và cập nhật agent thay vì nhúng vào AMI. Nhúng vào AMI cho kết quả ngay nhưng khoá bạn vào phiên bản agent tại thời điểm dựng image: mỗi lần AWS phát hành bản mới, bạn phải dựng lại AMI và cập nhật launch template cho mọi ASG. Distributor cài lên đội máy đang chạy và tự nâng cấp theo lịch, nên phiên bản agent không còn gắn với vòng đời của image.

Đáp án

B, C — hai điều đúng về đường đi của lưu lượng giữa các EC2 khi dùng IP công cộng:

• B — Lưu lượng giữa hai EC2 trong CÙNG một Region ở lại trong mạng AWS, kể cả khi đi qua địa chỉ IP công cộng.
• C — Lưu lượng giữa các EC2 ở KHÁC Region ở lại trong mạng AWS nếu có Inter-Region VPC Peering giữa hai VPC.

Vì sao đúng

Câu hỏi kiểm tra một điều rất cụ thể: dùng IP công cộng không có nghĩa là đi qua Internet công cộng.

⚠ Điểm mấu chốt: AWS định tuyến lưu lượng nội bộ khi nó nhận ra cả hai đầu đều thuộc mạng của mình — nhưng chỉ trong phạm vi một Region:

Hai EC2 cùng Region, gọi nhau qua IP công cộng
        ↓
    AWS nhận ra cả hai IP đều thuộc dải của mình trong Region đó
        ↓
    → định tuyến nội bộ, không ra Internet
        ↓
Hai Region khác nhau, không có peering
        ↓
    → lưu lượng đi qua Internet công cộng

⚠ Dùng IP riêng vẫn tốt hơn IP công cộng, kể cả khi đường đi giống nhau:

IP công cộng cùng Region → lưu lượng nội bộ, nhưng VẪN tính phí truyền dữ liệu
IP riêng cùng AZ → miễn phí
        ↓
    → luôn ưu tiên IP riêng khi có thể

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

• A (lưu lượng giữa hai EC2 LUÔN ở trong mạng AWS, kể cả qua IP công cộng, nhờ AWS Global Infrastructure) — đây là phương án gần nhất và nó đúng trong phần lớn trường hợp. Nhưng chữ "always" làm nó sai: khi hai instance ở hai Region khác nhau và không có kết nối peering, lưu lượng đi qua Internet công cộng.

• D (Direct Connect là cách mặc định khi không có peering) — Direct Connect nối trung tâm dữ liệu của bạn với AWS, nó không phải cơ chế mặc định giữa các EC2 và không tự tồn tại.

• E (dùng edge location để liên lạc giữa các Region mà không qua Internet) — edge location phục vụ CloudFront và Route 53, không phải đường trung chuyển cho lưu lượng EC2 tới EC2.

Ghi nhớ

⚠ Bốn cách nối hai VPC — bảng phải thuộc: | Cách | Phạm vi | |---|---| | VPC peering | trong Region hoặc liên Region | | Transit gateway | trong Region, nối Region bằng peering | | PrivateLink | phơi một dịch vụ, một chiều | | Qua IP công cộng | nội bộ nếu cùng Region |

Từ khoá nhận diện:

"cùng Region, IP công cộng" → ở trong mạng AWS "khác Region, có peering" → ở trong mạng AWS "always stays within AWS network" → SAI, có ngoại lệ "edge location cho lưu lượng EC2" → SAI, đó là CloudFront "Direct Connect mặc định" → SAI, DX nối on-premises

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đường đi thật | traceroute — không được thấy hop của nhà mạng | | Chi phí truyền dữ liệu | Cost Explorer, lọc theo DataTransfer | | Peering có hoạt động không | kiểm route table hai bên |

Và một lời khuyên: hãy dùng địa chỉ IP riêng bất cứ khi nào hai instance có thể tới nhau bằng đường riêng. Ngay cả khi lưu lượng qua IP công cộng cùng Region không rời khỏi mạng AWS, nó vẫn bị tính phí truyền dữ liệu như lưu lượng Internet — và đó là khoản chi phí ẩn phổ biến trong các kiến trúc cũ nơi ứng dụng được cấu hình bằng tên miền công khai. Đổi sang endpoint riêng thường không cần sửa gì ngoài một dòng cấu hình, và khoản tiết kiệm hiện ra ngay ở kỳ hoá đơn tiếp theo.

Đáp án

D — Bỏ qua hoặc chặn (suppress) cảnh báo đỏ này, vì trong tình huống này làm vậy là an toàn.

Vì sao đúng

Đề nói rõ security group bị gắn cờ là do AWS Directory Service tạo ra. Đây là trường hợp AWS ghi nhận công khai là dương tính giả.

⚠ Điểm mấu chốt: sửa security group do dịch vụ tự tạo sẽ làm hỏng chính dịch vụ đó:

Directory Service tạo security group với các cổng AD cần thiết
        ↓
    Trusted Advisor thấy dải cổng rộng → gắn cờ theo quy tắc chung
        ↓
    Nếu bạn siết lại theo cảnh báo
        ↓
    → domain controller ngừng hoạt động, người dùng không đăng nhập được
        ↓
    → AWS khuyến nghị BỎ QUA cảnh báo này cho security group của Directory Service

Trusted Advisor có tính năng suppress để đánh dấu một tài nguyên là đã xem xét và chấp nhận — cảnh báo không hiện lại nữa mà không cần sửa gì.

⚠ Bỏ qua không đồng nghĩa với lơ là — hãy ghi lại lý do:

Suppress một cảnh báo mà không ghi chú
        ↓
    Sáu tháng sau không ai nhớ vì sao
        ↓
    → ghi lại quyết định và lý do ở nơi đội bảo mật đọc được

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

• C (kiểm tra và sửa cấu hình security group cho khớp chuẩn bảo mật của AWS) — đây là phương án gần nhất và là phản xạ đúng với hầu hết cảnh báo bảo mật. Nhưng ở đây nó phá hỏng dịch vụ: các cổng mà Directory Service mở là bắt buộc cho LDAP, Kerberos, DNS và các giao thức của domain controller. Siết lại là làm Active Directory ngừng phục vụ.

• A (dùng Trusted Advisor để biết lý do chính xác rồi làm theo khuyến nghị) — chính Trusted Advisor là thứ đã gắn cờ, và khuyến nghị chung của nó là siết security group — dẫn tới cùng hậu quả như C.

• B (Directory Service có thể đã được khởi tạo từ tài khoản thiếu quyền, kiểm IAM role và user) — không liên quan. Thiếu quyền thì dịch vụ không tạo được, chứ không tạo ra security group mở rộng.

Ghi nhớ

⚠ Bốn tình huống dương tính giả thường gặp của Trusted Advisor — bảng phải thuộc: | Tình huống | Vì sao là dương tính giả | |---|---| | Security group của Directory Service | các cổng AD là bắt buộc | | Security group của ELB | phải mở cho lưu lượng công khai | | Bucket S3 cố ý công khai | website tĩnh | | RI utilization thấp ngay sau khi mua | chưa đủ thời gian đánh giá |

Từ khoá nhận diện:

security group do dịch vụ AWS tự tạo bị gắn cờ → thường là dương tính giả "suppress" trong Trusted Advisor → đánh dấu đã xem xét, không hiện lại sửa security group của Directory Service → phá hỏng đăng nhập thiếu quyền IAM → dịch vụ không tạo được, không phải cấu hình lỏng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Security group thuộc về ai | kiểm tag và mô tả — dịch vụ AWS thường ghi rõ | | Suppress có hiệu lực không | làm mới kiểm tra và xem cờ còn không | | Có cảnh báo thật nào bị lẫn không | rà toàn bộ danh sách trước khi suppress hàng loạt |

Và một lời khuyên: hãy ghi lại lý do mỗi lần suppress một cảnh báo, ở một nơi ngoài chính Trusted Advisor. Suppress là quyết định đúng ở đây, nhưng nó biến một cảnh báo hiển thị thành một trạng thái vô hình — và người tiếp quản hệ thống sau bạn sẽ không có cách nào biết đó là quyết định có cân nhắc hay là một cái nút ai đó bấm cho đỡ phiền. Một dòng ghi chú trong tài liệu vận hành biến nó từ thứ hai thành thứ nhất.

Đáp án

D — Tạo scheduled scaling action để tăng dung lượng TRƯỚC khi đợt tải tới.

Vì sao đúng

Đề mô tả một mẫu tải hoàn hảo cho co giãn theo lịch: đỉnh xảy ra 5–6 giờ chiều gần như mỗi ngày, tức là đoán trước được.

⚠ Điểm mấu chốt: co giãn phản ứng luôn chậm hơn đỉnh tải — co giãn theo lịch thì đi trước:

Target tracking hoặc step scaling
        ↓
    CloudWatch phát hiện tải tăng → alarm → thêm máy → chờ khởi động
        ↓
    Tổng cộng vài phút — trong khi người dùng đã gặp lag
        ↓
Scheduled scaling
        ↓
    Tăng dung lượng lúc 16:45, trước khi đỉnh tới lúc 17:00
        ↓
    → máy đã sẵn sàng khi lưu lượng đổ vào

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg --scheduled-action-name tang-truoc-dinh \
  --recurrence "45 16 * * *" --min-size 10 --desired-capacity 10

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg --scheduled-action-name ha-sau-dinh \
  --recurrence "30 18 * * *" --min-size 2 --desired-capacity 2

⚠ Giờ trong scheduled action tính theo UTC nếu không khai time zone:

Khai "0 17 * * *" mà không đặt time zone
        ↓
    Hành động chạy lúc 17:00 UTC = 00:00 giờ Việt Nam
        ↓
    → đỉnh tải vẫn không được phục vụ, và không có lỗi nào báo

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

• C (sửa launch configuration của ASG để có nhiều instance hơn) — đây là phương án gần nhất và nó thật sự tăng được dung lượng. Nhưng launch configuration khai cách dựng một instance, không khai số lượng — số lượng nằm ở DesiredCapacity của ASG. Và ngay cả khi hiểu ý là tăng dung lượng cố định, thì bạn trả tiền cho dung lượng đỉnh suốt 24 giờ để phục vụ một giờ.

• A (thêm vài instance thủ công vào ASG khi có đỉnh) — đòi ai đó có mặt đúng giờ mỗi ngày, và nhớ hạ xuống sau đó. Không bền vững.

• B (cấu hình ELB để thay thế ASG và chuyển mọi instance sang ELB) — nhầm vai trò. ELB phân phối lưu lượng, nó không thêm hay bớt máy — đó là việc của Auto Scaling. Hai thứ bổ sung cho nhau chứ không thay thế nhau.

Ghi nhớ

⚠ Bốn loại chính sách co giãn — bảng phải thuộc: | Loại | Thời điểm phản ứng | |---|---| | Scheduled | TRƯỚC — theo lịch biết trước | | Target tracking | sau khi tải tăng, giữ chỉ số ở mức mục tiêu | | Step scaling | sau, phản ứng theo bậc | | Predictive | trước — học máy dự đoán từ lịch sử |

Từ khoá nhận diện:

"đỉnh vào đúng khung giờ mỗi ngày" → scheduled scaling "đỉnh không đoán trước được" → target tracking hoặc predictive "launch configuration để tăng số instance" → SAI, số lượng ở DesiredCapacity "ELB thay thế ASG" → SAI, hai vai trò khác nhau thêm máy thủ công → không bền vững

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hành động có chạy đúng giờ không | lịch sử hoạt động của ASG | | Máy có kịp sẵn sàng không | so thời điểm scale với thời điểm đỉnh trong log | | Có hạ xuống sau đó không | biểu đồ số instance theo ngày |

Và một lời khuyên: hãy đặt scheduled action tăng dung lượng sớm hơn đỉnh ít nhất mười lăm phút. Instance cần thời gian để khởi động, cài đặt, qua health check và được đăng ký vào load balancer — thường vài phút, và lâu hơn nếu ứng dụng có bước khởi tạo. Nếu bạn đặt lịch đúng vào thời điểm đỉnh bắt đầu, máy mới vẫn đang khởi động khi lưu lượng đã đổ vào, và người dùng vẫn gặp đúng vấn đề mà bạn định giải quyết.

Đáp án

A — Kiểm tra xem tên thiết bị bạn khai lúc gắn volume có đang được dùng rồi không; thử gắn lại với một tên thiết bị khác.

Vì sao đúng

Trạng thái attaching kéo dài 10–15 phút là dấu hiệu đặc trưng của xung đột tên thiết bị.

⚠ Điểm mấu chốt: mỗi tên thiết bị chỉ dùng được một lần trên một instance:

Gắn volume với tên /dev/sdf
        ↓
    Nhưng /dev/sdf đã có một volume khác
        ↓
    Thao tác không hoàn tất, trạng thái treo ở attaching
        ↓
    → gắn lại với /dev/sdg là xong

aws ec2 describe-instances --instance-ids i-0abc \
  --query 'Reservations[].Instances[].BlockDeviceMappings[].DeviceName'

aws ec2 attach-volume --volume-id vol-0abc \
  --instance-id i-0abc --device /dev/sdg

⚠ Volume và instance phải ở CÙNG Availability Zone:

EBS volume gắn với một AZ cụ thể
        ↓
    Không gắn được vào instance ở AZ khác
        ↓
    → muốn chuyển AZ: chụp snapshot rồi tạo volume mới ở AZ đích

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

• B (volume có thể đã mã hoá và thiếu khoá KMS tuỳ chỉnh dùng để mã hoá snapshot, cần thêm khoá vào cấu hình volume) — đây là phương án gần nhất và vấn đề quyền KMS là nguyên nhân có thật với EBS. Nhưng nó gây ra triệu chứng khác: thiếu quyền KMS thì thao tác thất bại ngay với lỗi rõ ràng, hoặc volume chuyển sang trạng thái error — chứ không treo ở attaching. Và không có thao tác "thêm khoá KMS vào cấu hình volume"; khoá được gắn lúc tạo và không đổi được.

• C (mỗi volume nhận một số dư I/O credit ban đầu, lỗi tích luỹ credit ngăn volume gắn được, khởi động lại instance để sửa) — I/O credit liên quan tới hiệu năng của gp2, hoàn toàn không liên quan tới việc gắn volume.

• D (trạng thái attaching nghĩa là phần cứng bên dưới đã hỏng, không sửa được, phải mở yêu cầu hỗ trợ) — sai. attaching là trạng thái chuyển tiếp bình thường; trạng thái báo hỏng là error. Và bạn vẫn bị tính tiền cho volume ở trạng thái lỗi, trái với điều phương án này khẳng định.

Ghi nhớ

⚠ Các trạng thái của EBS volume — bảng phải thuộc: | Trạng thái | Nghĩa | |---|---| | creating | đang tạo | | available | sẵn sàng, chưa gắn | | in-use | đã gắn thành công | | deleting, deleted | đang hoặc đã xoá | | error | hỏng — đây mới là trạng thái báo lỗi |

Từ khoá nhận diện:

kẹt ở attaching → kiểm tên thiết bị đã bị chiếm chưa thất bại ngay với lỗi quyền → KMS hoặc IAM không gắn được vào instance → kiểm cùng AZ chưa "I/O credit" → hiệu năng gp2, không liên quan tới việc gắn attaching = phần cứng hỏng → SAI, đó là trạng thái chuyển tiếp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tên thiết bị nào đang dùng | describe-instances xem BlockDeviceMappings | | Volume và instance có cùng AZ không | so AvailabilityZone của cả hai | | Volume có xuất hiện trong OS không | lsblk trên instance |

Và một lời khuyên: hãy chạy lsblk sau khi gắn để xem tên thiết bị thật mà hệ điều hành đặt cho volume. Tên bạn khai lúc gắn (/dev/sdf) chỉ là gợi ý cho AWS; nhân Linux hiện đại thường đổi nó thành /dev/xvdf hoặc /dev/nvme1n1 tuỳ loại instance. Nếu script mount của bạn dùng tên đã khai, nó sẽ thất bại với thông báo "không tìm thấy thiết bị" trên đúng những dòng máy đời mới — và đó là một trong những khác biệt hay gây bối rối nhất khi nâng cấp loại instance.

Đáp án

D — Template CloudFormation có thể chứa tài nguyên IAM đặt tên tuỳ chỉnh (custom named), và đó là nguyên nhân của hành vi bất thường.

Vì sao đúng

Đề mô tả một tình huống rất đặc trưng: cùng một template, tạo stack ở nhiều Region, một số tài nguyên được tạo và một số bị bỏ qua.

⚠ Điểm mấu chốt: tài nguyên IAM là TOÀN CẦU — đặt tên cứng nghĩa là chỉ tạo được một lần trên cả tài khoản:

Template khai IAM role với tên cứng "MyAppRole"
        ↓
    Tạo stack ở Region A → role được tạo
        ↓
    Tạo stack ở Region B với cùng template
        ↓
    → tên "MyAppRole" đã tồn tại (IAM toàn cầu) → tạo thất bại
    → stack không hoàn tất, tài nguyên phía sau bị bỏ qua

Cách chữa là để CloudFormation tự sinh tên:

Resources:
  AppRole:
    Type: AWS::IAM::Role
    Properties:
      # KHÔNG khai RoleName — để CloudFormation tự sinh tên duy nhất
      AssumeRolePolicyDocument: {...}

⚠ Đặt tên cứng cũng ngăn CloudFormation thay thế tài nguyên khi cập nhật:

Một thay đổi đòi thay thế tài nguyên
        ↓
    CloudFormation tạo cái mới TRƯỚC rồi xoá cái cũ
        ↓
    Tên cứng → hai cái cùng tên tồn tại một lúc → xung đột
        ↓
    → cập nhật thất bại, dù ở cùng một Region

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

• B (thiếu quyền IAM — cần cả quyền dùng CloudFormation lẫn quyền dùng các dịch vụ mô tả trong template) — đây là phương án gần nhất và nó nêu một sự thật hoàn toàn đúng về CloudFormation. Nhưng nó không khớp triệu chứng: thiếu quyền thì stack thất bại và rollback, chứ không tạo ra một stack hoàn tất một phần với "một số tài nguyên có, một số không". Và đề nói vấn đề xuất hiện khi tạo ở nhiều Region, gợi ý một nguyên nhân liên quan tới phạm vi chứ không phải quyền.

• A (có lỗi phụ thuộc khiến stack không được tạo hoàn chỉnh) — lỗi phụ thuộc cũng làm stack thất bại và rollback toàn bộ, không để lại trạng thái hoàn tất một phần.

• C (template được tạo với tuỳ chọn dùng-một-lần và không được tái sử dụng) — không có tuỳ chọn nào như vậy; template CloudFormation vốn được thiết kế để dùng lại nhiều lần.

Ghi nhớ

⚠ Tài nguyên toàn cầu so với theo Region — bảng phải thuộc: | Toàn cầu | Theo Region | |---|---| | IAM (user, role, policy, group) | EC2, VPC, subnet | | Route 53 hosted zone | S3 bucket (tên toàn cầu, dữ liệu theo Region) | | CloudFront distribution | RDS, DynamoDB, Lambda | | WAF cho CloudFront | WAF regional |

Từ khoá nhận diện:

cùng template, nhiều Region, tài nguyên thiếu → xung đột tên tài nguyên toàn cầu "custom named IAM resources" → đặt tên cứng gây xung đột thiếu quyền IAM → stack thất bại và rollback, không hoàn tất một phần "template dùng một lần" → LUÔN SAI, không tồn tại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vì sao stack thất bại | tab Events của stack, đọc sự kiện lỗi đầu tiên | | Tài nguyên nào đặt tên cứng | tìm RoleName, PolicyName, BucketName trong template | | Có xung đột tên không | aws iam list-roles xem tên đã tồn tại chưa |

Và một lời khuyên: hãy đọc sự kiện lỗi ĐẦU TIÊN trong tab Events, không phải sự kiện cuối cùng. Khi một stack thất bại, CloudFormation sinh ra một chuỗi dài các sự kiện rollback, và sự kiện cuối cùng thường chỉ nói "ROLLBACK_COMPLETE" hoặc "Resource creation cancelled" — không cho biết gì. Nguyên nhân thật nằm ở sự kiện CREATE_FAILED đầu tiên theo thứ tự thời gian, và nó thường ghi rõ tên tài nguyên cùng lý do, ví dụ "Role with name MyAppRole already exists".