Hướng chinh phục AWS Certified DevOps Engineer – Professional trong gần 12 tuần

Giới thiệu

Xin chào mọi người. Mình vừa hoàn thành kỳ thi AWS Certified DevOps Engineer – Professional với số điểm 975/1000 vào ngày 18/07/2026

Đây là một niềm vui khá đặc biệt đối với mình. Không chỉ vì điểm số cao hơn mong đợi, mà còn vì chứng chỉ này đánh dấu gần 12 tuần mình học, ôn tập, làm bài thực hành và liên tục sửa lại những phần kiến thức mà trước đó mình nghĩ rằng mình đã hiểu khá rõ.

Trước ngày thi, mình từng đặt mục tiêu 1000 điểm nhưng số điểm không như kỳ vọng, phản ứng đầu tiên của mình là hơi tiếc một chút. Có lẽ mình những câu nào đó. Nhưng sau vài phút, cảm giác tiếc nuối nhanh chóng được thay bằng sự nhẹ nhõm.

Mình nhận ra điều quan trọng nhất không phải là số điểm còn thiếu, mà là mình đã hoàn thành được một mục tiêu từng khiến bản thân khá áp lực khi mới bắt đầu. Bài viết này không phải là một công thức chắc chắn để đạt điểm cao. Mình chỉ muốn chia sẻ lại quá trình học gần 12 tuần, những điều đã làm tốt, những lúc bị chững lại và một số kinh nghiệm có thể hữu ích với các bạn đang chuẩn bị cho kỳ thi này.

Cũng là để lan tỏa giá trị trong hệ sinh thái DevOps VietNam, ngôi nhà chung của lĩnh vực DevOps tại Việt Nam.

Background của mình

Trước khi là một DevOps, mình là một Infrastructure Engineer và có kiến thức nền tảng về Networking / System. Và làm một thời gian về hạ tầng rất nhiều. Đến 2025, mình quyết định chuyển sang con đường mới vì chán làm việc với quy trình, thay vào đó mình thích làm gì đó rộng hơn, mang tính chất sáng tạo hơn, nên đó là lý do tại sao mình đến với DevOps. Mình cũng đã hoàn thành chứng chỉ AWS Certified Solutions Architect – Associate vào tháng 3/2026, nên không bắt đầu hoàn toàn từ con số 0.

Những kiến thức như IAM, VPC, EC2, S3, RDS, Auto Scaling, Elastic Load Balancing, Route 53 hay CloudWatch không còn quá xa lạ. Tuy nhiên, khi chuyển sang cấp độ Professional, mình nhận ra rằng việc biết một dịch vụ dùng để làm gì mới chỉ là bước đầu.

Đề thi không đơn giản hỏi: AWS CodePipeline là gì? Nhưng thay vào đó, câu hỏi thường đặt mình vào một hệ thống khá lớn, có nhiều tài khoản AWS, nhiều region, nhiều nhóm phát triển, yêu cầu bảo mật, khả năng khôi phục và giới hạn vận hành khác nhau. Nhiệm vụ của người làm bài là lựa chọn giải pháp đáp ứng đủ yêu cầu nhưng vẫn phải cân bằng giữa:

• Mức độ bảo mật
• Khả năng mở rộng
• Chi phí
• Thời gian triển khai
• Khối lượng vận hành
• Khả năng tự động hóa
• Mức độ ảnh hưởng đến hệ thống hiện tại

Đây cũng là điểm khiến mình thấy chứng chỉ này rất gần với công việc DevOps thực tế mà mình đã làm vì không phải lúc nào giải pháp kỹ thuật phức tạp nhất cũng là đáp án tốt nhất. Đôi khi giải pháp đúng lại là giải pháp đơn giản hơn, sử dụng managed service và giảm tối đa phần vận hành thủ công.

Vì sao mình quyết định thi chứng chỉ này?

Mục tiêu ban đầu của mình không chỉ là có thêm một chứng chỉ AWS trong CV. Mình muốn hệ thống hóa lại kiến thức DevOps trên AWS theo một cách bài bản hơn. Trong công việc hằng ngày, chúng ta thường chỉ làm việc sâu với một phần của hệ thống. Có người tập trung vào CI/CD, có người làm Kubernetes, có người quản lý infrastructure, security hoặc monitoring , nói chung là một production có rất nhiều teams khác nhau làm từng phần. Điều đó dễ khiến kiến thức bị chia thành từng mảng riêng lẻ. Khi học cho kỳ thi này, mình buộc phải kết nối các mảng đó lại với nhau:

• Source code được quản lý và kiểm soát như thế nào?
• Artifact được build, lưu trữ và kiểm tra ra sao?
• Infrastructure được triển khai bằng code như thế nào?
• Làm sao triển khai phiên bản mới mà không gây downtime?
• Khi deployment thất bại thì rollback bằng cách nào?
• Làm sao giám sát hàng trăm tài khoản AWS?
• Khi có sự cố, hệ thống tự động phát hiện và xử lý đến đâu?
• Làm sao áp dụng security policy trên toàn bộ organization?
• Dữ liệu và hệ thống sẽ được khôi phục như thế nào nếu xảy ra sự cố lớn?

Việc ôn thi giúp mình nhìn DevOps như một vòng đời hoàn chỉnh, thay vì chỉ là một tập hợp các công cụ riêng lẻ.

Kế hoạch học trong gần 12 tuần

Mình không có 12 tuần học hoàn hảo. Có những ngày hoàn thành đúng kế hoạch, nhưng cũng có những ngày làm khá nhiều, chỉ đọc được vài trang tài liệu. Có tuần mình học nhanh hơn dự kiến, nhưng cũng có phần phải quay lại nhiều lần vì vẫn chưa thực sự hiểu. Thay vì ép bản thân phải học thật nhiều mỗi ngày, mình cố duy trì nhịp học đều và chia quá trình thành từng giai đoạn. Vì công việc mình là Hybrid, nên thời gian học cũng không quá khó để sắp xếp.

• Tài liệu mình tham khảo chính thức của AWS DOP-C02-Exam+Guide.pdf
• Tài liệu mình nghiên cứu và tổng hợp lại thành tài liệu DOP-C02-Examination-Study-Road.docx

Tuần 1 và 2: Xác định phạm vi kiến thức

Trong hai tuần đầu, mình chưa vội làm quá nhiều câu hỏi. Mình bắt đầu bằng việc xem lại phạm vi của kỳ thi và chia kiến thức thành các nhóm lớn theo cuốn lý thuyết mà chứng chỉ này bên AWS cung cấp:

• SDLC Automation
• Configuration Management và Infrastructure as Code
• Resilient Cloud Solutions
• Monitoring và Logging
• Incident and Event Response
• Security và Compliance

Sau đó mình tự đánh giá từng nhóm:

• Phần nào đã từng làm thực tế?
• Phần nào mới chỉ biết lý thuyết?
• Phần nào thường xuyên bị nhầm?
• Phần nào có nhiều dịch vụ với chức năng gần giống nhau?

Việc này khá quan trọng vì nó giúp mình tránh học lan man. Một sai lầm mình từng mắc khi học các chứng chỉ trước là mở quá nhiều tài liệu cùng lúc. Kết quả là học được nhiều thứ nhưng không biết phần nào thực sự quan trọng. Lần này, mình chọn một tài liệu chính để tạo khung kiến thức. Khi gặp phần chưa rõ, mình mới quay về AWS Documentation hoặc các tài liệu chính thức để đọc sâu hơn, chuẩn bị một tài khoản AWS cá nhân để tự dựng lab cho việc học hiệu quả hơn, đến lúc mình cần củng cố kiến thức , mình sử dụng một phần AI để tự tạo nhiều câu hỏi ôn tập, trắc nghiệm sát với thực tế hơn để đẩy quy trình mình hiểu nhanh hơn.

Tuần 3 và 4: CI/CD và chiến lược deployment

Đây là phần mình dành khá nhiều thời gian vì có rất nhiều tình huống thực tế. Mình ôn lại luồng triển khai từ đầu đến cuối: Source , Build , Test , Security Scan , Package , Approval , Deployment , Verification , Rollback

Các dịch vụ và chủ đề mình tập trung gồm:

• AWS CodeCommit hoặc source repository bên ngoài
• AWS CodeBuild , CodePipeline , CodeDeploy
• Amazon S3 artifact
• Amazon ECR
• ECS và EKS deployment
• Lambda deployment
• Manual approval
• Cross-account deployment , cross-region deployment
• Blue/green deployment , Canary deployment
• Rolling deployment
• Automatic rollback

Điều mình cố gắng làm không phải là ghi nhớ từng dịch vụ riêng lẻ, mà là hiểu khi nào nên sử dụng dịch vụ nào. Ví dụ, nếu câu hỏi yêu cầu triển khai phiên bản mới mà không làm gián đoạn người dùng, mình sẽ xem xét blue/green hoặc canary. Nhưng chưa thể chọn đáp án ngay. Mình vẫn phải đọc tiếp:

• Hệ thống đang chạy trên EC2, ECS, EKS hay Lambda?
• Có cần kiểm tra phiên bản mới trước khi chuyển toàn bộ traffic không?
• Có yêu cầu rollback tự động không?
• Có được phép tạo thêm một môi trường song song không?
• Công ty muốn giảm tối đa thao tác thủ công hay giảm chi phí?

Chỉ một điều kiện nhỏ thay đổi cũng có thể dẫn đến một đáp án khác.

Tuần 5 và 6: Infrastructure as Code và môi trường nhiều tài khoản

Giai đoạn này mình tập trung vào CloudFormation, cách quản lý thay đổi và triển khai infrastructure trên quy mô lớn. Một số phần mình ôn kỹ gồm:

• CloudFormation , Nested stacks
• Change sets
• Stack policies
• Drift detection
• CloudFormation StackSets
• Cross-account role
• AWS Organizations
• Service Control Policies
• Quản lý tài nguyên giữa nhiều account và region
• Lưu trữ, kiểm soát phiên bản template và tự động hóa việc tạo môi trường

Điểm mình từng nhầm là ranh giới giữa IAM policy và Service Control Policy. IAM policy xác định quyền mà một identity có thể được cấp trong tài khoản. Trong khi đó, SCP đặt ra giới hạn quyền tối đa cho các tài khoản hoặc organizational unit trong AWS Organizations. SCP không tự cấp quyền. Đây là một chi tiết nhỏ nhưng xuất hiện trong khá nhiều tình huống liên quan đến governance và multi-account. Mình cũng dành thời gian phân biệt giữa:

• Thay đổi trực tiếp trên resource
• Thay đổi thông qua CloudFormation
• Phát hiện configuration drift
• Ngăn tài nguyên quan trọng bị update hoặc delete
• Triển khai cùng một cấu hình tới nhiều tài khoản

Khi hiểu được mục đích của từng cơ chế, mình không còn phải cố nhớ đáp án theo từng câu hỏi nữa.

Tuần 7 và 8: Monitoring, logging và xử lý sự cố

Đây là phần có rất nhiều dịch vụ có thể kết hợp với nhau. Mình ôn các thành phần như:

• Amazon CloudWatch Metrics , Logs , Alarms , dashboards
• Amazon EventBridge
• AWS CloudTrail , Config
• AWS Systems Manager
• AWS Lambda
• Amazon SNS
• Auto Scaling
• Health checks , Log aggregation
• Automated remediation

Mình thường tự đặt một tình huống: Nếu hệ thống xảy ra lỗi lúc nửa đêm và không có kỹ sư trực tiếp thao tác, quy trình tự động nên hoạt động như thế nào? Một flow đơn giản có thể là:

• Phát hiện sự kiện.
• Gửi event.
• Kích hoạt automation.
• Thực hiện remediation.
• Gửi thông báo.
• Lưu audit log.

Từ đó, mình học cách kết nối CloudWatch, EventBridge, Systems Manager Automation, Lambda, SNS, CloudTrail và AWS Config. Mình cũng nhận ra một điểm khá quan trọng đó là monitoring không chỉ là gửi cảnh báo. Trong nhiều câu hỏi, AWS muốn hệ thống có khả năng tự động phản ứng với sự cố. Ví dụ:

• Thay thế instance không healthy
• Rollback deployment thất bại
• Khôi phục configuration đúng chuẩn
• Cô lập resource có dấu hiệu bất thường
• Kích hoạt runbook xử lý sự cố
• Gửi thông báo cho đội vận hành

Việc phân biệt giữa “phát hiện”, “thông báo” và “tự động xử lý” giúp mình loại được khá nhiều đáp án sai.

Tuần 9 và 10: Security, compliance và governance

Đây là phần mình phải đọc câu hỏi thật cẩn thận. Các chủ đề thường liên quan đồng thời đến nhiều lớp bảo mật:

• IAM roles và policies
• Permission boundaries , Service Control Policies
• AWS KMS
• Secrets Manager , Systems Manager Parameter Store
• CloudTrail
• AWS Config
• Security Hub
• GuardDuty
• Cross-account access
• Encryption
• Credential rotation
• Audit và compliance

Khi làm bài, mình thường kiểm tra bốn câu hỏi:

1. Ai cần truy cập?
2. Truy cập vào tài nguyên nào?
3. Truy cập trong cùng account hay cross-account?
4. Credential được quản lý và xoay vòng như thế nào?

Mình đặc biệt tránh các phương án sử dụng access key dài hạn nếu có thể thay bằng IAM role hoặc temporary credentials. Một đáp án có thể chạy được về mặt kỹ thuật, nhưng chưa chắc đã là phương án tốt nhất theo góc nhìn security và operational excellence.

Tuần 11: Làm đề tổng hợp và xây dựng error log

Đến tuần 11, đây là tuần mình sử dụng AI để generate ra 100 – 200 câu hỏi liên quan đến các dịch vụ để mình tự luyện độ hiểu của mình. Ở giai đoạn đầu, điểm số mock test của mình không phải lúc nào cũng cao. Có nhiều câu mình phân vân giữa hai đáp án. Đọc phần giải thích xong thì thấy đáp án đúng khá hợp lý, nhưng vài ngày sau gặp lại tình huống tương tự vẫn có thể chọn sai. Mình nhận ra chỉ đọc lời giải là chưa đủ. Sau mỗi lần làm đề, mình tạo một error log đơn giản với các cột.Ví dụ: Chủ đề: Multi-account . Mình đã chọn IAM Policy . Đáp án đúng : SCP kết hợp IAM . Sai là vì nhầm giữa cấp quyền và giới hạn quyền. Nên kiến thức cần xem lại là : AWS Organizations.

Điều quan trọng nhất không phải là ghi lại đáp án A, B, C hay D. Mình cố ghi lại lỗi tư duy của bản thân. Ví dụ:

• Đọc thiếu từ khóa
• Chọn giải pháp quá phức tạp
• Không để ý yêu cầu giảm operational overhead
• Nhầm giữa near real-time và scheduled processing
• Chọn giải pháp có thể hoạt động nhưng không đáp ứng multi-account
• Bỏ sót yêu cầu encryption hoặc audit

Sau một thời gian, mình bắt đầu thấy các lỗi lặp lại. Khi biết mình thường sai theo kiểu nào, việc cải thiện nhanh hơn rất nhiều.

Tuần 12: Ôn tập có chọn lọc

Tuần cuối cùng, mình không cố học thêm quá nhiều dịch vụ mới. Mình chủ yếu:

• Xem lại error log
• Ôn các phần thường xuyên nhầm
• Làm lại những câu đã sai
• Đọc lại một số sơ đồ kiến trúc
• So sánh các dịch vụ có chức năng gần nhau
• Luyện cách phân bổ thời gian
• Cố gắng nghỉ ngơi đủ trước ngày thi

Mình nghĩ đây là giai đoạn dễ bị hoảng nhất. Càng gần ngày thi, chúng ta càng có cảm giác còn quá nhiều thứ chưa biết. Mỗi lần gặp một câu khó lại muốn mở thêm khóa học hoặc tìm thêm một bộ đề khác. Nhưng học thêm quá nhiều nguồn ở tuần cuối đôi khi chỉ làm kiến thức bị rối. Mình chọn tin vào kế hoạch đã thực hiện trong gần 12 tuần và tập trung củng cố những phần đã học.

Phương pháp học giúp mình tiến bộ rõ nhất

Không chỉ tìm đáp án đúng

Khi review một câu hỏi, mình không dừng lại ở việc hiểu vì sao một đáp án đúng. Mình cố giải thích thêm:

• Vì sao ba đáp án còn lại sai?
• Trong điều kiện nào đáp án sai có thể trở thành đúng?
• Có từ khóa nào trong câu hỏi quyết định lựa chọn?
• Giải pháp nào có operational overhead thấp hơn?
• Giải pháp nào phù hợp với AWS best practices hơn?

Phương pháp này mất thời gian hơn trong giai đoạn đầu, nhưng càng về sau tốc độ làm bài của mình càng nhanh.

Tìm constraint trước khi nhìn dịch vụ

Những câu hỏi dài thường chứa rất nhiều thông tin, nhưng không phải thông tin nào cũng có vai trò ngang nhau. Mình thường đánh dấu các constraint như: Không được downtime , nhiều AWS accounts , nhiều regions , near real-time , Least operation overhead , most cost-effective , … Sau khi xác định constraint, mình mới đánh giá từng đáp án. Cách này giúp mình tránh bị cuốn vào những đoạn mô tả dài nhưng không quyết định đáp án.

Ưu tiên hiểu kiến trúc thay vì học thuộc câu hỏi

Một số câu mock test có thể xuất hiện lại dưới hình thức gần giống nhau. Tuy nhiên, mình không muốn phụ thuộc vào việc nhớ mặt câu hỏi. Mục tiêu của mình là khi đề thay đổi tên công ty, số lượng account, region hoặc loại workload, mình vẫn hiểu bản chất vấn đề. Khi đã hiểu kiến trúc, câu hỏi có thay đổi cách diễn đạt thì hướng giải quyết vẫn tương đối rõ.

Thực hành có chọn lọc

Mình không dựng một hệ thống lớn cho mọi chủ đề. Thay vào đó, mình chọn thực hành những phần dễ bị mơ hồ khi chỉ đọc lý thuyết, chẳng hạn:

• Tạo một pipeline đơn giản
• Thử một chiến lược deployment
• Tạo CloudFormation stack và change set
• Kiểm tra drift
• Thiết lập CloudWatch Alarm
• Kích hoạt action từ EventBridge
• Thử cross-account role
• Kiểm tra policy evaluation và quan sát log trong CloudTrail

Chỉ cần tự tay cấu hình một lần, mình thường nhớ lâu hơn rất nhiều so với việc đọc lại tài liệu nhiều lần.

Cách mình xử lý câu hỏi trong phòng thi

Trong bài thi, mình cố không dành quá nhiều thời gian cho một câu ở lượt đầu tiên. Mình chia câu hỏi thành ba nhóm:

• Câu có thể trả lời ngay
• Câu cần phân tích thêm
• Câu dài hoặc có nhiều đáp án gần giống nhau

Với câu dễ, mình chọn đáp án và tiếp tục. Với câu chưa chắc chắn, mình đánh dấu để quay lại (dùng highlight). Với câu rất dài, mình đọc phần yêu cầu cuối trước để biết đề đang hỏi điều gì. Sau đó mới quay lại tìm các constraint trong phần mô tả. Một số nguyên tắc mình sử dụng:

• Đọc kỹ số lượng đáp án cần chọn
• Không mặc định giải pháp phức tạp hơn là tốt hơn
• Kiểm tra tất cả constraint trước khi xác nhận
• Không thay đổi đáp án chỉ vì mất tự tin

Khoảnh khắc nhận kết quả 975/1000

Sau khi hoàn thành bài thi, cảm giác đầu tiên của mình không phải là chắc chắn đạt điểm cao. Có một vài câu mình vẫn còn phân vân. Cũng có những câu đã review nhiều lần nhưng không thể tự tin tuyệt đối. Khi nhận kết quả 975/1000, mình thực sự rất vui. Mình từng đặt mục tiêu 1000 điểm, nên vẫn có một chút tò mò không biết mình đã sai ở đâu. Nhưng kỳ thi không cung cấp chi tiết từng câu, vì vậy có lẽ mình sẽ không bao giờ biết chính xác. Sau cùng, 975 hay 1000 không thay đổi quá nhiều ý nghĩa của hành trình này. Điều có giá trị hơn là sau gần 12 tuần, mình đã:

• Hiểu rõ hơn cách xây dựng CI/CD trên AWS
• Kết nối được infrastructure, security, monitoring và incident response
• Cải thiện tư duy thiết kế hệ thống multi-account
• Nhìn rõ hơn sự khác nhau giữa một giải pháp “chạy được” và một giải pháp “phù hợp để vận hành lâu dài”
• Xây dựng được thói quen phân tích requirement trước khi chọn công nghệ

Chứng chỉ là kết quả có thể nhìn thấy. Nhưng quá trình học mới là phần sẽ tiếp tục hỗ trợ mình trong công việc sau này.

Một vài lời dành cho các bạn đang chuẩn bị thi

• Đừng chờ đến khi biết hết mọi thứ mới đăng ký thi
• Đừng chỉ nhìn vào điểm mock test
• Hãy tạo error log
• Học theo tình huống thực tế
• Giữ sức cho tuần cuối và ngày thi

Chứng chỉ không phải điểm kết thúc

Mình rất trân trọng kết quả 975/1000, nhưng cũng hiểu rằng chứng chỉ không đồng nghĩa với việc mình đã biết tất cả về AWS DevOps. Một hệ thống production thực tế luôn có thêm rất nhiều yếu tố như quy trình của doanh nghiệp , hệ thống legacy , giới hạn ngân sách , năng lực của đội ngũ , yêu cầu compliance , áp lực thời gian ,… . Chứng chỉ cung cấp một framework kiến thức tốt. Phần còn lại vẫn phải đến từ việc thực hành, triển khai, gặp lỗi và cùng đội ngũ giải quyết vấn đề. Đối với mình, đây không phải là điểm kết thúc của hành trình học AWS. Nó giống như một cột mốc xác nhận rằng mình đang đi đúng hướng trên con đường DevOps.

Tổng kết

Gần 12 tuần học không phải lúc nào cũng dễ dàng. Có những phần mình hiểu rất nhanh. Có phần phải đọc lại nhiều lần. Có những bài mock test làm xong khá tự tin nhưng kết quả không như mong đợi. Cũng có lúc mình tự hỏi liệu mình đã thực sự sẵn sàng cho kỳ thi hay chưa. Nhưng cuối cùng, sự đều đặn đã giúp mình đi hết hành trình. Kết quả AWS Certified DevOps Engineer – Professional là một cột mốc mà mình rất vui và tự hào. Tuy nhiên, điều mình trân trọng hơn là kiến thức, tư duy hệ thống và thói quen học tập có được trong quá trình chuẩn bị. Mình viết bài này với hy vọng những chia sẻ trên có thể giúp các bạn đang chuẩn bị cho kỳ thi có thêm một góc nhìn thực tế.

Không nhất thiết phải học giống mình, cũng không cần đặt mục tiêu điểm số giống mình. Mỗi người có background, quỹ thời gian và cách tiếp thu khác nhau. Quan trọng nhất là xây dựng được một kế hoạch phù hợp, học đều, hiểu lý do đằng sau mỗi giải pháp và không ngại nhìn lại những phần mình còn yếu. Cảm ơn mọi người đã đọc đến đây.

Chúc các bạn đang trên hành trình chinh phục AWS Certified DevOps Engineer – Professional sẽ đạt được kết quả mình mong muốn.