Ngân hàng đề — AWS Certified DevOps Engineer Professional

Đáp án

A — Khởi chạy EC2 với IAM instance profile, và lấy thông tin đăng nhập CSDL từ AWS Secrets Manager.

Vì sao đúng

Đề hỏi cách an toàn nhất để lấy mật khẩu. Có hai quyết định độc lập, và phải đúng cả hai:

Quyết định 1 — EC2 xác thực với AWS bằng gì? | | Instance profile | Access key | |---|---|---| | Thông tin xác thực | tạm thời, tự xoay vòng | tĩnh, tồn tại mãi | | Nằm ở đâu | metadata của instance | phải cất trong file/biến môi trường | | Rò rỉ thì | hết hạn sau vài giờ | dùng được tới khi bị thu hồi |

Quyết định 2 — mật khẩu CSDL cất ở đâu? Secrets Manager: mã hoá bằng KMS, phân quyền bằng IAM, có xoay vòng tự động cho RDS, và tách bạch theo môi trường — đúng nhu cầu dev/test/prod mà đề nêu:

/dev/app/db-password
/test/app/db-password
/prod/app/db-password

Mỗi môi trường một role, mỗi role chỉ đọc được prefix của mình.

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

• B và C. Dùng access key — cả hai chọn đúng kho bí mật nhưng sai ở cách xác thực. Access key tĩnh trên EC2 là điều AWS khuyến nghị không bao giờ làm khi đã có instance profile. Đây là điểm loại duy nhất, và nó đủ để loại cả hai. (C dùng Parameter Store SecureString — bản thân lựa chọn đó hợp lý, chỉ hỏng vì vế access key.)
• D. Instance profile nhưng lưu mật khẩu trong file cấu hình mã hoá trong system metadata — vế đầu đúng, vế sau sai nặng. Instance metadata và user data không phải nơi cất bí mật: bất kỳ tiến trình nào trên máy, kể cả ứng dụng bị chiếm quyền, đều đọc được qua 169.254.169.254. Và "file cấu hình mã hoá" thì lại đẻ ra câu hỏi: khoá giải mã cất ở đâu?

Ghi nhớ

Quy tắc bất biến: compute của AWS luôn dùng role, không bao giờ dùng access key. EC2 → instance profile, Lambda → execution role, ECS → task role, EKS → IRSA / Pod Identity. Thấy "access key" trong phương án thì gần như chắc chắn loại được.

Đáp án

A — Elastic Beanstalk, deploy phiên bản mới sang môi trường riêng rồi dùng swap CNAME để chuyển traffic.

Vì sao đúng

Yêu cầu: blue/green có rollback, với độ phức tạp vận hành thấp nhất.

Swap CNAME của Elastic Beanstalk là hiện thực blue/green đơn giản nhất có trên AWS:

1. Môi trường xanh lam đang chạy bản cũ
2. Dựng môi trường xanh lá, deploy bản mới, kiểm thử thoải mái trên URL riêng của nó
3. Swap URL — hai môi trường đổi CNAME cho nhau
4. Hỏng thì swap lại — rollback trong vài giây, không deploy lại gì cả

aws elasticbeanstalk swap-environment-cnames \
  --source-environment-name app-prod-xanh-lam \
  --destination-environment-name app-prod-xanh-la

Beanstalk lo hết phần bên dưới: EC2, Auto Scaling, load balancer, health check, phiên bản ứng dụng. Với ứng dụng Python, chỉ cần đẩy mã lên — đúng nghĩa "LEAST operational complexity".

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

• C. Beanstalk với traffic splitting — đây là bẫy sát nhất và cũng là phương án hợp lý thứ hai. Nhưng traffic splitting là canary, không phải blue/green: nó chia phần trăm traffic trong cùng một môi trường, và rollback nghĩa là deploy lại bản cũ, không phải bật ngược một công tắc. Blue/green thật sự đòi hai môi trường song song — đó là A.
• B. Amazon Lightsail — Lightsail là VPS đơn giản hoá; nó không có cơ chế blue/green dựng sẵn, không có khái niệm phiên bản ứng dụng, và toàn bộ quy trình deploy phải tự viết.
• D. CodeDeploy sang ECS + Route 53 failover — làm được, nhưng phải container hoá ứng dụng Python trước, rồi quản cluster ECS, task definition, service. Phức tạp hơn hẳn. Và failover routing không phải cơ chế blue/green — nó dành cho dự phòng khi hỏng, còn chuyển bằng DNS thì phải chờ TTL.

Ghi nhớ

Bốn kiểu deploy của Elastic Beanstalk: | Kiểu | Thời gian chết | Rollback | |---|---|---| | All at once | có | deploy lại | | Rolling / Rolling with additional batch | không | deploy lại | | Immutable | không | huỷ instance mới | | Blue/Green (swap CNAME) | không | swap ngược — tức thì |

Chỉ blue/green cho rollback tức thì, vì môi trường cũ vẫn còn nguyên.

Đáp án

B — EventBridge rule với event pattern EC2 Instance State-change Notification, gửi thông báo qua SNS.

Vì sao đúng

Đề đòi thông báo khi trạng thái của instance thay đổi — bất kỳ thay đổi nào, không riêng lỗi.

EC2 phát sự kiện này lên EventBridge ở mỗi lần chuyển trạng thái:

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {"state": ["stopping", "stopped", "shutting-down", "terminated", "running"]}
}

Đây là cơ chế duy nhất trong bốn phương án báo cho con người biết khi trạng thái đổi. Nó cũng bắt được cả những thay đổi không phải sự cố — ví dụ ai đó dừng nhầm một instance business-critical — mà health check không bao giờ phát hiện.

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

• A. Alarm StatusCheckFailed_Instance + hành động reboot — đây là hành động khắc phục, không phải thông báo. Đội DevOps sẽ không biết gì cả; instance tự khởi động lại trong im lặng. Đề yêu cầu "automated notification mechanism".
• C. Alarm StatusCheckFailed_System + hành động recover — cùng vấn đề với A. Recover là hành động tốt (di chuyển instance sang phần cứng khác) nhưng vẫn không thông báo cho ai. (Ghi chú: A và C là những biện pháp đúng đắn nên có song song với B — chúng chỉ không trả lời được câu hỏi đang hỏi.)
• D. Lambda theo lịch cập nhật Personal Health Dashboard — PHD do AWS quản lý, bạn không ghi vào đó được. Nó hiển thị sự kiện sức khoẻ của chính AWS ảnh hưởng tới tài khoản bạn. Phương án mô tả một việc không làm được. Ngoài ra polling theo lịch luôn để lọt các thay đổi diễn ra giữa hai lần kiểm tra.

Ghi nhớ

Phân biệt cho rõ ba loại status check của EC2: | Check | Nghĩa | Cách chữa | |---|---|---| | StatusCheckFailed_Instance | vấn đề bên trong instance (OS treo, kernel panic) | reboot | | StatusCheckFailed_System | vấn đề hạ tầng AWS bên dưới | recover (chuyển sang phần cứng khác) | | StatusCheckFailed_AttachedEBS | volume EBS gắn kèm không phản hồi I/O | điều tra volume |

Và nhớ: alarm action là để tự chữa, EventBridge + SNS là để báo người. Câu hỏi nói "notification" thì luôn là vế thứ hai.

Đáp án

B — EC2 stateless có Auto Scaling, CSDL chuyển sang Amazon RDS, và đẩy dữ liệu ad/referrer bằng Kinesis Data Firehose vào S3 để Redshift tiêu thụ.

Vì sao đúng

Cả bốn phương án giống hệt nhau ở vế web và CSDL. Điểm khác duy nhất là dịch vụ nào đưa dữ liệu click quảng cáo vào S3 — nên toàn bộ câu hỏi nằm ở đó.

Kinesis Data Firehose là lựa chọn đúng vì nó là dịch vụ nạp dữ liệu (delivery):

• Đích S3 dựng sẵn — không viết mã nào
• Tự gom lô, tự nén, tự chuyển sang Parquet, tự phân vùng theo thời gian
• Hoàn toàn được quản lý, tự co giãn theo lưu lượng
• Có sẵn tích hợp nạp thẳng vào Redshift nếu muốn bỏ qua S3

Với dữ liệu click quảng cáo — khối lượng lớn, không cần xử lý tức thì, cần đổ vào kho phân tích — đây đúng là mẫu sử dụng điển hình của Firehose.

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

• A. Amazon Athena "đẩy dữ liệu vào S3" — đảo ngược vai trò. Athena đọc dữ liệu đã có trên S3 và truy vấn bằng SQL; nó không nhận và không ghi dữ liệu vào S3. Sai về bản chất dịch vụ.
• C. Kinesis Data Analytics — dịch vụ phân tích luồng (chạy SQL hoặc Apache Flink trên dữ liệu đang chảy). Nó là bộ xử lý ở giữa, không phải bộ nạp; nó vẫn cần một stream làm nguồn và một delivery stream làm đích. Thừa hẳn một tầng.
• D. Kinesis Data Streams — có thể dùng, nhưng Data Streams không tự ghi vào S3: bạn phải tự viết consumer (Lambda hoặc KCL) để đọc shard và ghi ra S3, tự quản số shard, tự xử lý checkpoint. Data Streams hợp khi cần nhiều consumer độc lập hoặc cần phát lại dữ liệu; ở đây chỉ cần đổ vào S3 nên Firehose gọn hơn hẳn.

Ghi nhớ

Câu hỏi "đưa dữ liệu vào S3 với ít công sức nhất" gần như luôn là Firehose.

Đáp án

D — EventBridge rule lọc sự kiện CodePipeline Pipeline Execution State Change, đẩy lên SNS topic, và một Lambda gửi chi tiết sang webhook của công cụ chat.

Vì sao đúng

CodePipeline phát sự kiện trạng thái lên EventBridge — đây là nguồn dữ liệu đúng:

{
  "source": ["aws.codepipeline"],
  "detail-type": ["CodePipeline Pipeline Execution State Change",
                  "CodePipeline Action Execution State Change"],
  "detail": {"state": ["STARTED", "SUCCEEDED", "FAILED"]}
}

Vì sao cần Lambda ở cuối: SNS không gửi được tới webhook tuỳ ý với định dạng tuỳ ý. SNS có subscription kiểu HTTP/HTTPS, nhưng nó gửi định dạng riêng của SNS và đòi bước xác nhận đăng ký — công cụ chat bên thứ ba gần như chắc chắn không hiểu và không xác nhận được. Lambda là nơi dịch sự kiện AWS sang đúng payload mà webhook mong đợi:

def handler(event, context):
    msg = json.loads(event['Records'][0]['Sns']['Message'])
    requests.post(WEBHOOK_URL, json={
        'text': f"Pipeline *{msg['detail']['pipeline']}* → {msg['detail']['state']}"})

Vế yêu cầu phê duyệt cũng đi cùng đường: CodePipeline phát sự kiện riêng cho manual approval, và bản thân approval action còn cấu hình được SNS topic trực tiếp.

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

• A. CloudWatch Logs subscription lọc sự kiện CodePipeline — sai nguồn: sự kiện trạng thái của CodePipeline không đi qua CloudWatch Logs, chúng đi qua EventBridge. Không có log group nào để mà đăng ký.
• B. AWS Config rule kiểm tra sự kiện pipeline — Config theo dõi cấu hình tài nguyên, không theo dõi sự kiện thực thi. Nó không có khái niệm "pipeline đang chạy tới stage nào".
• C. Lambda được gọi bởi "CloudTrail API events" — CloudTrail không gọi Lambda trực tiếp. Nó ghi sự kiện, rồi EventBridge mới định tuyến. Ngoài ra CloudTrail ghi lời gọi API, không ghi thay đổi trạng thái nội bộ của pipeline — nên nhiều chuyển trạng thái sẽ không xuất hiện.

Ghi nhớ

Sơ đồ tích hợp chuẩn: CodePipeline → EventBridge → (SNS và/hoặc Lambda) → đích bên ngoài. Nếu đích là Slack hoặc Chime thì còn có AWS Chatbot làm sẵn phần dịch payload, không cần viết Lambda.

Đáp án

A — Thêm hook AfterAllowTestTraffic vào AppSpec, gọi Lambda chạy script kiểm thử; có lỗi thì thoát hàm với trạng thái thất bại để CodeDeploy tự rollback.

Vì sao đúng

Đây là câu về vòng đời blue/green của CodeDeploy trên ECS, vốn có nhiều hook hơn hẳn Lambda:

BeforeInstall → AfterInstall → AllowTestTraffic → AfterAllowTestTraffic
→ BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic

AfterAllowTestTraffic là mốc chính xác cần dùng: test listener đã trỏ vào target group xanh lá, nên script kiểm thử gọi được ứng dụng qua đường mạng thật, trong khi traffic production vẫn ở nguyên bản cũ. Không người dùng nào bị ảnh hưởng.

Nếu hook trả về thất bại, CodeDeploy tự dừng deployment và rollback — không cần gọi lệnh nào bằng tay:

def handler(event, context):
    ket_qua = 'Succeeded' if chay_kiem_thu() else 'Failed'
    codedeploy.put_lifecycle_event_hook_execution_status(
        deploymentId=event['DeploymentId'],
        lifecycleEventHookExecutionId=event['LifecycleEventHookExecutionId'],
        status=ket_qua)

Chi tiết "script chạy dưới 5 phút" cũng khớp: nằm gọn trong trần 15 phút của Lambda.

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

• C. AfterAllowTraffic — quá muộn. Hook này chạy sau khi traffic production đã chuyển sang bản mới, tức là người dùng thật đã chạm vào bản chưa được kiểm thử. Đề nói rõ phải kiểm thử trước khi chuyển traffic.
• B và D. Thêm stage vào pipeline giữa source và deploy — sai thứ tự một cách căn bản: ở thời điểm đó ứng dụng còn chưa được deploy, nên chẳng có phiên bản xanh lá nào để kiểm thử. Kiểm thử tích hợp trước khi deploy chỉ là kiểm thử bản cũ. Hai phương án này còn dựa vào aws deploy stop-deployment gọi bằng tay, trong khi hook cho rollback tự động.

Ghi nhớ

Bộ hook khác nhau theo nền tảng — đây là chi tiết bị hỏi rất nhiều: | Nền tảng | Hook viết được | |---|---| | ECS blue/green | BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, AfterAllowTraffic | | Lambda | chỉ BeforeAllowTraffic, AfterAllowTraffic | | EC2/On-prem | ApplicationStop, BeforeInstall, AfterInstall, ApplicationStart, ValidateService… |

AfterAllowTestTraffic chỉ có ở ECS, và đó chính là hook cho phép kiểm thử thật trước khi chuyển traffic.

Đáp án

A và B.

• A — Chụp snapshot của volume, tạo bản sao snapshot có mã hoá, rồi tạo volume mới từ snapshot đã mã hoá.
• B — Tạo và mount một volume EBS mới đã mã hoá, chuyển dữ liệu sang, rồi xoá volume cũ.

Vì sao đúng

Sự thật nền tảng: không mã hoá được một volume EBS đang tồn tại tại chỗ. Không có nút "bật mã hoá" cho volume đã tạo. Chỉ có hai đường vòng, và đề liệt kê đúng cả hai.

Đường A — qua snapshot (ít thao tác thủ công hơn, giữ nguyên toàn bộ dữ liệu):

aws ec2 create-snapshot --volume-id vol-xxxx --description "truoc khi ma hoa"
aws ec2 copy-snapshot --source-snapshot-id snap-xxxx --source-region ap-southeast-1 \
    --encrypted --kms-key-id alias/khoa-cua-toi     # mã hoá xảy ra ở bước COPY
aws ec2 create-volume --snapshot-id snap-da-ma-hoa --availability-zone ap-southeast-1a

Điểm mấu chốt: mã hoá xảy ra ở lệnh copy-snapshot, không ở create-snapshot. Bản sao được mã hoá; snapshot gốc vẫn không.

Đường B — chép dữ liệu thủ công: tạo volume mới có --encrypted, gắn vào cùng instance, rsync hoặc dd dữ liệu sang, đổi mount point, xoá volume cũ. Dài hơn nhưng làm được trong lúc máy vẫn chạy.

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

• C. Chứng chỉ SSL/TLS tự ký để "mã hoá dữ liệu truyền tới EBS" — nhầm lẫn hai khái niệm khác hẳn. TLS bảo vệ dữ liệu đang truyền qua mạng; đề hỏi encryption at rest. Ngoài ra EBS gắn qua giao thức khối, không qua TLS.
• D. "Unmount, chụp snapshot, mã hoá snapshot, mount lại volume cũ" — mã hoá snapshot không làm volume gốc được mã hoá. Mount lại đúng volume cũ nghĩa là dữ liệu vẫn nằm không mã hoá y như trước. Thiếu hẳn bước tạo volume mới từ snapshot đã mã hoá.
• E. AWS Data Lifecycle Manager "tự bật mã hoá và mã hoá dữ liệu hiện có" — DLM lên lịch tạo và xoá snapshot/AMI; nó có tuỳ chọn tạo bản sao snapshot có mã hoá, nhưng nó không mã hoá volume đang tồn tại. Câu chữ của phương án mô tả một khả năng không có.

Ghi nhớ

Vài quy tắc cứng về mã hoá EBS:

• Không mã hoá/giải mã volume tại chỗ được — luôn phải qua snapshot hoặc volume mới
• Volume tạo từ snapshot đã mã hoá thì luôn được mã hoá, không tắt được
• Bật "EBS encryption by default" ở mức tài khoản/Region để mọi volume mới tự mã hoá
• Mã hoá trong suốt với ứng dụng — không ảnh hưởng đáng kể tới IOPS hay độ trễ

Đáp án

A — Deploy bản mới sang môi trường song song riêng, rồi cấu hình API Gateway dùng canary release deployment để đưa một phần nhỏ traffic sang môi trường mới.

Vì sao đúng

Ràng buộc quyết định là "MINIMAL changes to the application", và API Gateway đang đứng ở cửa ngõ — nên nó là nơi hợp lý nhất để điều khiển traffic.

Canary release của API Gateway hoạt động ngay tại stage:

aws apigateway create-deployment --rest-api-id abc123 --stage-name prod \
  --canary-settings percentTraffic=10.0,useStageCache=false

• Chia traffic theo phần trăm ở tầng API, không đụng gì tới ứng dụng
• Metric riêng cho canary trong CloudWatch — so được tỷ lệ lỗi và độ trễ giữa hai bản
• Rollback là xoá canary settings — tức thì
• Xong thì promote canary thành bản chính

Không có thay đổi nào ở tầng ứng dụng, không có bản ghi DNS nào phải chờ TTL.

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

• B. Đổi bản ghi alias Route 53 — chuyển 100% cùng lúc, không có canary, nên trượt yêu cầu "minimal disruptions". Và rollback phải chờ TTL của DNS cùng các resolver ngoài tầm kiểm soát — không phải "quickly roll back".
• C. Target group mới sau ALB, API Gateway phân phối theo trọng số tới target group — sai về mặt cơ chế: API Gateway không định tuyến tới target group của ALB. Nó tích hợp với một HTTP endpoint (URL của ALB), và không biết gì về target group bên dưới. Muốn chia theo trọng số ở tầng ALB thì phải cấu hình weighted target group trên chính ALB, không phải trên API Gateway.
• D. API Gateway gửi toàn bộ traffic sang ALB, ALB gửi sang target group mới — chuyển 100% ngay lập tức, không có canary, không có cách rollback nhanh nào được nêu.

Ghi nhớ

Có nhiều tầng chia traffic được, chọn tầng phù hợp nhất với thứ đang có sẵn: | Tầng | Cơ chế | Rollback | |---|---|---| | API Gateway | canary stage | tức thì | | ALB | weighted target group | tức thì | | Lambda | weighted alias | tức thì | | Route 53 | weighted record | chậm — vướng TTL |

Quy tắc chung: càng gần ứng dụng thì chuyển càng dứt khoát; DNS luôn là lựa chọn kém nhất cho canary.

Đáp án

C — Thêm lifecycle hook vào Auto Scaling group và dùng warm pool để mở rộng nhanh.

Vì sao đúng

Hai triệu chứng trong đề có hai nguyên nhân, và phương án C chữa cả hai:

Triệu chứng 1 — instance mất quá lâu để sẵn sàng. Warm pool giữ sẵn một tập instance đã được khởi tạo trước (đã cài phần mềm, đã làm nóng cache) ở trạng thái Stopped hoặc Hibernated. Khi cần mở rộng, ASG chỉ bật chúng lên — mất vài chục giây thay vì nhiều phút. Instance ở trạng thái Stopped không tính tiền compute, chỉ tính tiền EBS, nên đây cũng là câu trả lời cho vế "chi phí tối thiểu".

Triệu chứng 2 — load balancer gửi traffic tới instance chưa lành. Lifecycle hook giữ instance ở trạng thái Pending:Wait cho tới khi quá trình khởi tạo báo xong (CompleteLifecycleAction). Chưa xong thì nó chưa được đăng ký vào target group, nên không nhận request nào.

aws autoscaling put-warm-pool --auto-scaling-group-name nhom-web \
  --min-size 20 --pool-state Stopped

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

• A. Đặt desired capacity lên cao trước sự kiện — làm được, nhưng trả tiền đầy đủ cho toàn bộ instance suốt thời gian chờ, kể cả những giờ chưa có ai truy cập. Trượt tiêu chí chi phí. Nó cũng không sửa được việc traffic bị gửi tới instance chưa sẵn sàng.
• B. Chuyển sang scaling thủ công — bỏ tự động hoá, quay về canh bằng tay, và tăng hẳn gánh nặng vận hành — trái thẳng "minimal operational overhead". Cũng không chữa được vế health.
• D. Đưa instance vào trạng thái Standby để gỡ lỗi thời gian khởi động — Standby là công cụ chẩn đoán/bảo trì (tạm gỡ một instance khỏi load balancer để xem xét), không phải cơ chế mở rộng. Nó không giúp gì cho một đợt bán hàng đang tới.

Ghi nhớ

Bốn công cụ của Auto Scaling cho vấn đề "khởi động chậm": | Công cụ | Giải quyết | |---|---| | Warm pool | instance sẵn sàng gần như tức thì, chi phí thấp | | Lifecycle hook | có thời gian khởi tạo trước khi nhận traffic | | Health check grace period | không đánh giá sức khoẻ quá sớm | | Golden AMI | nướng sẵn phần mềm để rút ngắn khởi động |

Trong thực tế nên dùng kết hợp: golden AMI để rút ngắn, warm pool để có sẵn, lifecycle hook để không nhận traffic sớm.

Đáp án

A và B.

• B — Tạo AWS Organization bật đầy đủ tính năng (all features) và thêm mọi tài khoản vào tổ chức.
• A — Bật trusted access với Organizations và tạo CloudFormation StackSets từ tài khoản quản lý.

Vì sao đúng

Đây là hai bước của một quy trình, phải làm đúng thứ tự.

Vì sao "all features" (B). AWS Organizations có hai chế độ: | Chế độ | Cho phép | |---|---| | Consolidated billing only | chỉ gộp hoá đơn | | All features | thêm SCP, trusted access cho dịch vụ, delegated administrator |

StackSets service-managed permissions bắt buộc phải có "all features" — vì nó dựa vào trusted access, mà trusted access chỉ tồn tại ở chế độ này. Đây chính là điểm loại phương án E.

Vì sao trusted access + StackSets (A). Bật trusted access cho cloudformation.amazonaws.com thì StackSets tự tạo các IAM role cần thiết ở mọi tài khoản thành viên. Không phải dựng role bằng tay ở từng nơi — đúng vế "minimize operational overhead". Kèm theo là automatic deployment: tài khoản mới thêm vào OU tự nhận stack.

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

• D. Trusted access + StackSets với self-managed permissions — mâu thuẫn nội tại: self-managed nghĩa là bạn tự tạo cặp role AWSCloudFormationStackSetAdministrationRole và AWSCloudFormationStackSetExecutionRole ở từng tài khoản. Nó không dùng trusted access, và nó tăng gánh nặng vận hành thay vì giảm.
• C. Tạo stack riêng ở từng tài khoản bằng cross-account role — bỏ hẳn StackSets, quay về thao tác lặp cho từng tài khoản. Không có quản lý tập trung, không có cập nhật đồng loạt, không có phát hiện drift chung.
• E. Organization chỉ bật consolidated billing — như đã nói, chế độ này không có trusted access, nên service-managed StackSets không hoạt động.

Ghi nhớ

Câu hỏi nêu "minimize operational overhead" cho nhiều tài khoản thì luôn là service-managed.