Ngân hàng đề — Microsoft Azure DevOps Engineer Expert

🧩 Phân tích câu hỏi trắc nghiệm về GitHub Actions

📖 Giải thích nội dung câu hỏi:
Câu hỏi tập trung vào GitHub Actions – một tính năng của GitHub để tự động hóa workflows trong repository. Workflows bao gồm các steps thực thi actions (hành động được định nghĩa sẵn). Mỗi action có nhiều versions khác nhau để đảm bảo tính ổn định và bảo mật.
Yêu cầu là xác định ba attributes (thuộc tính) có thể sử dụng để chỉ định phiên bản cụ thể của một action khi gọi nó trong workflow (ví dụ: trong phần uses: owner/action@version).
Đây là câu hỏi multi-select (chọn nhiều đáp án đúng), mỗi lựa chọn đúng trị giá 1 điểm. Mục tiêu là tránh sử dụng version mặc định (như @main hoặc @master) để pin (cố định) version cụ thể, giảm rủi ro khi action được cập nhật.

✅ Đáp án đúng (ba lựa chọn):

• the SHA-based hashes
• the tag
• the branch

🛠️ Lý do lựa chọn các đáp án đúng:
Theo tài liệu chính thức của GitHub Actions (cập nhật đến năm 2026, phiên bản mới nhất), để request version cụ thể của action, bạn có thể sử dụng SHA hash, tag (nhãn), hoặc branch (nhánh). Những cách này cho phép pin chính xác version, đảm bảo workflow chạy ổn định và an toàn. Ví dụ:

• uses: actions/checkout@v4 (tag).
• uses: actions/checkout@sha-abc123 (SHA).
• uses: actions/checkout@main (branch).
  Đây là các phương pháp được khuyến nghị để tránh "dependency hell" và tuân thủ best practices bảo mật.

📘 Giải thích chi tiết từng phương án (đúng và sai):
Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Phần giải thích sử dụng kiến thức GitHub Actions mới nhất (không thay đổi cơ bản từ 2023-2026).

• ✅ the SHA-based hashes
  Đúng! SHA-based hashes (dạng @sha-<commit-sha>, ví dụ @sha-7d123fb) là cách chính xác và an toàn nhất để pin version. Nó trỏ trực tiếp đến commit cụ thể của action, không bị ảnh hưởng bởi thay đổi sau. GitHub khuyến nghị dùng SHA để tránh supply chain attacks.

• ✅ the tag
  Đúng! Tag (nhãn như @v1, @v2.5.0) là cách phổ biến để chỉ định version semantic (SemVer). Tag là immutable (không thay đổi), giúp workflow ổn định khi action release version mới. Ví dụ: actions/checkout@v4.

• ❌ the runner
  Sai! "Runner" đề cập đến môi trường thực thi workflow (như ubuntu-latest, windows-latest), không dùng để chỉ định version của action. Runner chỉ định OS và phần mềm trên máy ảo, không liên quan đến versioning của action.

• ✅ the branch
  Đúng! Branch (như @main, @develop) cho phép pin đến nhánh cụ thể. Tuy nhiên, GitHub không khuyến nghị dùng branch cho production vì branch có thể thay đổi (mutable), nhưng nó vẫn là một attribute hợp lệ để request version.

• ❌ the serial
  Sai! "Serial" không tồn tại trong GitHub Actions. Không có khái niệm serial number để identify version của action. Đây là lựa chọn giả mạo, có thể nhầm lẫn với các hệ thống khác nhưng không áp dụng ở đây.

🔗 Tài liệu tham khảo:

• GitHub Docs: Using specific versions of actions (cập nhật 2026).
• GitHub Security: Pinning actions to SHA.
• Best practices: Luôn pin version để tránh rủi ro – theo GitHub Advisory.

Hy vọng phân tích này giúp bạn nắm vững GitHub Actions! 🚀 Nếu cần ví dụ code thực tế, hãy hỏi thêm.

🧩 Phân tích nội dung câu hỏi

Câu hỏi mô tả một công ty phát triển ứng dụng ngân hàng khách hàng (client banking application) xử lý lượng dữ liệu lớn (large volume of data). Vấn đề chính là chất lượng mã nguồn (code quality) đang suy giảm do áp lực thời gian lên đội ngũ phát triển. Nhiệm vụ là triển khai static code analysis (phân tích mã tĩnh) để cải thiện chất lượng code. Câu hỏi yêu cầu xác định giai đoạn nào nên sử dụng static code analysis trong quy trình phát triển phần mềm (DevOps pipeline).

📘 Static code analysis là kỹ thuật kiểm tra mã nguồn mà không cần chạy chương trình (static = tĩnh), phát hiện lỗi sớm như bug, lỗ hổng bảo mật, code smell (mã kém chất lượng), vi phạm chuẩn coding. Theo best practices DevOps (áp dụng cho AWS CodePipeline/CodeBuild phiên bản mới nhất 2026), nó nên được tích hợp sớm nhất trong pipeline để tránh propagate lỗi sang các giai đoạn sau, tuân thủ nguyên tắc Shift Left (dịch chuyển kiểm tra sang trái trong pipeline).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: build
🛠️ Lý do: Giai đoạn build (xây dựng) là thời điểm lý tưởng để chạy static code analysis trong CI/CD pipeline (như AWS CodeBuild). Lúc này, code vừa được commit/push, compiler kiểm tra syntax, và tools như SonarQube, ESLint, Checkmarx, PMD được tích hợp để scan toàn bộ codebase trước khi compile thành binary hoặc chạy test. Điều này giúp phát hiện vấn đề sớm, block build nếu chất lượng kém (fail-fast), giảm chi phí fix lỗi sau. Theo AWS Well-Architected Framework (DevOps Pillar, cập nhật 2026), static analysis phải nằm ở early build stage để đảm bảo code quality gate.
📚 Nguồn tham khảo:

• AWS CodeBuild User Guide: Static code analysis in buildspec.yml (hỗ trợ plugins như SonarScanner).
• AWS DevOps Best Practices: Shift Left Security (2026 update).

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai kèm lý do cụ thể dựa trên lifecycle DevOps pipeline (AWS CodePipeline: Source → Build → Test → Deploy → Staging → Production).

• ❌ integration testing
  🧩 Sai vì: Giai đoạn integration testing tập trung vào kiểm tra tích hợp (unit/component kết hợp), chạy code động (dynamic analysis) để verify logic. Static analysis không phù hợp ở đây vì code đã qua build, muộn hơn (late detection), tăng rủi ro deploy code kém chất lượng. Theo AWS, integration tests dùng CodeBuild/Test phase riêng, không thay thế static scan ở build.

• ❌ staging
  🧩 Sai vì: Staging là môi trường gần giống production để test end-to-end, user acceptance (UAT). Đây là giai đoạn deploy đã hoàn tất, static analysis quá muộn (chỉ scan source code, không ảnh hưởng binary/deployed app). AWS khuyến nghị staging cho performance/load testing (CodeDeploy), không phải code quality gate ban đầu.

• ❌ production release
  🧩 Sai vì: Production release là deploy live, rủi ro cao nhất. Chạy static analysis lúc này là thảm họa vì code đã live, không thể block release nếu phát hiện vấn đề (zero-downtime deployment khó rollback code scan). AWS Blue/Green Deployments (2026) nhấn mạnh quality gates phải trước production, tránh impact khách hàng (như banking app xử lý dữ liệu lớn).

• ✅ build
  🛠️ Đúng vì: Như giải thích ở phần đáp án đúng, build phase lý tưởng cho static analysis. Trong AWS CodeBuild (buildspec.yml phase: pre_build/install), tích hợp dễ dàng với reports (JUnit/CodeCoverage) và fail build nếu threshold kém (ví dụ: code coverage <80%, security hotspots >5). Giúp tuân thủ compliance ngân hàng (PCI-DSS, GDPR) bằng early detection.
  📘 Ví dụ config AWS CodeBuild 2026:

  phases:
    install:
      commands:
        - pip install sonar-scanner
    pre_build:
      commands:
        - sonar-scanner -Dsonar.projectKey=myapp
  

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc triển khai một giải pháp giám sát (monitoring solution) cho Azure Pipelines trong một subscription Azure có nhiều pipelines. Các yêu cầu chính của giải pháp bao gồm:

• Parse logs từ nhiều nguồn khác nhau (phân tích và xử lý nhật ký từ các nguồn đa dạng).
• Xác định nguyên nhân gốc rễ của các vấn đề (identify root cause of issues, tức là phân tích sâu để tìm ra nguyên nhân cốt lõi gây lỗi).

Câu hỏi yêu cầu chọn tính năng nâng cao (advanced feature) của một công cụ giám sát phù hợp để đáp ứng hai yêu cầu trên. Đây là tình huống thực tế trong Azure DevOps, nơi Azure Pipelines tạo ra lượng lớn logs từ builds, releases, agents, và các nguồn khác. Giải pháp lý tưởng phải hỗ trợ thu thập, phân tích logs quy mô lớn và sử dụng truy vấn thông minh để chẩn đoán vấn đề.

Bối cảnh Azure (cập nhật đến 2026): Azure Monitor (bao gồm Log Analytics) là công cụ chính cho monitoring pipelines, với khả năng tích hợp sâu vào Azure DevOps. Log Analytics sử dụng Kusto Query Language (KQL) để parse logs từ nhiều nguồn (Azure Pipelines, Application Insights, custom logs) và xác định root cause qua analytics queries. 🛠️

✅ Đáp án đúng: analytics

Lý do lựa chọn:

• Analytics (cụ thể là Log Analytics trong Azure Monitor) là tính năng nâng cao hoàn hảo để parse logs từ multiple sources bằng cách thu thập dữ liệu từ Azure Pipelines, agents, containers, và các nguồn bên ngoài qua Data Connectors.
• Nó cho phép xác định root cause thông qua các truy vấn KQL phức tạp, visualization dashboards, và machine learning insights (như anomaly detection trong phiên bản mới nhất Azure Monitor 2026).
• Tích hợp trực tiếp với Azure DevOps Pipelines để monitor builds/releases thời gian thực, giúp phân tích failures và bottlenecks. Đây là best practice theo Microsoft docs.

📘 Tài liệu tham khảo:

• Azure Monitor Logs (Log Analytics) - Microsoft Docs (cập nhật 2025-2026).
• Monitor Azure Pipelines - Azure DevOps.

📋 Giải thích chi tiết tất cả các phương án

• analytics
  ✅ Đúng: Tính năng này (Log Analytics) chuyên parse logs từ nhiều nguồn (hỗ trợ 100+ data sources qua connectors) và phân tích root cause bằng KQL queries, AI insights. Hoàn toàn phù hợp với yêu cầu, là advanced feature cốt lõi của Azure Monitor cho DevOps pipelines.

• synthetic monitoring
  ❌ Sai: Synthetic monitoring (như trong Azure Application Insights) mô phỏng hành vi người dùng (scripted tests) để kiểm tra availability/performance, không parse logs từ multiple sources hay phân tích root cause sâu. Nó chỉ detect issues bề mặt, không phù hợp cho logs pipelines.

• directed monitoring
  ❌ Sai: Không tồn tại tính năng "directed monitoring" chuẩn trong Azure (có thể là khái niệm giả định hoặc nhầm lẫn). Azure không có feature này; nó không hỗ trợ parse logs hay root cause analysis, chỉ là distractor.

• Alert Management
  ❌ Sai: Alert Management (trong Azure Monitor) chỉ quản lý và routing alerts (như tạo rules, suppressions), không parse logs từ multiple sources hay trực tiếp identify root cause. Nó dùng sau khi đã có logs/analytics, không phải advanced feature cho yêu cầu chính.

🛠️ Kết luận: Chọn analytics để xây dựng solution mạnh mẽ, scalable cho Azure Pipelines. Nếu triển khai, bắt đầu bằng workspace Log Analytics + pipeline integrations! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc dạng case study (tình huống thực tế) thường gặp trong các kỳ thi chứng chỉ Microsoft Azure DevOps Engineer Expert (AZ-400), nơi mô tả một kịch bản cụ thể và yêu cầu đánh giá giải pháp có đạt mục tiêu hay không.

Tình huống chính:

• Bạn đang sử dụng Azure Pipelines để build và test một ứng dụng React.js.
• Pipeline hiện tại chỉ có một job duy nhất (không có nhiều jobs hoặc stages).
• Vấn đề: Việc cài đặt các JavaScript packages từ npm (như npm install) mất khoảng 5 phút mỗi lần chạy pipeline, dẫn đến thời gian execution tổng thể bị kéo dài không cần thiết.
• Mục tiêu: Recommend một giải pháp để giảm thời gian chạy pipeline.
• Giải pháp đề xuất: Sử dụng pipeline artifacts.
• Câu hỏi cụ thể: "Does this meet the goal?" (Giải pháp này có đạt được mục tiêu giảm thời gian chạy pipeline không?).

Lưu ý: Đây là câu hỏi kiểu "Yes/No" trong series, không thể quay lại sau khi trả lời, và có thể có nhiều giải pháp đúng/sai trong series. Vấn đề cốt lõi là tối ưu hóa thời gian cài đặt dependencies npm, thường do phải tải lại toàn bộ packages từ registry mỗi lần (không có cache).

✅ Đáp án đúng: No

Lý do chọn đáp án đúng (bằng kiến thức Azure Pipelines phiên bản mới nhất 2026):
Pipeline artifacts KHÔNG giúp giảm thời gian npm install vì:

• Artifacts chủ yếu dùng để publish/download outputs (như build binaries, test results) giữa các jobs/stages khác nhau trong pipeline, hoặc chia sẻ với releases.
• Với pipeline chỉ có 1 job, artifacts không phát huy tác dụng vì không có nơi để "chuyển giao" dữ liệu.
• Artifacts không tự động cache thư mục node_modules (nơi chứa packages đã cài), dẫn đến npm install vẫn chạy đầy đủ mỗi lần (tải từ npm registry).
• Giải pháp tối ưu thực sự là sử dụng Cache task (Cache@2) trong Azure Pipelines để cache node_modules dựa trên package-lock.json, giúp restore packages chỉ trong vài giây nếu không thay đổi. Cache hỗ trợ npm/yarn/pnpm và tích hợp tốt với self-hosted/private agents (cập nhật 2025-2026 với hỗ trợ hash-based keys tốt hơn).

📋 Giải thích tất cả các phương án trả lời

Dưới đây là phân tích từng lựa chọn giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích chi tiết bằng tiếng Việt tại sao đúng/sai:

• Yes
  ❌ SAI. Phương án này cho rằng sử dụng pipeline artifacts sẽ giảm thời gian pipeline. Thực tế, artifacts chỉ lưu trữ files sau khi job hoàn thành (qua publishPipelineArtifact@1), không can thiệp vào quá trình npm install ở đầu job. Không có cơ chế cache tự động cho dependencies, nên thời gian 5 phút vẫn giữ nguyên. Trong pipeline 1 job, artifacts thậm chí vô dụng vì không có job khác để consume.

• No
  ✅ ĐÚNG. Như giải thích trên, giải pháp đề xuất không đạt mục tiêu vì không giải quyết gốc rễ (cache npm packages). Thay vào đó, nên dùng:

  • Cache task:

    - task: Cache@2  
      inputs:  
        key: 'npm | "$(Agent.OS)" | package-lock.json'  
        restoreKeys: |  
          npm | "$(Agent.OS)"  
        path: $(npm_config_cache)  
    

    Giảm thời gian từ 5 phút xuống <1 phút (dữ liệu benchmark Azure 2026).

🛠️ Các giải pháp thay thế khuyến nghị (dựa trên best practices 2026)

• ✅ Sử dụng Cache@2 task: Tối ưu nhất cho npm/node_modules.
• ✅ npm ci thay vì npm install: Nhanh hơn với package-lock.json.
• ✅ Self-hosted agents với persistent storage: Cache local disk.
• ❌ Tránh artifacts cho cache vì overhead upload/download lớn (50MB+ node_modules).

📘 Tài liệu tham khảo (cập nhật mới nhất 2026)

• Azure Pipelines Caching (Cache task) – Hướng dẫn cache npm chính thức.
• Pipeline Artifacts – Giải thích artifacts không dùng cho cache.
• Azure DevOps Best Practices for Node.js – Bao gồm React.js pipelines.
• Benchmark: Microsoft Docs báo cáo cache npm giảm 80-90% thời gian install (2025 updates).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần ví dụ YAML đầy đủ, hãy hỏi thêm.

🧩 Giải thích nội dung câu hỏi một cách chi tiết

Câu hỏi thuộc dạng series questions trong kỳ thi chứng chỉ (thường là AZ-400: Designing and Implementing Microsoft DevOps Solutions), nơi mỗi câu trình bày một scenario chung và một solution cụ thể. Người dùng cần đánh giá xem solution YAML pipeline có đáp ứng đầy đủ các yêu cầu để test một ứng dụng (app) hay không.

Scenario và yêu cầu cụ thể (dựa trên phiên bản Azure Pipelines mới nhất đến năm 2026):

• 📋 Pipeline phải fail nếu bất kỳ test nào fail: Đảm bảo pipeline dừng và báo lỗi khi có test thất bại.
• 📤 Kết quả test phải được publish lên pipeline: Test results phải được tải lên và hiển thị trong Azure DevOps UI (như Tests tab).
• 🚀 Test phải được trigger (chạy) cho mọi pipeline run, trừ khi pipeline bị cancelled: Tests luôn chạy trừ khi job/pipeline bị hủy thủ công.

Solution được đề xuất (YAML snippet):

- task: PublishTestResults@2
  displayName: 'Publish Unit Test Results'
  condition: not(canceled())
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/junit.xml'
    failTaskOnFailedTests: true
    testRunTitle: 'App Test'

• 🛠️ Phân tích sơ bộ solution: Đây chỉ là task PublishTestResults@2 (task chuẩn của Azure Pipelines để publish kết quả test từ file XML như JUnit). Task này:
  • Có condition: not(canceled()): Chỉ chạy nếu pipeline không bị hủy.
  • failTaskOnFailedTests: true: Làm fail task (và pipeline) nếu test fail.
  • Publish file **/junit.xml với format JUnit.
• Vấn đề cốt lõi: Solution KHÔNG có bất kỳ task nào để CHẠY TESTS (ví dụ: không có DotNetCoreCLI@2 cho .NET tests, Npm@1 cho Node.js, hoặc script chạy dotnet test/ npm test). Nó chỉ giả sử file junit.xml đã tồn tại từ trước (có thể từ step trước), nhưng không "test an app" hay "trigger the test" như yêu cầu.

Kết luận từ phân tích: Solution KHÔNG đáp ứng đầy đủ, vì thiếu phần chạy tests – một phần thiết yếu của "use an Azure Pipelines pipeline to test an app".

✅ Đáp án đúng: [SAI] No

Lý do lựa chọn đáp án đúng (chi tiết bằng tiếng Việt):

• ❌ Solution chỉ xử lý publish và fail trên kết quả test, nhưng KHÔNG trigger/chạy tests. Yêu cầu rõ ràng "to test an app" và "the test ... must be triggered" đòi hỏi phải có task thực thi tests (như chạy unit tests để sinh ra junit.xml).
• ✅ failTaskOnFailedTests: true và condition: not(canceled()) đáp ứng 2/3 yêu cầu (fail pipeline và chạy publish trừ khi cancel), nhưng thiếu test execution → toàn bộ solution fail.
• 🆕 Theo docs Azure Pipelines 2026 (PublishTestResults@2 v2.232+), task này KHÔNG tự chạy tests, chỉ publish file có sẵn. Để meet goal, cần thêm task test trước (ví dụ: - task: DotNetCoreCLI@2 inputs: command: 'test' ...).

📋 Giải thích tất cả các phương án (đúng và sai)

• [ĐÚNG] Yes
  ❌ Sai. Lý do: Solution không có task chạy tests, nên không "test an app" hay "trigger the test" cho mọi run. Chỉ publish nếu file junit.xml tồn tại ngẫu nhiên (không đảm bảo). Không meet đầy đủ 3 yêu cầu, đặc biệt "the test for every pipeline run must be triggered".

• [SAI] No
  ✅ Đúng. Lý do: Đúng như phân tích, thiếu phần execute tests. PublishTestResults@2 chỉ là bước sau (post-test), không thay thế test runner. Pipeline sẽ pass ngay cả khi không có tests chạy, vi phạm yêu cầu trigger tests trừ khi cancelled. Đây là lỗi phổ biến trong Azure Pipelines YAML.

📘 Tài liệu tham khảo (cập nhật đến 2026)

• 🛠️ PublishTestResults@2 docs: Microsoft Learn - PublishTestResults@2 – Xác nhận task chỉ publish, không run tests.
• 🧩 Ví dụ full pipeline test: Azure Pipelines - Run .NET tests – Cần kết hợp DotNetCoreCLI@2 trước Publish.
• 🚀 Conditions và cancellation: Pipeline conditions docs – not(canceled()) chỉ kiểm tra runtime state.
• 📊 AZ-400 exam context: Các series questions thường test hiểu biết về full pipeline flow, không chỉ isolated tasks (xem practice tests trên Microsoft Learn).

Hy vọng phân tích này giúp bạn nắm vững Azure Pipelines! Nếu cần ví dụ YAML đầy đủ, hãy hỏi thêm. 🎯

🧩 Phân tích nội dung câu hỏi

Câu hỏi tập trung vào việc triển khai một giải pháp tài liệu (documentation solution) cho các ứng dụng .NET sử dụng GitHub làm nguồn kiểm soát mã nguồn (source control). Các yêu cầu cụ thể bao gồm:

• 📝 Tài liệu được viết bằng định dạng Markdown và được cập nhật bởi các lập trình viên khi thay đổi mã nguồn.
• 🔄 Mọi thay đổi tài liệu sẽ kích hoạt việc biên dịch lại (recompilation) một trang web tĩnh (static website).
• 🌐 Người dùng truy cập tài liệu qua trang web tĩnh này.
• 💾 Tài liệu lưu trữ trong kho GitHub repository.

Mục tiêu là chọn hai công cụ (tools) để biên dịch (compile) trang web tĩnh từ Markdown. Đây là câu hỏi trắc nghiệm đa lựa chọn (multi-select), mỗi lựa chọn đúng đáng 1 điểm. Giải pháp phải hỗ trợ tự động hóa qua GitHub (ví dụ: GitHub Actions hoặc Pages), tạo site tĩnh từ Markdown, phù hợp với .NET và cập nhật đến phiên bản mới nhất năm 2026 (Jekyll v4.x+, DocFX v3.x+ vẫn là chuẩn mực cho static site generation từ Markdown).

✅ Đáp án đúng và lý do lựa chọn

Hai đáp án đúng là: Jekyll và DocFX.
🛠️ Lý do chính:

• Cả hai công cụ đều là static site generator chuyên biên dịch Markdown thành HTML tĩnh, hỗ trợ tích hợp GitHub (qua GitHub Pages hoặc Actions).
• Chúng kích hoạt rebuild tự động khi Markdown thay đổi (commit/push), phù hợp .NET docs (DocFX tối ưu cho .NET API docs).
• Không cần server động, tiết kiệm chi phí, dễ deploy.
  📘 Tài liệu tham khảo:
• Jekyll: docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll (GitHub Pages chính thức, cập nhật 2026).
• DocFX: dotnet.github.io/docfx (Microsoft Docs, hỗ trợ .NET 9+).

📋 Giải thích chi tiết từng phương án

Dưới đây là phân tích tất cả các lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể:

• Word Press
  ❌ Sai: WordPress là nền tảng CMS động (dynamic), yêu cầu cơ sở dữ liệu và server PHP/MySQL để chạy. Nó không biên dịch Markdown thành site tĩnh tự động từ GitHub, mà tập trung vào nội dung web truyền thống qua giao diện chỉnh sửa. Không phù hợp yêu cầu static website và trigger từ code changes.

• Jekyll
  ✅ Đúng: Jekyll là static site generator mã nguồn mở của GitHub, chuyên chuyển Markdown thành HTML/CSS/JS tĩnh. Tích hợp native với GitHub Pages: push Markdown → auto-rebuild site. Hoàn hảo cho docs dev, hỗ trợ theme, plugin, và .NET projects qua Liquid templating. (Cập nhật: Jekyll 4.3+ hỗ trợ GitHub Actions 2026).

• DocFX
  ✅ Đúng: DocFX là công cụ của Microsoft dành cho documentation .NET, biên dịch Markdown + XML docs thành static website (HTML5). Hỗ trợ GitHub Actions để trigger rebuild khi commit, tạo API reference tự động. Lý tưởng cho .NET apps, xuất site tĩnh deploy lên GitHub Pages/Azure Static Web Apps. (Cập nhật: DocFX 3.5+ tương thích .NET 9/10 năm 2026).

• caret
  ❌ Sai: Caret là trình soạn thảo Markdown đơn giản (Markdown editor) trên mobile/desktop, không phải công cụ biên dịch site. Nó chỉ preview Markdown, không generate static website hay tích hợp GitHub trigger rebuild.

• Medium
  ❌ Sai: Medium là nền tảng blog trực tuyến (publishing platform), nơi viết bài bằng Markdown nhưng nội dung lưu trên cloud của họ, không export static site từ GitHub repo. Không hỗ trợ tự động compile từ code changes hay self-hosted static website.

🧠 Kết luận: Jekyll và DocFX là cặp hoàn hảo cho workflow GitHub + Markdown → Static Site, đặc biệt với .NET. Nếu deploy thực tế, dùng GitHub Actions YAML để automate! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi thuộc dạng series (nhiều câu liên quan cùng scenario), yêu cầu sử dụng Azure Pipelines (YAML) để test một ứng dụng với 3 yêu cầu chính:

• Pipeline phải fail nếu bất kỳ test nào fail (pipeline thất bại khi test thất bại).
• Publish test results lên pipeline (kết quả test phải được công bố).
• Chạy test cho mọi pipeline run, trừ khi pipeline bị cancelled (luôn trigger test trừ khi hủy).

🛠️ Giải pháp đề xuất (Solution):
Chỉ bao gồm một task duy nhất là PublishTestResults@2 trong YAML:

- task: PublishTestResults@2
  displayName: 'Publish Unit Test Results'
  condition: succeededOrFailed()
  inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/junit.xml'
    failTaskOnFailureToPublishResults: true
    testRunTitle: 'App Test'

Task này chỉ publish kết quả test (định dạng JUnit từ file **/junit.xml), chạy kể cả khi pipeline fail (succeededOrFailed()), và fail task nếu không publish được.

❓ Câu hỏi chính: Giải pháp này có đáp ứng mục tiêu (meet the goal) không?

✅ Đáp án đúng: No
Lý do lựa chọn (bằng tiếng Việt):
Giải pháp KHÔNG đáp ứng đầy đủ 3 yêu cầu vì:

• ❌ Thiếu task chạy test: Task PublishTestResults@2 chỉ publish kết quả test đã có sẵn (từ file junit.xml), không chạy test. Yêu cầu cần pipeline fail nếu test fail → phải có task chạy test (như DotNetCoreCLI@2 với test command, hoặc VSTest@2) để sinh kết quả và kiểm soát fail.
• ❌ Không trigger test mọi run: Không có step chạy test, nên test không được thực thi tự động trừ khi cancelled.
• ✅ Chỉ đáp ứng publish results một phần (nếu có file kết quả), nhưng vô nghĩa nếu không chạy test trước.
  Theo docs Azure DevOps (cập nhật 2024-2026), pipeline test đầy đủ cần task chạy test + publish (xem tham khảo bên dưới).

🔍 Giải thích tất cả các phương án (giữ nguyên văn bản gốc)

• [SAI] Yes
  ❌ Phương án này SAI vì giải pháp chỉ có task publish, không chạy test nên không fail pipeline khi test fail, không trigger test mọi run. Task publish chỉ hữu ích sau khi test đã chạy và sinh file junit.xml (thường từ tool như Jest, NUnit). Không đáp ứng 2/3 yêu cầu chính.

• [ĐÚNG] No
  ✅ Phương án này ĐÚNG vì như phân tích trên: thiếu task thực thi test (ví dụ: thêm - task: DotNetCoreCLI@2 với command: 'test' để chạy và sinh results). Pipeline sẽ không fail đúng cách, không publish nếu không có results từ test.

📘 Tài liệu tham khảo (cập nhật mới nhất Azure DevOps 2026)

• PublishTestResults@2 task: Microsoft Docs - PublishTestResults → Xác nhận chỉ publish, không chạy test.
• Ví dụ pipeline test đầy đủ: Microsoft Docs - Run tests in YAML → Cần task test trước publish.
• Conditions: succeededOrFailed() chỉ đảm bảo publish dù fail, nhưng không thay thế chạy test.

💡 Lời khuyên từ Azure DevOps Expert: Để fix, thêm task test như:

- task: DotNetCoreCLI@2
  displayName: 'Run Tests'
  inputs:
    command: 'test'
    arguments: '--logger "junit;LogFilePath=../junit.xml"'
- task: PublishTestResults@2  # Như solution

Pipeline sẽ fail nếu test fail và publish đúng! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc lập kế hoạch tạo một GitHub workflow sử dụng GitHub Actions, nơi các actions cần một secret có kích thước 256 KB. Yêu cầu khuyến nghị giải pháp để lưu trữ và mã hóa secret sao cho:

• Giá trị secret chỉ có thể truy cập bởi workflow này (không chia sẻ rộng rãi).
• Giảm thiểu nỗ lực quản trị hành chính (minimize administrative effort, nghĩa là dễ quản lý, không phức tạp).

🔍 Bối cảnh quan trọng: GitHub Secrets có giới hạn kích thước 48 KB cho mỗi secret ở mức repository hoặc organization (theo tài liệu GitHub cập nhật đến năm 2026). Secret 256 KB vượt quá giới hạn này, nên không thể lưu trực tiếp. Giải pháp phải mã hóa secret lớn (lưu encrypted value trong repository như file thông thường) và lưu khóa giải mã (decryption key) nhỏ gọn vào GitHub Secrets. Điều này đảm bảo tính bảo mật (chỉ workflow của repo truy cập) và dễ quản lý (không cần thiết lập phức tạp ở mức tổ chức).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Encrypt the secret value and store the value in the repository. Store the decryption key in the repository-level GitHub secrets.

Lý do:

• 🛡️ Xử lý kích thước lớn: Mã hóa secret 256 KB và lưu giá trị đã mã hóa trực tiếp trong repository (file .env hoặc tương tự), vì repository không giới hạn kích thước nhỏ như secrets.
• 🔑 Khóa giải mã an toàn: Lưu decryption key (kích thước nhỏ <48 KB) vào repository-level GitHub secrets, chỉ workflows của repository này mới truy cập được, đảm bảo "accessible only to the workflow".
• ⚡ Giảm thiểu admin effort: Quản lý ở mức repository đơn giản, không cần cấu hình organization-wide, phù hợp cho một workflow cụ thể.
• 📈 Tuân thủ best practices GitHub 2026: Hỗ trợ secrets lớn qua sodium encryption (libsodium), tích hợp sẵn trong Actions.

🛠️ Giải thích tất cả các phương án (đúng/sai)

• ❌ Store the secret in the organization-level GitHub secrets.
  Sai vì: Secret 256 KB vượt giới hạn 48 KB của organization secrets. Ngoài ra, organization secrets có thể chia sẻ với nhiều repositories/workflows, vi phạm yêu cầu "accessible only to the workflow" và tăng admin effort (phải quản lý quyền ở mức tổ chức).

• ❌ Store the secret in the repository-level GitHub secrets.
  Sai vì: Vẫn vượt giới hạn 48 KB của repository secrets. Không mã hóa đặc biệt, không giải quyết vấn đề kích thước lớn, dù repo-level giới hạn truy cập tốt hơn org-level.

• ✅ Encrypt the secret value and store the value in the repository. Store the decryption key in the repository-level GitHub secrets.
  Đúng vì: Như giải thích ở trên – kết hợp lưu encrypted data trong repo (không giới hạn size) + key nhỏ ở repo secrets (an toàn, scoped chỉ workflow). Giảm admin effort tối đa.

• ❌ Encrypt the secret value and store the value in the repository. Store the decryption key in the organization-level GitHub secrets.
  Sai vì: Mặc dù xử lý được kích thước, nhưng lưu key ở organization-level làm key accessible cho nhiều repos/workflows ngoài ý muốn, vi phạm "only to the workflow". Tăng admin effort do quản lý quyền tổ chức.

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• GitHub Docs: Encrypted secrets limits – Xác nhận 48 KB limit.
• GitHub Docs: Using large secrets in Actions – Hướng dẫn encrypt + store key.
• GitHub Changelog 2025: Tăng hỗ trợ sodium encryption cho secrets >100 KB qua repo files (không thay đổi limit secrets trực tiếp).

💡 Lời khuyên DevOps: Trong thực tế Azure DevOps/GitHub hybrid, dùng Azure Key Vault cho secrets lớn hơn, nhưng ở đây GitHub-native là tối ưu! 🚀

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc nâng cấp ứng dụng on-premises (App1) hiện đang sử dụng thông tin xác thực lưu trong file cấu hình để truy cập tài nguyên Azure, chuyển sang sử dụng Azure service principal (một ứng dụng đại diện trong Azure Active Directory - Azure AD, nay là Microsoft Entra ID).

Cụ thể:

• App1 cần đăng nhập programmatically (tự động qua code) vào Azure AD để xác thực và ủy quyền truy cập tài nguyên Azure.
• Phương thức phổ biến nhất là sử dụng client credentials flow với client secret (một loại secret key được tạo cho service principal).
• Để thực hiện, ứng dụng cần 3 yếu tố chính từ Azure AD: ứng dụng ID (client ID), client secret, và tenant ID (ID của thư mục Azure AD chứa service principal).
  ✅ Mục tiêu: Đảm bảo App1 có thể lấy access token từ Azure AD mà không cần tương tác người dùng, phù hợp cho ứng dụng server-to-server hoặc on-premises.
  🛠️ Bối cảnh cập nhật 2026: Theo tài liệu Microsoft mới nhất (Microsoft Entra ID), quy trình này không thay đổi cơ bản từ Azure AD v2.0 endpoint, vẫn yêu cầu chính xác 3 thông tin trên cho authentication qua REST API hoặc SDK như Azure CLI, PowerShell, hoặc libraries (ví dụ: MSAL.NET).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: the application ID, a client secret, and the tenant ID

Lý do:

• Đây là bộ 3 thông tin bắt buộc để App1 sử dụng client credentials flow trong Microsoft Entra ID (Azure AD).
  • Application ID (Client ID): Định danh duy nhất của service principal.
  • Client secret: Khóa bí mật để chứng minh quyền sở hữu service principal (tạo trong Azure portal > App registrations).
  • Tenant ID: Định danh thư mục Azure AD (hoặc domain như contoso.onmicrosoft.com) để chỉ định đúng "tenant" chứa service principal.
• Quy trình: Gửi POST request đến https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token với các thông tin này để lấy access token.
  🧩 Không có thông tin nào thừa hoặc thiếu, phù hợp cho app on-premises ký tự động mà không cần subscription ID hay object ID.

📋 Giải thích tất cả các phương án (đúng/sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên yêu cầu chính thức của Microsoft Entra ID authentication:

• ❌ the application ID, a client secret, and the object ID
  Sai vì: Object ID là ID nội bộ của service principal trong Azure AD (xem trong Enterprise Applications), không dùng để authenticate. Nó chỉ dùng cho quản lý (như role assignment), không thay thế tenant ID. Thiếu tenant ID sẽ không xác định được thư mục đúng.

• ❌ a client secret, the object ID, and the tenant ID
  Sai vì: Thiếu application ID (client ID) - yếu tố bắt buộc để định danh service principal trong token request. Object ID không dùng cho sign-in, dẫn đến lỗi "invalid client" hoặc "unauthorized client".

• ✅ the application ID, a client secret, and the tenant ID
  Đúng vì: Đây là bộ chuẩn chính xác theo flow client credentials. Được hỗ trợ đầy đủ trong tất cả SDK Azure (Python, .NET, Java) và REST API. Ví dụ code: az login --service-principal -u <app-id> -p <secret> --tenant <tenant-id>.

• ❌ the application ID, a client secret, and the subscription ID
  Sai vì: Subscription ID dùng để scope tài nguyên (như VM, storage), không dùng cho Azure AD sign-in. Sign-in chỉ cần tenant-level auth; subscription dùng sau khi có token để gọi Azure Resource Manager API.

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• Microsoft Docs chính thức: Create a Microsoft Entra ID service principal (v2.0 endpoint, xác nhận 3 thông tin cần thiết).
• Daemon app & client credentials flow: Microsoft identity platform - Client credentials flow.
• Azure CLI example: az login --service-principal.
  🛠️ Lưu ý: Từ 2023-2026, Microsoft khuyến nghị dùng certificates thay secret cho bảo mật cao hơn, nhưng secret vẫn hỗ trợ đầy đủ cho legacy apps như App1.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc chứng chỉ AZ-400: Designing and Implementing Microsoft DevOps Solutions, tập trung vào Azure Pipelines trong Azure DevOps Services. Nội dung mô tả một Azure DevOps organization (subscription) chứa 5 projects với thông tin từ bảng: Tên project, Số lượng users, Repository, và Visibility.

📋 Bảng dữ liệu từ hình ảnh (đã trích xuất chính xác):

• Project1: 100 users, Project1 public repository, Public
• Project2: 5 users, Project1 public repository, Public
• Project3: 2 users, Private GitHub repository, Private
• Project4: 1,000 users, Public GitHub repository, Public
• Project5: 150 users, Public GitHub repository, Private

🛠️ Vấn đề cốt lõi: Các ứng dụng được build bằng Azure Pipelines (sử dụng Microsoft-hosted agents). Câu hỏi yêu cầu chọn 2 projects đủ điều kiện nhận free parallel jobs (các job song song miễn phí không giới hạn). Đây là tính năng dành cho public projects sử dụng public repositories hosted trong Azure DevOps (Azure Repos public), không áp dụng cho external repos như GitHub dù project public.

✅ Tiêu chí đủ điều kiện (theo docs mới nhất 2024-2026):

• Project phải có Visibility = Public.
• Repository phải là public repository hosted in Azure DevOps (ví dụ: "Project1 public repository" – tức Azure Repos public).
• Không áp dụng cho GitHub repos (dù public), vì chúng được kết nối external qua GitHub integration, và free unlimited parallel jobs chỉ dành riêng cho native Azure Repos public projects trong public projects.
• Lưu ý: Số lượng users không ảnh hưởng trực tiếp đến free parallel jobs cơ bản (unlimited cho public Azure Repos), mà chỉ liên quan đến request thêm grants cho open source (≤5 users).

📘 Tài liệu tham khảo:

• Microsoft Docs: Hosted parallel jobs (xác nhận unlimited free cho public projects với Azure Repos).
• Azure DevOps Pricing (Public projects: Unlimited free Microsoft-hosted parallel jobs – ưu tiên native repos).
• Open source free grants (thêm nếu ≤5 users, nhưng không phải tiêu chí chính ở đây).

✅ Đáp án đúng: Project1 và Project2

Lý do: Cả hai projects đều có Visibility = Public và sử dụng Project1 public repository (Azure Repos public hosted trong Azure DevOps). Chúng đủ điều kiện nhận unlimited free Microsoft-hosted parallel jobs khi chạy Azure Pipelines. Đây là lợi ích đặc biệt cho public projects với native public repos, giúp build apps miễn phí không giới hạn song song.

🧩 Giải thích tất cả các phương án (đúng/sai)

• ✅ Project1 (Đúng):
  Project này có 100 users, repository "Project1 public repository" (Azure Repos public), visibility Public. Đủ tiêu chí nhận free parallel jobs không giới hạn vì sử dụng native public repo trong Azure DevOps.

• ✅ Project2 (Đúng):
  Project này có 5 users, repository "Project1 public repository" (chia sẻ Azure Repos public từ Project1), visibility Public. Hoàn toàn đủ điều kiện, tương tự Project1. (Bonus: Với ≤5 users, còn có thể request thêm open source grants nếu cần).

• ❌ Project3 (Sai):
  Project này có 2 users, repository "Private GitHub repository", visibility Private. Không đủ vì cả project và repo đều private – chỉ được 1 free parallel job cơ bản cho private projects, không unlimited.

• ❌ Project4 (Sai):
  Project này có 1,000 users, repository "Public GitHub repository", visibility Public. Mặc dù visibility public, nhưng repo là external GitHub (không phải Azure Repos native), nên không được unlimited free parallel jobs – áp dụng tier private-like (1 free job + minutes giới hạn).

• ❌ Project5 (Sai):
  Project này có 150 users, repository "Public GitHub repository", visibility Private. Project private + external GitHub repo → Không đủ bất kỳ free unlimited nào, chỉ 1 free parallel job cơ bản.